The BAA lifecycle on a CPaaS — a healthcare walkthrough from signature to PHI audit row

Quick answer: A Business Associate Agreement on a communications platform is a scope contract — it designates the provider as your business associate for the PHI-adjacent work your traffic creates. On Devotel Orbit the lifecycle is explicit and enforced: attest that PHI is in scope, an owner executes the BAA with a type-the-name e-signature, then the workspace-owner HIPAA-mode toggle opens. Until the status reads executed, PHI-designated sends are refused with 422 HIPAA_BAA_REQUIRED and the toggle returns a 403. Every access to PHI afterward writes an audit row with a reason code, and that row is one entry in the processing-records catalog under your Data Processing Agreement. Nothing here claims the platform "is HIPAA compliant" as a product property — what follows is the opt-in technology controls and how you operate them.

This is the narrative walkthrough; the reference material lives in the docs — the BAA flow, HIPAA compliance controls, and PHI-adjacent audience designations. If you are still in procurement, the HIPAA buyer checklist is the evaluation half; this post is the operations half.

What a BAA in CPaaS actually covers

HIPAA attaches the moment health-related data tied to an identifiable person flows through your communications provider. A CPaaS is not in the room when you decide that an appointment reminder, a care call recording, or a treatment-outreach list counts as PHI — but the agreement has to exist before the platform may handle any of it on your behalf. That designation is what a BAA records: the provider acts as your business associate for the storage, transport, and logging your traffic creates.

Three properties of the agreement are worth holding separately, because buyers routinely collapse them:

• Scope, not posture. The BAA names which processing is permitted — message bodies, recordings, transcripts, media — and the obligations that follow. It does not make any workflow compliant; it makes the workflow covered. The posture is the controls you configure after signing.
• Business-associate designation is per-relationship. Your BAA with Devotel covers Devotel's side of the wire. Your own covered-entity duties — patient consent, minimum-necessary access, workforce training — do not transfer. The BAA never absorbs them.
• The term is finite. An executed BAA on Orbit carries a one-year term, and the platform tracks the countdown. Section two walks the expiry mechanics; the point here is that "signed a BAA once" is not a terminal state — it is a renewable one.

The companion docs page lays out the four lifecycle states the rest of this post runs on (BAA flow): not_required (the default — no PHI attested), pending (PHI attested, awaiting signature), executed (signed and in-term), and expired (past term — gating resumes).

The platform BAA lifecycle, end to end

The lifecycle on Devotel Orbit is deliberately circuit-breaker-shaped: an attestation opens the signature flow, the signature opens the toggle, and the toggle activates the safeguards. Here is the full circuit.

Step one — attest that PHI is in scope. The flow starts with your own determination, not Devotel's. An owner or admin calls POST /api/v1/compliance/baa/require (or uses the "Start handling PHI" action under Settings → Compliance → BAA), which sets the HIPAA-required flag and moves the organization from not_required to pending. The attestation is a recorded legal event — it appends an entry to the audit log naming the actor and the reason, so the decision to bring PHI into scope is on the chain, not just in someone's memory.

