NIST released the Cybersecurity Framework 2.0 (CSF 2.0) in February 2024 — the first major revision since the original framework launched in 2014. The update is more than a refresh. It reflects a decade of real-world implementation experience, responds to the expanded role of cybersecurity risk management in organizational governance, and broadens the framework's intended audience beyond critical infrastructure to all organizations.

If your security program is built around CSF 1.1, you need to understand what changed, what gaps you might have, and how to map your existing controls to the new structure. This guide covers all of it.

The Core Change: Five Functions Become Six

CSF 1.1 organized cybersecurity activities into five core functions: Identify, Protect, Detect, Respond, Recover. CSF 2.0 adds a sixth: Govern.

Govern isn't just a new column in the framework. It represents a fundamental shift in how NIST treats cybersecurity risk management — elevating it from a technical program to a governance and organizational risk management responsibility.

The six functions now are:

  • GOVERN (GV) — The new function. Organizational context, risk management strategy, cybersecurity supply chain risk management, roles and responsibilities, policies, oversight. This is the leadership and governance layer.
  • IDENTIFY (ID) — Asset management, risk assessment, improvement. Revised to include improvement activities moved from other functions.
  • PROTECT (PR) — Identity management, access control, awareness training, data security, platform security, technology infrastructure resilience.
  • DETECT (DE) — Adverse event detection, continuous monitoring.
  • RESPOND (RS) — Incident management, incident analysis, incident response, communication, mitigation.
  • RECOVER (RC) — Incident recovery, communication.

What the Govern Function Actually Requires

Govern is the most significant change for most organizations because it formalizes what was often informal or assumed.

The Govern function has six categories:

  • GV.OC — Organizational Context — Understanding the organizational mission, stakeholder expectations, and legal/regulatory obligations that inform cybersecurity risk decisions.
  • GV.RM — Risk Management Strategy — Established, communicated risk tolerance. Leadership's risk appetite must be documented and used to guide security investment decisions.
  • GV.RR — Roles, Responsibilities, and Authorities — Who owns cybersecurity risk decisions? This must be defined, assigned, and understood across the organization — not just in the IT department.
  • GV.PO — Policy — Cybersecurity policies must be established, communicated, and enforced, and reviewed when context changes.
  • GV.OV — Oversight — Results of cybersecurity risk management must be reviewed by senior leadership. Cybersecurity risk must be integrated into enterprise risk management.
  • GV.SC — Cybersecurity Supply Chain Risk Management — Expanded significantly from CSF 1.1. Supply chain risks must be identified, assessed, and managed. This maps to the increasing focus on third-party and software supply chain attacks.

For most small and mid-sized organizations, Govern exposes the gap between "we have a CISO/security team doing good work" and "leadership understands and owns cybersecurity risk." CSF 2.0 makes it explicit that the latter is required.

Other Significant Changes in CSF 2.0

Scope Expanded Beyond Critical Infrastructure

CSF 1.1 was explicitly designed for critical infrastructure sectors (energy, financial services, healthcare, etc.) but was widely adopted outside them. CSF 2.0 formalizes this: it's explicitly designed for all organizations of all sizes, sectors, and security maturity levels. The language throughout the framework is more accessible and universally applicable.

Cybersecurity Supply Chain Risk Management Elevated

Supply chain risk management existed in CSF 1.1 as a category under Identify. In CSF 2.0, it's elevated to a full category under the new Govern function (GV.SC). The controls include:

  • Identifying and prioritizing suppliers and third parties with access to systems or data
  • Conducting due diligence on suppliers before engagement
  • Incorporating cybersecurity requirements into supplier contracts
  • Monitoring suppliers for security incidents and changes in risk posture
  • Planning for supplier disruption or compromise

If your current program treats vendor risk management as a checkbox on a questionnaire, CSF 2.0 expects more.

Implementation Examples Added

CSF 2.0 introduces "Implementation Examples" — informative (not required) guidance showing concrete examples of how to achieve each subcategory. These are particularly useful for small organizations that don't have dedicated security staff and need practical starting points.

Framework Tiers Clarified

