NIST CSF 1.1 vs 2.0: What Changed and Why It Matters

NIST CSF 2.0 is not a minor patch. The February 2024 release added an entirely new function, reorganized key content, overhauled supply chain risk management, and expanded the framework's intended audience from critical infrastructure to every organization. If your security program is built on CSF 1.1, here is exactly what changed and what it means for your work.

Why NIST Updated the Framework

NIST began the CSF 2.0 revision in 2022 with a concept paper and public request for information. The revision was driven by several converging factors that had made CSF 1.1, published in 2018, feel incomplete for many organizations.

First, the threat environment had shifted dramatically. Software supply chain attacks like SolarWinds (2020) and Log4Shell (2021) demonstrated that perimeter-focused security was insufficient and that organizations were deeply vulnerable through their vendors and dependencies. CSF 1.1's supply chain category (ID.SC) existed but was thin relative to the actual risk.

Second, the audience using CSF had expanded far beyond its original critical infrastructure focus. Small businesses, healthcare organizations, financial firms, and technology companies were all using CSF as a general-purpose framework, but the document still read as if it was written for power plants and water utilities.

Third, and most significantly: organizations were implementing the five technical functions reasonably well but failing at the governance prerequisites. They had technical controls without clear ownership, risk management activities without executive visibility, and security programs without defined risk tolerance. This was not a technical failure; it was a governance failure.

CSF 2.0 addresses all three of these gaps.

The Biggest Change: A New Govern Function

The addition of Govern (GV) as a sixth function is the most significant structural change in CSF history. Where CSF 1.1 implied governance through its Identify function, CSF 2.0 makes it explicit, mandatory in a conceptual sense, and elevated to the same level as the operational security functions.

Govern does not fit neatly alongside the other five functions in the sense that it is not a sequential activity. The original five functions (Identify, Protect, Detect, Respond, Recover) follow a logical operational cycle. Govern is more foundational: it sets the context in which all other functions operate. Think of it as the frame that holds the other five together.

The Govern function contains six categories:

GV.OC: Organizational Context New

The organization's mission, stakeholder expectations, legal/regulatory requirements, and supply chain dependencies are understood and inform the cybersecurity risk strategy. This is about understanding why security matters to your specific organization, not just that it matters in general. Five subcategories (GV.OC-01 through GV.OC-05).

GV.RM: Risk Management Strategy New

The organization's risk appetite, risk tolerance, and risk management priorities are established and communicated. This is the explicit documentation of how much risk the organization is willing to accept and in which areas, information that should be driving every security investment decision but often exists only informally. Five subcategories (GV.RM-01 through GV.RM-07).

GV.RR: Roles, Responsibilities, and Authorities New

Cybersecurity roles, responsibilities, and decision-making authorities are established, communicated, understood, and enforced. Who owns security? Who approves risk acceptance decisions? Who communicates with regulators after an incident? These questions have clear answers in well-governed organizations and unclear answers in most others. Four subcategories.

GV.PO: Policy New

Organizational cybersecurity policy is established, communicated, and enforced. Policies are reviewed and updated regularly to account for changes in the threat environment and organizational context. Two subcategories.

GV.OV: Oversight New

Results of organization-wide cybersecurity risk management activities inform, improve, and adjust the risk management strategy. This addresses the feedback loop between the security program and executive leadership, something that CSF 1.1 did not explicitly require. Three subcategories.

GV.SC: Cybersecurity Supply Chain Risk Management Moved + Expanded from ID.SC

Cyber supply chain risk management processes are identified, established, managed, monitored, and improved. This category was completely overhauled from the five subcategories in CSF 1.1's ID.SC to ten subcategories in GV.SC. The expansion reflects the post-SolarWinds reality that supply chain risk is a governance responsibility requiring board-level visibility, not just an IT procurement concern.

Complete Function and Category Comparison

What Changed in Identify

The Identify function lost two of its five CSF 1.1 categories to the new Govern function: ID.BE (Business Environment) content moved to GV.OC and GV.RM, and ID.GV (Governance) content moved to GV.PO and GV.RR. ID.SC (Supply Chain) moved and expanded into GV.SC.

What remains in Identify is a tighter focus on the operational discovery and assessment activities: asset management (ID.AM), risk assessment (ID.RA), and a new improvement category (ID.IM) that formalizes the continuous improvement and lessons-learned processes that previously had no explicit home in the framework.

