SOC 2 vs HIPAA compliance: side by side.

SOC 2 is an attestation, not a certification. A licensed CPA firm audits your organization against the AICPA Trust Services Criteria — the universal Security bucket (CC1–CC9, the common criteria for control environment, communication, risk assessment, monitoring, and change management) and four optional categories: Availability, Processing Integrity, Confidentiality, and Privacy. The deliverable is a customer-facing report attesting to the design and operating effectiveness of those controls over a defined period.

In practice, SOC 2 is principle-based. The auditor wants evidence that your access reviews happen, that your change management includes approval and testing, that incidents are detected and responded to, and that monitoring is continuous. The standard does not prescribe MFA on every administrator account by section number; it asks for the outcome and lets the engineer choose the mechanism.

HIPAA is a federal regulation enforced by HHS / the Office for Civil Rights, not an attestation. The Security Rule (45 CFR Part 164, Subpart C) is the dense part: administrative safeguards (§164.308), physical safeguards (§164.310), and technical safeguards (§164.312). The Privacy Rule (§164.502–§164.514) governs how covered entities and business associates may use and disclose PHI. Breach Notification (§164.404) requires affected individuals, HHS, and — above 500 records — the media to be notified within 60 days.

HIPAA is prescriptive. Where SOC 2 asks for evidence that access control exists, HIPAA names the controls: unique user identification (§164.312(a)(2)(i)), automatic logoff (§164.312(a)(2)(iii)), and encryption in transit and at rest when reasonable and appropriate. HIPAA carries civil monetary penalties and, in egregious cases, criminal liability. PHI is the entire point of the regulation.

Two concrete buyer archetypes hit this every quarter. The first is a digital health or healthtech SaaS: software that handles PHI on behalf of hospitals, payers, or telehealth providers. They are HIPAA business associates from day one, and the moment those providers ask for a SOC 2 report (often in the procurement questionnaire), the team inherits a parallel attestation workload.

The second is a mid-market SaaS whose customers are asking — usually in a security review — for “a SOC 2 report or equivalent.” Half of those customers also ingest or transit PHI on behalf of their own HIPAA-covered entity, even if the SaaS itself is not regulated. The cleanest path is a dual framework program: SOC 2 as the external report, HIPAA as the internal standard for PHI-handling surfaces, with one evidence trail feeding both.

The two frameworks share most of the same controls. The honest way to map them is named-criterion to named-criterion, then let one scanner surface serve both.

Access control

SOC 2 CC6.1 – CC6.3 cover logical access (authentication, authorization, provisioning), physical access, and privileged access. HIPAA §164.312(a) is the technical safeguards section on access control, and §164.308(a)(3) is workforce security — termination procedures, clearance, and the supervisory layer. Same controls: MFA on root, just-in-time privileged access, role-based reviews, evidence captured continuously rather than quarterly.

Audit logging

SOC 2 CC7.2 asks for system monitoring that produces evidence controls are operating. The HIPAA equivalent — §164.312(b) — is a single one-paragraph requirement (audit controls) that mandates hardware, software, and procedural mechanisms recording PHI access. Both frameworks are asking for the same thing: a tamper-evident trail of who touched what data, when, and why.

Incident response

SOC 2 CC7.3 – CC7.5 cover incident detection, response, and recovery — tempoed, with named roles and post-mortems. HIPAA matches with §164.308(a)(6) (security incident procedures) and Breach Notification (§164.404), which adds a hard 60-day clock on disclosures to affected individuals, HHS, and the media. SOC 2 asks for a response capability; HIPAA demands one and times it.

Where they diverge is the framing. HIPAA is prescriptive because it regulates a specific data class — PHI — and the regulator can apply penalties. SOC 2 is principle-based because it is a market signal: any set of controls that meet the Trust Services Criteria, audited by an independent firm, earns the report.

The simplest mental model is that the audit asks two different questions about the same underlying system. A continuous watch plane turns one stream of findings into both answers at once: an IAM drift surfaces once — as a SOC 2 CC6 finding and as a HIPAA §164.312(a) finding — without the team double-classifying, writing the same narrative twice, or running the same remediation in parallel.

The health board view collapses severity-aware rollups so a lead auditor or a HIPAA officer sees the same posture, ranked identically, with the same evidence trail. The cross-mapped control IDs — a CC6 finding tagged to §164.312(a)(2)(i), a CC7.2 audit log gap also tagged to §164.312(b) — make evidence requests come back answered during the actual SOC 2 audit cycle, not six weeks into it.

If you are running SOC 2 and HIPAA in parallel today, the live dashboards for each are at /dashboard/frameworks/soc2 and /dashboard/frameworks/hipaa. Both are auth-gated — visitors without a session are routed to /login and bounced back, which is the same flow your auditors and security reviewers will experience.

The clearest takeaway from running SOC 2 + HIPAA together is that dual compliance is cheaper than it looks if the evidence trail is unified. Different frameworks, different report deliverables, same control plane. The auditor wants to see evidence; the regulator wants to see named safeguards. A continuous health board gives you both without rebuilding the same controls twice.