Mapping ISO 27001 to SOC 2: what actually overlaps, and where teams get burned

The pitch every consultant gives you is "ISO 27001 and SOC 2 overlap 80 percent, do one and the other is easy." It's half true. The control language overlaps. The audit mechanics do not, and that gap is where most teams lose a quarter redoing work they thought was done.

So before you copy a crosswalk spreadsheet into your GRC tool and call it a plan, it helps to be precise about what maps to what, and what each auditor is actually going to test.

The two documents are not the same kind of thing

ISO/IEC 27001 certifies a management system. The Annex A controls (93 of them in the 2022 revision, grouped into organizational, people, physical, technological) are the visible part, but the certificate is really about Clauses 4 to 10: context, leadership, risk assessment, risk treatment, the Statement of Applicability, internal audit, management review. An auditor can fail you on Clause 9 alone while every Annex A control is humming.

SOC 2 is an attestation. A CPA firm issues an opinion on whether your controls, as you described them, were suitably designed (Type 1) and operating effectively over a period (Type 2) against the Trust Services Criteria. There is no certificate. There is no ISMS requirement. There is no Statement of Applicability. You pick the categories in scope (Security is mandatory, then Availability, Confidentiality, Processing Integrity, Privacy as needed) and you write the system description yourself.

That difference matters more than any control-to-control table. ISO asks "do you run a risk-managed security program." SOC 2 asks "did these specific controls work, every time, for the last however many months."

Where the mapping is honest

The common-criteria backbone of SOC 2 (the CC series) lines up cleanly with the technical and organizational halves of Annex A. This part of the crosswalk holds up under audit:

Access control is the strongest match. SOC 2 CC6.1 and CC6.2 cover logical access provisioning and authentication. That maps to ISO A.5.15 (access control), A.5.16 (identity management), A.8.2 (privileged access), A.8.5 (secure authentication). If you have a clean joiner-mover-leaver process and enforce MFA, you are feeding both at once. The access control crosswalk is the one place I tell people to start, because the evidence is identical: access reviews, deprovisioning tickets, IdP config.

Change management, CC8.1 to ISO A.8.32. Same pull requests, same approvals, same ticket trail.

Logging and monitoring, CC7.1 and CC7.2 to A.8.15 and A.8.16. Vulnerability management, CC7.1 again to A.8.8. Encryption, CC6.7 to A.8.24. Incident response, CC7.3 to A.5.24 through A.5.26. Vendor risk, CC9.2 to A.5.19 to A.5.22.

None of that is controversial. If you have a real security program, these controls already exist and the ISO 27001 to SOC 2 mapping is mostly a relabeling exercise.

Where it quietly breaks

The risk side does not map. ISO Clause 6.1.2 wants a documented risk assessment methodology, a risk register, owners, and a treatment plan that justifies every included or excluded Annex A control through the Statement of Applicability. SOC 2 has CC3 (risk assessment) but it is far lighter, and no auditor is going to ask for your SoA. Teams coming from SOC 2 into ISO consistently underestimate this. They have controls. They do not have the paper trail explaining why those controls and not others, and Stage 1 of the ISO audit exists specifically to catch that.

The other direction has its own trap. ISO does not care about operating effectiveness across a window the way SOC 2 Type 2 does. ISO surveillance audits sample. A SOC 2 Type 2 auditor wants evidence that a control fired correctly every time it should have over, say, the nine-month period. Quarterly access reviews? Then you need all the quarters in the window, with dates, with the reviewer, with what changed. A snapshot taken the week before fieldwork is worthless. I have watched companies with a valid ISO certificate flunk readiness for SOC 2 because their evidence was a current-state export, not a longitudinal record.

And the system description. SOC 2 reports include a written description of your system, and the auditor opines on whether it is fairly presented. Complementary user entity controls, subservice organizations and the carve-out versus inclusive method, the boundaries of the system. ISO has nothing equivalent. People writing their first SOC 2 description tend to either copy marketing copy or dump an architecture diagram, and both get sent back.

The evidence reuse problem nobody warns you about

Even where the controls map one to one, the evidence often does not transfer without rework, because the two audits ask for it in different shapes.

Take access reviews. For ISO you need to show the review happened and access was appropriate. For SOC 2 Type 2 you need to show the review happened on its defined cadence across the entire period, who performed it, what exceptions were found, and how they were remediated, with timestamps that an auditor can tie to your own stated control frequency. Same underlying control. Different burden of proof.

The practical move is to design the evidence for the stricter consumer first. That is almost always SOC 2 Type 2, because of the period-of-time requirement. Capture longitudinal, dated, owner-attributed evidence, and ISO will accept a sample of it. Do it the other way and you will be backfilling history you never recorded.

This is the actual argument for a crosswalk, by the way. Not "map the controls" but "run one control, capture evidence once, satisfy both auditors." The mapping is the index. The discipline is in the evidence pipeline.

A sane sequence if you are doing both

If you have neither, do SOC 2 Type 1 first, then run the Type 2 observation window, and stand up the ISO management system in parallel during that window. The Type 1 forces you to write controls down and describe the system. The observation window gives you the dated evidence. The ISO clauses (risk assessment, SoA, internal audit, management review) are the part SOC 2 never made you build, so treat them as net-new work and budget accordingly rather than assuming your SOC 2 readiness covered it.

If you already hold ISO 27001, you are closer to SOC 2 than the reverse, but do not skip the operating-effectiveness gap. Pull a real period of evidence for your top controls and see whether it actually exists historically. That dry run tells you more than any gap assessment slide.

The mapping tables are useful. They are not a project plan. Start from the full crosswalk, pick the domains where evidence is shared, and build the pipeline once.