NIST Cybersecurity Framework 2.0: A Practical Implementation Guide
A detailed guide to implementing NIST CSF 2.0, including the six core functions, implementation tiers, profiles, framework mapping to other standards, and using CSF to communicate risk to the board.
NIST released version 2.0 of its Cybersecurity Framework in February 2024, the first major update since the original 2014 publication. The most visible change is the addition of a sixth core function — Govern — elevating cybersecurity risk management to a board-level organizational concern. For organizations that built programs around CSF 1.1, the update requires a thoughtful review. For organizations adopting the framework for the first time, CSF 2.0 offers a more complete and actionable starting point.
What the Framework Is and Is Not
CSF is a voluntary framework. It does not prescribe specific technologies, require third-party certification, or carry regulatory enforcement. What it provides is a common language for describing cybersecurity activities and a flexible structure for organizing your program. Its real value is in communication: between technical teams and executives, between organizations and their partners, and between your program today and where you want it to be.
The framework has three components:
- The Core: the six functions, their categories, and subcategories
- Tiers: a four-level maturity scale for characterizing organizational practice
- Profiles: snapshots of your current and target cybersecurity posture
The Six Core Functions
Govern (GV)
New in CSF 2.0, the Govern function addresses the organizational context for cybersecurity risk management. It covers:
- Organizational Context (GV.OC): Understanding the business environment, including stakeholders, regulatory requirements, and mission-critical processes
- Risk Management Strategy (GV.RM): Establishing risk tolerance, risk appetite statements, and the organizational risk management hierarchy
- Roles, Responsibilities, and Authorities (GV.RR): Ensuring cybersecurity responsibilities are documented, communicated, and understood from board level through operational teams
- Policy (GV.PO): Maintaining and communicating cybersecurity policies aligned to strategy
- Oversight (GV.OV): Management review of cybersecurity performance
- Cybersecurity Supply Chain Risk Management (GV.SC): Integrating third-party risk into the overall governance structure
The inclusion of Govern reflects recognition that cybersecurity failures are frequently governance failures: insufficient board awareness, unclear accountability, and risk appetite that was never formally defined.
Identify (ID)
The Identify function establishes the foundation for all other activities. You cannot protect what you cannot see. Key categories:
- Asset Management (ID.AM): Cataloging hardware, software, data, and systems, including those managed by third parties. CSF 2.0 expands this to explicitly include software inventory and systems supporting critical services.
- Risk Assessment (ID.RA): Identifying and prioritizing cybersecurity risks to operations, assets, and individuals. This includes threat intelligence integration and assessment of likelihood and impact.
- Improvement (ID.IM): New in 2.0, this category covers lessons learned from previous events and exercises.
Protect (PR)
Protect covers the safeguards that limit the impact of a cybersecurity event. Categories include:
- Identity Management, Authentication, and Access Control (PR.AA): MFA, least privilege, privileged access management
- Awareness and Training (PR.AT): Role-based training, phishing simulations
- Data Security (PR.DS): Encryption at rest and in transit, data loss prevention, secure disposal
- Platform Security (PR.PS): Configuration management, vulnerability management, secure development practices
- Technology Infrastructure Resilience (PR.IR): Network segmentation, redundancy, backup and recovery
Detect (DE)
Detection capabilities determine how quickly your organization identifies an active attack. The gap between compromise and detection — dwell time — directly determines breach impact. Categories:
- Continuous Monitoring (DE.CM): Network traffic analysis, endpoint detection, user behavior analytics, log aggregation and alerting
- Adverse Event Analysis (DE.AE): Correlating events to detect incidents, integrating threat intelligence to improve signal-to-noise ratio
Respond (RS)
The Respond function covers incident management from initial detection through containment and communication. Categories:
- Incident Management (RS.MA): Activating response plans, executing predefined playbooks
- Incident Analysis (RS.AN): Determining scope, understanding root cause
- Incident Response Reporting and Communication (RS.CO): Notifying stakeholders, regulators, and affected parties as appropriate
- Incident Mitigation (RS.MI): Containing and eradicating the threat
Recover (RC)
Recovery addresses restoring normal operations and incorporating lessons learned:
- Incident Recovery Plan Execution (RC.RP): Executing recovery procedures, validating system integrity before returning to production
- Incident Recovery Communication (RC.CO): Communicating recovery status to stakeholders
- Incident Recovery Improvement (RC.IM): Updating plans, controls, and training based on post-incident review
Implementation Tiers
CSF tiers describe the rigor and integration of cybersecurity risk management practices. They are not maturity levels to be maximized — they describe appropriate investment given your organization's risk profile and resources.
Tier 1 — Partial: Cybersecurity risk management is ad hoc, reactive, and not coordinated across the organization. No formal risk management program.
Tier 2 — Risk Informed: Risk management practices exist but are not fully organization-wide. Threat awareness is present but not formally integrated into risk decisions.
Tier 3 — Repeatable: Formal risk management processes are approved by management, consistently implemented, and regularly reviewed. Organization-wide awareness of cybersecurity risk.
Tier 4 — Adaptive: Cybersecurity practices adapt in real time based on threat intelligence, lessons learned, and continuous improvement processes. Risk management is integrated with business strategy.
Most regulated industries expect Tier 3 at minimum. Critical infrastructure and defense contractors should target Tier 4 for high-priority systems. A Series B SaaS company processing personal data realistically targets Tier 3.
When selecting a target tier, consider: the sensitivity of data processed, regulatory requirements, customer contractual obligations, cost of a security incident, and available resources. Tier selection should be documented with business justification.
Profiles
A CSF Profile describes your current or target cybersecurity posture relative to the Core functions. Creating profiles involves:
- Current Profile: Assessing which outcomes in the Core are currently achieved and to what degree
- Target Profile: Defining which outcomes you want to achieve, at what tier, within what timeframe
- Gap Analysis: Comparing current and target profiles to identify prioritized actions
Profiles should be business-context specific. A profile for your customer-facing production environment will look different from one for your internal development environment. Multiple profiles covering different organizational contexts are appropriate for larger organizations.
The gap between current and target profile drives your security roadmap. Prioritize gaps based on risk impact, not framework section order.
Mapping CSF to Other Frameworks
One of CSF's practical values is that its subcategories map to specific controls in other frameworks. NIST publishes a CSF Crosswalk tool that maps CSF 2.0 subcategories to:
- NIST SP 800-53 Rev 5 (federal information systems)
- ISO/IEC 27001:2022
- CIS Controls v8
- COBIT 2019
- PCI DSS v4.0
If your organization is pursuing ISO 27001 certification, mapping your ISO 27001 control set to CSF subcategories lets you use a single control implementation to satisfy multiple frameworks. For example, CSF PR.AA-01 (identities and credentials are managed for authorized users, services, and hardware) maps to ISO 27001 Annex A 5.16 and 5.17 (identity management and authentication information), NIST 800-53 IA controls, and CIS Control 5. Implementing robust identity management once addresses all of these.
NIST's online CSF Reference Tool provides searchable mapping across all published informative references.
Using CSF to Communicate Risk to the Board
Technical security teams struggle to communicate risk to boards and executives who think in business terms. CSF 2.0, particularly the Govern function, explicitly addresses this translation problem.
Risk appetite statements translate business strategy into risk tolerance. Instead of "we have a CVSS 7.8 vulnerability," communicate "we have an unpatched external-facing system in the customer data environment that we assess has a 15% probability of exploitation within 90 days, with estimated impact of $2.4M based on our breach cost model."
Profile-based reporting gives boards a consistent framework for tracking cybersecurity posture over time. Reporting current profile status against target profile, with trend data, is more meaningful than point-in-time vulnerability counts.
Tier-based framing helps boards understand investment decisions. "We are currently Tier 2 on incident detection and response. Achieving Tier 3 requires $400K in SIEM tooling and one additional analyst. Given our regulatory environment, we recommend this investment."
Business impact language converts technical findings into business outcomes. The Identify function's risk assessment category provides the methodology; the board conversation frames risks as operational downtime, data breach costs, regulatory penalties, and reputational damage.
Executive risk dashboards built on CSF structure are increasingly common. They show function-level health (red/yellow/green), trend over time, comparison against industry benchmarks, and the top five risks with treatment status. This format gives boards sufficient context to exercise oversight without requiring technical expertise.
Getting Started with CSF 2.0
Organizations new to CSF should start with a current state assessment rather than jumping directly to implementation planning. Use the CSF Core as a questionnaire: for each subcategory, assess whether the described outcome is achieved, partially achieved, or not achieved. This takes two to four weeks with a small team.
From the current state assessment, build a target profile based on your business context, regulatory environment, and risk appetite. Prioritize gaps using risk impact as the primary criterion. Build a twelve-month roadmap addressing the highest-impact gaps first.
CSF 2.0 also introduces Community Profiles — pre-built profiles for specific sectors (financial services, healthcare, manufacturing) developed by industry groups. These provide a starting point that reflects sector-specific risk priorities and regulatory context, saving organizations the time of building a profile from scratch.
The framework's flexibility is both its strength and its challenge. Organizations that invest the time in genuine current-state assessment and thoughtful target-profile development get substantial value. Organizations that treat it as a checkbox exercise produce documentation that does not reflect operational reality and provides no meaningful security improvement.