NIST CyberSecurity Framework (CSF) Explained: What Changed in CSF 2.0 and What It Means for You

CSF 2.0 adds a sixth function, Govern. Its dedicated governance outcomes change how boards, regulators, and executive teams evaluate cybersecurity accountability and risk reporting.

Organizations that mapped controls to CSF 1.1 now need to determine how much work carries forward to CSF 2.0. The NIST CSF 2.0 PDF often sits alongside the transition spreadsheet, a half-finished gap analysis, and board materials for the next quarterly review.

As noted in this NIST blog post, many organizations are still treating CSF 2.0 as a control-mapping update, but the bigger shift is governance: how cybersecurity risk is owned, reported, and monitored.

TL;DR:

• The defining change in CSF 2.0 is the new Govern function, which consolidates governance from a handful of scattered directives into a dedicated function and positions cybersecurity as an enterprise risk discipline with explicit board accountability.
• The framework now applies to organizations of any size and sector, and a formalized profile system makes it a workable reference point whether you are building a security program or maturing one.
• Supply chain risk management moves from an identification task under Identify to a governance-level program under Govern, adding obligations for supplier prioritization, due diligence, ongoing monitoring, and post-relationship provisions.
• Cross-framework mappings have left the static PDF appendix for an online catalog that updates independently, so anyone mapping CSF to other frameworks should work from the current online reference rather than the document.

What Actually Changed: CSF 1.1 to CSF 2.0

The framework PDF lays out the move from five functions to six. CSF 2.0 also reorganizes the category structure around that six-function model and broadens its scope and audience beyond critical infrastructure to organizations more generally.

The Numbers

The structural totals shifted only modestly between versions, with one clear exception.

‍

The raw counts look like a wash, with slightly fewer categories and subcategories, but the category movements matter more than the totals.

Function-Level Changes

Identify lost half its categories. CSF 1.1's Identify function had six categories: Business Environment (ID.BE), Governance (ID.GV), Asset Management (ID.AM), Risk Assessment (ID.RA), Risk Management Strategy (ID.RM), and Supply Chain (ID.SC). CSF 2.0 reduces Identify to three: Asset Management, Risk Assessment, and a new Improvement category (ID.IM). The governance categories migrated to the new Govern function. Supply chain moved under Govern to GV.SC.

Protect reorganized around modern infrastructure. Access control became PR.AA (Identity Management, Authentication, and Access Control). Two new category names reflect current operational realities: Platform Security (PR.PS) and Technology Infrastructure Resilience (PR.IR).

CSF 2.0 consolidated Detect, Respond, and Recover structurally without major conceptual shifts. Detect narrowed to two categories (Continuous Monitoring and Adverse Event Analysis), Respond restructured around four categories with Incident Management (RS.MA) as the primary entry point, and Recover now has two categories covering recovery planning and communication.

For gap analysis work, NIST CSWP 29 states that subcategory numbering gaps are intentional. The Framework Core is organized by Function, Category, and Subcategory. The transition spreadsheet on NIST's CSF 2.0 page provides information for tracking those relocations.

The Govern Function: CSF 2.0's Defining Structural Change

NIST defines Govern as: "The organization's cybersecurity risk management strategy, expectations, and policy are established, communicated, and monitored."

Govern sits at the center of the framework model and runs continuously in parallel with all other framework activity. It grew from roughly four governance directives in CSF 1.1 to 31 subcategories.

1. Organizational Context (GV.OC)

GV.OC has five subcategories covering how organizational context, including mission, stakeholder expectations, dependencies, and legal requirements, informs cybersecurity risk management. GV.OC-03 includes privacy and civil liberties alongside traditional compliance.

2. Risk Management Strategy (GV.RM)

GV.RM has seven subcategories. GV.RM-03 mandates integration with enterprise risk management, which encourages more regular interaction between CISOs and enterprise stakeholders such as CFOs, COOs, and risk committees. GV.RM-06 requires a standardized, documented risk calculation methodology. Informal or ad hoc risk scoring is insufficient under this subcategory.

GV.RM-07 adds a requirement to characterize positive risks (strategic opportunities) alongside threats.

3. Roles, Responsibilities, and Authorities (GV.RR)

GV.RR has four subcategories. GV.RR-01 places accountability at the organizational leadership level, which makes it directly relevant to executive cybersecurity oversight. GV.RR-03 provides a formal basis for budget and resource allocation: the framework calls for adequate resources commensurate with the cybersecurity risk strategy, roles, responsibilities, and policies. ISACA notes that these accountability discussions belong at the highest organizational level, including top-level members of the enterprise.

4. Policy (GV.PO)

Two subcategories cover establishing and updating organizational cybersecurity policy. GV.PO-02 makes policy maintenance a continuous requirement triggered by changes in threats, technology, or mission.

5. Oversight (GV.OV)