The four implementation tiers (Partial, Risk-Informed, Repeatable, Adaptive) remain in CSF 2.0 but with clearer guidance that tiers don't represent maturity levels to "complete" in sequence. Tiers describe your organization's approach to cybersecurity risk management — specifically, how well risk management practices are embedded in organizational decision-making. Moving from Tier 1 to Tier 2 isn't automatically better if your organization's size and risk profile don't warrant it.

CSF 2.0 Profiles: The Practical Planning Tool

Profiles are how you make CSF 2.0 actionable. A profile maps the CSF functions and categories to your organization's specific business requirements, risk tolerance, and resources.

CSF 2.0 distinguishes between:

  • Current Profile — Your security posture today. Which subcategories are you addressing, and how well?
  • Target Profile — Where you need to be based on your risk tolerance, regulatory requirements, and business context.

The gap between Current and Target Profile is your prioritized remediation roadmap. This is the practical output of a CSF implementation exercise: a documented, gap-mapped security program tied to your actual risk context rather than a generic control checklist.

NIST has published several Community Profiles for specific sectors (small business, enterprise IT, AI, vehicle cybersecurity) that serve as starting points for organizations that don't want to build their Target Profile from scratch.

Mapping CSF 2.0 to Other Frameworks

One of the most useful things about CSF 2.0 is NIST's expanded work on framework mapping. NIST maintains the CSF 2.0 Reference Tool, which maps CSF subcategories to controls in:

  • NIST SP 800-53 Rev 5
  • NIST SP 800-171
  • ISO/IEC 27001:2022
  • CIS Controls v8
  • COBIT 2019
  • PCI DSS v4.0

If you're using CSF as your primary framework and need to demonstrate alignment with SOC 2 TSC, HIPAA, or ISO 27001, the crosswalk tables let you map your existing CSF profile to those standards rather than starting from scratch. This is a significant efficiency for multi-framework compliance programs.

Implementation for Small Businesses: Where to Start

CSF 2.0 is explicitly designed to be accessible to small organizations without large security teams. The practical starting sequence:

  1. Organizational context first. Before touching controls, answer the Govern questions: What are your most important business functions? What data do you handle? What's your regulatory context? Who owns cybersecurity decisions? If you can't answer these, you're not ready to build a meaningful security program — you're just checking boxes.
  2. Build a Current Profile. Assess where you are today across all six functions. Use the Implementation Examples to understand what "addressing this subcategory" looks like at your scale. Don't try to be exhaustive — prioritize the subcategories most relevant to your risk context.
  3. Define a Target Profile. Based on your risk tolerance, regulatory obligations, and customer requirements, define where you need to be. NIST's Small Business Community Profile is a good starting point for companies under 100 employees.
  4. Prioritize the gaps. Not all gaps are equal. Focus remediation effort on subcategories where you're furthest from target AND where the risk is highest. An asset inventory gap (ID.AM) in a 10-person company with 20 devices is a smaller problem than an access control gap (PR.AA) in the same company if you're handling customer financial data.
  5. Map to your compliance obligations. If you need to demonstrate SOC 2 or HIPAA compliance, use NIST's crosswalk to understand which CSF subcategories map to those requirements. Build once, map to multiple frameworks.

CSF 2.0 vs. CSF 1.1: Do You Need to Update Your Program?

Yes — but the scope of update depends on your current program:

  • If you're using CSF 1.1 informally (as a reference, not a compliance requirement): Adopt CSF 2.0 on your next annual review cycle. The Govern function additions are genuinely useful and worth implementing regardless of compliance drivers.
  • If you're using CSF 1.1 in a formal program with a documented profile: Map your existing profile to CSF 2.0's structure, add the Govern function categories, and close gaps. NIST provides a CSF 1.1-to-2.0 mapping to facilitate this.
  • If a contract or regulation specifically references CSF 1.1: Check whether the reference has been updated to CSF 2.0. Federal agencies are beginning to update their CSF references; private sector contracts move slower.

The core control set between CSF 1.1 and 2.0 is largely consistent — NIST didn't deprecate categories wholesale. The primary additions are Govern and the expanded supply chain requirements. A mature CSF 1.1 program can typically achieve CSF 2.0 alignment with 2–4 months of focused work on the Govern gaps.