Short answer: These three frameworks overlap heavily at the control layer — access control, logging, incident response, supplier management and change control appear in all three — but they differ fundamentally in what they are. ISO 27001 certifies a management system. NIST CSF 2.0 is a voluntary outcomes framework with no certification. SOC 2 is an auditor's attestation about a service organisation. You can implement one control set and satisfy all three, but you cannot map the frameworks one-to-one, because two of the three demand things the other has no concept of.
Work through the mappings interactively in the Control Mapper & Gap Assessment, look up individual controls in the ISO 27001 Control Reference, and record treatment decisions in the Risk Register.
What each framework actually is
This distinction is the one most crosswalk articles skip, and it determines everything downstream.
| ISO/IEC 27001:2022 | NIST CSF 2.0 | SOC 2 | |
|---|---|---|---|
| Type | Certifiable management system standard | Voluntary framework of outcomes | Attestation report by a licensed CPA firm |
| Structure | Clauses 4–10 (the ISMS) + Annex A (93 controls) | 6 Functions, 22 Categories, 106 Subcategories | 5 Trust Services Categories; Security = Common Criteria CC1–CC9 |
| Scope decided by | You, documented in the scope statement | You, via Organizational Profiles | You, in the system description |
| Output | Certificate from an accredited body, 3-year cycle with surveillance audits | Current/Target Profile and a gap plan | Type 1 (design at a point in time) or Type 2 (operating effectiveness over a period, typically 3–12 months) |
| Who asks for it | Global customers, tenders, regulators | US federal supply chain, boards, internal strategy | North American SaaS buyers, procurement |
| Mandatory core | Clauses 4–10 are non-negotiable; Annex A controls are selectable via the SoA | Nothing is mandatory | Security (Common Criteria) is mandatory; the other four categories are optional |
The practical consequence: NIST CSF has no equivalent of ISO Clause 9.3 (management review) or Clause 10 (nonconformity and corrective action), and SOC 2 has no equivalent of the Statement of Applicability. Conversely, ISO has no equivalent of SOC 2's requirement that an independent auditor test operating effectiveness across a period with sampled evidence.
You can map controls. You cannot map governance obligations. Plan for both.
The structures side by side
ISO/IEC 27001:2022 Annex A reorganised the 114 controls of the 2013 edition into 93 controls across four themes:
- Organizational (37)
- People (8)
- Physical (14)
- Technological (34)
Eleven controls are genuinely new, and they are the ones that most often expose gaps in a 2013-era ISMS: threat intelligence (5.7), information security for use of cloud services (5.23), ICT readiness for business continuity (5.30), physical security monitoring (7.4), configuration management (8.9), information deletion (8.10), data masking (8.11), data leakage prevention (8.12), monitoring activities (8.16), web filtering (8.23) and secure coding (8.28). ISO/IEC 27002:2022 contains a correspondence annex mapping 2022 controls back to 2013, which is the authoritative source for transition work.
NIST CSF 2.0 (published February 2024) added a sixth function, Govern (GV), alongside Identify, Protect, Detect, Respond and Recover. Govern is the significant change: it pulls organisational context, risk management strategy, roles and responsibilities, policy, oversight and — importantly — supply chain risk management (GV.SC) into a first-class function. That move brought CSF structurally closer to ISO 27001's management-system clauses than version 1.1 ever was.
SOC 2 rests on the AICPA Trust Services Criteria. The Common Criteria (CC1–CC9) are organised on the COSO internal control framework: control environment, communication, risk assessment, monitoring, control activities, logical and physical access, system operations, change management, and risk mitigation. Security is always in scope; Availability, Confidentiality, Processing Integrity and Privacy are elected based on what you commit to customers.
Where they genuinely overlap
These are the areas where a single implemented control produces evidence for all three. This is where the "test once, satisfy many" economics live.
| Control domain | ISO 27001:2022 Annex A | NIST CSF 2.0 | SOC 2 |
|---|---|---|---|
| Identity and access management | 5.15–5.18, 8.2–8.5 | PR.AA-01 … PR.AA-06 | CC6.1, CC6.2, CC6.3 |
| Asset inventory and classification | 5.9–5.13 | ID.AM-01 … ID.AM-08 | CC6.1, CC3.2 |
| Risk assessment and treatment | Clause 6.1, 5.7 | ID.RA, GV.RM | CC3.1–CC3.4 |
| Logging and monitoring | 8.15, 8.16 | DE.CM, DE.AE | CC7.2 |
| Incident management | 5.24–5.28 | RS.MA, RS.AN, RS.MI, RC.RP | CC7.3, CC7.4, CC7.5 |
| Change management | 8.32 | PR.PS-06, ID.IM | CC8.1 |
| Supplier / third-party risk | 5.19–5.23 | GV.SC-01 … GV.SC-10 | CC9.2 |
| Business continuity / resilience | 5.29, 5.30, 8.14 | RC.RP, PR.IR-04 | A1.1–A1.3 (Availability) |
| Awareness and training | 6.3 | PR.AT-01, PR.AT-02 | CC1.4, CC2.2 |
| Data protection / encryption | 8.24, 8.10–8.12 | PR.DS-01, PR.DS-02 | CC6.7, C1.1–C1.2 (Confidentiality) |
| Vulnerability management | 8.8 | ID.RA-01, PR.PS-02 | CC7.1 |
| Secure development | 8.25–8.31 | PR.PS-06 | CC8.1 |
| Physical security | 7.1–7.14 | PR.AA-06, PR.IR-02 | CC6.4, CC6.5 |
| HR security | 6.1–6.6 | GV.RR-04, PR.AT | CC1.1, CC1.4, CC1.5 |
Two cautions before you copy this into a spreadsheet and call it done.
Mappings are approximate by nature. A NIST subcategory is an outcome ("access permissions are managed, incorporating least privilege and separation of duties"); an ISO Annex A control is a control statement; a SOC 2 criterion is a criterion an auditor tests. Relationships are usually many-to-many and rarely exact. Any crosswalk — including this one — is an aid to implementation, not an audit position. Your certification body and your CPA firm each decide what satisfies them.
Verify against the authoritative sources. NIST maintains machine-readable informative references through its OLIR programme, ISO/IEC 27002:2022 carries the 2013↔2022 correspondence, and the AICPA publishes points of focus for each criterion. Generative AI tools are notably unreliable at producing these mappings from memory — treat any mapping you did not verify against a primary source as a hypothesis.
Where they diverge — and what that costs you
ISO 27001 requires an ISMS; the others do not. Clauses 4–10 demand documented scope, an information security policy, defined roles, risk assessment and treatment methodology, a Statement of Applicability justifying inclusion and exclusion of all 93 Annex A controls, measurable objectives, internal audit, management review at planned intervals, and a corrective action process. NIST CSF asks for none of this. SOC 2 tests governance indirectly through CC1–CC5 but has no SoA and no certification cycle.
If you built to CSF and now want ISO, the gap is almost never controls — it is the management system.
SOC 2 requires evidence over time; ISO samples differently. A Type 2 report tests operating effectiveness across a defined period. If your access review did not happen in Q2, no amount of policy documentation repairs it. ISO auditors also sample evidence, but the certification model, cycle and materiality differ. Design your evidence collection for the more demanding of the two: continuous, timestamped, retrievable.
CSF has implementation tiers and profiles; the others have neither. Tiers 1–4 describe rigour, not compliance. Profiles let you express a target state and measure toward it. This makes CSF the better communication instrument for a board conversation, even in an organisation certified to ISO.
Scope means three different things. ISO scope is a formal, certificate-bearing statement. SOC 2 scope is the system description your auditor opines on. CSF scope is whatever you choose to profile. Do not assume one scope decision satisfies all three.
Building one control library
The efficient architecture is a single internal control library with framework mappings as attributes, not three parallel control sets.
- Define controls in your own language, at the granularity you actually operate.
AC-04: Privileged access is granted through PIM with approval and time limits, and reviewed quarterly. - Attach mappings as metadata — ISO 8.2, CSF PR.AA-05, SOC 2 CC6.1/CC6.3. One control, several tags.
- Attach the evidence source, not a description of it. Name the system, the export, the owner and the frequency. "PIM activation and approval export, monthly, IT Security Manager."
- Automate the collection. Anything a human assembles quarterly will be assembled badly. Pull from source systems on a schedule.
- Run gap assessment against each framework as a filter over the same library rather than as three separate exercises. This is exactly what the Control Mapper is built to do — assess once, report per framework.
- Keep the SoA generated, not maintained by hand. If your library carries ISO mappings and applicability decisions, the SoA is a report, not a document.
Sequencing advice for organisations doing more than one: if you need SOC 2 for a North American sales cycle and ISO 27001 for international tenders, build the control library and evidence pipeline first, take SOC 2 Type 1 for speed, layer the ISMS clauses on top, then run Type 2 and ISO certification in parallel. Doing ISO first and retrofitting evidence for a Type 2 period is the slower path.
A realistic view of effort
Consolidation genuinely saves work — a large share of the control effort is shared. But the framework-specific overhead does not compress:
- ISO-only work: SoA, internal audit programme, management review, corrective actions, certification audit stages 1 and 2.
- SOC 2-only work: system description, auditor readiness, evidence sampling across the observation period, the report itself.
- CSF-only work: profile development and tier assessment (comparatively light — and reusable as board reporting).
Budget for the overlap in controls and the divergence in governance. Teams that promise leadership "one project, three frameworks" usually discover the ISMS clauses in month five.
Related: Third-Party Risk Management · EPSS vs CVSS vs KEV: A Data-Driven Patch Prioritisation Model · Zero Trust Cheat Sheet