Skip to main content

​
Assembling a HIPAA Posture End to End

The Compliance group documents each HIPAA control on its own page: the BAA lifecycle, the HIPAA mode toggle, the PHI-adjacent audience registry, retention, the inbox AI privacy gates, and AI-turn verbatim audit. This guide is the sequence across all of them — the order a tenant actually assembles a HIPAA posture in, and what each step leaves behind as evidence. It extends Posture D from the posture map into a full walkthrough.
This page describes Orbit’s platform controls. It is not legal advice. Whether HIPAA applies to you — covered entity or business associate, what counts as PHI in your workflows, whether your retention window satisfies your state law — depends on your processing. Confirm with qualified counsel.

​
The tenant-owned framing

Read this first, because it shapes everything below. Orbit’s HIPAA surface follows the same model as the rest of the compliance map (posture overview):
  • Every control here defaults open or off. A new workspace has no BAA, HIPAA mode off, no designated PHI audiences, no retention window configured, the inbox AI gates on, and verbatim AI audit off. Nothing on this page is mandated, and nothing gates sending by itself. You assemble the posture; the platform enforces what you set, not a posture it picked for you.
  • Orbit is the conduit and the ledger. It carries your PHI-bearing traffic, enforces the gates you configure, and keeps the auditable record — the PHI access log, the BAA audit chain, the binder generation history.
  • The binder reflects what you did. An unexecuted BAA exports as an open item; an unset retention window exports as unset. Assemble the posture first; export second.

​
Section 1 — The HIPAA surface map

One row per obligation a regulated-healthcare sender usually has to answer, mapped to the Orbit control that holds it and the deep page that documents it. Two adjacent controls round out the map:
  • Voice data residency decides where call recordings and transcripts physically live — a residency choice you document, not a gate (Voice data residency).
  • Transcript redaction stays on by default for voice and video — confirm it in writing before you store PHI (HIPAA controls).

​
Section 2 — A worked sequence for a PHI-bearing tenant

A concrete run for a healthcare workspace moving from “we handle PHI” to “we can show an audit trail.” Each step names what you do and what evidence it leaves behind.

​
1. Execute the BAA

Nothing else unblocks until the Business Associate Agreement is executed. Two gates read BAA status directly: HIPAA mode refuses to enable with 403 while baa_status is not executed, and any PHI send is rejected with 422 HIPAA_BAA_REQUIRED. Execute it through the dashboard’s Compliance → BAA pane, or over the API:
Evidence left behind: the canonical executed BAA PDF, the compliance.baa.executed audit-chain row, and the GET /api/v1/compliance/baa status a buyer’s procurement review can read. See BAA.

​
2. Enable HIPAA mode

With the BAA executed, flip the per-organization HIPAA flag. This activates the enhanced control set — PHI access logging, enforced retention, and BAA tracking — in one call, and no re-authentication challenge is required (only disabling needs one).
Evidence left behind: GET /api/v1/settings/hipaa returns enabled: true — the configuration the HIPAA evidence binder reads back. See HIPAA controls.

​
3. Restrict roles and API scopes to minimum necessary

HIPAA’s minimum necessary standard is your responsibility — it sits on the customer side of the shared-responsibility table. Orbit’s controls are coarse, so provision for it honestly:
  • Assign the billing role to staff who only need financial surfaces. Billing members receive 403 on message-content endpoints.
  • Mint API keys with only the scopes an integration needs; grant messages:read only to services that genuinely read PHI-bearing message content.
Every permitted read lands in the PHI access log, so this step is what makes that log meaningful. See HIPAA controls.

​
4. Set your retention window

Set the deletion window before PHI accumulates beyond it. The default is 365 days, configurable from 30 to 3,650 days; a background job scans for expired message content, call recordings, and media attachments and deletes them.
If you record calls, pin the voice data residency region at the same time — a retention window and a residency choice are one decision. See HIPAA controls. Evidence left behind: the configured data_retention_days the binder reports back, and the enforced deletion clock.

​
5. Close the AI gates

Both inbox AI behaviours ship message content to a third-party LLM: auto_categorize reads inbound bodies, and auto_summarize reads recent messages at close time. Both default ON. For a PHI-bearing workspace, turn both off and verify:
Evidence left behind: GET /api/v1/settings/compliance/inbox-ai-privacy returns both fields false — the day-0 verification your audit file needs. See Inbox AI privacy.

​
6. Decide on verbatim AI audit

AI-turn audit records every completed AI agent turn — system prompt, user prompt, response, and model metadata — verbatim to your tenant audit table. It is off by default and fails closed, so “off by accident” and “on by accident” are both findings in a HIPAA review. Enable it with PUT /api/v1/settings/compliance/ai-turn-audit only when your written policy requires verbatim records, and pair it with the retention decision from step 4. Evidence left behind: either an explicit “off” verification or a deliberate enabled: true row in your audit log — never a leftover. See AI Turn Audit.

​
7. Generate the HIPAA evidence binder

When an auditor or a buyer’s procurement team asks for the whole posture, generate the HIPAA framework binder from Settings → Compliance → Binder (or POST /api/v1/compliance/binder/generate). It assembles PHI access logging, BAA status, and your configured retention into one pack with a 24-hour signed download link — PDF for a human reviewer, ZIP for a GRC import. Every generation is recorded in your audit log. See Evidence Binder. Run the binder last. It reads the surfaces steps 1–6 populated, so generating before them hands the reviewer an open-items pack.

​
Section 3 — What Orbit does NOT do

Boundary conditions, stated once and plainly:
  • Orbit never picks your PHI-adjacent audiences or channels. The registry marks list and segment ids that carry PHI, and the channel matrix decides which channels may carry PHI at all. Both decisions stay tenant-owned.
  • Orbit never auto-signs or auto-accepts the BAA. The type-the-name e-signature is a deliberate act by your workspace owner.
  • Orbit never decides that your traffic is compliant. Designating audiences, configuring retention, and choosing whether your processing is lawful are your calls; the platform enforces what you set.
  • Orbit never narrows message-content reads beyond the billing role. Minimum necessary is provisioned by your workspace membership and API-key scopes.
  • Nothing on this page gates sending by itself. The PHI send gate and the launch precheck exist only as far as the BAA and designations you turned on. Each control defaults open.
  • This is not legal advice. The sequence assembles Orbit’s controls; whether the assembled posture satisfies HIPAA for your processing is a call for your counsel.