Mapping SOC 2 to ISO 27001 to HIPAA without losing your mind
A practical guide to the cross-framework mapping work that nobody warns you about. Including which controls actually overlap, which ones do not, and where the spreadsheets break down.
Every regulated company runs into the same wall: you got SOC 2. The next customer wants ISO 27001. The customer after that wants HIPAA. The customer after that wants HITRUST.
If you are smart, you have a control library that gets reused across frameworks. If you are not yet smart, you have a separate implementation for each one and your evidence team is in pain. Either way, mapping is real work and it is rarely as clean as the marketing decks make it look.
The fundamental shape
Frameworks are not equivalent. They are overlapping in places, contradictory in others, and orthogonal in still others.
- SOC 2 is principles-based and audited against your stated policies. The trust services criteria (CC1 through CC9, plus the categories you select: A, C, PI, P) give you a structure, but the controls are largely your own.
- ISO 27001 is built around an Information Security Management System (ISMS). Annex A controls (now reorganized into 4 themes in the 2022 update) are required to be considered, but you can deviate with a documented Statement of Applicability.
- HIPAA Security Rule is administrative, physical, and technical safeguards. Many are “required”; many are “addressable”, which is regulator code for “implement or document why not”.
- HITRUST CSF is a unified, prescriptive framework that already maps across many of these. It is also the one that requires the most evidence per control.
A pure technical control like “logical access reviewed quarterly” maps cleanly across all four. A control like “data classification policy” maps in name but the requirements drift: SOC 2 wants the policy, ISO 27001 wants the policy plus evidence of training, HIPAA wants the policy plus evidence the policy was applied to PHI specifically, HITRUST wants all of the above plus quantitative metrics.
Where the spreadsheets break down
Most teams build a control catalog in a spreadsheet. Columns: Control ID, description, owner, status, evidence link. Rows: one per control, often a thousand or more once you map across frameworks.
This works until the second framework. It collapses by the third. Specifically:
- Same control, different evidence requirements. Your CC6.1 (logical access) and ISO A.5.15 (access control) and HIPAA § 164.308(a)(4) (information access management) are conceptually the same control. Each auditor wants different evidence. Your spreadsheet now needs a row per control × framework combination, or a multi-tab catastrophe.
- Different control, same underlying activity. “Backup integrity testing” is one control in SOC 2, two in ISO 27001 (A.8.13 and A.5.30), and split across required + addressable in HIPAA. Mapping this with a column per framework gets you 30% of the way; the actual review of the work happens in commit messages on a script that nobody can find.
- Drift over time. ISO 27001 had 114 Annex A controls in 2013 and 93 in 2022, regrouped under different themes. Your 2024 mapping is wrong by 2025 if you did not version it. Your 2026 customer is asking about the 2022 update; your spreadsheet still has the 2013 numbering.
- Owner accountability. A spreadsheet is not where engineers live. Engineers live in Jira, GitHub, Linear, ticketing systems. A control with an owner field that points to a name in a spreadsheet has a fictional owner.
The actual overlap (rough)
If you are starting from SOC 2 and need to add ISO 27001, here is the real mapping at the top level:
| SOC 2 (CC) | ISO 27001:2022 (Annex A) | What overlaps |
|---|---|---|
| CC1. Control Environment | A.5.1, A.5.2, A.5.4 | Governance + roles |
| CC2. Communication | A.5.16, A.6.3 | Internal/external comms; awareness |
| CC3. Risk Assessment | A.5.7, A.5.10, A.5.13 | Risk methodology; threat intel |
| CC4. Monitoring | A.5.36, A.8.16 | Compliance monitoring; activities monitoring |
| CC5. Control Activities | Crosscuts most A.5, A.8 | Implementation across themes |
| CC6. Logical & Physical Access | A.5.15, A.5.18, A.7.1, A.7.14 | Access controls; physical security |
| CC7. System Operations | A.8.1, A.8.6, A.8.16 | Endpoints; capacity; logging |
| CC8. Change Management | A.8.32 | Change control |
| CC9. Risk Mitigation | A.5.20, A.5.23, A.5.30 | Supplier management; BCM |
This is the rough scaffolding. The real work is in the requirement deltas inside each cell. ISO 27001 wants threat intelligence as a discrete control (A.5.7). SOC 2 implies it. HIPAA does not mention it. If your control catalog says “covered by CC3”, an ISO auditor will mark it gap.
For HIPAA, the mapping is more uneven because HIPAA is regulation, not a framework:
- HIPAA § 164.308(a)(1) (security management) ↔ SOC 2 CC1, CC3, CC4 ↔ ISO A.5.1, A.5.2, A.5.36
- HIPAA § 164.308(a)(4) (access management) ↔ SOC 2 CC6.1, CC6.2 ↔ ISO A.5.15, A.5.16
- HIPAA § 164.308(a)(7) (contingency plan) ↔ SOC 2 A1.2, A1.3 ↔ ISO A.5.29, A.5.30
- HIPAA § 164.312(c) (integrity) ↔ SOC 2 PI1.1 ↔ ISO A.8.13
For HITRUST, the framework already provides a mapping table that includes SOC 2 and ISO 27001 references. If you are heading to HITRUST, do not bother with manual mapping. Start from their CSF and reverse-map your existing controls into it.
What to actually do
If you only have SOC 2 today and you are about to add ISO 27001:
- Stop adding columns to the spreadsheet. Move to a tool. Yours, ours, anyone’s. That lets a control reference multiple frameworks without duplicating the control itself.
- Write the deltas, not the duplicates. A control like “annual access review” gets one definition, then per-framework notes about what evidence each auditor wants.
- Tie evidence to the control, not to the framework. When you collect a quarterly access-review screenshot, it should satisfy the SOC 2 control, the ISO 27001 control, the HIPAA addressable, and the HITRUST quantitative requirement, all from one capture.
- Pre-build the gap analysis. When you add a framework, the gap should be machine-derived from the existing control library plus the new framework’s requirements. If you are building it by hand, you will miss things.
Why I am writing this
We built opsnite because the cross-framework mapping work is exactly the work the platform should do for you. Adding a new framework copies your existing controls and shows you the gap. Evidence captures attach to controls and propagate to every framework that references them. Drift between framework versions is handled by versioning the framework itself.
You can do this yourself with spreadsheets and grit. I have done it three times. I will not do it a fourth.