The NIST Cybersecurity Framework has become the default way US organizations describe a security program to people who are not in security. Version 2.0, released in 2024, made changes worth understanding, particularly if your program was built against version 1.1 and has not been revisited.
The Structure
CSF organizes cybersecurity outcomes into functions, each containing categories and subcategories that state what should be achieved rather than how.
Govern is the addition in 2.0 and sits at the center of the others. It covers organizational context, risk management strategy, roles and responsibilities, policy, oversight and supply chain risk management.
Identify covers understanding what you have and what threatens it: asset management, risk assessment, and improvement.
Protect covers the safeguards: identity and access management, awareness and training, data security, platform security and technology infrastructure resilience.
Detect covers finding adverse events: continuous monitoring and adverse event analysis.
Respond covers acting on them: incident management, analysis, reporting and mitigation.
Recover covers restoring: recovery plan execution and communication.
The framework's strength is that this vocabulary works in a board meeting and in an engineering review, which is a genuinely difficult thing to achieve.
What Govern Actually Asks
The addition of Govern is the most consequential change, and it is easy to underestimate as an administrative reshuffle.
It is not. Placing governance at the center formalizes something practitioners have argued for years: that most security failures are organizational rather than technical. Unclear ownership, risk decisions made at the wrong level, policy that does not match practice, and no mechanism for leadership to know whether any of it is working.
Govern asks you to evidence that cybersecurity risk is understood in the context of the organization's mission, that a risk management strategy exists and is applied, that roles and authorities are established and communicated, that policy exists and is enforced, that oversight informs and adjusts the strategy, and that supply chain risk is managed as part of all of it.
Those are harder to demonstrate than a technical control, and they are the questions that come up after an incident.
Supply Chain, Promoted
Version 2.0 substantially elevated supply chain risk management, placing it inside Govern rather than treating it as a subsidiary concern.
This reflects the actual threat picture. A large and growing share of incidents arrive through a third party: a compromised software vendor, a managed service provider with access to client environments, an open-source dependency with a malicious commit.
The framework asks for suppliers to be identified and prioritized by criticality, for requirements to be established and included in contracts, for suppliers to be assessed before and during the relationship, and for supply chain considerations to appear in incident planning. That last one is regularly missing: organizations plan to respond to their own incident and not to their vendor's.
Worth noting is that assessment means more than a questionnaire. The question worth answering about any supplier is what they could reach if compromised, which is a reachability question rather than a scoring one. We have written more on this in supply chain and third-party risk.
Using It Without Drowning In It
CSF has 106 subcategories in version 2.0. An organization that attempts to address all of them in order will produce a great deal of documentation and not much security.
The approach that works is profile-driven. Build a Current Profile: honestly, where are you against the outcomes that matter for your organization? Build a Target Profile: where do you need to be, given your risk, sector and obligations? The gap is your roadmap, prioritized by risk rather than by subcategory order.
Two cautions. First, a Current Profile built from self-assessment records beliefs rather than facts, and the gap between the two is usually widest in Detect and Respond, where teams consistently overestimate coverage. Technical assessment is what grounds it: a purple team exercise will tell you what your detection actually catches, which is otherwise guesswork.
Second, Tiers are not maturity levels, though almost everyone treats them as such. They describe how integrated and adaptive your risk management approach is. An organization can be Tier 2 and appropriately secure for its risk.
Where It Fits Among the Others
CSF is the organizing layer. It does not replace the control sets underneath it.
If you handle controlled unclassified information, NIST SP 800-171 specifies the controls and CMMC assesses them. If you take card payments, PCI DSS is prescriptive and mandatory. If you serve enterprise customers, SOC 2 is what they ask for. If you operate in healthcare, the HIPAA Security Rule applies directly.
CSF is how you structure a program that satisfies whichever of those apply, and how you explain that program to a board. Used that way it is genuinely valuable. Used as a compliance checklist it becomes an expensive documentation exercise, which is the failure mode to watch for.
To discuss assessing your program against the framework, get in touch.
Frequently asked questions
What is the NIST Cybersecurity Framework?
A voluntary framework organizing cybersecurity outcomes into functions, categories and subcategories, published by the National Institute of Standards and Technology. It is descriptive rather than prescriptive: it states outcomes to achieve rather than controls to implement, which makes it useful as a common language across technical teams, executives and boards. It is widely used well beyond the critical infrastructure sectors it was originally written for.
What changed in version 2.0?
Three things principally. A sixth function, Govern, was added and placed at the center, covering strategy, roles, policy and oversight. The scope was broadened explicitly beyond critical infrastructure to all organizations. And supply chain risk management was elevated substantially, reflecting how much of current risk arrives through third parties.
Is NIST CSF mandatory?
Not in itself. It is voluntary, and adopting it carries no legal obligation. In practice it appears in contracts, particularly federal and state contracting, is referenced by regulators, and is frequently used by insurers and enterprise customers as an assessment basis. Voluntary and consequential are not mutually exclusive.
How does CSF relate to NIST SP 800-171 and CMMC?
They serve different purposes. CSF is a flexible outcome-based framework for organizing a program. SP 800-171 is a specific control set for protecting controlled unclassified information in non-federal systems, and CMMC is the mechanism for assessing compliance with it. If you handle CUI you need 800-171; CSF is how many organizations structure the wider program around it.
What are Tiers and Profiles?
Tiers describe how rigorous and integrated your risk management practices are, from Partial through Adaptive. Profiles describe your current or target state against the framework's outcomes. The useful practice is a Current Profile and a Target Profile, with the gap between them becoming your roadmap. Tiers are frequently mistaken for maturity scores and are better read as a description of approach.