Security & our commitment to your clinic

A kiddo’s record is the most sensitive thing you hold.

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.

Included with membership · U.S. clinics

A clear agreement.
A shared responsibility.

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 us
231tables with row-level security switched on, carrying 646 access policies. Separation is enforced by the database itself, not by the application asking nicely.
AES-256-GCMon the fields that identify a child — names, dates of birth, contact details — each value with its own initialisation vector and authentication tag.
Append-onlyaudit log. Insert and read policies exist; there is no update policy and no delete policy, so a record of access cannot be rewritten or removed.
01 · Separation

One clinic cannot reach another clinic’s records.

Every 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.

02 · Who can see what

Authorisation is layered, and no layer is the browser.

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.

RoleWhat the scope allows
RBTTheir assigned caseload and their own schedule. Nothing else, and no list of other children to search.
BCBATheir caseload and clinical surfaces. No finance, no payroll cost.
AdminAdministrative operations. Not clinical authorisation decisions, not finance, not the parent view.
Billing adminBilling and payroll. No treatment authority.
OwnerUnrestricted within their own organisation.
ParentTheir own child, exclusively.
Care Graph™ — access follows the assignment. Cue’s own algorithm for who belongs where. A technician assigned to a child is admitted to that child’s record, schedule and care-team channel by the assignment itself. End the assignment and every one of those closes in the same movement — not when somebody remembers to go and revoke them. The safest permission is the one nobody had to remember to withdraw. See it work →
03 · Encryption

Encrypted in transit, at rest, and again at the field.

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.

04 · The audit log

You can find out who looked, and nobody can unfind it.

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.

OperationPolicy
InsertAny authenticated staff member, for their own organisation.
ReadOwner and billing admin, within their own organisation. Cue platform admins, separately.
UpdateNo policy exists. There is no path to edit an entry.
DeleteNo 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.

05 · The other promise

Cue Assure™ — the session that survives a dead zone.

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 →

06 · AI and PHI

The model provider is a Business Associate, or it does not see anything.

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.

Two honest exceptions, which apply to every vendor in this category and are worth knowing rather than discovering: content flagged by automated trust-and-safety systems, and anything under a legal hold, may be retained longer than ordinary traffic.
07 · If something goes wrong

The clock is in the software, not in somebody’s calendar.

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.

08 · Controls & independent assurance

Controls are only worth what the evidence behind them is worth.

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:

ControlThe evidence behind it
Tenant isolationPolicy inventory, cross-organisation negative tests, and a review of anywhere the service role bypasses RLS.
Role accessAutomated tests per role — owner, admin, billing admin, BCBA, RBT, parent — over routes and widgets.
PHI handlingAn inventory of which fields are encrypted, export controls, and the access log.
Support accessLogs for role preview, support assignment and response times, so troubleshooting is never invisible.
BackupsRestore drills recorded with real timestamps and measured RPO and RTO — a backup nobody has restored is a hope.
Dependency riskDependency audits with a register for anything knowingly accepted.
Incident responseA 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.

Ask us the hard question.

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.