HIPAA compliance, in detail.
VaultMail implements the HIPAA Security Rule Technical Safeguards at 45 CFR § 164.312. Every safeguard is enforced in code and verified by automated tests.
Technical Safeguards — 45 CFR § 164.312
How VaultMail satisfies each required and addressable safeguard.
Access Control — Standard
All encrypted objects are governed by policies stored in a relational database. Policies define allowed recipient emails, expiration timestamps, and forwarding permission. Decrypt requests are authenticated and authorized against these policies server-side before any cryptographic operation is performed.
Unique User Identification
Every user has a globally unique identifier generated at account creation. Authentication is provided by Google OAuth, Microsoft Entra ID, or verified magic-link email. No shared accounts, no password reuse, no legacy session mechanisms.
Emergency Access Procedure
Because senders hold access to their own encrypted content, emergency access to PHI is exercised by the covered entity through its own out-of-band procedure documented in the BAA — VaultMail does not provide a break-glass override that bypasses the sender. Any support-assisted access is consent-gated per ticket and recorded in the audit log.
Automatic Logoff
Sessions expire after 15 minutes of inactivity. Session cookies are httpOnly, Secure, SameSite=Lax. Re-authentication is required to resume access to PHI.
Encryption & Decryption
AES-256-GCM with a unique 256-bit Data Encryption Key (DEK) per object. DEKs are wrapped with per-user Key Encryption Keys (KEKs) via RFC 3394 AES Key Wrap. KEKs are derived via HKDF-SHA256 from a master key held in Google Secret Manager. Plaintext is never written to disk.
Audit Controls
Every cryptographic operation and access attempt is recorded in an append-only audit log with timestamp, object ID, accessor email, action, IP address, User-Agent, and outcome. Log records are retained for a minimum of six years per §164.530(j).
Integrity — Standard
AES-GCM provides authenticated encryption. Any modification to ciphertext, IV, or authentication tag causes decryption to fail. Tampering is detectable and logged.
Mechanism to Authenticate ePHI
GCM authentication tags verify the integrity of every decrypted object. Integrity check failures return an opaque error and are recorded in the audit log.
Person or Entity Authentication
Authentication delegated to trusted identity providers (Google, Microsoft) or verified via single-use magic links sent to the claimed email. No password-based authentication for PHI access.
Transmission Security — Standard
All network traffic uses TLS 1.3 with modern cipher suites. HSTS preload enforced. HTTP requests are redirected to HTTPS. No plaintext PHI ever transits the network.
Integrity Controls — Transmission
TLS 1.3 provides transmission integrity via AEAD cipher suites. Combined with AES-GCM at rest, PHI integrity is continuously verified from client to storage and back.
Encryption — Transmission
In addition to TLS 1.3, object ciphertext is already encrypted at rest before transmission, providing defense in depth if TLS were ever compromised.
Administrative Safeguards — highlights
Key administrative controls from 45 CFR § 164.308. Full details in the BAA and security documentation available on request.
Workforce Security (§164.308(a)(3))
Access to VaultMail infrastructure is limited to authorized engineering staff with documented role-based access controls. Off-boarding is tracked and enforced.
Information Access Management (§164.308(a)(4))
Customer PHI is segmented per-tenant. Service account permissions follow least privilege. Cross-tenant access is prevented at the application and database layer.
Security Incident Procedures (§164.308(a)(6))
Incident response plan with 24-hour breach notification per §164.410. Security contact: support@spriggan.ai.
Contingency Plan (§164.308(a)(7))
Cloud-backed durable storage on Google Cloud Storage (11 nines durability). Daily database snapshots. Disaster recovery playbook documented.
Scope & limitations
To set expectations clearly:
- VaultMail is a business associate service. Your clinic remains the covered entity responsible for HIPAA Administrative and Physical Safeguards within your own environment.
- VaultMail does not provide email transport. We generate share links you paste into any email client. The security of the email client itself (Gmail, Outlook, etc.) is outside VaultMail’s scope.
- Recipients must verify their identity via OAuth sign-in before decrypting. If a recipient forwards their login credentials, VaultMail cannot prevent the resulting access.
- This page describes our current implementation as of the last audit. Security controls evolve; the most current version is always what is enforced in production.