Step two — preview, then execute the BAA. Execution is owner-only, because a click-wrap signature binds the organization. The signer can preview the rendered agreement first (GET /api/v1/compliance/baa/template fills in your organization's legal name), then execute with a type-the-name e-signature: the typed attestation must match the signer's legal name exactly, or the request is rejected. On success the platform renders the finalized agreement, stores the executed copy, stamps the organization executed with the signer, template version, execution timestamp, and term expiry — and writes the execution entry to the audit log. Any owner or admin can then download the executed copy; the download URL is valid for 24 hours.

Step three — the workspace-owner HIPAA-mode toggle opens. HIPAA mode is a per-organization toggle under Settings → Compliance → HIPAA, and only the workspace owner can switch it. Until the BAA status is executed, enabling it returns 403. That ordering is deliberate: the agreement precedes the controls. Once the toggle is on, the safeguard set activates:

• Encryption at rest — PHI is encrypted at rest with Google-managed AES-256 (the Cloud SQL default), with TLS 1.3 in transit.
• Role-restricted PHI access — message-content reads are confined by role, with the billing role locked out of message surfaces entirely (the full matrix is in section three).
• Audit logging with reason codes — every PHI access writes an append-only row carrying the accessor, the accessed resource, and a reason category.
• Retention with deletion — a configurable retention window (365 days by default, 30–3,650 days) is enforced by an automated deletion job over message content, call recordings, and media attachments. Audit logs are exempt — the access evidence outlives the content.
• BAA status tracking — the platform tracks the one-year term; within 60 days of expiry the dashboard shows a re-execute banner, and past expiry the status reads expired and the gates close again until you re-execute.

While any of that is missing, the gates are closed. While PHI is attested and no in-term BAA is on file, outbound sends that touch PHI are rejected with 422 HIPAA_BAA_REQUIRED. Campaigns get the same verdict at launch time against designated audiences, so a PHI cohort is refused at the campaign level instead of failing recipient-by-recipient. And if the compliance state cannot be read at all, the gate fails closed rather than admitting the traffic. Executing the BAA lifts one gate and opens the other (the toggle); it changes nothing else about your data.

One more property to internalize early: the BAA gates the workspace-level controls, and the PHI-adjacent audience registry gates campaigns. The registry — GET/PUT /api/v1/compliance/hipaa/phi-audiences — is your organization's own designation of which contact lists and segments carry PHI (an EHR export, a treatment-outreach opt-in list). The campaign wizard warns when you pick a designated audience, and the launch precheck enforces the BAA gate at launch. Neither designation is made by the platform; both are your attestation, enforced on your behalf. Reference: PHI-adjacent audience designations.

The roles-versus-surface matrix for PHI access

HIPAA's minimum-necessary standard is met by knowing exactly who can reach each surface. On Orbit the assignment is explicit, so map your staff to roles deliberately:

Two rows deserve attention. The billing role is confined to financial surfaces and receives a 403 on message-content endpoints — a hard partition between the people who see money and the people who see PHI. And every role that can read message content is logged doing so: the read endpoint records an automatic read reason, and where an operator supplies a reason explicitly the categories are treatment, payment, operations, legal, and support. The disable path deserves the same attention as the enable path: disabling HIPAA mode is a destructive transition on a workspace that may hold PHI, so it requires a short-lived re-auth challenge token — a stolen browser session cannot silently lower the posture.

Why "tenant-owned" is the load-bearing frame

Every control in this walkthrough is opt-in, and that is the frame, not a caveat. HIPAA mode is off by default and comes on only when your workspace owner turns it on. The PHI-audience registry is empty until you fill it. The retention window is your number within the allowed range. The PHI-in-scope attestation is your legal determination, recorded as such when you make it.

The alternative design — a platform that declares itself "HIPAA compliant" as a property of the product — inverts the responsibility HIPAA actually assigns. Compliance attaches to use: the same platform carries a reminder about a flu shot for one tenant and a cardiology follow-up for another, and only the tenant can tell the difference. Devotel supplies the machinery — the e-sign pipeline, the gates, the audit chain, the retention job — and never decides your scope. When a marketing page on any vendor's site says "HIPAA compliant," read it as "we operate tenant-owned controls," and check whether the controls actually exist as product rather than as adjectives.

From PHI audit row to DPA processing-records catalog

The last leg of the lifecycle is the one an external auditor reads. Every PHI access — a message-content read, a transcript view, a recording fetch — appends a row to the PHI access log: the accessor, the resource, the reason category, the timestamp. The log is append-only, holds up to 10,000 entries per organization with the oldest rotated out, and is readable by owner and admin over the dashboard or GET /api/v1/settings/hipaa/phi-access-log. Export it when your auditor asks; no support ticket involved.

That row is not an isolated artifact. It is one entry in the processing-records catalog your organization maintains under the Data Processing Agreement — the DPA page is the upstream catalog of those records and of the attestations that bind them. The BAA execution event, the PHI-in-scope attestation, the audience designations, the access rows: each is a recorded legal event feeding the same processing record. That framing matters for HIPAA's documentation duty — Article 30-style processing records under the DPA umbrella are built from exactly these rows, hand-assembled for you rather than hand-assembled by you.

Your healthcare-buyer checklist pointer

If you are still evaluating rather than operating: the companion HIPAA buyer checklist condenses this walkthrough into the ten questions to put in any vendor's questionnaire — storage layer, subprocessor chain, BAA self-serve, per-organization posture, disable path, audience designation, log export, redaction defaults, retention windows, and which controls are tenant-owned versus platform-owned. Bring section two of this post as the answer key; a vendor that cannot walk the lifecycle in order has not shipped it.

Frequently asked questions

Does an executed BAA make our organization HIPAA compliant?

No — and no vendor's agreement can. The BAA designates Devotel as your business associate for the covered processing; the compliance posture is what you operate afterward — designated audiences, minimum-necessary access, retention windows, exported logs. The contract enables the work; it does not do it.

What happens the day our BAA term expires?

The status flips to expired, PHI-designated sends start refusing with HIPAA_BAA_REQUIRED again, and the dashboard's re-execute banner — which has been showing for the prior 60 days — becomes your queue to re-run the same owner-only execute flow. Nothing is lost: the prior executed copy and its audit history are preserved.

Can an admin sign the BAA to unblock a stuck send?

No. Execution and revert are owner-only because they bind or unwind a legal agreement. An admin can attest PHI in scope, read the state, preview the template, and download the executed copy — but the signature itself waits for an owner.

Where do the docs for each step live?

The full endpoint reference for the lifecycle is the BAA flow page; the control set the toggle activates is on the HIPAA compliance page; and the audience designations the campaign precheck enforces are on the PHI-adjacent audiences page. This post is the narrative; those pages are the contract.

The takeaway

A BAA on a CPaaS is a renewable scope contract wrapped in enforceable machinery: attest, execute, toggle, operate, re-execute. The platform's part is the gates and the evidence — fail-closed sends, an append-only audit chain, a checksum of who signed what when. Your part is the determination that PHI is in scope and the posture you run after the signature. The controls are opt-in on purpose; the journey above is the whole loop.