Skip to main content
Back to blog

HIPAA-ready CPaaS — the buyer's checklist for messaging, voice, and AI agents

A runnable checklist for evaluating a CPaaS vendor on HIPAA — where PHI actually lands (SMS callbacks, voice transcripts, agent assist), what a BAA must cover, and the tenant-owned controls to configure on Devotel Orbit once it is signed.

Orbit Editorial Team

Quick answer: HIPAA on a communications platform is not a certificate you buy — it is a scope agreement plus a set of controls you operate. PHI enters a CPaaS the moment a patient reply, a call recording, a transcript, or an AI-assist summary touches the provider, and "we are HIPAA-compliant" answers none of that. This checklist walks the PHI risk surface per channel, the four things a Business Associate Agreement must cover, the tenant-owned controls to configure on Devotel Orbit (HIPAA mode, the PHI-audience registry, the campaign precheck, PHI access-log export, transcript redaction), and the questions to put in any vendor's questionnaire — including ours.

A healthcare procurement team evaluating a messaging or voice platform usually starts with one question: "Do you sign a BAA?" That question clears a vendor for maybe ten percent of the review. The rest is where PHI lands once the contract says it can — and a vendor that cannot enumerate those surfaces is telling you their compliance answer is a sales answer.

The division of responsibility stays explicit throughout. Devotel Orbit is the conduit; the posture decisions — which audiences hold PHI, what retention window you keep, who may read message content — are tenant-owned and yours to configure.

1) HIPAA's CPaaS risk surface — where PHI actually lands

Protected health information is any health-related data tied to an identifiable person. On a communications platform, it arrives through five surfaces, most of them inbound and unprompted:

  • Inbound SMS, WhatsApp, and RCS replies. A patient who answers your appointment reminder with "confirm my cardiology follow-up with Dr. Patel" has put PHI into your messaging store. Providers process inbound bodies as received; the question is what safeguards wrap them afterward.
  • Delivery-status and callback webhooks. Status callbacks (message.delivered, message.failed) themselves carry identifiers, not bodies — but a callback to your system that embeds a patient name or chart number in the URL or metadata is PHI in flight. Audit what your own webhook payloads carry, channel by channel.
  • Voice recordings and transcripts. A recorded care call is PHI end to end, and the transcript inherits everything the caller said — including the numbers a raw transcript would preserve word for word. On Orbit, transcript redaction masks sensitive numerics at the speech-to-text source, before any transcript text is stored or logged, and it is on by default. A vendor whose redaction is optional or off has a PHI leak at the transcript layer before you even start.
  • Agent-assist and AI-agent summaries. When a voice agent or a live-assist surface summarizes a call, the summary is a new PHI derivative. The scrub has to happen at the model output, before the summary is written — and you should ask which roles can read it afterward.
  • Email and fax surfaces. Email replies and fax payloads are the same inbound-body problem on a different transport. If a vendor handles fax for healthcare, the same question set applies.

The vendor's job is to map these surfaces and wrap them with the right defaults — stored-surface access logging, source-level transcript redaction, enforced retention. Your job is to keep the PHI question accurate per channel and to configure the controls below. "We just encrypt everything" is deflection; the surface map is the answer.

2) What the BAA must actually cover

The Business Associate Agreement is the legal scope document that lets a vendor handle PHI on your behalf. Review four clauses before you sign; a BAA that misses one of them leaves a channel uncovered:

  • Storage. Where PHI physically rests — which database, which region, which encryption at rest. On Orbit that is Google Cloud's AES-256 with TLS 1.3 in transit, documented per surface. The BAA should name the storage layer, not gesture at "secure infrastructure."
  • Subprocessors. Every downstream processor that can touch PHI must be under a BAA chain. On the AI voice path, that means the speech-to-text and (if applicable) LLM legs. Orbit runs its voice stack itself — Devotel's speech-to-text subprocessor handles transcription with redaction at the source — so the subprocessor list is short by construction. Ask any vendor for the full chain; each unnamed leg is an unvetted path for PHI.
  • Retention. The deletion clock for message content, call recordings, and media attachments — and what is exempt. On Orbit, HIPAA mode enforces a configurable window (365 days default, 30–3,650 days range) with audit logs retained independently of the content window. If the BAA is silent on retention, the contract assumes data lives forever.
  • Audit and breach. Which accesses get logged, who can export the log, and the breach-notification clock the vendor commits to. Orbit's PHI access log is append-only (up to 10,000 entries per organization) and exportable; breach notification follows the HIPAA Breach Notification Rule timeline. Ask for the export path in writing.

Execute the agreement before PHI flows. On Orbit the lifecycle is explicit: not_required → pending (you attest PHI is in scope) → executed (signed, in-term, one-year term) → expired. HIPAA mode cannot be enabled, and PHI-designated sends are refused, until the status is executed — the platform fails closed on this one, and a reviewer should hear that as a feature.

3) The tenant-owned controls you should configure

