NIST CSF 2.0: The Cybersecurity Framework Most Compliance Programs Are Ignoring

Ask most compliance teams to name the frameworks that matter, and you'll hear SOC 2 first, ISO 27001 second, and maybe HIPAA or PCI DSS depending on the industry. NIST CSF tends to come up later in the conversation, if it comes up at all.

That's a mistake, and increasingly an expensive one. NIST CSF isn't a certification you can frame on the wall, which is probably why it gets less attention than the frameworks that come with an audit and a badge. But it's quietly become one of the most widely used tools for how enterprise security teams actually evaluate vendor risk, and most organizations have no idea it's the lens being applied to them.

Here's what it is, why it matters more than its profile suggests, and what to do about it.

What Changed in Version 2.0

NIST CSF 2.0, released in February 2024, was the first major update to the framework since its original publication a decade earlier. The update reflected a decade of lessons about how organizations were actually using the framework, and where the original version fell short.

The most significant change was the addition of a sixth core function: Govern. The original framework was built around five functions: Identify, Protect, Detect, Respond, and Recover. These map reasonably well to the operational lifecycle of managing cybersecurity risk. What they didn't capture explicitly was governance: how an organization makes decisions about risk tolerance, how cybersecurity strategy connects to business strategy, how oversight and accountability are structured, and how third-party and supply chain risk gets managed at the leadership level.

Adding Govern as a standalone function was a deliberate signal. Cybersecurity risk management isn't just a technical operations problem. It's a governance problem that starts in the boardroom and flows down through the organization. That reframing matters more now than it did in 2014, in an environment where boards, regulators, and enterprise clients are all asking sharper questions about how cybersecurity decisions get made.

The second major change was scope. The original CSF was written with critical infrastructure organizations in mind. CSF 2.0 was explicitly rewritten for organizations of any size, in any sector. The language is more accessible, the implementation guidance is more practical for smaller organizations without dedicated security teams, and the framework is positioned as broadly applicable rather than infrastructure-specific.

The Six Functions, in Practice

Govern sets the foundation. This function covers organizational context, risk management strategy, roles and responsibilities, policy, and oversight of supply chain risk. It's where leadership defines what an acceptable level of risk looks like and how the rest of the program gets resourced and held accountable.

Identify covers understanding what you actually have: assets, data, systems, and the risks associated with each. You can't protect what you don't know exists, and incomplete asset inventories are one of the most common gaps security teams find when they actually look.

Protect is the function most people associate with cybersecurity in general: access control, data security, platform security, and the technical and procedural safeguards that reduce the likelihood of an incident.

Detect covers the ability to notice when something has gone wrong. Continuous monitoring, anomaly detection, and the processes that surface a problem before it becomes a crisis live here.

Respond covers what happens once an incident is detected: containment, communication, and the operational steps taken to limit damage.

Recover covers restoration of normal operations and the processes for getting systems and data back to a working state, along with the lessons-learned work that should follow any significant incident.

Each function breaks down further into categories and subcategories, giving organizations a detailed map for assessing where they stand and where the gaps are.

What NIST CSF Actually Is

The Cybersecurity Framework was developed by the National Institute of Standards and Technology, a non-regulatory agency within the US Department of Commerce. It was first published in 2014, originally aimed at organizations operating critical infrastructure. Adoption spread well beyond that scope almost immediately, because the framework solved a problem that wasn't industry-specific: how do you organize, communicate about, and improve a cybersecurity program in a way that makes sense to both technical teams and executive leadership.

Unlike SOC 2 or ISO 27001, NIST CSF is not something you get audited against by an accredited third party and certified for. There's no NIST CSF certificate. It's a voluntary framework, which means organizations adopt it because it's useful, not because a contract or regulation requires it.

That voluntary status is exactly why it gets underestimated. The absence of a certification badge makes it easy to assume the framework is less rigorous or less relevant than the ones that come with formal attestation. The opposite is closer to true. NIST CSF is less about proving compliance to an outside party and more about giving an organization an honest internal picture of its own security posture, organized in a way that's useful for decision-making.

Why Enterprise Clients Are Using It to Evaluate Vendors