The three subcategories in the Oversight (GV.OV) category support continuous improvement in the governance cycle. Performance data from risk management activities must flow upward to inform strategy adjustments, not just populate the operational dashboards built for day-to-day security work.

6. Cybersecurity Supply Chain Risk Management (GV.SC)

With ten subcategories, GV.SC is the most expanded governance area.

What This Means for Your Role

The Govern function lands differently depending on where you sit, from board-level accountability down to how operational data feeds oversight.

‍

ISACA has already updated its Cybersecurity Audit Program for CSF 2.0, covering all six functions. CISOs should anticipate Govern categories appearing within internal audit scope and security program assessments.

The Concept Paper presents CSF 2.0 as a taxonomy of high-level cybersecurity outcomes usable by organizations regardless of their maturity. Some practitioners pair it with external maturity instruments such as CMMI or C2M2 and map those to CSF outcomes, though the framework does not require this. Govern also emphasizes how cybersecurity risk information is established, communicated, and monitored at the board and leadership level. Executives set risk appetite downward, and managers report against it upward. Board reporting structured around gap closure progress against a documented Target Profile directly reflects the framework's intended use.

Scope Expansion: Beyond Critical Infrastructure

The title change from "Framework for Improving Critical Infrastructure Cybersecurity" to simply "The NIST Cybersecurity Framework (CSF) 2.0" is a formal expansion of applicability. NIST CSWP 29 states the framework is designed for "organizations of all sizes and sectors," spanning industry, government, academia, and nonprofit, to manage and reduce their cybersecurity risks. Technology scope expanded to IT, IoT, OT, cloud, mobile, and AI environments.

CSF 2.0 formalizes three profile types. Organizational Profiles (Current and Target) describe cybersecurity posture in terms of the Core's outcomes, and an organization can maintain as many as needed, each scoped differently. Community Profiles are baselines of CSF outcomes created and published to address shared interests and goals among a number of organizations, and they can serve as a starting point for organizations developing their own Target Profiles. Published profiles already exist for financial services, communications, small network service providers, and other sectors. NIST SP 1301 provides the dedicated organizational profile guide.

Supply Chain Risk: Four New Subcategories You Need to Know

Supply chain risk management moved from ID.SC under Identify in CSF 1.1 to GV.SC under Govern in CSF 2.0. This repositions vendor risk from an identification-phase activity to a governance-level program requiring executive visibility. Of GV.SC's ten subcategories, several carry forward or expand earlier ID.SC practices, while four address phases of the supplier relationship that CSF 1.1 did not cover.

The New Subcategories

Each of the four additions targets a different phase of the vendor relationship.

• GV.SC-04: Suppliers are known and prioritized by criticality. NIST SP 1305 recommends creating CSF Target Profiles for each supplier criticality level. Those profiles link tiering to differentiated assessment requirements.
• GV.SC-06: Pre-Relationship Due Diligence requires risk reduction activities before formalizing a supplier relationship. NIST's SP 1326 draft, a due diligence assessment quick-start guide, maps directly to this subcategory.
• GV.SC-09: Lifecycle Performance Monitoring integrates supply chain security practices into cybersecurity and enterprise risk management programs, with performance monitored throughout the technology product and service lifecycle.
• GV.SC-10: Post-Relationship Provisions requires formal documentation of what occurs after a vendor relationship ends.

Read together, the four describe an ongoing supplier program rather than a one-time procurement check.

Supply Chain Requirements Extend Beyond GV.SC

Additional subcategories outside GV.SC carry third-party risk obligations: ID.RA-10 (pre-acquisition assessment of critical suppliers), DE.CM-06 (monitoring external service provider activities), and ID.IM-02 (security tests coordinated with suppliers). Teams that limit their transition to re-mapping ID.SC to GV.SC will miss these cross-function requirements.

Cross-Framework Mapping: The Static Appendix Is Dead

CSF 1.1 placed Informative References in Appendix A as part of the tabular Framework Core (Functions, Categories, Subcategories, and Informative References). CSF 2.0 decouples them into an online-only, continuously updated catalog. The CPRT tool provides a centralized way to access and browse mapping tables.

Current Mapping Status

Official NIST mappings to CSF 2.0, browsable through the CPRT catalog, exist for some frameworks, are absent for others, and are only partial for several common ones.

‍

No official NIST mapping; organizations commonly align CSF outcomes to SEC disclosure requirements on their own

For SOC 2 specifically: the table above lists no official NIST mapping, so distinguish official NIST mappings from community-derived alignments when presenting evidence to auditors.

The Govern function creates the primary new mapping surface for governance-focused regulations. Regulatory deadlines are also pushing adoption. The FFIEC sunset statement retired the Cybersecurity Assessment Tool on August 31, 2025, and named NIST CSF 2.0 as one of several alternative resources.

