Your clinic membership includes a Business Associate Agreement (BAA). Cue combines access controls, encryption and an audit trail to support your clinic’s HIPAA responsibilities.
Here are the controls behind that commitment, the responsibilities we share with your clinic, and our current independent audit status.
Our BAA sets out Cue’s responsibilities as your Business Associate when we handle protected health information on your behalf. Your clinic remains responsible for its own HIPAA policies, staff practices and use of the platform.
Review the BAA with usEvery operational row carries the organisation that owns it, and Row Level Security decides what a query is allowed to return before the application sees a single row. That distinction matters: an application bug that forgets a filter returns nothing rather than somebody else’s data, because the boundary is underneath the bug.
Four checks stand between a request and a record: the route gate in the app, a server-side role check in the API, the row-level policy in the database, and a separate platform-admin check for anything belonging to Cue rather than to a clinic. No sensitive behaviour depends on client-side filtering — hiding a button is not a permission.
| Role | What the scope allows |
|---|---|
| RBT | Their assigned caseload and their own schedule. Nothing else, and no list of other children to search. |
| BCBA | Their caseload and clinical surfaces. No finance, no payroll cost. |
| Admin | Administrative operations. Not clinical authorisation decisions, not finance, not the parent view. |
| Billing admin | Billing and payroll. No treatment authority. |
| Owner | Unrestricted within their own organisation. |
| Parent | Their own child, exclusively. |
Transport and storage encryption are table stakes and are in place. On top of them, the fields that actually identify a child are encrypted individually with AES-256-GCM, so a value is self-contained: its own initialisation vector, its own authentication tag, its own ciphertext. GCM is authenticated encryption — a tampered value fails to decrypt rather than decrypting to something plausible.
PHI access and mutation are written to an audit log through one shared path, recording the organisation, the user, the action, the kind of record and its id. The interesting property is not that the log exists — every platform has a log — it is what the database will let you do to it.
| Operation | Policy |
|---|---|
| Insert | Any authenticated staff member, for their own organisation. |
| Read | Owner and billing admin, within their own organisation. Cue platform admins, separately. |
| Update | No policy exists. There is no path to edit an entry. |
| Delete | No policy exists. There is no path to remove one. |
Because RLS denies anything a policy does not explicitly allow, the absence of those two policies is the guarantee. The log is append-only at the database level, not by convention and not because the application declines to offer a delete button.
Sessions happen in classrooms, living rooms and cars. A trial recorded where there is no signal is written to the device first, before any network call is attempted, and survives a closed tab or a restarted app. A failed sync marks the session as still waiting, never as done — and the BCBA who has to sign it off is told, in their action queue, in the app and on their phone, so the session is closed properly rather than left for somebody to notice.
The part that matters for billing integrity: every session carries its own identifier, and a replay updates the record it already created rather than creating a second one. There is no time bound on that match, so a session that reaches us days late still cannot bill a visit twice. The full protocol →
Cue uses a language model to write the daily brief and to draft from what a clinician already recorded. Using AI on PHI is not the violation; sending PHI to any vendor without a Business Associate Agreement is the violation. So the agreement comes first, and the covered surface is written down rather than assumed.
Cue acts as your Business Associate. If we discover an incident affecting your organisation’s data, the notification duty under 45 CFR §164.410 is ours, and the platform tracks it rather than leaving it to memory.
Our next step is an independent SOC 2 Type II audit. Cue has not yet completed that audit and does not currently hold a SOC 2 report or HITRUST certification. Internal readiness work is separate from an independent auditor’s examination.
Our internal evidence programme brings together control inventories, testing and operational records. These are the areas it covers:
| Control | The evidence behind it |
|---|---|
| Tenant isolation | Policy inventory, cross-organisation negative tests, and a review of anywhere the service role bypasses RLS. |
| Role access | Automated tests per role — owner, admin, billing admin, BCBA, RBT, parent — over routes and widgets. |
| PHI handling | An inventory of which fields are encrypted, export controls, and the access log. |
| Support access | Logs for role preview, support assignment and response times, so troubleshooting is never invisible. |
| Backups | Restore drills recorded with real timestamps and measured RPO and RTO — a backup nobody has restored is a hope. |
| Dependency risk | Dependency audits with a register for anything knowingly accepted. |
| Incident response | A runbook, the regional deadlines, and exercises against them. |
Runs are recorded rather than remembered. If you are evaluating Cue for a clinic and your reviewer needs the detail, ask and we will send the evidence package.
If your security reviewer has a questionnaire, send it. If something on this page is not specific enough to answer it, that is worth knowing — tell us which line and we will either point at the control or say it is not built yet.