Once the BAA is executed, the posture is still yours. These are the controls a healthcare tenant should turn on deliberately, and each maps to a checklist row you can verify in the vendor's product — Devotel Orbit or anyone else's:

  • HIPAA mode. A per-organization toggle under Settings → Compliance → HIPAA that activates enforced retention, the PHI access log, and the BAA gate. Enabling is a single call (no re-auth challenge, because it only tightens posture); disabling is a two-step flow with a fresh re-auth token, so a stolen browser session cannot silently lower the posture of a workspace that holds PHI.
  • PHI-adjacent audience registry. An organization-level register of the contact lists and segments whose members carry PHI — for example, a list of patients opted into treatment outreach. Designation belongs on the audience, not the campaign, because the source data is what makes it PHI-adjacent. PUT /api/v1/compliance/hipaa/phi-audiences replaces the registry atomically (up to 500 ids), and the change is audit-logged.
  • Campaign launch precheck. Before a campaign targeting a designated audience can launch, the precheck verifies the BAA is executed and in-term; otherwise the launch is refused at the campaign level instead of failing thousands of per-recipient sends. If the compliance state cannot be read, it fails closed rather than admitting the audience. The campaign wizard also shows an advisory warning when you pick a designated audience — the hard gate lives at launch, not at the picker.
  • PHI access-log export. Every read of message content is recorded with the accessor and a reason category (treatment, payment, operations, legal, support). Owners and admins paginate the log via GET /settings/hipaa/phi-access-log and export it for outside auditors. One limitation to internalize honestly: the log records access; it does not confine reads to a subset of roles beyond excluding the billing role, so meet the minimum-necessary standard through workspace membership and API-key scopes.
  • Redaction by default. Live captions, call transcripts, and post-call transcripts are redacted at the speech-to-text source — sensitive numerics and similar are masked before text is stored. It is on by default and cannot be toggled per workspace; confirm its status in writing as part of your BAA if your deployment handles PHI, and treat any vendor who lets a single tenant flip it off as a deployment-level risk.

The shared-responsibility line to hand your reviewers: Devotel owns infrastructure security, encryption, access-control enforcement, PHI logging, transcript redaction, and the BAA machinery. You own workforce training, the minimum-necessary standard, patient consent, and — on Orbit — confirming redaction is enabled before PHI flows.

4) The buyer checklist — questions to put in any vendor's questionnaire

Ten questions, in the order a procurement review should ask them:

  1. Where does PHI physically rest — which storage layer, which region, which encryption standard at rest and in transit?
  2. Which subprocessors can touch PHI, and is each under a BAA or equivalent agreement? Name them.
  3. Is the BAA available on self-serve, what is its term, and does anything in the platform enforce that it is signed before PHI-designated traffic flows?
  4. Is the protective mode per-organization or per-workspace, and what exactly does enabling it change?
  5. What happens when someone disables the mode — is there a re-authentication step, and is it audit-logged?
  6. Can we designate which audiences carry PHI, and does campaign launch enforce the BAA against those designations?
  7. Is every PHI read logged, with reason categories, and can we export the log without filing a support ticket?
  8. Is transcript and agent-summary redaction on by default, and if it can be turned off, who can turn it off and at what scope?
  9. What retention window applies to message bodies, recordings, and media — is it enforced, per-channel configurable, and what happens at expiry?
  10. What is your breach-notification commitment, and which of these controls are tenant-owned versus platform-owned — stated explicitly?

A vendor that answers #10 crisply is usually answering the other nine honestly. A vendor that describes compliance as a platform property rather than a scoped agreement plus configured controls has not run this review before.

The full control reference — API endpoints, roles per endpoint, the BAA lifecycle states, redaction scope, the shared-responsibility table — is the public HIPAA compliance page, and it pairs with the send-gates reference for how the BAA gate behaves at message time.

Frequently asked questions

Does a signed BAA make us HIPAA compliant?

No. The BAA is the scope agreement that lets the vendor handle PHI on your behalf; compliance is the posture you operate afterward — designated audiences, minimum-necessary access, retention windows, exported logs. The contract enables the work; it does not do it.

Is transcript redaction enough for voice PHI?

Redaction masks sensitive numerics at the source, before storage. It does not redact free-text PHI (a patient's name, a diagnosis), and the underlying question — who may read the transcript and how long it is retained — is still yours to answer with access control and the retention window. Treat redaction as a leak-stop at the transcript layer, not as voice-PHI policy.

What if our BAA expires mid-campaign?

On Orbit, an expired BAA flips baa_status and blocks both HIPAA mode enablement and PHI-designated sends — and the campaign launch precheck refuses designated audiences the same way. Track days_until_expiry on GET /compliance/baa/ and re-execute before the one-year term runs out.

Can we test the gates before moving real patient traffic?

Yes. Designate a test list in the PHI-audience registry, attempt a campaign launch against it with an unexecuted BAA, and expect a refusal (HTTP 422). That fire drill mirrors the one from the production checklist — same gate, same fail-closed behavior.

HIPAA-ready CPaaS — the buyer's checklist for messaging, voice, and AI agents — Orbit by Devotel