Security Whitepaper

Scribeable is an AI-powered clinical documentation platform that transforms ambient patient encounters into structured medical notes. Given the sensitivity of Protected Health Information (PHI) processed through our platform, security is foundational to every architectural decision we make.

Our security posture is built on four pillars:

• 5-Layer Envelope Encryption — AES-256-GCM encryption with ECDH P-256 key exchange across API requests, responses, WebSocket messages, audio streams, and field-level storage. Enforcement mode rejects plaintext PHI at the server on covered paths. Since October 2026, an app that does not encrypt live audio is refused. Two features still send data protected by TLS only, which Cloudflare can read in transit: calculator inputs and practice roster CSV uploads.
• Application-Layer Encryption — Encryption keys are negotiated via ECDH and never transmitted in plaintext. On enforced channels, CDN, edge, and intermediary infrastructure see only ciphertext. Our servers decrypt PHI in memory to generate notes.
• HIPAA-First Design — Every feature is designed, reviewed, and tested with HIPAA compliance as a mandatory requirement.
• Continuous Monitoring — 15-minute encryption health checks, real-time threat detection, comprehensive audit logging, and proactive vulnerability management.

A downloadable PDF version of this whitepaper is available on our Security page.

Scribeable's architecture is designed to minimize the attack surface while providing a seamless user experience for clinicians. Each component is secured independently:

All inter-component communication is encrypted using TLS 1.3. Internal services communicate over private networks with no public internet exposure.

5-Layer Envelope Encryption (ECDH-A)

Scribeable uses AES-256-GCM envelope encryption with ECDH P-256 (Elliptic Curve Diffie-Hellman) key exchange. Plaintext encryption keys are never transmitted between client and server. PHI is protected by five independent encryption layers on our enforced channels:

Enforcement Mode

Enforcement mode is a server-side technical control that is active on our covered PHI-bearing endpoints — API requests, API responses, and WebSocket connections from an up-to-date app. It is not a policy or configuration option. Since October 2026, an app that does not encrypt live audio is refused. Two features still send data protected by TLS only, which Cloudflare can read in transit: calculator inputs and practice roster CSV uploads.

ECDH P-256 Key Exchange

Key agreement uses Elliptic Curve Diffie-Hellman (ECDH) on the NIST P-256 curve. The protocol works as follows:

• The client generates an ephemeral ECDH key pair per session.
• The client and server exchange public keys and independently derive a shared secret.
• The shared secret is used to derive AES-256-GCM encryption keys via HKDF.
• Plaintext keys are never transmitted between client and server at any point.
• Ephemeral keys provide forward secrecy: compromise of a future session key does not expose past sessions.

CDN and Reverse Proxy Blindness

Because envelope encryption operates at the application layer (above TLS), all intermediary infrastructure is blind to PHI:

• CDN nodes (Cloudflare) — Terminate TLS but see only encrypted payloads. No PHI is exposed at the edge.
• Reverse proxies (Caddy) — Route traffic but cannot inspect encrypted request/response bodies.
• Load balancers — Distribute traffic based on headers, never accessing PHI in payloads.
• Logging and monitoring systems — PHI is scrubbed before ingestion. Even if a log pipeline were compromised, it contains only ciphertext references.

This architecture means that a compromise of CDN credentials, edge infrastructure, or any intermediary system yields zero usable patient data.

Encryption at Rest

• All stored data is encrypted using AES-256 encryption, a standard approved by NIST for protecting classified information.
• Encryption keys are managed through Google Cloud KMS with automatic key rotation.
• Database backups are encrypted with separate keys from primary storage.
• Field-level envelope encryption (Layer 5) provides an additional encryption layer independent of the storage provider's at-rest encryption.

Encryption in Transit

• All network traffic uses TLS 1.3 (the latest protocol version) with strong cipher suites. This is the transport layer — envelope encryption (Layers 1-4) operates independently above TLS.
• HTTP Strict Transport Security (HSTS) is enforced across all domains.
• iOS App Transport Security enforces TLS 1.2+ with Certificate Transparency to prevent man-in-the-middle attacks.
• WebSocket connections for real-time features use WSS (WebSocket Secure) protocol, with per-message envelope encryption on top.

Key Management Hierarchy

• Master KEK — Key Encryption Key stored in Google Cloud KMS. Never exported. Used to wrap/unwrap DEKs.
• Organization DEKs — Data Encryption Keys scoped to each organization. Used for field-level at-rest encryption (Layer 5).
• Ephemeral session keys — Derived per-session via ECDH for in-transit encryption (Layers 1-4). Discarded after session ends.
• Automatic key rotation on a regular schedule.
• Continuous monitoring with automated alerting on all key management operations.

Encryption Monitoring and Incident Response

Encryption health is continuously monitored:

• 15-minute health checks verify encryption integrity across all 5 layers.
• Telemetry tracks encryption match rates, ECDH key exchange success rates, and enforcement compliance.
• Daily encryption telemetry is stored in Firestore for audit trail and trend analysis.
• Any anomaly (match rate drop, key exchange failure, enforcement bypass attempt) triggers immediate alerts to the security team.
• Graduation criteria for encryption changes: 1,000+ successful matches, 0 mismatches, 14 consecutive clean days before promoting changes.

Application-Layer Encryption

Scribeable encrypts PHI at the application layer, above TLS. Encryption keys are exchanged via ECDH, so the key that protects each request is never sent over the network. Our application servers decrypt PHI in memory to generate notes; on enforced channels, CDN, edge infrastructure, reverse proxies, load balancers, and all intermediary systems process only ciphertext. A direct read of the database shows encrypted PHI fields as ciphertext. Some derived clinical data is not yet field-encrypted, and our administrators hold the keys.

