HIPAA on a CPaaS — how Devotel Orbit handles HIPAA mode, the Business Associate Agreement (BAA), and PHI access controls

Why "HIPAA-compliant texting" is a posture, not a product feature

HIPAA on a CPaaS is a set of tenant-owned controls a communications platform makes available — an opt-in HIPAA mode, a Business Associate Agreement (BAA) lifecycle, PHI access logging, role-based access, and retention — not a badge the platform confers. HIPAA (the US Health Insurance Portability and Accountability Act) applies to use, not to accounts: a platform cannot decide that your traffic carries Protected Health Information (PHI), and no vendor configuration alone makes an organization's messaging "HIPAA-compliant." What a platform can provide is the control surface a covered entity or business associate configures, and the evidence trail its compliance program needs.

Organizations in healthcare run appointment reminders, care-team coordination, patient intake, and billing notifications over SMS and voice at volume. The procurement question that follows — "can we run PHI on this platform?" — resolves into a short list of specific controls: a BAA on file, encrypted storage, an access log on every PHI read, a retention clock, and role-based access. On Devotel Orbit each of these is a tenant-owned control: you decide that PHI is in scope, you execute the agreement, you set the retention window. The platform supplies the machinery and the audit evidence; the legal determination stays yours.

Term-level definitions already exist for the individual vocabulary — see the HIPAA glossary entry; this guide is the long-form background that connects the pieces before you configure any of them. It complements the telecom-side regulatory guide in this library (TCPA, 10DLC, STIR/SHAKEN, and opt-out), which covers the deliverability regulations; HIPAA sits on the data-handling side.

The tenant-owned posture — and the one platform-wide guard

Compliance posture on Orbit is deliberately the operator's to configure. HIPAA mode is an opt-in, per-organization toggle: off by default, switched on by a workspace owner once a BAA is on file, and never mandated by the platform. Every HIPAA control — the BAA gates, retention, role scoping — is a tenant control you opt into and own.

There is exactly one guard Orbit enforces platform-wide rather than delegating to tenant configuration: the US federal TCPA 8 am–9 pm dialing window for campaign and dialer voice traffic, because the statutory per-call penalty is not a tenant-decidable risk. Everything else, HIPAA included, is tenant-owned. For how that posture reads across every gate, see the send-gates reference and the compliance posture FAQ.

What HIPAA mode turns on

Enabling HIPAA mode activates five control families, documented in the HIPAA compliance controls reference:

1. Encryption at rest — PHI encrypted with Google-managed AES-256, covered below.
2. Access controls — message-content reads governed by workspace role and API-key scope, with every read recorded.
3. PHI audit logging — every access to PHI-containing data generates an append-only log entry.
4. Data retention — automated deletion after your configured retention period.
5. BAA tracking — the Business Associate Agreement status lifecycle that gates everything above.

PUT /api/v1/settings/hipaa flips the toggle (owner-only; disabling is a destructive, two-step re-auth flow). Enabling is refused with a 403 until the BAA lifecycle below reports executed.

The BAA lifecycle: four states of baa_status

A Business Associate Agreement is the contract between a covered entity and a vendor (the "business associate") that handles its PHI. Orbit tracks the agreement per organization on a canonical status with four states, from the BAA flow guide:

• `not_required` — the organization has attested (or defaulted) that no PHI is in scope. The default for every new organization.
• `pending` — PHI is in scope and the BAA is awaiting execution. The execute form opens in this state.
• `executed` — a BAA has been signed and is within its one-year term. This is the only state that satisfies the HIPAA-enable and PHI-send gates.
• `expired` — an executed BAA has passed its term. PHI sends gate again until you re-execute; re-execution opens 60 days before expiry.

The flow starts with an attestation, because the platform never assumes your workspace handles PHI: an owner (or admin) attests that PHI is in scope, which moves the organization to pending and opens the execute step. Both the require and decline attestations write an audit-chain entry naming the actor — the attestation itself is a recorded legal event, not a setting toggle.

The e-sign pipeline

BAA execution runs over the /api/v1/compliance/baa endpoints — the same flow the dashboard's Settings → Compliance → BAA page drives:

1. Preview the template — GET /api/v1/compliance/baa/template renders the agreement with your organization's legal name filled in, before anyone signs.
2. Execute — POST /api/v1/compliance/baa/execute is owner-only: the signer re-types their legal name into typed_attestation, and the server requires it to match signer_name exactly. A mismatch is rejected, which also blocks blank-form auto-submits.
3. Record — on success the server renders the document with signer details and timestamps, stores the executed PDF, stamps the organization executed with the signer, template version, execution timestamp, and term expiry, and appends the execution entry to the organization's audit log with the signature method (type_the_name) — the append-only audit chain is the legal evidence, not the status field.
4. Download — once executed, any owner or admin fetches the executed copy for records or an external audit; each request returns a fresh URL valid for 24 hours.

Execution is rate-limited to a handful of requests per minute; it is a deliberate legal act, not a scripted loop.

Roles: who can do what

HIPAA controls are assigned to roles so each surface maps to the people in your workspace. The matrix, per the HIPAA reference:

The billing role is confined to financial surfaces and receives 403 on message-content endpoints. Every other role, including viewer, can read message content — and each access is written to the PHI access log.

PHI access logging: the evidence trail

Every access to PHI-containing data generates an audit log entry structured as { id, userId, resource, reason, accessedAt }. The log:

