NIST Cybersecurity Framework 2.0: What Changed and How to Implement It

NIST Cybersecurity Framework 2.0: What Changed and How to Implement It

TL;DR

• NIST published CSF 2.0 on February 26, 2024, the first major revision since 1.0 launched in 2014.
• The biggest structural change is a new sixth function, Govern, which addresses risk strategy, roles, policy, oversight, and supply chain risk management.
• CSF 2.0 explicitly covers organizations of any size and sector, not only critical infrastructure operators as the original framing implied.
• The full framework now organizes cybersecurity outcomes into 6 functions, 22 categories, and 106 subcategories.
• Informative references (mappings to SP 800-53, ISO 27001, CIS Controls) were moved to a separate online tool, keeping the core document smaller and easier to update.

Who this is for

This article is for security practitioners, IT managers, and compliance leads who need to understand what changed in CSF 2.0, how the six functions map to real program activities, and what an update from version 1.1 actually requires. It assumes you know what a cybersecurity framework is but may not have read the 2.0 document in full.

Background: What CSF 2.0 Is and When It Arrived

NIST released the Cybersecurity Framework version 2.0 on February 26, 2024, through NIST CSWP 29. That made it the first major revision in a decade: version 1.0 came out in 2014, version 1.1 in 2018, and 2.0 marks a genuine structural overhaul rather than an incremental update.

The original framework was created in response to a 2013 Executive Order focused on protecting critical infrastructure. For years, that origin shaped how organizations perceived it — as something for power grids and water utilities, not SaaS startups or regional health systems. CSF 2.0 formally drops that framing. The document now states its guidance applies to "organizations of any size, in any sector, in any country."

NIST developed 2.0 through a multi-year public comment process that included two draft releases, multiple workshops, and a request for information in 2022. The final document reflects that input, particularly around governance gaps, supply chain risk, and the need for clearer implementation guidance for smaller organizations.

The Six Functions: An Overview

CSF 2.0 organizes cybersecurity outcomes into six core functions. Five of them carry over from version 1.1, though with updated categories and subcategories. One is entirely new.

The functions are arranged in a way that reflects their relationship: Govern sits at the center because governance decisions inform what you prioritize across all other functions. The remaining five form a cycle — Identify what you need to protect, Protect it, Detect when something goes wrong, Respond to incidents, and Recover from them.

Govern (GV) — The organization's cybersecurity risk management strategy, expectations, and policy are established, communicated, and monitored.

Identify (ID) — The organization's current cybersecurity risks are understood.

Protect (PR) — Safeguards to manage the organization's cybersecurity risks are in use.

Detect (DE) — Possible cybersecurity attacks and compromises are found and analyzed.

Respond (RS) — Actions regarding a detected cybersecurity incident are taken.

Recover (RC) — Assets and operations affected by a cybersecurity incident are restored.

The Govern Function in Detail

Govern is the addition that most distinguishes 2.0 from 1.1. It contains six categories — more than any other function — which reflects how much ground it covers.

GV.OC: Organizational Context

Covers understanding the circumstances that inform cybersecurity risk decisions: your mission, stakeholder expectations, dependencies, and legal, regulatory, and contractual requirements. The idea is that risk decisions should be grounded in what your organization actually does and who depends on it, not generic best practices applied without context.

GV.RM: Risk Management Strategy

Covers establishing and communicating organizational priorities, constraints, risk tolerance and appetite statements, and assumptions that guide operational risk decisions. This is where you document how much risk your organization will accept and under what conditions.

GV.RR: Roles, Responsibilities, and Authorities

Covers defining and communicating cybersecurity roles and responsibilities to drive accountability, performance evaluation, and ongoing improvement. Version 1.1 addressed governance under the Identify function; pulling this into a dedicated category signals that NIST views it as foundational rather than ancillary.

GV.PO: Policy

Covers establishing, communicating, and enforcing organizational cybersecurity policy. Policy here means documented guidance that shapes how employees and systems behave — not just a document that exists in a shared drive.

GV.OV: Oversight