ID.IM (Improvement) is worth calling out specifically. This new category requires organizations to identify improvements to their cybersecurity practices, processes, and plans based on security reviews, assessments, and lessons learned from incidents. It formalizes the PDCA (Plan-Do-Check-Act) cycle that mature security programs already follow but that CSF 1.1 never explicitly captured.

What Changed in Protect

The Protect function was significantly restructured. CSF 1.1 had six categories (AC, AT, DS, IP, MA, PT). CSF 2.0 has five (AA, AT, DS, PS, IR). The consolidation eliminated some redundancy and created two clearer categories:

PR.PS (Platform Security) absorbed the old PR.IP (Information Protection Processes), PR.MA (Maintenance), and PR.PT (Protective Technology) categories. The new category focuses on securing the technology platforms (operating systems, firmware, applications, cloud services) that the organization operates.

PR.IR (Technology Infrastructure Resilience) is a new category focused specifically on ensuring the availability and recovery of technology infrastructure, recognizing that resilience deserves explicit treatment separate from security controls.

PR.AC was renamed to PR.AA (Identity Management, Authentication, and Access Control) without major content change; the rename clarifies the category's scope.

What Changed in Detect

The Detect function consolidated from three categories (AE, CM, DP) to two (AE, CM). The Detection Processes category (DE.DP) was absorbed into the other two categories. More significantly, DE.AE was renamed to Adverse Event Analysis and updated to reflect modern detection realities: the subcategories now address continuous monitoring outputs, analysis of anomalies, and the coordination between detection systems and response activities.

What Changed in Respond and Recover

Both functions received updates to category names and subcategory numbering without major structural overhaul. RS.RP (Response Planning) became RS.MA (Incident Management), reflecting that the category covers the full management of incident response activities, not just planning. New subcategories in RS.AN (Incident Analysis) address root cause analysis more explicitly than CSF 1.1 did.

The Profiles Enhancement

CSF 2.0 formalized the distinction between Current Profiles and Target Profiles that practitioners had been using informally for years. A Current Profile describes your present state across the framework subcategories. A Target Profile describes your desired state based on your risk tolerance, business objectives, and applicable requirements.

More importantly, NIST published a reference tool on its website (csrc.nist.gov/projects/cybersecurity-framework) that allows organizations to build and export Profiles, and released a set of Community Profiles created for specific sectors and use cases. These community profiles give organizations a validated starting point rather than building from scratch.

For organizations that have been using CSF 1.1 informally, often as a checklist rather than a genuine gap assessment tool, the formal Profile structure in 2.0 is one of the highest-value changes. Done correctly, a Current/Target Profile comparison produces a prioritized roadmap tied directly to your risk tolerance, something that a generic control checklist never can.

Scope Expansion: From Critical Infrastructure to Everyone

CSF 1.1's opening language specifically referenced critical infrastructure. CSF 2.0 removes that limitation explicitly. The document states that CSF 2.0 "can be used by organizations regardless of their sector or size."

NIST backed this up with resources: a Small Business Quick-Start Guide published alongside CSF 2.0, Community Profiles for specific use cases, and updated reference tools designed to work for organizations without dedicated security staff. The practical implication is that using CSF 2.0 no longer requires contextualizing it away from its critical infrastructure framing. It reads like it was written for your organization because, for the first time, it actually was.

What This Means for Your Program

If you have an existing CSF 1.1 program, the migration to 2.0 is additive, not a rebuild. Your existing Identify, Protect, Detect, Respond, and Recover work remains valid. The primary gaps for most organizations will be in the Govern function, specifically in areas like formal risk tolerance documentation (GV.RM), supply chain program formalization (GV.SC), and executive oversight processes (GV.OV).

If you are building a new program, starting with CSF 2.0 is the right choice. There is no reason to build on CSF 1.1 at this point. The 2.0 structure is more complete, better supported with tooling and community resources, and reflects how modern security programs actually operate.

If you are using CSF to communicate with executives or insurers, CSF 2.0's Govern function gives you a much cleaner structure for board-level reporting. GV.OV specifically addresses the feedback loop between the security program and organizational leadership, which is exactly what boards and audit committees want to see documented.

Implement Each Function: Practitioner Guides

Ready to go deeper on implementation? Each guide breaks down the categories and subcategories with practical steps, common mistakes, and evidence requirements - written for practitioners, not framework theorists.