The NIST Cybersecurity Framework is the most widely used way of organizing a conversation about cybersecurity risk, and it is regularly misdescribed. It is not a standard, not a control catalog, and not something an organization can be certified against.
What it is, is a structure: a way of arranging security outcomes so that an organization can describe its current position, decide on a target, and explain both to people who are not specialists. This article covers the structure, how it is used in practice, and the misuses worth avoiding.
The six functions
The framework arranges everything into six functions. NIST states the purpose plainly: the core functions, GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND, and RECOVER, organize cybersecurity outcomes at their highest level.
The version 2.0 release added govern, and that addition is the most consequential change in the framework's history. It moved organizational context, roles, policy and risk management strategy from being implied around the edges to being a named function, reflecting the finding that technical work fails predictably when the decisions behind it have no owner.
The functions are not a sequence to be worked through once. NIST is explicit that actions supporting GOVERN, IDENTIFY, PROTECT, and DETECT should all happen continuously, while those supporting respond and recover should be ready at all times and happen when incidents occur. That is the same argument made in the managed cybersecurity lifecycle, stated by the source.
What each function covers
Govern establishes and monitors the organization's cybersecurity risk management strategy, expectations and policy: who decides, what the appetite is, how it is overseen and how supply chain risk is managed.
Identify establishes what the organization has and what could threaten it: asset and data inventory, risk assessment, and the improvement loop that feeds back from everything else. The practice is covered in cybersecurity risk assessments.
Protect covers the safeguards themselves: identity and access, awareness, data security, platform security and the resilience of technology infrastructure.
Detect covers finding and analyzing possible attacks, addressed in security monitoring and incident detection.
Respond covers acting on a detected incident, and recover covers restoring what was affected. Both are discussed in incident response and cybersecurity recovery.
Beneath the functions sit categories and subcategories, and the subcategories are where the framework becomes specific enough to assess against. They are written as outcomes rather than as actions, which is what allows an organization to decide for itself how an outcome is achieved.
Profiles, and the actually useful part
The mechanism that makes the framework practical is the profile: a statement of which outcomes matter to this organization and how it is doing against them.
A current profile records where the organization stands. A target profile records where it intends to stand, chosen against its own risk rather than against an ideal. The difference between the two is the improvement plan, and expressing it that way makes it fundable, because it is a gap rather than a list of complaints.
This is also where most of the value is lost. Organizations frequently produce a current profile, discover it is uncomfortable, and produce no target profile, which leaves them with an assessment and no plan.
Tiers, and the common misreading
The framework describes tiers, from partial through risk informed and repeatable to adaptive. They are regularly treated as a maturity score to be maximized, and that is a misreading.
The tiers describe how rigorously an organization manages cybersecurity risk, and NIST's framing is that the appropriate tier depends on the organization's own risk, obligations and resources. A small organization with modest exposure operating at a lower tier may be making an entirely correct allocation. Announcing an intention to reach the highest tier without a reason connected to risk is ambition rather than strategy.
What it is not
Three clarifications, because each is regularly implied in the market.
It is not a certification. No body certifies an organization against the framework, and a claim of being certified under it should be read as a claim about the speaker rather than about their security. Where certification is genuinely wanted, the relevant instrument is ISO/IEC 27001 and information security management.
It is not a control catalog. The subcategories state outcomes and deliberately do not prescribe implementations. Where a detailed control set is needed, that is NIST SP 800-53 security controls, which maps to the framework.
It is not a priority order. The framework does not tell an organization what to do first, which is precisely the gap that the CIS Critical Security Controls fill. Using the framework for structure and the controls for sequence is a common and sensible combination.
What changed between version 1.1 and version 2.0
Organizations with an existing profile against the earlier version do not have to start again, but three changes are worth knowing.
The addition of the govern function is the substantive one. Material that previously sat inside identify, covering business environment, governance and risk management strategy, was promoted and expanded. An existing profile will have covered some of this ground under a different heading.
The second change is scope of audience. The earlier version was framed around critical infrastructure; the current one is explicitly for organizations of all sizes and sectors. In practice this removed the awkwardness of small organizations using a document that appeared to be addressed to somebody else.
The third is the surrounding material. NIST now publishes implementation examples and quick start guides alongside the framework, which addresses the longest standing complaint about it, that the subcategories state an outcome and leave a smaller organization unsure what would satisfy it.
Where it meets an incident
A detail worth noting, because it shows the functions are not merely a filing scheme. NIST describes how they divide across the life of an incident: GOVERN, IDENTIFY, and PROTECT outcomes help prevent and prepare for incidents, while GOVERN, DETECT, RESPOND, and RECOVER outcomes help discover and manage incidents.
Govern appears in both halves, which is the useful observation. Governance is not only the thing done beforehand; it is also what determines whether the decisions needed during an incident can be made quickly, because those decisions are authorities established in advance. An organization whose incident response stalls while somebody looks for permission has a governance gap presenting as a response gap.
Why it is worth adopting anyway
Given all of that, the framework earns its place for reasons that are partly social.
It is a shared vocabulary. When a security team, an executive, an auditor, an insurer and a customer all use the same six functions, a great deal of translation disappears. That is not a trivial benefit; a large share of the friction in security programs is people describing the same thing differently.
It is comprehensive without being prescriptive, so it can be used by organizations of very different sizes without one of them pretending. And it is recognized, which means a report structured around it needs no preamble explaining the structure.
Adopting it without a large project
Adoption goes wrong when it becomes a documentation exercise ahead of any improvement. A workable sequence is smaller.
Assess the current position honestly, at the category level rather than every subcategory, and accept that the first pass will be rough. Decide the target using the organization's own obligations and risk rather than an ideal. Identify the largest gaps that matter and sequence them, using a prioritized control set if the ordering is unclear. Then report against the same structure consistently, so the trend is legible.
The honesty of the first assessment determines the value of everything after it. A generous self assessment produces a comfortable report and a plan aimed at the wrong things, which is the failure mode described in continuous security and compliance monitoring.
How LABUSA uses it
LABUSA structures its managed security reporting around the framework's functions, because a buyer reading a report organized that way does not have to learn a vendor's vocabulary first, and an auditor can map it to their own requirements without assistance.
The operational work under each function is delivered through managed cybersecurity service delivery. Assessment against the framework, and the target profile conversation, are engagements delivered through cybersecurity and risk management.
One closing caution. The framework describes outcomes an organization should achieve, and it is entirely possible to produce a profile showing strong coverage while the underlying controls are configured and unexercised. The framework will not catch that, because it was never designed to. Validating that a control operates, rather than exists, remains a separate discipline and is the one that determines what happens on the day it is needed.
Sources
- NIST, The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29, February 2024.
- NIST, Security and Privacy Controls for Information Systems and Organizations, SP 800-53 Rev. 5.
- Center for Internet Security, The 18 CIS Critical Security Controls.