Many organizations end up running both. ISO 27001 arrives because a customer or a market wants a certificate. The NIST Cybersecurity Framework arrives because a board, a regulator, or a parent company wants posture described in its terms.
Running them as two programs doubles the work for no extra assurance. Mapping one to the other lets you implement controls once and report on them both ways. This article shows how the CSF 2.0 functions line up with ISO/IEC 27001:2022, where the correspondence is weak, and how to build a mapping you can defend.
Two different kinds of document
The mapping only makes sense once you see that the two documents do different jobs.
ISO/IEC 27001:2022 is a requirements standard for an information security management system. Clauses 4 to 10 set mandatory requirements for the management system: context, leadership, planning, support, operation, performance evaluation, and improvement. Annex A lists 93 controls in four themes: organizational, people, physical, and technological. You select controls through risk treatment and record the decisions in a Statement of Applicability. An accredited certification body can certify you against it, as the ISO 27001 framework page outlines.
NIST CSF 2.0 is a voluntary framework of outcomes. It has no mandatory clauses and no certification. Its Core describes what should be true, organized into six functions, 22 categories, and the subcategories beneath them. Our overview of the six functions covers that structure.
So the mapping is not control to control. It is outcome to requirement or control, and it is many to many. One Annex A control can support several subcategories. One subcategory can need several controls plus a clause requirement.
Function by function
The table gives the main correspondences. It is a starting point, not a complete or authoritative mapping.
| CSF function | ISO 27001 clauses | Annex A examples |
|---|---|---|
| Govern | 4 (context), 5 (leadership), 6.1 (risk criteria and planning) | 5.1 policies, 5.2 roles and responsibilities, 5.19 to 5.23 supplier relationships and cloud services, 5.31 legal and contractual requirements |
| Identify | 6.1.2 and 8.2 (risk assessment), 9.2, 9.3, and 10 (for the improvement category) | 5.7 threat intelligence, 5.9 inventory of assets, 5.12 classification, 8.8 technical vulnerabilities |
| Protect | 7.2 and 7.3 (competence and awareness) | 5.15 to 5.18 access control and identity, 6.3 awareness training, 8.5 secure authentication, 8.9 configuration management, 8.24 cryptography |
| Detect | None directly | 5.25 assessment of events, 6.8 event reporting, 8.15 logging, 8.16 monitoring activities |
| Respond | None directly | 5.24 incident planning, 5.26 response to incidents, 5.27 learning from incidents, 5.28 collection of evidence |
| Recover | None directly | 5.29 security during disruption, 5.30 ICT readiness for business continuity, 8.13 backup, 8.14 redundancy |
Two patterns stand out. Govern and Identify map largely to clauses, because they describe management activities that ISO 27001 makes mandatory. Protect, Detect, Respond, and Recover map largely to Annex A, because they describe operational safeguards.
A caution on clauses 9 and 10. They concern the management system: monitoring its performance, auditing it, and correcting its nonconformities. They are not security monitoring or incident response, even though the vocabulary sounds close. For a tour of the controls side, see our article on the ISO 27001:2022 Annex A themes.
Where the mapping is weak
A mapping that hides its gaps causes trouble later. These are the places to be careful.
Recover has thin coverage. ISO 27001 addresses continuity and backup, but CSF recovery outcomes include executing a recovery plan and communicating during recovery. Controls 5.29 and 5.30 cover part of that. You may need recovery procedures that go further than your ISO controls require.
Oversight is framed differently. CSF's oversight category (GV.OV) asks that the results of the risk strategy be reviewed and the strategy adjusted. ISO 27001's internal audit (clause 9.2) and management review (clause 9.3) reach similar ends, scoped to the management system. Check that your management review discusses cybersecurity risk strategy, not only ISMS performance.
Risk appetite has no exact twin. ISO 27001 clause 6.1.2 requires risk acceptance criteria. CSF's risk management strategy category asks for risk appetite and tolerance statements. Acceptance criteria can be written to serve both, but they are not automatically the same thing.
Profiles and tiers have no ISO equivalent. A Statement of Applicability records which controls you apply and why. A CSF profile records the outcomes you achieve and the ones you target. They answer different questions, so do not make one document do both. Our guide to writing a Statement of Applicability covers what the SoA must contain, and our guide to current and target profiles covers the CSF side.
Granularity differs. Some subcategories are broader than any single control. Others are narrower. Mark each link as full or partial, so nobody reads a partial match as coverage.
Building a mapping you can defend
NIST publishes informative references that relate CSF subcategories to other standards, through its online reference tooling. Check what is currently available for ISO/IEC 27001:2022, and who produced it, before relying on it. Treat any published mapping as a draft that you confirm against your own controls.
A workable process:
Start from your Statement of Applicability. It already lists the Annex A controls you apply. Each one is a candidate source for CSF subcategories.
Map from the CSF side. For each subcategory, list the clauses and controls that support it. Working subcategory by subcategory exposes gaps. Working control by control tends to hide them.
Record the strength. Mark each link as full, partial, or related only. Write a sentence of rationale for every partial link.
List the gaps. Subcategories with no full support become actions, or explicit decisions not to pursue them.
Assign one owner. The mapping goes stale the first time someone adds a control and forgets to tag it. One person reviews it on a set cycle.
If you have worked through control overlap between frameworks before, the method is the same. The difference is that CSF subcategories are outcomes. The question for each link is "does this control produce this outcome", not "do these two controls say the same thing".
Using one evidence set for both
The payoff of a good mapping is evidence reuse. An access review record that supports ISO 27001 control 5.18 also supports the CSF's identity and access outcomes. A documented restore test supports both control 8.13 and the CSF's recovery plan execution category.
Two conditions make this work. The evidence is stored once, with the control it belongs to, and tagged to every requirement it supports. And it is strong enough for the stricter use. A certification auditor samples evidence formally against your stated controls. Evidence that holds up there will usually serve a CSF self-assessment as well. The reverse is less reliable.
Watch the scopes as well. Your ISMS scope statement defines what the ISO 27001 certificate covers. A CSF profile can have a different scope, such as a single product or the whole group. Where the profile reaches beyond the ISMS scope, the ISO evidence does not cover the difference, and you will need to collect it separately or narrow the profile. Write the relationship between the two scopes into the mapping document, so a reader can see at a glance which outcomes rest on certified controls and which rest on self-assessment.
How TrustLynce helps
TrustLynce maps controls across frameworks and reuses evidence between them, so a control tagged to ISO 27001 can carry its CSF subcategories too (compliance automation). It also maintains the Statement of Applicability for ISO 27001, which keeps the starting point of the mapping current.