Here's the part that doesn't get discussed enough: NIST CSF has become one of the default mental models enterprise security and procurement teams use when they evaluate vendors, even when they never mention the framework by name.

When an enterprise client's security team asks a vendor about access controls, asset inventories, incident response plans, monitoring capabilities, and how cybersecurity decisions get made at the leadership level, they are effectively running a NIST CSF assessment, whether or not they call it that. The six functions map closely to the categories most vendor security questionnaires are organized around.

This matters for a specific reason: a vendor that can articulate its security program using the NIST CSF structure, even informally, tends to come across as more mature and more credible than one that answers each question in isolation without an underlying framework connecting the answers. Enterprise security reviewers have seen enough vendor assessments to recognize the difference between an organization that understands its own program holistically and one that's assembling answers ad hoc.

NIST CSF also introduces a concept that's particularly useful in vendor conversations: Implementation Tiers. These range from Partial, where cybersecurity risk management is informal and reactive, to Adaptive, where the organization has a fully integrated, continuously improving risk management practice. A vendor who can clearly say "we operate at a Risk Informed tier and here's our roadmap to Repeatable" is giving a client something concrete to evaluate. A vendor who can't characterize their own maturity level at all is giving the client very little to go on.

Where Compliance Programs Go Wrong with NIST CSF

The most common mistake is treating NIST CSF as optional because it's voluntary, and therefore deprioritizing it relative to frameworks that come with a certification requirement.

That's a reasonable instinct if the only goal is passing an audit. It's a costly one if the goal is actually understanding and communicating your security posture. SOC 2 and ISO 27001 tell you and your clients whether specific controls are operating as designed. NIST CSF tells you whether your overall program is coherent, mature, and aligned with how your organization actually manages risk. Both are useful. Neither replaces the other.

The second mistake is engaging with NIST CSF only at the technical level, skipping the Govern function entirely. Organizations that focus exclusively on Identify, Protect, Detect, Respond, and Recover, while treating governance as someone else's problem, end up with security programs that are operationally sound but disconnected from how leadership actually makes decisions about risk. That disconnect shows up clearly in vendor reviews, where sophisticated clients are increasingly asking governance-level questions: who owns cybersecurity risk at the executive level, how often does leadership review the program, and how are third-party and AI-related risks factored into governance decisions.

The third mistake is treating a NIST CSF self-assessment as a one-time exercise. The framework is most useful as an ongoing tool for tracking improvement over time, not a document that gets created once and filed away. Organizations that revisit their CSF profile regularly, tracking movement across implementation tiers, get far more value from the framework than those who complete an initial assessment and never return to it.

NIST CSF is less about proving compliance to an outside party and more about giving an organization an honest internal picture of its own security posture.

The Bottom Line

NIST CSF doesn't come with a certificate, and that's exactly why it's underrated. It's not a box to check for an auditor. It's a working model for understanding and improving your security program, and it happens to be the model that a large share of the organizations evaluating you are already using, often without naming it.

The compliance programs treating it as an afterthought are missing a structural advantage: a way to talk about their security posture that sophisticated clients already understand, in language that maps directly to how those clients are quietly scoring them.

Fortellar helps organizations build security programs that map cleanly to the frameworks their clients actually use to evaluate them. Get in touch to talk through where your program stands against NIST CSF 2.0.

A vendor that can articulate its security program using the NIST CSF structure, even informally, tends to come across as more mature and more credible than one that answers each question in isolation.

What to Do with This

If your organization hasn't formally engaged with NIST CSF 2.0, a reasonable starting point is a current-state profile: where does your organization actually stand across the six functions, today, honestly. Not where the policy documents say you stand. Where the operational reality actually is.

From there, identify the target profile: where you need to be, given your client base, your risk tolerance, and the expectations being placed on you by the enterprise organizations you sell to or work with. The gap between current and target state becomes your roadmap.

If you're already engaging with SOC 2 or ISO 27001, NIST CSF isn't competing work. It's the connective layer that helps you communicate your overall posture in a way that maps to how enterprise security teams are already thinking, whether or not they say so explicitly.