Scope
This guide explains how to integrate NIST CSF 2.0 and ISO/IEC 27001:2022 into a unified security program. You'll learn to map the frameworks, sequence implementation, and operate them as complementary components. This is for security engineers and compliance managers designing, implementing, or maintaining programs using both frameworks.
Key Concepts and Definitions
NIST CSF 2.0: A voluntary, outcome-oriented framework with six functions (Govern, Identify, Protect, Detect, Respond, Recover), 22 categories, and 106 subcategories. Released February 2024. No certification available.
ISO/IEC 27001:2022: An auditable standard for an Information Security Management System (ISMS). Contains mandatory requirements in Clauses 4-10 and 93 reference controls in Annex A across four themes (organizational, people, physical, technological). Certification available through accredited bodies.
Current Profile: Your organization's current cybersecurity outcomes, documented using CSF subcategories.
Target Profile: Required cybersecurity outcomes based on business objectives, risk appetite, and regulatory obligations.
Statement of Applicability (SoA): ISO/IEC 27001 document listing all Annex A controls, marking each as applicable or not, with justification.
Implementation Tiers: CSF's four-level framework (Partial, Risk-Informed, Repeatable, Adaptive) describing program maturity across risk management process, integrated risk management, and external participation. Not a maturity model; advancement should be risk-driven.
Requirements Breakdown
NIST CSF 2.0 Core Structure
| Function | Purpose | Key Categories |
|---|---|---|
| GV (Govern) | Organizational context, risk strategy, policy, oversight | GV.OC, GV.RM, GV.RR, GV.PO, GV.OV, GV.SC |
| ID (Identify) | Asset management, risk assessment, improvement | ID.AM, ID.RA, ID.IM |
| PR (Protect) | Identity management, data security, platform security | PR.AA, PR.DS, PR.PS |
| DE (Detect) | Continuous monitoring, adverse event analysis | DE.CM, DE.AE |
| RS (Respond) | Incident management, analysis, mitigation, communication | RS.MA, RS.AN, RS.MI, RS.CO |
| RC (Recover) | Recovery planning and implementation | RC.RP, RC.CO |
ISO/IEC 27001:2022 Mandatory Requirements
| Clause | Requirement | Deliverable |
|---|---|---|
| 4 | Context of the organization | ISMS scope, interested parties analysis |
| 5 | Leadership | Information security policy, role assignments |
| 6 | Planning | Risk assessment methodology, risk treatment plan, SoA, security objectives |
| 7 | Support | Competence records, awareness evidence, documented information control |
| 8 | Operation | Executed risk assessments, treatment evidence, change records |
| 9 | Performance evaluation | Metrics, internal audit program, management review minutes |
| 10 | Improvement | Nonconformity records, corrective action tracking |
Implementation Guidance
Integration Sequence
Step 1: Build CSF Profiles
Create your Current Profile by documenting which CSF subcategories you currently achieve. Be honest; this is a planning tool, not a sales document. Then build your Target Profile based on regulatory requirements, customer commitments, and board-approved risk appetite.
The gap between Current and Target becomes your security roadmap. Sequence it logically: GV.OC and GV.RM before ID.RA; ID.AM before PR.AA. You can't protect assets you haven't inventoried.
Step 2: Map to ISO/IEC 27001 Structure
Use the CSF 2.0 Informative References to map your Target Profile to ISO controls. Key mappings:
- GV.OC → Clauses 4.1, 4.2 (organizational context)
- GV.RM → Clauses 6.1.2, 6.1.3 (risk management)
- GV.SC → A.5.19, A.5.22 (supply chain risk)
- ID.AM → A.5.9, A.5.12 (asset management)
- PR.AA → A.5.15, A.5.18 (access control)
- DE.CM → A.8.15, A.8.16 (monitoring)
- RS.MA → A.5.24, A.5.28 (incident management)
Step 3: Build the ISMS Foundation
Translate your CSF Target Profile into ISO requirements:
- Clause 4: Define ISMS scope matching your CSF coverage
- Clause 5: Assign accountability for each CSF function
- Clause 6: Document risk assessment methodology, create a risk treatment plan addressing CSF gaps, produce SoA showing which Annex A controls support which CSF outcomes
Step 4: Operate with Evidence
Design operational processes to produce evidence as a byproduct:
- Access reviews generate PR.AA evidence and satisfy A.5.18
- Vulnerability scans feed ID.RA and A.8.8
- Incident tickets document RS.MA and A.5.24
- Change records support both frameworks' change management requirements
Step 5: Close the Loop
Implement Clauses 9-10 machinery:
- Internal audit (9.2): Audit both ISMS compliance and CSF profile accuracy
- Management review (9.3): Review metrics from both frameworks, update risk treatment plan
- Corrective action (10.1): Feed findings back into the next CSF profile revision
Practical Control Library Design
Maintain one control library, not two. Structure each control with:
- Control ID and description
- Mapped CSF subcategories
- Mapped ISO Annex A references
- Implementation evidence location
- Responsible party
- Testing frequency
This eliminates duplicate work and prevents the two frameworks from drifting apart over time.
Common Pitfalls
Treating Annex A as the Whole Standard
ISO/IEC 27001 certification requires Clauses 4-10, not just Annex A controls. Teams that build 93 control descriptions but skip internal audit (9.2) or management review (9.3) face major nonconformities at Stage 2 audit. The controls were never the hard part; the management system is.
Self-Graded CSF Inflation
Without audit discipline, "partially implemented" becomes "largely implemented" over two quarters with nothing changing. CSF has no enforcement mechanism. This is exactly what ISO Clause 9.2 internal audit provides.
Scope Games
Certifying a narrow slice (say, production infrastructure only) while sales implies the whole company is covered. Buyers read the certificate scope statement. Define scope honestly and consistently across both frameworks.
Running Two Separate Programs
Separate risk registers, separate control libraries, separate reporting to leadership. If your CSF assessment and ISO risk treatment plan are maintained by different people in different tools, you've doubled the cost and halved the value.
Skipping the Govern Function
CSF 1.1 users upgrading to 2.0 sometimes skip GV categories as "already covered." Don't. GV.OC, GV.RM, GV.RR, and GV.PO now cover territory ISO Clauses 4-6 require, and documenting them narrows your distance to certification significantly.
Quick Reference Table
| Need | Use CSF 2.0 | Use ISO/IEC 27001 |
|---|---|---|
| Board communication | ✓ Six functions, clear outcome language | Limited; clause structure is technical |
| Prioritization and roadmapping | ✓ Current/Target Profile gap analysis | Limited; doesn't prioritize controls |
| Customer certification requirement | ✗ No certificate available | ✓ Accredited third-party certificate |
| Governance discipline | Weak; voluntary self-assessment | ✓ Mandatory audit, review, corrective action |
| Evidence requirements | Informal; self-defined | ✓ Formal; auditor-verified |
| Supply chain risk management | ✓ GV.SC expanded significantly in 2.0 | A.5.19, A.5.22 (basic coverage) |
| Detect and Respond coverage | ✓ Detailed subcategories | Thinner; mostly A.5.24, A.5.28 |
| Cost to implement | Free framework; staff time only | Certification fees, consultant fees, staff time |
| Time to initial implementation | 2-4 weeks for profile | 6-12 months to certification |
| Regulatory alignment (US) | ✓ Federal, critical infrastructure | Varies by sector |
| Regulatory alignment (EU) | Limited | ✓ NIS2, DORA, GDPR alignment |
Decision Framework: Start with CSF if you need direction and prioritization. Start with ISO/IEC 27001 if deals are stalling in security review or customers require certification. For most mature programs, run a CSF profile as a two-to-three week exercise, then build the ISMS around it. The profile makes your ISO scope defensible and your Statement of Applicability grounded in outcomes rather than auditor requests.
