HIPAA-Compliant SaaS Architecture: A Builder's Guide

HIPAA-compliant SaaS is not a label you buy. It is a posture you build, document, and prove. The Security Rule's safeguards are deliberately principles-based, which means two clean implementations can both be defensible and look nothing alike. This guide is the architecture we ship at QUANT LAB USA when the build touches PHI.

Background: What is HIPAA compliance? and our healthcare industry page.

1. BAA coverage end-to-end. Every vendor in the PHI data path has a signed BAA. No exceptions.
2. Encryption. At rest (AES-256, KMS-managed keys) and in transit (TLS 1.2+, modern ciphers).
3. Identity and access. Unique IDs, MFA on workforce access, SSO for admin, RBAC with minimum-necessary.
4. Audit logging. Immutable, six-year retention, anomaly alerting.
5. Incident response. Written plan, breach notification timeline (60 days), tabletop exercise annually.
6. Risk analysis. Annual SRA, with documented decisions on addressable vs required controls.

Layer your encryption. The standard pattern we ship:

• Volume / disk: Provider-managed (EBS encryption, GCP persistent disk encryption). Covers backups, snapshots automatically.
• Database TDE: Postgres TDE via the cloud provider's managed offering. Encrypts the data files on disk.
• Application-layer column encryption: For sensitive fields like SSN, DOB, clinical notes. Use envelope encryption with KMS-managed data encryption keys.
• TLS everywhere: TLS 1.2 minimum (TLS 1.3 preferred), HSTS with preload, no SSLv3/TLS 1.0/1.1.
• Backup encryption: Encrypted with separate keys from production. Test restore quarterly.
• Key management: AWS KMS, GCP KMS, Azure Key Vault, or HashiCorp Vault. Annual key rotation. Audit log for every key access.

Access controls are the most-cited HIPAA finding category. Build them at the data layer, not the UI layer. UI-only hiding is a recurring audit fail.

• Unique user IDs. No shared accounts. Service accounts get unique IDs too.
• MFA enforced. SSO with MFA for all workforce access. Hardware keys for admins where feasible.
• RBAC at the database. Use Postgres row-level security (RLS) or equivalent. Application middleware is a backup, not the primary boundary. See our multi-tenant SaaS with Postgres RLS guide.
• Just-in-time elevation. Support staff request elevated access per-incident with reason capture and time limits.
• Termination automation. When workforce members offboard, all access revokes within 24 hours, ideally same day.
• Privileged session recording. Database admin sessions, prod shell sessions, captured for review.

Audit logs are how you prove the program works. The pattern we ship:

1. Application emits structured audit events on every PHI access (read, create, update, delete).
2. Events written to an append-only Postgres table with row-level immutability triggers.
3. Events also forwarded to long-term archive (S3 Glacier with object-lock, BAA covered).
4. Six-year retention minimum. Many programs keep ten.
5. Real-time anomaly detection on unusual access patterns (volume spikes, off-hours access, geographic outliers).
6. Quarterly audit log review by the privacy officer. Documented.

What to log: actor identity, action, resource ID, timestamp, IP, user agent, outcome (success/fail), and request reason for elevated-access flows. Do NOT log the PHI itself unless absolutely necessary — log the resource ID instead.

The single most common HIPAA architecture mistake we see: PHI leaks into logs, error reports, and third-party analytics. Build redaction at the application boundary so PHI does not escape into systems without BAA coverage.

• Structured logging with explicit field allowlists. Unknown fields drop by default.
• Pre-Sentry middleware that scrubs request bodies and stack-trace variables.
• No client-side telemetry of patient inputs. PostHog and similar require careful field-level scrubbing.
• Sanitize URL paths — patient IDs in URLs end up in CDN logs.
• Audit your CDN and WAF logs. Cloudflare WAF logs without BAA coverage are a risk.

HIPAA mandates a 60-day breach notification window for impermissible disclosures affecting 500+ individuals. Have the plan written before you need it.

• Defined incident classification (Sev 1/2/3) with response timelines.
• Named incident commander role with delegation.
• Breach assessment protocol — what triggers the 60-day clock.
• OCR notification template ready.
• Individual notification template ready.
• Annual tabletop exercise. Document it.
• Forensic readiness — log retention, evidence collection procedure.

The Security Risk Analysis is the most-skipped HIPAA requirement and the easiest finding for an auditor. Annual SRA, documented, with risk treatment decisions, owners, and remediation timelines.

We use NIST 800-30 as the SRA methodology. Threats and vulnerabilities are inventoried, likelihood and impact scored, residual risk calculated after compensating controls, and treatment decisions logged. The output is a 30-50 page document that auditors love.

HIPAA does not name penetration testing explicitly, but auditors expect it. Plan on:

• Annual web application penetration test. Budget $15K to $40K. See our pentest cost guide.
• Quarterly authenticated vulnerability scans.
• Dependency scanning in CI (Snyk, Dependabot, Trivy).
• SAST in CI for code review automation.
• Documented patch SLA (critical < 7 days, high < 30 days).

See our pentest vs scan explainer for the distinction.

HITRUST CSF is a control framework that maps HIPAA, NIST, ISO, and others. Many large hospital systems prefer or require HITRUST i1 or r2 certification from vendors. Plan on $50K to $200K and 9 to 18 months for full HITRUST r2.

Pursue HITRUST when buyers are demanding it. Do not pursue it before then — HIPAA self-attestation plus SOC 2 Type II is usually sufficient for most healthcare buyers.