Mapping ISO 27001 Annex A to SOC 2 — where the overlap really is
The second framework is mostly re-filing, not double work. Where Annex A and the Trust Services Criteria genuinely coincide, and the four areas where neither covers the other.
Rony Shulkin · Software Engineer

On this page
If you hold one and are being asked for the other, the useful number is this: a large majority of the evidence you already collect will answer both. The second framework is mostly a re-filing exercise. What it is not is zero work, and the parts that are genuinely new are predictable enough to plan for.
This assumes ISO/IEC 27001:2022, whose Annex A was restructured into 93 controls across four themes, and SOC 2's Common Criteria.
Why they overlap at all
Both descend from the same lineage of control thinking, so they ask similar questions in different registers.
The structural difference matters more than the control lists. ISO 27001 certifies a management system — the ISMS, clauses 4–10 — and Annex A is a reference set you select from and justify in a Statement of Applicability. SOC 2 is an attestation by a CPA firm that controls meeting the Trust Services Criteria were designed and, for Type II, operating over a period.
So ISO asks do you run a system for managing security, and can you show it improving. SOC 2 asks did these specific controls work over these months. The evidence overlaps heavily; the framing does not.
Where the overlap is strongest
Access control — near-total
Annex A 5.15 (access control), 5.16 (identity management), 5.17 (authentication information), 5.18 (access rights), 8.2 (privileged access), 8.3 (information access restriction), 8.5 (secure authentication) map onto SOC 2 CC6.1, CC6.2 and CC6.3 almost cleanly.
The same artefacts serve both: the user listing with grant dates, approval records, quarterly reviews, privileged access justification, MFA configuration, termination-to-revocation timing. Collect once, file twice.
Operations and logging — very strong
A 8.15 (logging), 8.16 (monitoring), 8.6 (capacity), 8.7 (malware), 8.8 (vulnerabilities) sit against CC7.1 and CC7.2. Scan results, remediation tickets, log configuration and alert history answer both.
Change management — very strong
A 8.31 (separation of environments), 8.32 (change management), 8.25–8.29 (secure development) against CC8.1. Your deploy listing, pull request reviews and branch protection config cover it.
Incidents — strong, with a wrinkle
A 5.24–5.28 against CC7.3, CC7.4 and CC7.5. Same incident records.
The wrinkle: ISO explicitly wants evidence collection procedures (5.28) with forensic soundness in mind. SOC 2 does not press on this. It is a small documentation addition, not a new capability.
Vendors — strong
A 5.19–5.23 against CC9.2. Vendor inventory, due diligence, contract terms, reviews. ISO 5.23 calls out cloud services specifically, which SOC 2 folds into general vendor management.
Cryptography, physical, HR — strong to moderate
A 8.24 against CC6.7. A 7.1–7.14 against CC6.4 and CC6.5 — both largely satisfied by your data centre provider's own report if you are cloud-hosted. A 6.1–6.6 against CC1.4 and CC1.5.
Where they genuinely diverge
Four areas. These are the ones to budget for.
The ISMS itself — ISO only
Clauses 4–10 have no SOC 2 equivalent, and this is the bulk of net-new work going ISO-first:
- Context of the organisation and interested parties (4)
- Leadership, policy, roles (5)
- Risk assessment methodology, risk treatment plan, Statement of Applicability (6)
- Competence, awareness, documented information (7)
- Operational planning and control (8)
- Internal audit and management review (9)
- Nonconformity, corrective action, continual improvement (10)
The Statement of Applicability is the artefact with no analogue at all: all 93 Annex A controls, each marked applicable or not, each with a justification. Auditors read it closely.
Internal audit and management review are the other two. SOC 2's CC4.1 gestures at monitoring but does not require an independent internal audit function or a formally minuted management review on a defined cycle.
Period of operation — SOC 2 only
A Type II tests over months and samples occurrences. ISO certification audits examine the system at a point, with surveillance audits after.
Practically: SOC 2 demands retained evidence across the whole period — see continuous control monitoring vs point-in-time audit. ISO is more forgiving about historical depth and less forgiving about whether the management system exists and functions. A team that passed ISO can be surprised by how much history a Type II wants.
The Trust Services categories — SOC 2 only, if selected
Availability, Confidentiality, Processing Integrity and Privacy are optional SOC 2 categories with no direct Annex A counterpart. Availability partially maps to A 5.29–5.30 and 8.13–8.14; Privacy overlaps ISO 27701 rather than 27001.
Threat intelligence and data masking — ISO 2022 additions
A 5.7 (threat intelligence), 8.10 (information deletion), 8.11 (data masking), 8.12 (data leakage prevention), 8.23 (web filtering), 8.28 (secure coding) were new or newly explicit in the 2022 revision. Several have thin SOC 2 equivalents.
Doing both without doing it twice
Map at the evidence level, not the control level. Control-to-control mapping tables are a documentation exercise. What saves real time is knowing that this quarterly access review export answers A 5.18 and CC6.2 and CC6.3, and filing it against all three at collection.
Collect once, against the stricter requirement. Where the two disagree on frequency or depth, satisfy the stricter one and the looser is covered automatically.
Watch the direction of travel. ISO-first then SOC 2: your controls are fine, your evidence history may be thin — start retaining early. SOC 2-first then ISO: your evidence is strong, you have no ISMS — budget for the SoA, internal audit and management review.
Expect a genuine gap of maybe 15–25%, mostly the ISMS clauses. Anyone promising near-total reuse is counting Annex A against the Common Criteria and quietly ignoring clauses 4–10.
Why we build it this way
Mapping in both directions — control to evidence, evidence to every control it satisfies — is the core of how Cyberwiz models compliance, and the reuse is made visible rather than implied. When you upload an access review, you can see the seven controls across both frameworks it just answered.
That visibility is the point. A team that cannot see reuse re-collects, and re-collecting is where the second framework's reputation for doubling the work comes from.