The NIST Cybersecurity Framework Explained

• CSF 2.0 has SIX functions: Govern, Identify, Protect, Detect, Respond, Recover. Govern was added in 2.0.
• It is voluntary and there is no certification. Nobody can be "NIST CSF certified".
• The CSF is NOT NIST 800-53 (a control catalogue) and NOT 800-171 (protecting controlled unclassified information). Different documents, different jobs.
• Its real value is as an organising vocabulary - a way to see which part of your programme is thin.

The NIST Cybersecurity Framework is a voluntary structure for organising and describing a security programme, built around six functions: Govern, Identify, Protect, Detect, Respond and Recover. It is not a control checklist, not a certification, and not the same document as NIST 800-53 or 800-171 - three confusions that account for most of the misunderstanding around it.

Version 2.0 is the current shape, and its headline change was adding Govern as a function in its own right, alongside broadening the framing beyond critical infrastructure to any organisation.

The six functions

Govern. Who decides, what the risk appetite is, how roles and accountability are set, and how security fits organisational strategy. New as a function in 2.0, and the addition is telling: the previous five described activity, and plenty of programmes were busy without anyone owning direction.

Identify. Understanding what you have and what could threaten it - asset inventory, risk assessment, supplier landscape. The function everything else depends on, because you cannot protect or detect on assets you have not enumerated.

Protect. The safeguards: access control, awareness and training, data security, platform hardening, resilience of the technology base.

Detect. Finding that something is happening - monitoring, anomaly analysis, and the ability to distinguish an event from noise.

Respond. What you do once you know: incident management, analysis, communication, mitigation.

Recover. Getting back to operating, and communicating during it - restoration, and the plan that makes restoration a procedure rather than an improvisation.

Tiers and Profiles

Two mechanisms make the functions usable, and both are more interesting than the function list itself.

Profiles describe where you are and where you intend to be. A Current Profile records how you handle each outcome today; a Target Profile records where you want to be. The gap between them is your programme, and expressing it that way makes it arguable with a budget holder in a way a control checklist is not.

Tiers describe how rigorous your risk-management practice is, from ad hoc through to adaptive. They are deliberately not a maturity score to chase - the framework is explicit that a higher tier is not automatically the goal, since the right level depends on your risk and resources.

What the CSF is NOT

Worth being blunt, because these conflations show up constantly, including in vendor material.

And there is no CSF certification. An organisation can align with it, self-assess against it, or hire someone to assess them, but "NIST CSF certified" is not a thing that exists. If a vendor claims it, that is a useful signal about the rest of their claims.

The CSF earns its place as a shared vocabulary rather than a standard to pass. Its most valuable property is that it makes an imbalanced programme visible - most teams discover they are heavy on Protect and thin on Detect and Recover.

How to actually use it

Three steps that produce something useful rather than a filled-in spreadsheet.

1. Map what you already do onto the six functions. Not aspirationally - what actually happens.
2. Look for the thin function. There is almost always one. If you cannot describe how you would detect an intrusion, or what your first hour of Recover looks like, that is your priority regardless of how strong Protect is.
3. Write a Target Profile for the next twelve months, not the end state. The gap becomes your roadmap, and it is expressed in language a non-technical budget holder can follow.

Where testing fits

The CSF describes outcomes rather than prescribing methods, so it does not tell you to run a penetration test. Testing is how you get evidence for several of them at once: whether Protect safeguards hold under attack, and whether Detect actually notices.

That second one is underused. A test is an opportunity to ask what your monitoring saw while it was running - if the answer is nothing, you have learned something about Detect that no control review would have told you.

Our penetration testing services page sets out what that testing covers.

If your interest in NIST is the federal control catalogue rather than the framework, that is a different document and we cover it separately: what NIST 800-53 control CA-8 says about penetration testing. The compliance hub has the same treatment for the other frameworks.