Trust · Security Architecture Whitepaper · v2026.05
How we secure your records.
Plain-English engineering description of the controls protecting patient data — keys, transit, storage, audit, recovery. If a sentence here looks like marketing, point it out and we'll cut it.
1. Threat model
We design against three categories of adversary. External attacker: opportunistic credential stuffing, phishing, ransomware, supply-chain compromise. Insider: a Conceptual Healthcare employee or contractor with legitimate platform access acting outside policy. Coerced operator: a Conceptual Healthcare employee acting under legal compulsion (subpoena, NSL) or duress.
The third category is what most of the architecture is for. The patient holds the keys, not us. Even when we want to read your records, we can't.
2. Identity & access
| Population | Authentication | Authorization | Recertification |
|---|---|---|---|
| Patients | Email + WebAuthn passkey (preferred), TOTP fallback. Passwords are not stored. | Self-only by default. Family/clinical grants explicit, time-bound, revocable. | n/a |
| Providers | SSO with hardware-token MFA (FIDO2). DEA number bound at enrollment. | Role-based. Patient-record access requires an active care relationship. | Quarterly |
| Employees | SSO + FIDO2 hardware token. No password fallback. | Just-in-time elevation via PAM with peer approval. PHI access logged and reviewed. | Quarterly |
| Service-to-service | mTLS with short-lived certificates (24h max), workload identity tied to deployment manifest. | Least-privilege scopes per service. | Per-deploy |
3. Keys & encryption
Patient PHI is encrypted with a per-record content key (AES-256-GCM). The content key is wrapped with the patient's master key. The master key never leaves the patient's device in plaintext; it is derived locally from a passkey signature and unwrapped only client-side or in a confidential-compute enclave the patient explicitly grants access to.
Platform secrets (TLS keys, signing keys, KMS roots) live in a FIPS 140-3 Level 3 hardware security module operated under the dual-control rule. No single employee can extract a key. KMS root keys rotate annually; data-encryption keys rotate per-record on amendment.
The "even we can't" claim
For records the patient has not granted to a clinician or to us: we possess only the wrapped ciphertext and the wrapped key. Without the patient's passkey signature, neither is reversible. A subpoena directed at us produces ciphertext. A subpoena must be directed at the patient.
4. Data in transit
All public traffic is TLS 1.3 with modern cipher suites only (AEAD ciphers, forward-secret key exchange). HSTS preload is set with a one-year max-age and includeSubDomains. Internal service-to-service traffic is mutually authenticated TLS with workload-bound short-lived certificates issued by an internal Certificate Transparency-monitored CA.
WebSocket and gRPC streams use the same trust fabric. Mobile apps pin the public key of the API gateway with a 90-day rotation window.
5. Storage architecture
Tier 1 — Patient vault. Per-patient encrypted blob store (S3 in us-east-1 and us-west-2 with cross-region replication). Object-level encryption with the patient master key. Server-side encryption with KMS as a defense-in-depth layer. Versioning enabled; deletes are soft for 30 days.
Tier 2 — Operational data. Per-tenant Postgres (multi-tenant isolation by row-level security and per-row-encrypted PHI columns), in private VPC. No public ingress.
Tier 3 — Analytics. Differentially private aggregates only. Re-identification of individual patients from analytics output is mathematically prevented, not policy-prevented.
6. Audit log & chain anchoring
Every read, write, grant, revocation, and administrative action is recorded in an append-only audit log. Every five minutes the Merkle root of the new log entries is anchored to CH Chain. Anchoring proves to a third party — or a future regulator — that the log was not retroactively modified.
Patients see their own entries in real time inside the app on the "Audit log" screen. Enterprise customers see their tenant's log in the compliance console.
7. Backup & recovery
| Asset | RPO | RTO | Geographic |
|---|---|---|---|
| Patient vault | ≤ 60 seconds | ≤ 1 hour | Multi-region (us-east-1 + us-west-2) |
| Operational Postgres | ≤ 5 minutes (PITR) | ≤ 4 hours | Cross-AZ + cross-region snapshots |
| Audit log + chain | 0 (chain is the source of truth) | ≤ 1 hour | Multi-region + chain anchor |
| KMS keys | 0 | ≤ 4 hours | HSM mirror in second region |
Disaster recovery is tested quarterly with full game-day exercises. The most recent test report is available to enterprise customers under NDA.
8. Breach response
The Privacy Officer is paged on any anomaly that meets the breach threshold. Within one hour of confirmation, affected Covered Entities are notified per the BAA. Within 24 hours, controllers under GDPR are notified per the DPA. Within 60 days, individual notifications are sent under HHS rules. Forensic findings are published in the next quarterly transparency report unless an active law-enforcement investigation requires otherwise — in which case the warrant canary is allowed to expire.
9. Secure software development lifecycle
- Code review. Two-person rule on production-deployed code. PHI-touching paths require a security-team reviewer.
- Static analysis. Semgrep + CodeQL on every PR. Secret scanning on push.
- Dependency hygiene. SBOM generated per build; vulnerable dependencies patched on a 7-day SLA for Critical, 30 days for High.
- Penetration testing. Third-party annually plus continuous bug bounty (HackerOne or equivalent).
- Build provenance. SLSA Level 3. Reproducible builds for security-critical components.
10. Data inventory
The current data inventory — every category of personal data we process, the lawful basis, the retention period, the storage tier — is published in machine-readable form at /compliance#data-inventory and updated with every release that adds or removes a category.
Document control. Whitepaper version 2026.05. Reviewed by the Security Officer (CIO) at every release. Past versions archived at /trust/transparency-report. Questions: security@conceptualhealth.com.