Covers applying organization-wide cybersecurity risk management results and performance metrics to refine and adjust the risk management strategy. This is where metrics feed back into decisions — a feedback loop between what your program is doing and what leadership decides to prioritize.

GV.SC: Cybersecurity Supply Chain Risk Management

Covers developing and managing cyber supply chain risk processes across organizational stakeholders. This category is new in 2.0 and reflects years of practitioner feedback following incidents like SolarWinds (2020) and the Log4Shell vulnerability (2021), both of which exposed how third-party dependencies create systemic risk that internal controls alone cannot address.

The Other Five Functions and Their Categories

Identify (ID) — 3 Categories

ID.AM: Asset Management — Assets including data, hardware, software, systems, facilities, services, and people are identified and managed in line with their importance to organizational objectives and the risk strategy.

ID.RA: Risk Assessment — Cybersecurity risk to the organization, assets, and individuals is understood. This includes threat identification, vulnerability analysis, and likelihood and impact determination.

ID.IM: Improvement — Improvements to organizational cybersecurity risk management processes and activities are identified across all CSF functions. In version 1.1, improvement activities were distributed across Respond and Recover. Consolidating them into Identify signals that learning and adaptation are upstream activities, not afterthoughts.

Protect (PR) — 5 Categories

PR.AA: Identity Management, Authentication, and Access Control — Access to physical and logical assets is limited to authorized users, services, and hardware, managed according to assessed risk levels. This replaces the 1.1 category called "Identity Management, Authentication and Access Control" (PR.AC) and brings in more explicit handling of service accounts and non-human identities.

PR.AT: Awareness and Training — Personnel receive cybersecurity education that enables them to perform security-related job functions.

PR.DS: Data Security — Information is handled per the organizational risk strategy to maintain confidentiality, integrity, and availability.

PR.PS: Platform Security — Hardware, software (firmware, operating systems, applications), and services across physical and virtual environments are managed per the risk strategy. The term "platform" intentionally covers both on-premises and cloud environments.

PR.IR: Technology Infrastructure Resilience — Security architectures are managed to safeguard asset confidentiality, integrity, and availability and to maintain organizational resilience. This pulls together elements previously scattered across protective technology and information protection processes in version 1.1.

Detect (DE) — 2 Categories

DE.CM: Continuous Monitoring — Assets are monitored to find anomalies, indicators of compromise, and other potentially adverse events.

DE.AE: Adverse Event Analysis — Anomalies, indicators of compromise, and other potentially adverse events are analyzed to characterize the events and detect cybersecurity incidents.

Version 1.1 had three Detect categories: Anomalies and Events, Security Continuous Monitoring, and Detection Processes. CSF 2.0 consolidates them into two, folding detection process requirements into the monitoring and analysis categories rather than treating them as a separate documentation exercise.

Respond (RS) — 4 Categories

RS.MA: Incident Management — Responses to detected cybersecurity incidents are managed.

RS.AN: Incident Analysis — Investigations are conducted to ensure effective response and support forensics and recovery activities.

RS.CO: Incident Response Reporting and Communication — Response activities are coordinated with internal and external stakeholders as required by laws, regulations, or policies. Version 2.0 makes communication requirements more explicit, which aligns with the SEC's cybersecurity disclosure rules (effective for most large accelerated filers in December 2023, smaller reporting companies in June 2024) and state breach notification laws.

RS.MI: Incident Mitigation — Activities are performed to prevent expansion of an event and mitigate its effects.

Recover (RC) — 2 Categories

RC.RP: Incident Recovery Plan Execution — Restoration activities are performed to ensure operational availability of systems and services affected by cybersecurity incidents.

RC.CO: Incident Recovery Communication — Restoration activities are coordinated with internal and external parties, including customers, Internet Service Providers, owners of attack systems, and vendors.

What Actually Changed from Version 1.1

The category counts tell part of the story. Version 1.1 had 23 categories across five functions. Version 2.0 has 22 categories across six functions. The net reduction of one category obscures more than it reveals, because the distribution shifted significantly.

The Govern function is entirely new. Six categories that either did not exist in 1.1 or were embedded in other functions now have their own home. Organizational governance, risk management strategy, and supply chain risk were afterthoughts in 1.1 — elements mentioned in passing rather than organized into a coherent set of outcomes. In 2.0 they are primary.

