Vendor BAA Matrix
Reviewed: 2026-07-22 · Canon: generation 8, effective 2026-07-21
The governing rule: every vendor that would touch real PHI has an executed BAA before real PHI exists in the system, or the data does not flow. Because the deployed environment runs synthetic data only, no vendor currently processes Rōvn-managed PHI. This matrix is therefore a gating register, and execution status for any vendor is stated only with the signed document on file.
1. Vendor gating table
| Vendor class | Role | PHI exposure if activated | BAA gate |
|---|---|---|---|
| Google Cloud | Cloud Run compute, Cloud SQL database, storage, Secret Manager, Vertex AI | PHI at rest and in transit once real data activates | Cloud BAA executed on HIPAA-covered services before any real PHI; only HIPAA-eligible services on PHI paths |
| AI model providers | Document extraction, drafting, workflow agents (Anthropic-first routing; runtime is model-agnostic) | Credential metadata only, minimized and logged | Provider BAA plus configuration, minimization, and logging gates per 06.5 before regulated data flows |
| Identity verification vendor | Government-ID identity proofing for workers | Identity documents and PII | BAA or equivalent executed before activation with real workers |
| Background check vendor | Background screening where a workflow requires it | PII and screening data; FCRA obligations apply | BAA plus FCRA workflow review by counsel before activation |
| Enterprise SSO (WorkOS) | Customer SSO federation | Organization user identity; no clinical PHI in normal flow | Contract terms reviewed; BAA if scope ever includes PHI |
| Communications (email, SMS) | Workflow notifications | Contact details and notification text; designed to exclude PHI | BAA required before any PHI-bearing message content |
| Error tracking and observability | Application errors and metrics | None by design; PHI scrubbing enforced before real-data activation | Scrubbing verified as a real-data gate; BAA if design changes |
| Billing processor | Invoicing and payments | Billing metadata only, never PHI | No BAA required; PHI exclusion is a design rule |
| Cloudflare | DNS and selected static delivery | None; no PHI surface is proxied through it on PHI paths | No BAA required under current design |
2. Register discipline
- The authoritative vendor register, with counterparties, dates, and signed documents, is maintained under outside counsel (Jason Acevedo, Klehr Harrison) and shared with investors on request through diligence access.
- Earlier dated room documents recorded vendor BAA statuses from the prior AWS-era stack. Those are historical snapshots. Under the current claim rules, execution is asserted only with the signed agreement on file, re-papered under Rōvn, Inc. where the original predates the entity conversion.
- Renewal reviews follow the vendor register cadence; changes are logged and disclosed per the sub-processor process (06.11).
3. Customer-facing BAA
| Item | Status |
|---|---|
| Template | Maintained under outside counsel; summary at 08.9; available on request through diligence access |
| Standard terms | HIPAA baseline plus Rōvn-specific PHI scope and sub-processor flow-down |
| Signature workflow | Manual execution at this stage |
| Storage of executed BAAs | Immutable artifact storage with an audit-ledger reference, per the retention design |
4. Flow-down
When a customer signs a BAA with Rōvn:
- The customer BAA sits at the top of the cascade.
- Sub-processor flow-down clauses disclose the vendor list and bind downstream vendors to equivalent restrictions (08.11).
- Customers receive advance notice of material sub-processor changes and may raise objections per the disclosure language (06.11).
- Every BAA execution event is designed to be logged in the audit ledger with a reference to the stored artifact.
End of vendor BAA matrix.