The NIST Cybersecurity Framework 2.0

The NIST Cybersecurity Framework is the closest thing security has to a common language. It was published in 2014 for critical infrastructure, and version 2.0 arrived in February 2024 as the first major rewrite.

Its most useful property is that it does not tell you how to do anything. It is a list of outcomes you should be able to achieve, sector-neutral and technology-neutral, so a hospital, a factory and a five-person software company can all use the same vocabulary while implementing completely different things.

What changed in 2.0

Three things worth knowing if you already used version 1.1.

It is for everyone now. The old title was "Framework for Improving Critical Infrastructure Cybersecurity". That title is gone. The framework now explicitly targets organisations of any size, sector or maturity.

A sixth function appeared: Govern. The original five were Identify, Protect, Detect, Respond, Recover. Govern was added because too many organisations were buying tools without anyone deciding on strategy, roles, policy or acceptable risk. It also absorbed and expanded supply chain risk management.

NIST added the practical material. Implementation examples showing concrete ways to achieve each outcome, Quick-Start Guides for specific audiences including small business, Community Profiles for particular sectors, and a searchable set of Informative References that cross-map the framework to other standards. The 1.1 version was often criticised for being abstract. That criticism is now largely addressed.

The Core:

Six Objectives, split into 22 Categories, split into just over 100 Subcategories, each with a specific outcome written as a plain statement.

GOVERN (GV)

Establishing and monitoring your cybersecurity strategy, expectations and policy.

Categories:

Organizational Context,
Risk Management Strategy,
Roles/Responsibilities/Authorities,
Policy,
Oversight, and
Cybersecurity Supply Chain Risk Management.

In practice:

who owns security,
what risk you are willing to accept,
what your policies say, and
how you hold suppliers accountable.

This Objective informs all the others.

IDENTIFY (ID)

Understanding your current risk.

Categories:

Asset Management,
Risk Assessment,
Improvement.

In practice:

an inventory of hardware,
software,
data,
services and suppliers,
plus a risk assessment on top of it.

You cannot protect what you have not listed.

PROTECT (PR)

Safeguards to manage the risk you identified.

Categories:

Identity Management/Authentication/Access Control,
Awareness and Training,
Data Security,
Platform Security,
Technology Infrastructure Resilience.

In practice:

multi-factor authentication,
least privilege,
encryption,
patching,
hardening,
network segmentation,
backups,
training.

DETECT (DE)

Finding attacks and anomalies.

Categories:

Continuous Monitoring,
Adverse Event Analysis.

In practice:

log collection,
a SIEM,
intrusion detection,
endpoint detection, and
someone whose job is to look at what they produce.

RESPOND (RS)

Acting on a confirmed incident.

Categories:

Incident Management,
Incident Analysis,
Incident Response Reporting and Communication,
Incident Mitigation.

In practice:

a written plan,
defined roles,
a way to contain a compromised machine, and
a contact list you can reach without your corporate email.

RECOVER (RC)

Restoring normal operations.

Categories:

Incident Recovery Plan Execution,
Incident Recovery Communication.

In practice:

tested restore procedures,
a defined order of restoration, and
communication to staff,
customers and regulators.

A subcategory looks like this:

PR.AA-05: Access permissions, entitlements, and authorizations are defined
          in a policy, managed, enforced, and reviewed, and incorporate the
          principle of least privilege and separation of duties

Notice it says nothing about which product to buy.

Tiers: how rigorous is your approach

Tiers describe the character of your risk management practice, not your security score. There are three, and they are not maturity levels you are obliged to climb.

Tier	Name	What it looks like
1	Basic	Ad hoc and reactive. Little awareness of risk. Security happens when something breaks and/or Management is aware and approves practices, but they are not organisation-wide or consistent.
2	Managed	Formal policy, regularly updated, applied consistently. Suppliers are assessed.
3	Optimized	Practices evolve from lessons learned and predictive indicators. Risk management is part of the culture and budget.

Tier 3 is not the goal for every organisation. A twelve-person company operating at Tier 2 with tested backups and MFA is in a better position than one at Tier 3 on paper with neither. Pick the tier that matches the risk you actually carry.

Profiles: where you are and where you want to be

This is the part that turns the framework into a project plan.

A Current Profile records which outcomes you achieve today. A Target Profile records which outcomes you want to achieve, chosen based on your risk, your obligations and your budget.

The gap between them is your roadmap. Prioritise the gaps by risk, assign owners and dates, and you have a security programme that you can present to a board without hand-waving.

How to actually use it

Read the Quick-Start Guide for your situation. NIST publishes short ones, including for small business. Start there, not with the full document.
Do the inventory (IDENTIFY). Everything else is guesswork without it.
Score your Current Profile. For each subcategory, mark it as Basic, Managed or Optimized. A spreadsheet is fine. Involve people outside IT.
Set a Target Profile. Be realistic. Not every subcategory needs to be Optimized.
Prioritise the gaps by risk, not by how easy they are.
Assign owners and dates, and review quarterly.
Use the Informative References when you need specific controls. They map CSF outcomes to ISO 27001, NIST 2.0, COBIT 2019 and dozens of other documents, so you are not inventing controls yourself.

Common mistakes

Treating it as a checklist. The CSF describes outcomes, not tasks. "PR.AA-05 Managed" means access control genuinely works, not that a policy document exists.
Starting with the full document. It is a reference, not a tutorial. Start with a Quick-Start Guide and one Objective.
Skipping GOVERN. It is first for a reason. Without a decision on who owns security and what risk is acceptable, the other five functions have no direction.
Confusing it with compliance. The CSF is voluntary. It is not a certification and there is no audit to pass. That is a strength: you adopt what fits. If you need certification, ISO 27001 is the usual route, and the CSF maps to it cleanly.

Takeaway

The framework's real value is communication. It gives your engineers, your management and your auditors one vocabulary, and it turns "are we secure?" into a question with a structured answer.

Start small. Inventory your assets, score yourself against one Objective, and see what the gap looks like. That first honest scoring exercise usually tells you more than any tool you could buy.