Supply chain risk management moved from scattered references to a dedicated category (GV.SC). Version 1.1 addressed supply chain risk under the ID function's Risk Management Strategy category. That positioning treated it as one input among many. GV.SC in 2.0 gives it dedicated structure with subcategories covering supplier identification, supplier risk assessment, establishing requirements for suppliers, and ongoing monitoring.

The Improvement category (ID.IM) is new and consolidates lessons-learned activities. In 1.1, improvement was addressed separately under Respond (RS.IM) and Recover (RC.IM). Pulling it into Identify reflects a view that continuous improvement is a forward-looking, risk-management activity, not just a post-incident task.

The Protect function was reorganized and renamed. PR.AC became PR.AA, PR.IP (Information Protection Processes and Procedures) was broken up and distributed, and Platform Security (PR.PS) emerged as a distinct category to reflect modern infrastructure realities.

Informative references were separated from the core document. In version 1.1, every subcategory in the framework appendix included inline references to SP 800-53 controls, ISO 27001 clauses, CIS Controls, COBIT, and other frameworks. In 2.0, NIST moved those mappings to a separate online reference tool and the NIST CSF 2.0 Reference Tool maintained at NIST's website. The practical effect: the core framework document is shorter and clearer, and NIST can update mappings when SP 800-53 or ISO 27001 revision happens without reprinting the framework itself.

The scope statement changed. Version 1.1 explicitly targeted critical infrastructure. Version 2.0 states applicability to organizations of any size, in any sector, in any country. This is a policy statement more than a technical one — the subcategories were always general enough to apply broadly — but it removes an excuse organizations used to avoid engaging with the framework.