• Is append-only and cannot be modified or deleted.
• Retains up to 10,000 entries per organization, with oldest entries rotated.
• Is accessible to owner and admin roles via the dashboard or API (GET /api/v1/settings/hipaa/phi-access-log).
• Can be exported for external compliance audits.

Reason codes on the entry (treatment, payment, operations, legal, support) describe the access purpose where an operator supplies one explicitly; dashboard and API reads record an automatic read reason. To meet the HIPAA minimum necessary standard, provision workspace membership and API-key scopes so only staff who need PHI can reach the message-read endpoints.

Encryption at rest: what "AES-256" actually means here

All PHI — message body, media_url, and metadata — is encrypted at rest using Google-managed AES-256 keys (the Cloud SQL default at-rest encryption), with TLS 1.3 in transit. Keys are managed and rotated by Google Cloud.

One clarification matters in a procurement review: Orbit does not perform per-organization application-layer encryption of message bodies. Confidentiality at rest relies on Google Cloud's transparent AES-256 rather than an application-layer cipher, and the encryption_algorithm field in the GET /settings/hipaa response is for reporting only — it does not indicate that message bodies are individually encrypted at the application layer.

Data retention: 30–3,650 days, your choice

When HIPAA mode is active, retention is enforced automatically:

• Default retention period: 365 days; configurable from 30 to 3,650 days.
• Scope: message content, call recordings, and media attachments.
• Mechanism: an automated background job scans for expired records and deletes them.
• Exceptions: audit logs and PHI access logs are retained independently of the retention policy — the evidence trail outlives the content it describes.

Retention is configured at Settings → Compliance → HIPAA → Data Retention or via PUT /api/v1/settings/hipaa.

Failure modes: fail-open by default, one fail-closed backstop

Across Orbit's compliance surface, gates you opt into fail open on unverifiable input — the platform never blocks your traffic on a check it cannot evaluate. The BAA gate is the designed exception: when your organization attests PHI is in scope, the send path fails closed and a blocked send returns 422 HIPAA_BAA_REQUIRED with a reason of pending, expired, or not_signed; a gate that cannot verify BAA status (500 HIPAA_BAA_GATE_DB_FAIL) keeps sends blocked and logs the failure rather than letting a PHI transmission through unchecked. Expiry is re-derived from the execution timestamp at send time, so an aged-out BAA blocks again even before the daily expiry check runs.

Where a tenant gate blocks a recipient on your own attestation — the TCPA known-litigator list is the example — a verified consent record bypasses the block, and every such bypass writes an audit event so the exception is itself evidence. That fail-open-default, fail-closed-for-BAA asymmetry is summarized gate-by-gate in the compliance posture FAQ.

Where this lands operationally

Nothing above is abstract for an Orbit operator: HIPAA mode is a toggle in Settings → Compliance, the BAA flow lives in Settings → Compliance → BAA, and the roles matrix binds at workspace membership. Work through the step-by-step mechanics in the docs:

• HIPAA compliance controls — the full control reference this page summarizes.
• Business Associate Agreement (BAA) flow — the status lifecycle, e-sign endpoints, and audit chain.
• Send gates — the HIPAA BAA block — the send-time verdict and fail-closed behaviour.
• HIPAA onboarding: from BAA to audit-ready — the runbook sequence.

And for the telecom-side regulations that apply to the same traffic, see the sister explainer in this library: TCPA, 10DLC, STIR/SHAKEN, and opt-out.

Frequently asked questions

Is HIPAA mode on by default on Devotel Orbit?

No — HIPAA mode is an opt-in, per-organization toggle. It stays off until a workspace owner enables it, and enabling is refused with a 403 until the organization's BAA lifecycle reports executed. Enabling is a single call that tightens the workspace's posture; disabling is destructive and requires a two-step re-authentication challenge.

What is a Business Associate Agreement and why does HIPAA mode require one?

A BAA is the contract between a HIPAA covered entity and a vendor (the "business associate") that processes its PHI. HIPAA mode is gated on an executed BAA because the agreement records the platform's obligations before PHI-specific controls activate. Orbit tracks the agreement on a four-state baa_status lifecycle — not_required, pending, executed, expired — and only executed within its one-year term satisfies the gate.

Which roles in my workspace can read message content or view the PHI access log?

Access is role-based: owner and admin can both read message content and view the PHI access log; developer and viewer can read message content (each read is logged) but cannot see the access log; billing is confined to financial surfaces and cannot read message content or the log. Only an owner can execute a BAA or toggle HIPAA mode.

How is PHI encrypted at rest?

All database-stored PHI — message bodies, media URLs, and metadata — is encrypted at rest with Google-managed AES-256 on Cloud SQL, with TLS 1.3 in transit. This is transparent infrastructure-level encryption, not per-organization application-layer encryption; the encryption_algorithm field on the HIPAA settings response is a reporting field, not evidence of an application-layer cipher.

Can we set our own data retention window for PHI?

Yes. The default retention period is 365 days, configurable from 30 to 3,650 days, and an automated background job deletes expired message content, call recordings, and media attachments. Audit and PHI access logs are retained independently of that window so the evidence trail survives the content it describes.

Sources and further reading

• HIPAA compliance controls for healthcare messaging: the full control reference this explainer summarizes.
• Business Associate Agreement (BAA) flow: the four-state lifecycle, the e-sign endpoints, and the audit chain.
• Send gates: the HIPAA-BAA send-time verdict and its fail-closed behaviour.
• Data Processing Agreement: the processing-records catalog the PHI access log rolls into.
• HHS — Health Information Privacy: the US Department of Health and Human Services' HIPAA portal.