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.
• Zero-Knowledge Architecture — Encryption keys are negotiated via ECDH and never transmitted in plaintext. CDN, edge, and intermediary infrastructure see only ciphertext. Scribeable staff cannot access unencrypted PHI.
• 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. All PHI is protected by five independent encryption layers:

Enforcement Mode

Enforcement mode is a server-side technical control that is always active on all PHI-bearing endpoints. It is not a policy or configuration option — it is a cryptographic guarantee.

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.

Zero-Knowledge Architecture

Scribeable implements a zero-knowledge architecture for all PHI operations. Encryption keys are exchanged via ECDH so that plaintext keys never leave the user's device. This means that even in the event of a full server compromise, encrypted PHI remains protected. CDN, edge infrastructure, reverse proxies, load balancers, and all intermediary systems process only ciphertext. Scribeable employees with production database access see only encrypted field values.

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
• Automatic session timeout after periods of inactivity
• 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

Scribeable employees are subject to strict access controls. Production database access requires multi-party approval and is logged. Due to our zero-knowledge architecture, employee access to production systems does not grant access to unencrypted PHI.

• 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 Sentry error tracking
• 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. Sentry is configured with data scrubbing to prevent inadvertent PHI exposure in error reports.

Audio Processing

Patient encounter audio is processed in real-time through Deepgram's HIPAA-compliant transcription service. Audio data is streamed directly and is never stored in raw form on Scribeable servers. Deepgram does not retain audio data after transcription is complete.

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 and does not use any customer data to train AI models. Processing occurs in memory with no persistent storage of PHI on Anthropic's systems.

Data Retention

All third-party services that process or have access to PHI operate under signed Business Associate Agreements. 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 third-party penetration testing by independent security firms
• Quarterly internal vulnerability assessments and 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