NIST Cybersecurity Framework (CSF) 2.0

What it is

The NIST Cybersecurity Framework (CSF) 2.0 is a voluntary taxonomy of high-level cybersecurity outcomes, published by the US National Institute of Standards and Technology, that "any organization... regardless of its size, sector, or maturity" can use to understand, assess, prioritise and communicate its cybersecurity risk. It does not prescribe how an outcome should be achieved or in what order; it describes what a well-run cybersecurity programme covers, then leaves the how to a separate, continuously updated set of online resources.

Before this version the document was called the "Framework for Improving Critical Infrastructure Cybersecurity," a title the document says plainly "is not used for CSF 2.0." The 2.0 revision broadens the framing from critical infrastructure to any organisation and adds GOVERN, a new Function placed at the centre of the model because governance decisions set priorities for the other five.

The six Functions

The CSF Core (Appendix A) organises outcomes under six Functions, each split into Categories and further into Subcategories describing an outcome rather than a procedure:

• GOVERN (GV): organisational context, risk management strategy, roles and responsibilities, policy, oversight, and a dedicated Cybersecurity Supply Chain Risk Management category. Concretely, this means risk management objectives agreed by organisational stakeholders, a policy that is "reviewed, updated, communicated, and enforced" as circumstances change, and suppliers that are known, ranked by criticality, and bound by cybersecurity requirements built into contracts.
• IDENTIFY (ID): asset management, risk assessment and improvement. Inventories of hardware, software, services and data; vulnerabilities that are "identified, validated, and recorded"; critical suppliers assessed before acquisition.
• PROTECT (PR): identity and access control, awareness and training, data security, platform security, and technology infrastructure resilience. Access permissions that "incorporate the principles of least privilege and separation of duties," personnel trained both generally and in specialised roles, and backups that are "created, protected, maintained, and tested."
• DETECT (DE): continuous monitoring and adverse event analysis. Networks, the physical environment, personnel activity and external service providers are all monitored "to find potentially adverse events," with information correlated across sources before an incident is declared.
• RESPOND (RS): incident management, analysis, reporting and mitigation. An incident response plan "executed in coordination with relevant third parties once an incident is declared," incidents that are contained and eradicated.
• RECOVER (RC): recovery plan execution and recovery communication. The recovery portion of the incident response plan is executed once initiated, and the integrity of restored assets and backups is verified before they are relied on again.

Profiles and Tiers

Two mechanisms sit above the Core. An Organizational Profile (Current and/or Target) records which outcomes an organisation is achieving now and which it has prioritised for later, scoped as broadly or narrowly as the organisation chooses: an entire organisation, or something as specific as "countering ransomware threats and handling ransomware incidents involving those financial systems." Tiers then characterise how rigorous the organisation's governance and risk management practices actually are, from Partial (Tier 1: ad hoc, "generally unaware of the cybersecurity risks associated with its suppliers") to Adaptive (Tier 4: organisation-wide and continuously improving). Neither is scored against a passing threshold; they describe a state, and the gap between a Current and a Target Profile becomes the organisation's own action plan.

Who has to care, and when

The document names "individuals responsible for developing and leading cybersecurity programs" as its primary audience, extending to executives, boards of directors, acquisition professionals, risk managers, and those who make and influence policy. Nothing in the CSF creates an obligation by existing: it "may be adopted voluntarily and through governmental policies and mandates," and, in practice, a supplier often meets it because a customer that has already adopted the CSF sets out its "requirements and expectations to suppliers, partners, and other third parties as a target for those parties to achieve" through a Target Profile.

NIST is a US federal agency, but the CSF is explicit that its "taxonomy and referenced standards, guidelines, and practices are not country-specific," and notes that earlier versions "have been leveraged successfully by many governments and other organizations both inside and outside of the United States."

What stands out

The Subcategories describe outcomes, not procedures, and the CSF supplies none of the how itself: that is delegated to Informative References, Implementation Examples and Quick-Start Guides, hosted online and revised on their own schedule, separately from this document. The numbering inside the Core is also deliberately not sequential: gaps in the numbering mark where a CSF 1.1 Subcategory was relocated in 2.0, not an error.

How it is evaluated

There is no certification against the CSF. The document names no accreditation body, government-surveillance regime, or notified body; it simply does not describe one. What it describes instead is self-assessment: an organisation documents its current and target posture, works out the gaps, and tracks the result through its own action plan (a risk register, a risk detail report, or a Plan of Action and Milestones), reviewed as part of its own ongoing risk management.

The one place a third party enters is contractual, not official: a customer or partner that has adopted the CSF can hold a supplier to a Target Profile as a stated expectation. What that customer checks, in that case, is whatever the Target Profile specifies, since the CSF itself sets no pass mark. A regulator or agency that has adopted the CSF through its own policy checks against that policy, not against this document.

Standards it references

NIST's own Risk Management Framework (NIST SP 800-37) and security controls catalogue (NIST SP 800-53) are named as the pairing the CSF complements for an organisation already using them. [NIST SP 800-30](/standards/nist-sp-800-30), the risk assessment guide, and [NIST AI RMF](/standards/nist-ai-rmf), which uses the same Function/Category/Subcategory structure for AI-specific risk, are both named directly. The NIST Privacy Framework, SP 800-161r1 (supply chain risk), SP 800-221 and SP 800-221A (enterprise ICT risk), and NIST IR 8286 A-D (enterprise risk management) are each named for a specific integration point; none are yet in our catalogue, so they are named here rather than linked.