Legal · Security Architecture
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 at security@conceptualhealth.com and we will cut it. Document version: v2026.05. Prior versions in the transparency report archive.
1 · Threat model
Three adversaries. Three answers.
External attacker. An outsider with no privileged access, attempting to compromise the network. Defended by network segmentation, mTLS service-to-service, hardware-token MFA for staff, and the published bug-mining program at /trust/bug-bounty/.
Insider. A current or former employee, contractor, or vendor. Defended by per-record AES-256-GCM encryption with patient-held master keys (we cannot decrypt without the patient's device), least-privilege access, just-in-time elevation with quarterly recertification, and immutable audit logs anchored to the public chain.
Coerced operator. A staff member acting under duress or compulsion. Defended by multi-officer approval for sensitive operations, anomaly detection on access patterns, and the architectural impossibility of decrypting a patient record without that patient's device unlocking the key.
2 · Identity & access
Hardware tokens. Quarterly recertification. JIT elevation.
Every employee, contractor, and validator authenticates with a hardware security key (FIDO2) backing biometric + PIN second factor. Standing access is reviewed quarterly; sensitive resources require just-in-time elevation with a documented approver. All staff sessions are logged with device fingerprint, network origin, and access scope.
3 · Keys & encryption
AES-256-GCM. FIPS 140-3 Level 3 HSM. Patient holds the master.
Patient PHI is encrypted per-record with AES-256-GCM. The data-encryption key is wrapped by a key-encryption key derived from the patient's device passkey — we hold the ciphertext, the patient's device holds the key. KMS root keys live in FIPS 140-3 Level 3 hardware security modules and rotate annually. All transit uses TLS 1.3; the corporate domain is HSTS-preloaded with a one-year max-age.
4 · Data in transit
TLS 1.3, HSTS, mutual auth for service-to-service.
All client-to-server traffic is TLS 1.3 with modern ciphers only; legacy versions are disabled at the load balancer. Service-to-service traffic inside our VPC uses mutual TLS with per-service certificates rotated daily. The corporate domain and every subdomain we own are HSTS-preloaded; downgrade attempts fail at the browser before reaching us.
5 · Storage architecture
Multi-region. Sealed. Separated.
Patient vault. Per-record encrypted blobs in multi-region object storage (us-east-1 + us-west-2). RPO ≤ 60 seconds; RTO ≤ 1 hour. Cryptographic shredding on revocation.
Operational Postgres. Operational state (sessions, audit log buffer, clinical workflow). RPO ≤ 5 minutes; RTO ≤ 4 hours.
Audit chain. Append-only HMAC chain with per-row crypto-agility: SHA3-512 forward (since sequence #24971, 2026-05-26), SHA-256 history preserved exactly as written. Anchored to the public CH Chain every five minutes by Merkle root. See the chains catalog for the live verification surface.
6 · Audit log & chain anchoring
Every action. Signed by its predecessor. Anchored every five minutes.
Every state-changing operation writes a row to one of the HMAC chains: audit_logs (system-wide), fhir_audit_logs (clinical), ch_transactions (token), and several more. Each row's previous_hmac is the hash of its predecessor's entry_hmac under the row's own hash_algo (SHA-256 for historic rows, SHA3-512 going forward) — tampering with any row breaks the chain at that point. The chain head is anchored to the public CH Chain by Merkle root every five minutes. Anyone can re-verify any chain at any time via /proof/chains.html.
7 · Backup & recovery
Tested quarterly. Documented in the transparency report.
Backups are end-to-end encrypted with separate keys and stored in multiple regions. Disaster recovery is tested quarterly with a documented runbook; the test result and the time-to-recovery are published in the quarterly transparency report. We do not consider a backup "working" until we have restored from it in a tabletop exercise.
8 · Breach response
Within one hour of confirmation. Without exception.
Our internal SLA for breach notification to affected individuals is within one hour of confirmation — sixty days faster than the HIPAA statutory maximum. Regulatory notice goes out within four hours. A full public post-incident report is published within seven days of resolution. The runbook covers: containment, scope determination, evidence preservation, individual notice, regulatory notice, public disclosure, remediation, and post-mortem.
9 · Secure SDLC
SLSA Level 3. Continuous bug-bounty. Annual third-party pen test.
Every build is reproducibly produced from signed source, with SLSA Level 3 provenance attached to the artifact. Every dependency is pinned. Every release is signed with an Ed25519 key in a hardware module. The bug-mining program at /trust/bug-bounty/ runs continuously; an annual third-party penetration test covers external network, application, AI prompt-injection, BAA-as-code, and edge-node verification.
10 · Data inventory
Every category we hold. Every place it lives.
The full data inventory — every category of personal and clinical data we collect, where each is stored, who can access it, how long we retain it, and the disposition on account closure — lives at /compliance/threaded/#data-inventory and updates whenever the architecture changes. Subprocessors are listed at /compliance/threaded/#subprocessors and refreshed within 30 days of any change.
Security contact
Found a problem? Bring it.
Email: security@conceptualhealth.com
PGP: see /trust/bug-bounty/
Bug Mining Program: /trust/bug-bounty/