Security and HIPAA
Built aroundone principle:PHI never persiststo the platform.
Most voice AI platforms hold patient data by default. We don't. Patient information lives in a sealed boundary for the duration of one interaction, then is destroyed before any database is written. Reasoning, persistence, audit, and customer-facing surfaces operate on structured proofs — never on PHI.
Architecture
Watch a call resolve.
PHI never crosses the boundary.
A call enters the boundary, where patient information is held briefly in process memory. The colleague reasons on the call, decides what to extract, and emits a structured proof to the core. PHI is destroyed before any persistent system writes the call. The core reasons, persists, and serves customer-facing surfaces — all on typed proofs that contain no patient identifying information. Every state transition is captured in a hash-chained audit log.
Boundary model
Two zones.
PHI lives in only one of them.
Zone 01 / Boundary
Where reality is touched.
The boundary is where the platform meets the outside world — inbound and outbound voice, integration endpoints, customer-supplied context. PHI may be present here, briefly, in process memory, scoped to a single interaction.
On completion, the boundary destroys all transient PHI and emits a structured, redacted, typed proof to the core. A destruction receipt is hashed into the audit log.
PHI present · ephemeral · process memory · destruction-proven
Zone 02 / Core
Where everything else happens.
The core is everything else: reasoning, workflow orchestration, persistence, learning, audit, and every surface a customer ever sees. The core operates exclusively on structured proofs — typed events that contain no patient identifying information.
This is enforced architecturally, not by policy. Engineers cannot read PHI from production systems. The persistence schema does not contain PHI fields.
PHI absent · enforced by architecture · not by policy
Audit log
Every state transition across both zones is captured in a hash-chained, append-only log. Tamper-evident. Customer-queryable. Retention configurable per contract.
HIPAA posture
We sign BAAs.
Without exception.
Business Associate Agreements are executed with every customer that processes PHI through our platform. A standard BAA is available on request, and we accommodate customer paper where reasonable.
Subprocessors in our chain are also BAA-covered. We notify customers in writing 30 days before adding or changing a subprocessor that materially handles PHI.
Minimum-necessary access is enforced architecturally. The core never receives PHI. Engineers cannot read PHI from production. Customer support sees audit metadata only.
Subprocessor categories
The categories below describe the types of services in our chain. Specific vendor identities are disclosed under NDA during procurement review and in the executed BAA.
Controls
Encryption
TLS 1.3 in transit. AES-256 at rest. Cloud-native key management with annual rotation.
Data residency
All processing, persistence, and telephony in US-only cloud regions. No cross-border movement of PHI.
Audit logging
Hash-chained, append-only, customer-queryable log of every state transition. Retention configurable per contract.
Tenant isolation
Single-tenant deployments today; database-level row-level security policies for shared deployments rolling out Q3 2026.
Access control
Role-based access. Mandatory MFA. SSO via SAML for customer-facing dashboards. Least-privilege by default.
Vulnerability management
Dependency scanning on every build. Critical advisories patched within 72 hours. Annual third-party penetration test.
Incident response
24-hour notification SLA on confirmed incidents involving customer data. Post-incident report within 14 days.
Backup and recovery
Encrypted daily backups. 30-day retention. Quarterly restore drills. RPO 24h, RTO 4h for core services.
What we don't do
Equally important.
- ×We do not store raw call audio after structured outputs are emitted, unless the customer explicitly opts in.
- ×We do not retain prompt or response logs containing PHI beyond the call.
- ×We do not use customer data to train models, ours or any third party's.
- ×We do not move customer PHI outside US infrastructure.
Roadmap
Q3 2026
SOC 2 Type I
In progress with a qualified third-party auditor. Targeting completion this quarter.
Q1 2027
SOC 2 Type II
Six-month observation window begins after Type I. Report expected H1 2027.
2027
HITRUST
Pursued where customer demand requires. Scoped to platform components handling PHI.
Procurement and security
BAAs, vendor questionnaires, subprocessor disclosure, vulnerability reports. Email digital@ibridgedigital.com. We respond within one business day.