NIST CSF 2.0 Explained: A Practical Guide for Real Programmes

The NIST Cybersecurity Framework (CSF) is the most widely adopted security framework in the world. Version 2.0 — published in 2024 — added a new Govern function and modernised the language across the rest. If you’re building, refining or just trying to articulate a cyber programme, CSF is a good lingua franca.

What follows is a practical walkthrough — what each function means, how to use it, and where teams typically get stuck.

The six functions

CSF 2.0 organises cybersecurity activities into six high-level functions. Each function contains categories, each category contains subcategories, each subcategory maps to control standards (CIS, ISO 27001, COBIT, etc.).

1. Govern (GV) — strategy, policy, risk management, supply chain, accountability
2. Identify (ID) — assets, data, business context, vulnerabilities
3. Protect (PR) — identity & access, awareness, data security, platform security, infrastructure resilience
4. Detect (DE) — continuous monitoring, adverse event analysis
5. Respond (RS) — incident management, analysis, response activities, communications
6. Recover (RC) — recovery plan execution, communications

The functions are not phases — they’re concurrent areas of activity. A mature programme is doing all six all the time.

Govern: the new function

CSF 2.0’s biggest change. In CSF 1.x, governance was scattered. Now it’s its own function with categories like:

• Organisational context (mission, business objectives)
• Risk management strategy
• Cybersecurity supply chain risk management (C-SCRM)
• Roles, responsibilities and authorities
• Policy
• Oversight

If you’ve never had board-level cybersecurity governance, this is the function to start with. Without governance, the rest is hobby work — important things get done by individuals, not by an organisation.

Quick test: Can you point to a cybersecurity strategy document, signed off by leadership, with measurable objectives? If no, your Govern maturity is below “Tier 2 — Risk Informed” regardless of how good your detection content is.

Identify: know your stuff

The classic adage — “you can’t protect what you don’t know you have” — sits in Identify. Categories include:

• Asset management (hardware, software, data, services, suppliers)
• Risk assessment
• Improvement (lessons learned, programme adjustments)

This is where most programmes claim more maturity than they have. An asset inventory in a spreadsheet that nobody updates isn’t an asset inventory — it’s archaeological evidence of one.

Modern asset management uses automated discovery: cloud asset inventories, EDR rolls, network discovery, SaaS access logs, employee directory integrations. The goal is a near-real-time picture of what you have to defend.

Protect: the most populated function

Categories under Protect span identity, awareness, data security, platform security, technology infrastructure resilience. This is where the bulk of “what does cybersecurity actually do” lives — MFA, EDR, encryption, segmentation, training, patching, hardening.

The temptation is to treat Protect as a checklist. The smarter approach is risk-based: which controls reduce the most risk for the threats most relevant to your business? A regional retailer’s Protect priorities look different from a SaaS company’s, which look different from a hospital’s.

Detect: visibility is the gating factor

Detect has narrowed in CSF 2.0 to two categories: continuous monitoring and adverse event analysis. The simplification reflects the reality — your detect maturity is roughly: do you collect the right telemetry, do you have detection content, and does someone act on alerts?

The gating factor for almost every detection programme is logging. Without comprehensive logs from endpoints, identity providers, networks and applications, you can’t detect anything.

Respond: the most under-invested function

Most programmes over-invest in Detect tools and under-invest in Respond capability. A great alert that nobody can act on is worse than no alert — it creates false confidence.

Respond categories are about incident management lifecycle: triage, analysis, mitigation, reporting, communication. The deliverables are written: incident response plan, communication templates, decision authorities, escalation paths.

If you only test your Respond function during real incidents, you’re testing it under the worst possible conditions. Tabletop exercises are how you find out which playbooks work and which fall apart on contact with reality.

Recover: not just backups

Recover is often misread as “restore from backup.” It’s bigger:

• Restoration of services and capabilities (yes, including backup restore)
• Recovery communications (internal, customer, regulator, public)
• Lessons learned, fed back into the rest of the programme

The lessons-learned loop is what turns Recover into a multiplier for the other functions. Every incident is data — what worked, what didn’t, where the playbook had gaps. Without a structured post-incident process, you fix the same problem six times.

Tiers — the maturity model

CSF defines four implementation tiers describing how integrated and adaptive your programme is:

• Tier 1 — Partial. Ad-hoc, reactive, limited awareness.
• Tier 2 — Risk Informed. Risk decisions made but not consistently across the org.
• Tier 3 — Repeatable. Formalised processes, organisation-wide policy, supply chain awareness.
• Tier 4 — Adaptive. Continuous improvement, lessons learned drive change, real-time risk awareness.

Tiers are not a goal in themselves — pick the tier that fits your risk profile. A Tier 4 programme costs Tier 4 money. Most organisations should target Tier 3.

Profiles — your way of using the framework

NIST encourages you to build a Current Profile (where you are now) and a Target Profile (where you need to be), then close the gap. The profile is essentially a spreadsheet of subcategories with implementation status.

Pragmatic advice: don’t try to assess all ~100+ subcategories the first time. Start with the highest-risk ten. Close those gaps. Add another ten. Iterate. A perfect 100% gap analysis that takes 9 months is less useful than a partial one that drives action in 3.

Common failure modes

• Treating CSF as a project. It’s a way of organising your programme, not a one-off engagement. The gap analysis isn’t the deliverable — the closure plan is.
• Mapping for mapping’s sake. If your CSF mapping isn’t driving budget, headcount, or roadmap decisions, you’re producing a museum exhibit.
• Over-relying on consultants. External help is useful for facilitation. The owner of the programme has to be internal — otherwise the framework dies when the consultant leaves.
• Confusing maturity with effectiveness. A mature process can still be defending against the wrong things. Pair maturity assessment with threat modelling.

Where to start

If you’re new to CSF:

1. Read the framework document (it’s surprisingly readable).
2. Self-score your maturity per function — be honest, not aspirational.
3. Identify your two weakest functions and put quarterly objectives against them.
4. Build a one-page profile that fits on a whiteboard. Avoid 200-row spreadsheets.
5. Review quarterly with leadership. Adjust.

Take the 25-question NIST CSF Quick Check → for a directional read of where you stand across all six functions.