Compliance Mapping

The envelope encryption system satisfies the following regulatory and framework requirements:

Cloud Infrastructure

Scribeable's primary infrastructure runs on Google Cloud Platform (GCP) and Firebase, both of which maintain SOC 2 Type II, ISO 27001, HIPAA, and HITRUST certifications. Our infrastructure is deployed exclusively in United States data centers.

• Primary hosting on Google Cloud Platform (Firebase) with HIPAA BAA in place
• Disaster recovery infrastructure on OVH Public Cloud (US-East, Virginia) with separate BAA
• Encrypted backups stored on Backblaze B2 Cloud Storage with customer-side encryption
• Cloudflare provides CDN, WAF, and DDoS protection at the edge layer

Network Security

• Web Application Firewall (WAF) with custom rulesets for healthcare-specific threats
• DDoS protection via Cloudflare with sub-second mitigation
• Network segmentation isolates production, staging, and development environments
• VPN-protected access to administrative systems with IP allowlisting
• Intrusion detection and prevention systems (IDS/IPS) monitor all network traffic

Server Hardening

• All servers run hardened operating system configurations with unnecessary services disabled
• Automated security patching ensures vulnerabilities are addressed promptly
• Container isolation for application workloads prevents lateral movement
• Immutable infrastructure: servers are replaced rather than patched in place where possible

User Authentication

• Firebase Authentication with support for email/password, Google, and Apple sign-in
• Multi-factor authentication (MFA) available and recommended for all accounts
• Bounded session lifetimes with per-device revocation and explicit sign-out
• Secure token-based authentication (JWT) with short expiration and refresh token rotation
• Biometric authentication (Face ID, Touch ID) supported on iOS devices

Role-Based Access Control (RBAC)

• Granular role-based permissions control access to features and data
• Organization-level roles: Owner, Admin, Provider, and Staff
• Principle of least privilege enforced: users can only access data necessary for their role
• Role assignments reviewed quarterly by organization administrators

Internal Access Controls

Protected health information (patient identity fields, transcripts and notes) is encrypted with AES-256-GCM under per-organization keys before it is stored.

• Comprehensive audit logging of all PHI access, modifications, and deletions
• Immutable, tamper-evident audit trail stored separately from application data
• Audit logs retained for a minimum of six (6) years per HIPAA requirements
• Real-time monitoring and alerting for suspicious access patterns
• Infrastructure monitoring via PM2 process management and Google Cloud Operations (Cloud Logging + Cloud Error Reporting)
• Automated health checks every five minutes across all server nodes
• Encryption-specific health checks every 15 minutes verifying integrity across all 5 envelope encryption layers
• Daily encryption telemetry aggregation for audit trail and trend analysis

All monitoring and logging data is scrubbed of PHI before storage in analytics and error-tracking systems. The shared phiRedactor module enforces structural and value-level redaction at the application boundary before any log line is forwarded to Google Cloud Logging, Cloud Error Reporting, or the Wazuh SIEM.

Audio Processing

Patient encounter audio is processed in real-time through Deepgram's HIPAA-compliant transcription service. Single-visit audio is processed in memory on our servers and not stored there. Rounding Mode audio is stored on our servers, encrypted, until it is transcribed, and is deleted within 24 hours after transcription. Audio that fails to transcribe is deleted after 7 days. If a technical fault stops us reading a recording, we hold it, encrypted, until we can retry it or destroy it. Fixing the fault does not involve listening to it. On iPhone, the recording stays on your iPhone until you delete the note or sign out. There is no option to save a recording.

AI Note Generation

Transcribed text is processed through Anthropic's Claude API to generate structured clinical notes. Anthropic operates under a signed BAA with Scribeable. Anthropic may retain requests and outputs under its terms; we have no zero-retention arrangement.

Data Retention

Every vendor that stores or processes PHI for us is under a BAA, except as the Subprocessor List states (Cloudflare carries network traffic without one). We evaluate each subprocessor's security posture before onboarding and monitor them continuously.

A complete and current subprocessor list is maintained at scribeable.ai/legal/subprocessors. Customers receive 30 days advance notice before any new subprocessor is added.

Scribeable maintains a comprehensive incident response plan that is reviewed and tested annually. The plan includes the following phases:

Phase 1: Detection and Containment

• 24/7 automated monitoring detects anomalies in real time
• Immediate containment actions are initiated to prevent further exposure
• The incident response team is activated within 15 minutes of detection

Phase 2: Investigation and Assessment

• Forensic analysis determines the scope and impact of the incident
• Affected data and systems are identified
• Root cause analysis begins in parallel with containment efforts

Phase 3: Notification

• Affected individuals and covered entities notified within 24 hours of confirmed breach
• Regulatory bodies notified as required by HIPAA (within 60 calendar days)
• Ongoing communication throughout the resolution process

Phase 4: Remediation and Recovery

• Root cause remediated and validated
• Systems restored from verified clean backups if necessary
• Post-incident review conducted to improve controls

Security Assessments

• Annual internal security assessments, with documented remediation
• Continuous automated security scanning of application code and dependencies
• Regular HIPAA risk assessments with documented remediation plans

Security is not a destination but an ongoing commitment. Scribeable continuously invests in improving our security posture through:

• Regular training for all employees on HIPAA, security best practices, and incident response
• Adoption of emerging security technologies and standards
• Active participation in healthcare security communities and information sharing
• Customer feedback integration into our security roadmap
• Quarterly review of all security policies and procedures