The NIST Cybersecurity Framework has quietly become the common vocabulary of cybersecurity risk management. Originally published to help critical-infrastructure operators, it spread far beyond that audience because it did something rare: it organized the sprawling field of security into a structure that executives, engineers, and auditors could all reason about together. The 2024 release of version 2.0 marked the most significant update since its debut — broadening its scope to organizations of every size and sector, and adding a sixth core Function that reshapes how the whole thing fits together.
This guide explains CSF 2.0 for people who have to use it, not just cite it. It walks through the six Functions — including the new Govern function and why it sits at the center — the Tiers and Profiles that make the framework adaptable, how to actually apply it rather than admire it, and how it relates to ISO 27001 and SOC 2, the two standards practitioners most often ask about alongside it. The official CSF 2.0 resources from NIST remain the authoritative reference, and everything here is meant to help you put them to work.
What are the six Functions of CSF 2.0?
The framework’s core is organized into Functions — the highest-level grouping of cybersecurity outcomes. Version 1 had five: Identify, Protect, Detect, Respond, and Recover. Version 2.0 adds a sixth, Govern, and positions it as the foundation that informs all the others.
Govern establishes and monitors the organization’s cybersecurity risk-management strategy, expectations, and policy. It covers roles and responsibilities, risk appetite, oversight, and how cybersecurity fits into broader enterprise risk. Identify is about understanding what you have and what threatens it — your assets, data, suppliers, and the risks to them. Protect covers the safeguards that prevent or limit incidents: access control, data security, awareness, and maintenance. Detect is about finding cybersecurity events promptly — the monitoring and analysis that surface something wrong. Respond covers the actions taken once an incident is detected: containment, mitigation, and communication. And Recover is about restoring capabilities and returning to normal operations while learning from what happened.
The Functions are best read not as a checklist but as a lifecycle. Identify and Govern set the foundation of understanding and direction; Protect reduces the likelihood of incidents; Detect, Respond, and Recover deal with them when — not if — they occur. This is the same “assume incidents happen” realism that runs through modern practice, from proactive threat hunting under Detect to the recovery testing that gives Recover its teeth.
Why does Govern sit at the center?
The addition of Govern is the headline change in 2.0, and it reflects a hard-won lesson: cybersecurity fails most often not for lack of technical controls but for lack of organizational direction. Teams deploy tools without a strategy, make risk decisions no one ratified, and discover after an incident that no one actually owned the outcome. Govern exists to fix that by making risk management an explicit, accountable, enterprise-level responsibility rather than an IT afterthought.
NIST depicts Govern as encircling and informing the other five Functions, and that placement is deliberate. Governance decisions — how much risk the organization is willing to accept, who is responsible for what, how cybersecurity aligns with business objectives, how supply-chain risk is managed — shape every choice made within Identify, Protect, Detect, Respond, and Recover. Without governance, the other Functions become disconnected activities; with it, they become a coherent strategy.
For practitioners, the practical effect is that CSF 2.0 pushes cybersecurity conversations into the boardroom. Govern’s outcomes speak the language of risk appetite, accountability, oversight, and policy — the vocabulary executives and boards already use for other enterprise risks. This elevation is arguably the framework’s most valuable contribution: it gives security teams a legitimate, standard way to connect technical work to organizational decision-making, and it gives leadership a structured way to exercise the oversight they are increasingly held responsible for.
How do Tiers and Profiles make it adaptable?
A frequent misunderstanding is that CSF is a rigid checklist you either pass or fail. It is not. Its adaptability comes from two mechanisms: Tiers and Profiles.
Tiers describe the degree to which an organization’s cybersecurity risk-management practices are rigorous and integrated, ranging from Partial (Tier 1), where practices are ad hoc and reactive, through Risk Informed and Repeatable, to Adaptive (Tier 4), where the organization actively improves and adapts based on lessons learned. Tiers are not maturity grades to maximize blindly — a small organization with modest risk may be perfectly well served at a lower Tier. They are a way to characterize your current approach and to have a deliberate conversation about whether it matches your risk.
Profiles are where the framework becomes concrete for a specific organization. A Current Profile describes the cybersecurity outcomes you are achieving today; a Target Profile describes the outcomes you want to achieve, given your business needs, risk appetite, and resources. The gap between the two is your roadmap. This is the mechanism that turns an abstract framework into a prioritized, organization-specific action plan: you assess where you are, decide where you need to be, and work the difference.
Together, Tiers and Profiles are what let the same framework serve a two-person startup and a global enterprise. Neither prescribes specific technologies. They let each organization apply the framework proportionally, which is exactly why it has spread so widely across sectors of every size.
How do you actually apply the framework?
The framework is only valuable if it drives action, and the common failure is treating it as a documentation exercise — mapping controls, producing a binder, and changing nothing. A practical application follows a recognizable arc.
Start with governance and context: understand your business objectives, your risk appetite, and your obligations, and establish who is accountable — the Govern and Identify Functions doing their foundational work. Then assess your Current Profile honestly: for the outcomes across all six Functions, what are you actually achieving today? Resist the temptation to score generously; an inflated baseline produces a useless roadmap. Next, define a Target Profile grounded in your real risks and resources rather than an aspiration to do everything at once. Then prioritize the gaps — not every gap is equally urgent, and CSF’s structure helps you reason about which outcomes matter most given your risk. Finally, execute, measure, and revisit, because your risk environment and your organization both change.
The framework’s power in application is as a communication and prioritization tool. It gives disparate stakeholders — the board, IT, security engineers, auditors, suppliers — a shared structure for talking about risk and for agreeing on what to do next. Many of the specific outcomes map to concrete disciplines covered elsewhere: the Protect and Detect Functions encompass the software supply-chain security practices that guard what you build and incorporate, and the access-control outcomes align closely with the zero trust architecture principles many organizations are adopting. CSF does not replace those disciplines; it organizes them into a coherent whole.
How does CSF relate to ISO 27001 and SOC 2?
Practitioners constantly ask how CSF fits with ISO 27001 and SOC 2, and the honest answer is that they are complementary instruments serving different purposes — not competitors you must choose between.
CSF is a voluntary framework for organizing and communicating cybersecurity risk-management outcomes. It is descriptive and flexible, tells you what outcomes to pursue without prescribing exactly how, and is not something you get formally “certified” against. Its strength is as a common language and a prioritization tool that spans the whole enterprise, now including governance.
ISO 27001 is an international standard for an information security management system (ISMS) against which an organization can be formally certified by an accredited body. It is more prescriptive about the management-system requirements and provides an auditable, internationally recognized credential — valuable when customers or regulators want independent assurance. Many organizations use CSF to structure their thinking and ISO 27001 to obtain certification, and the two map onto each other well enough that work on one substantially supports the other.
SOC 2 is different in kind: it is an attestation report, produced by a licensed auditor, on the controls relevant to security and related trust-service criteria at a service organization. It is most commonly requested by customers of a service provider who want assurance about how their data is handled. SOC 2 focuses on demonstrating that controls are designed and operating effectively over time, rather than on providing an internal risk-management framework — see what a SOC 2 audit actually checks for the evidence auditors look for in practice.
The pragmatic view: use CSF as the organizing framework and common language for your risk-management program — especially now that Govern elevates it to a genuine enterprise-risk instrument — and pursue ISO 27001 certification or a SOC 2 report when an external party needs formal, independent assurance. They reinforce rather than duplicate one another, and mature programs commonly run all three in concert.
Frequently Asked Questions
What changed in NIST CSF 2.0?
The most significant change is the addition of a sixth core Function, Govern, which addresses cybersecurity risk-management strategy, roles, policy, and oversight and is positioned to inform all the other Functions. Version 2.0 also broadened the framework’s scope beyond critical infrastructure to organizations of every size and sector, and expanded guidance on supply-chain risk management and on implementing the framework in practice.
What is the new Govern function for?
Govern establishes and monitors an organization’s cybersecurity risk-management strategy, expectations, roles and responsibilities, risk appetite, and policy. NIST places it at the center, informing the other five Functions, because security programs often fail from lack of organizational direction rather than lack of tools. Govern elevates cybersecurity to an enterprise-risk conversation involving leadership and the board, giving oversight a standard structure.
Can you get certified in the NIST Cybersecurity Framework?
No. CSF is a voluntary framework for organizing and communicating cybersecurity outcomes, not a certifiable standard. There is no formal CSF certification. Organizations seeking a recognized credential typically pursue ISO 27001 certification, which is auditable by an accredited body, or a SOC 2 attestation report from a licensed auditor. Many use CSF to structure their program and one of those standards for external assurance.
What are Tiers and Profiles?
Tiers describe how rigorous and integrated an organization’s risk-management practices are, from Partial and reactive up to Adaptive and continuously improving; they characterize your approach rather than serving as grades to maximize. Profiles make the framework concrete: a Current Profile captures the outcomes you achieve today, a Target Profile the outcomes you want, and the gap between them becomes a prioritized, organization-specific roadmap.
How does CSF compare to ISO 27001 and SOC 2?
They are complementary. CSF is a flexible framework for organizing and communicating risk-management outcomes across the enterprise. ISO 27001 is an international standard you can be formally certified against, providing recognized assurance of a management system. SOC 2 is an auditor’s attestation report on a service organization’s controls, usually requested by customers. Many mature programs use CSF to structure their approach and ISO 27001 or SOC 2 for external assurance.