Profiles became more practical. Version 1.1 introduced the concept of Current Profile and Target Profile but gave little guidance on how to actually build one. CSF 2.0 clarifies what a Profile is (a prioritized selection of CSF outcomes tailored to an organization's context) and introduced the concept of Community Profiles: pre-built sector-specific starting points developed by industry groups, regulators, or NIST itself. As of 2024, NIST and sector partners have published Community Profiles for sectors including small businesses, enterprise risk management, and ransomware risk management.

Implementation Tiers: What They Mean in Practice

The four implementation tiers describe how mature and integrated your cybersecurity risk management practices are. NIST explicitly states that tiers are not maturity levels in the traditional sense — you do not need to reach Tier 4 to have a good program. The appropriate tier depends on your threat environment, risk tolerance, regulatory requirements, and resources.

Tier 1: Partial — Risk management is ad hoc and reactive. No organization-wide policy exists. Practices vary by department. Leadership has limited awareness of cybersecurity risk as a business issue.

Tier 2: Risk Informed — Risk management practices exist but are not formalized into organization-wide policy. Leadership is aware of cybersecurity risk. The organization understands some of its cybersecurity dependencies and supply chain relationships.

Tier 3: Repeatable — Formal, documented cybersecurity policies exist and are applied consistently. Risk management practices update in response to changing requirements and threats. Leadership actively participates in cybersecurity risk decisions. The organization can respond to incidents consistently.

Tier 4: Adaptive — The organization continuously adapts cybersecurity practices based on lessons learned, threat intelligence, and performance metrics. Cybersecurity considerations are embedded in organizational culture. The organization participates in information-sharing with peers and sector partners.

A 20-person SaaS company processing non-sensitive data may be well-served at Tier 2. A hospital handling protected health information under HIPAA, or a defense contractor handling controlled unclassified information, should target Tier 3 or Tier 4 because their threat environment and regulatory exposure warrant it. The tier choice should follow from a risk conversation, not a desire to appear mature.

Who Faces Real Pressure to Adopt CSF 2.0

The framework is voluntary for most private organizations. Three groups face meaningful external pressure.

Public companies subject to SEC cybersecurity disclosure rules. The SEC's rules (effective December 2023 for large accelerated filers, June 2024 for smaller reporting companies) require disclosing material cybersecurity incidents on Form 8-K and describing cybersecurity risk management processes in annual Form 10-K filings under Item 1C. Many companies reference NIST CSF alignment as evidence of a structured risk management program in their 10-K disclosures. The SEC does not mandate any specific framework, but CSF is among the most commonly cited.

Federal contractors. Federal agencies operate under FISMA, which requires using NIST standards. Defense contractors handling controlled unclassified information (CUI) must comply with NIST SP 800-171, which maps to CSF. Many civilian agency contracts also reference NIST standards in their security requirements.

Organizations seeking cyber insurance with higher coverage limits. Underwriters across the market have raised scrutiny of applicants' security postures following years of ransomware claims. Having no documented framework alignment is increasingly a disqualifier for higher coverage limits or better premium terms. CSF is one of the most commonly referenced frameworks in underwriting questionnaires, alongside CIS Controls.

How to Update an Existing Program from CSF 1.1

If your program already runs against version 1.1, the update is primarily an assessment and documentation exercise, not a rebuild. Most of your controls already address CSF 2.0 outcomes. The gaps tend to concentrate in a few areas.

Assess your Govern posture first. Most organizations upgrading from 1.1 will find their largest gap here. Specifically: formal risk tolerance and appetite statements (GV.RM), documented roles and authorities for cybersecurity (GV.RR), and a structured supply chain risk management process (GV.SC). If your organization has not explicitly documented its risk appetite in a way that leadership has approved, that is where to start.

Review your ID.IM activities. The new Improvement category consolidates lessons-learned activities that may have been informal or embedded in incident response procedures. Document how your organization captures improvement actions across all six functions and who is responsible for following through on them.

Remap your control documentation. If your existing documentation references CSF 1.1 category codes (e.g., ID.GV for Governance, PR.AC for Access Control), update those references. Many 1.1 category codes no longer exist in 2.0, and some subcategories moved to different categories. The NIST CSF 2.0 Reference Tool provides crosswalk tables between versions.

Update your Profile documents. If you maintain a Current Profile and Target Profile, revise them to reflect the 22 categories in 2.0. NIST's updated Profile template is available through the CSF 2.0 resource library.

How to Start If You Have No Prior CSF Program

The practical sequence is: build a Current Profile, define a Target Profile, gap-assess, prioritize by risk, implement.

Build a Current Profile. Document what cybersecurity activities your organization actually performs today, mapped to the six functions. The discipline here is accuracy — document what happens, not what should happen.

Define a Target Profile. Determine what outcomes your organization needs to achieve given its risk tolerance, regulatory requirements, contractual obligations, and threat environment. If you operate under HIPAA, PCI DSS, or CMMC, your Target Profile is partly defined by those external requirements and their mappings to the CSF.

Gap-assess and prioritize. Compare Current to Target. Sequence remediation by risk, not alphabetical order. A gap in GV.SC (supply chain risk management) likely carries more business risk than a gap in PR.AT (awareness training) for most organizations, but that depends on your specific threat model.

Use the community resources NIST provides. NIST has published Quick Start Guides targeting specific audiences: small businesses, enterprise risk management teams, and organizations responding to ransomware. These are freely available through nist.gov/cyberframework and give you a shorter path to a working program than starting from the full framework document.

CSF 2.0 and Other Frameworks

CSF 2.0 is not a replacement for SP 800-53, ISO 27001, or CIS Controls. It is a different kind of tool: an outcomes framework that tells you what your program should achieve, not the specific controls required to achieve it. The frameworks listed below describe the controls.

Organizations already certified to ISO 27001 or compliant with SP 800-53 will find that most CSF 2.0 outcomes are already covered by their existing controls. The documentation exercise is the primary effort, not new control implementation.

CSF 2.0 alignment does not satisfy SOC 2 or ISO 27001 requirements on its own. SOC 2 is an attestation issued by a licensed CPA firm against the AICPA's Trust Services Criteria — a different standard with a different audit process. ISO 27001 is a certification issued by an accredited certification body against the ISO standard. An organization aligned to CSF 2.0 at Tier 3 will find significant overlap with both, reducing the work required to pursue those certifications, but alignment and certification are distinct outcomes.

For more on what SOC 2 actually requires, see The Complete SOC 2 Compliance Checklist for 2026 and the Cybersecurity Compliance Checklist for a cross-framework view.

Common Errors in CSF 2.0 Programs

Treating the framework as a questionnaire to fill out. Organizations that map their existing controls to CSF categories without using the framework to make actual risk decisions get little value. The purpose is to give leadership a common language for prioritization, not to generate a mapping document.

Skipping Govern because it is new. The six Govern categories require organizational decisions — what is our risk appetite, who owns what, how do we assess vendors — that security teams often cannot make unilaterally. Engage legal, procurement, and executive leadership early.

Ignoring GV.SC for lack of a formal vendor program. Supply chain risk management does not require a fully mature third-party risk program to start. A vendor inventory, a set of contractual security requirements for high-risk suppliers, and a process for reviewing those requirements annually is a viable starting point at Tier 2.

Over-scoping the initial effort. CSF 2.0 is designed to scale. The appropriate scope for a 15-person company is not the same as for a regional bank. Start with the subcategories that address your highest-probability, highest-impact risks and build from there.

Mini-FAQ

Is NIST CSF 2.0 mandatory?

For most private organizations, no. Federal agencies must use NIST standards under FISMA. Defense contractors handling CUI must comply with NIST SP 800-171. Some state laws and regulated industries reference the CSF, so check your specific environment. The SEC's cybersecurity disclosure rules do not mandate any particular framework but create practical pressure to document your program against one.

Can I still use CSF 1.1?

NIST no longer updates version 1.1. You can reference it internally, but it predates the Govern function and the current supply chain risk management guidance. Auditors, regulators, and insurance underwriters increasingly expect 2.0 alignment. Updating is worth the effort, and for programs already running a mature program, the work is primarily documentation.

How many subcategories does CSF 2.0 have?

CSF 2.0 has 106 subcategories across 22 categories and 6 functions. Version 1.1 had 108 subcategories across 23 categories and 5 functions. The overall count is similar; the distribution shifted significantly, particularly with the addition of the Govern function.

Does aligning to CSF 2.0 help with SOC 2 or ISO 27001?

Indirectly. CSF 2.0 alignment reduces the effort required to pursue SOC 2 or ISO 27001 because the frameworks share significant outcome overlap, but they are separate processes. SOC 2 requires a CPA firm attestation against the AICPA's Trust Services Criteria; ISO 27001 requires certification by an accredited certification body. CSF alignment is not a substitute for either.

Where can I access the official framework document?

The full CSF 2.0 document is available at doi.org/10.6028/NIST.CSWP.29. Quick Start Guides, Community Profiles, and the online reference tool are available through nist.gov/cyberframework.

Sources

1. NIST, "The NIST Cybersecurity Framework 2.0," NIST CSWP 29, February 26, 2024. https://doi.org/10.6028/NIST.CSWP.29
2. NIST Cybersecurity Framework resource center, accessed 2026-05-12. https://www.nist.gov/cyberframework
3. CSF 2.0 online reference tool (functions, categories, subcategories), accessed 2026-05-12. https://csf.tools/reference/nist-cybersecurity-framework/v2-0/
4. SEC, "Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure," Final Rule, 17 CFR Parts 229 and 249, effective December 18, 2023. https://www.sec.gov/rules/final/2023/33-11216.pdf
5. AICPA, "SOC 2 — SOC for Service Organizations: Trust Services Criteria," accessed 2026-05-12. https://www.aicpa-cima.com/resources/landing/soc-2

Sources used

1. NIST CSWP 29 — accessed 2026-05-12
2. online reference tool — accessed 2026-05-12
3. CSF 2.0 Reference Tool — accessed 2026-05-12
4. Trust Services Criteria — accessed 2026-05-12

Last reviewed: 2026-05-12. This article was prepared by the Security Compliance Guide Editorial Team. We use AI to draft initial summaries of publicly available cybersecurity compliance documentation, then verify every claim against primary sources before publication. We are not licensed auditors, attorneys, or compliance consultants. For binding decisions, consult a qualified professional. See our editorial standards for full sourcing rules.