A SaaS company selling to healthcare usually hears two requests in the same security review: "Send us your SOC 2 report" and "Confirm you comply with HIPAA." The controls behind those answers overlap heavily. Building them twice is wasted work.
The overlap has limits, though. A SOC 2 report is an attestation against the AICPA's trust services criteria. HIPAA is a federal regulation with no certification at all, and HHS does not recognize any third-party HIPAA certification. A clean SOC 2 report does not show HIPAA compliance by itself.
This article gives a working map from HIPAA's Security Rule to SOC 2's criteria, shows where the map breaks, and sets out how to run one control set that serves both.
Why the two map at all
The HIPAA Security Rule at 45 CFR Part 164, Subpart C, groups its standards into administrative, physical, and technical safeguards. SOC 2's common criteria, CC1 through CC9, follow the COSO internal control structure: control environment, communication, risk assessment, monitoring, control activities, and then the security-specific series. The organizing logic differs, but both ask whether you protect systems and data through governance, people, and technology.
The overlap is strongest in the Security Rule. The Privacy Rule and the Breach Notification Rule map weakly, because SOC 2 does not address HIPAA's rules on uses and disclosures or its notification clock. If you are new to the criteria, read the SOC 2 trust services criteria explained first.
A working map
The table below pairs each Security Rule standard with the SOC 2 criteria closest to it. Mapping is a judgment, not an official crosswalk. Agree your version with your auditor, and test it against your own risk analysis.
| HIPAA Security Rule provision | Closest SOC 2 criteria |
|---|---|
| Risk analysis and risk management, §164.308(a)(1)(ii)(A) and (B) | CC3.1 to CC3.4 |
| Sanction policy, §164.308(a)(1)(ii)(C) | CC1.5 |
| Information system activity review, §164.308(a)(1)(ii)(D) | CC7.2, CC4.1 |
| Assigned security responsibility, §164.308(a)(2) | CC1.3 |
| Workforce security and information access management, §164.308(a)(3) and (4) | CC6.2, CC6.3 |
| Security awareness and training, §164.308(a)(5) | CC1.4, CC2.2 |
| Security incident procedures, §164.308(a)(6) | CC7.3, CC7.4 |
| Contingency plan, §164.308(a)(7) | CC7.5, CC9.1; A1.2 and A1.3 if Availability is in scope |
| Evaluation, §164.308(a)(8) | CC4.1 |
| Business associate contracts, §164.308(b) | CC9.2 |
| Facility access, workstation use and security, §164.310(a) to (c) | CC6.4 |
| Device and media controls, §164.310(d) | CC6.5 |
| Access control, §164.312(a) | CC6.1 |
| Audit controls, §164.312(b) | CC7.2 |
| Integrity, §164.312(c) | CC6.1, CC8.1 |
| Person or entity authentication, §164.312(d) | CC6.1 |
| Transmission security, §164.312(e) | CC6.7 |
| Policies, procedures, and documentation, §164.316 | CC5.3 |
Read the right-hand column as "a control that satisfies this SOC 2 criterion usually satisfies part of the HIPAA standard." The word "part" is doing real work. The next section explains where.
Where the map breaks
Seven gaps come up repeatedly. Each needs a control or a record that SOC 2 will not give you on its own.
Scope. A SOC 2 report covers the system you describe in your system description. HIPAA covers wherever ePHI is, full stop. An analytics copy, a support tool, or a data export outside your SOC 2 boundary is still in HIPAA scope.
Addressable specifications. HIPAA requires you to assess each addressable specification and document why you implemented it, an alternative, or neither. SOC 2 has no equivalent. The addressable vs required encryption explainer covers the documentation this needs.
Business associate agreements. CC9.2 asks you to assess and manage vendor risk. It does not check that each subcontractor handling ePHI has signed a BAA with the content §164.314(a) requires.
Breach notification. CC7.3 and CC7.4 cover incident evaluation and response. They do not cover HIPAA's four-factor risk assessment, the 60-day outer limit for notice to individuals, or the business associate's duty to notify the covered entity. Those belong in your incident procedure explicitly. See HIPAA breach notification timelines and thresholds.
The Privacy Rule. SOC 2's privacy category is built around its own criteria, not around HIPAA's permitted uses and disclosures. As a business associate, your use of PHI is limited by your BAAs, and SOC 2 will not test that.
Retention. HIPAA requires six years for required documentation under §164.316(b)(2)(i). SOC 2 sets no retention period for your policies and records.
Time. A SOC 2 Type II report covers an observation period and then stops. HIPAA obligations are continuous. The gap between report periods is still HIPAA time.
Running one control set for both
The practical goal is one set of controls, each tagged with every requirement it serves, with a short list of HIPAA-only additions. A sequence that works:
Define ePHI scope from the HIPAA risk analysis. Then check the SOC 2 system boundary against it. Either extend the boundary or document why the difference is acceptable.
Write each control once. Tag it with its SOC 2 criteria and its HIPAA citations. A quarterly access review, for example, carries CC6.2, CC6.3, and §164.308(a)(4).
Add the HIPAA-only controls. At minimum: a named security official, a BAA register and review, a breach risk assessment procedure, a log of addressable specification decisions, and six-year retention.
Collect evidence once. The same access review export serves both, if it is dated and complete.
Test the HIPAA-only controls yourself. Your SOC 2 auditor will not test them unless engaged to. The evaluation standard at §164.308(a)(8) requires periodic evaluation in any case, so record it.
Say a hypothetical 40-person SaaS company already has a SOC 2 Type II report and signs its first BAA. Most of its access, logging, change, and incident controls carry over with a new citation. The new work is narrower than it looks: extending the system boundary to cover a support tool that displays patient records, adding the breach risk assessment to its incident runbook, recording its encryption decisions, and starting a BAA register for its subprocessors. That is focused work, not a second program.
The control overlap between frameworks article covers the general method for tagging and reusing controls across standards.
Should your SOC 2 report include HIPAA?
The AICPA's SOC 2 guidance allows a service auditor to report on additional subject matter and additional criteria alongside the trust services criteria. These reports are often called SOC 2+ reports. Some companies use this to have the HIPAA Security Rule requirements examined in the same engagement.
Whether it is worth doing depends on your buyers. Some healthcare customers accept a standard SOC 2 report plus a HIPAA self-assessment and a signed BAA. Others want an independent examination of HIPAA requirements, and some ask for HITRUST instead. The HITRUST vs SOC 2 for healthcare buyers article sets out that choice.
Ask your target customers before you commit, and agree the scope with your auditor. Whatever the report says, it describes controls an auditor tested. It does not certify HIPAA compliance, and you should not describe it that way to customers.
How TrustLynce helps
TrustLynce's compliance automation maps each control to HIPAA and SOC 2 requirements together and reuses the same evidence for both. HIPAA-only controls sit in the same register, so the gaps in this article are tracked alongside everything else.