Decision Criteria for Your CSF 2.0 Transition

1. If you're already on CSF 1.1, start with the official Transition Spreadsheet to map subcategory relocations. Audit existing governance practices against the six GV categories. Your largest gap likely lives there.
2. If you're adopting a framework for the first time, check whether a relevant Community Profile exists for your sector before building from scratch. Use NIST SP 1301 for the organizational profile process.
3. If you're facing a regulatory deadline (FFIEC, NIS2, DORA), prioritize the Govern function, especially the GV.SC supply chain subcategories, as a practical starting point, since they align with the governance and third-party risk management expectations emphasized across current regulations.
4. If your board is asking about cybersecurity oversight, GV.RR-01 (leadership accountability) and the Current/Target Profile gap cycle are your most defensible reporting instruments, provided you can translate posture into board-level metrics directors can act on. Combine these with NACD's board reporting toolkit for a structured approach.
5. If you depend on cross-framework compliance mappings, verify the current status of official NIST mappings in the CPRT tool before starting transition work.
6. If your team is still building maturity in the original five functions, that's a legitimate starting point. Govern requires organizational changes such as ERM integration, executive accountability formalization, and standardized risk quantification. A phased approach is more productive than attempting to address all six functions simultaneously.

Treating the CSF 2.0 Move as a Governance Shift

The headline numbers, six functions instead of five and a slightly smaller subcategory count, understate what changed. The substantive shift is that governance is now a first-class function rather than a cluster of directives buried inside Identify, and that supply chain risk has been elevated alongside it. For teams that already mapped to CSF 1.1, most of the work that carries forward sits in Detect, Respond, and Recover. The gaps that demand real organizational change concentrate in Govern, which few programs have formalized as a discipline.

Treat the transition as a governance program rather than a re-mapping exercise. The Current and Target Profile cycle gives you a credible way to show progress to a board, and the online mapping catalog keeps cross-framework alignment current. The framework rewards programs that can demonstrate how cybersecurity risk decisions are made, communicated, and monitored, which is the evidence regulators and executives increasingly ask for. A SOC report structured around CSF outcomes is one practical way to connect operational evidence to governance oversight.

Frequently Asked Questions About NIST Cybersecurity Framework

How Does CSF 2.0 Interact With ISO 27001:2022 for Organizations Maintaining Both?

Official NIST mappings between CSF 2.0 and ISO 27001:2022 exist through the OLIR catalog. The two frameworks are complementary: CSF 2.0 defines outcomes, while ISO 27001 specifies a management system with certifiable controls. Organizations can use CSF 2.0 profiles to identify gaps and ISO 27001 controls to close them without redundant effort, but the mapping requires active maintenance through the CPRT tool since it updates independently of either framework document.

What's the Practical Difference Between Implementation Tiers and a Maturity Model?

Tiers describe the rigor and integration of cybersecurity risk management practices, and tier selection depends on organizational risk context. Even Tier 4 is a context-specific choice rather than a default target. The Concept Paper states that CSF 2.0 will not provide a maturity model. In practice, organizations may use an external maturity instrument such as C2M2, CMMI, or an internally developed model and map it to CSF outcomes. Tiers can be applied per Function or Category.

GV.RM-07 Requires Characterizing "Positive Risks." What Does That Look Like in Practice?

GV.RM-07 requires organizations to include strategic opportunities in cybersecurity risk discussions alongside threats. In practice, this means documenting scenarios where cybersecurity capability creates business advantage: faster compliance certification that opens a new market, security posture differentiating the organization in customer procurement evaluations, or threat intelligence capabilities identifying competitor targeting that informs business strategy.

How Should Small or Mid-Sized Organizations Approach CSF 2.0 Without Dedicated Governance Staff?

CSF 2.0 states it applies to organizations "regardless of the maturity level of their cybersecurity programs." Community Profiles exist as pre-built starting points, so organizations can use existing Target Profile models instead of building from scratch. NIST SP 1301 walks through the organizational profile process. Implementation Tiers describe an organization's approach to cybersecurity risk management and are not prescribed for specific Functions; in practice, organizations may reflect different levels of rigor across different areas such as Govern and Protect. Partial implementation that builds governance capacity over time is more productive than deferring adoption entirely.

What Happens to Organizations Still Using FFIEC's Cybersecurity Assessment Tool?

The FFIEC sunset statement retired the Cybersecurity Assessment Tool on August 31, 2025, and pointed institutions to resources including NIST CSF 2.0, rather than naming it as the sole successor. Financial services organizations should look at the Cyber Risk Institute Community Profile as a sector-specific starting point. The FFIEC CAT-to-CSF 2.0 transition also requires governance changes beyond direct control mapping. CSF 2.0's Govern function introduces requirements, including executive accountability, ERM integration, and supply chain governance, that the CAT did not address at equivalent depth.