A common source of confusion: NIST CSF 2.0 has six functions, not five. When NIST published version 2.0 on February 26, 2024, they added a new function — Govern — that sits at the center of everything else. A lot of guides written before that date are still floating around describing the original five-function model from CSF 1.1. If you're implementing or evaluating the framework in 2026, you're working with the 2.0 standard.
NIST has continued updating CSF 2.0 implementation resources through early 2026 — including new Quick-Start Guides covering cybersecurity, enterprise risk management, and workforce integration, plus a preliminary Cybersecurity Framework Profile for Artificial Intelligence published in December 2025 for public comment. The framework is actively evolving around AI and supply chain threats.
Here's what the NIST Cybersecurity Framework actually is, what each of the six functions requires, and how to use it as a foundation for your security program — whether you're building from scratch or mapping existing controls to it for a future compliance audit.
What the NIST Cybersecurity Framework is (and isn't)
NIST CSF is a voluntary framework for managing cybersecurity risk. It organizes security activities into functions, categories, and subcategories — giving organizations a structured vocabulary and outcome-based checklist for their security programs. It doesn't tell you exactly how to implement specific controls; it tells you what outcomes your security program should achieve.
This is different from standards like NIST 800-171 (which specifies exact control requirements for handling Controlled Unclassified Information) or NIST 800-53 (the federal system control catalog). CSF is the flexible, outcome-oriented cousin of those more prescriptive documents.
CSF 2.0 is structured around three main components:
- The Core: Six functions, 22 categories, 106 subcategories describing specific security outcomes
- Profiles: Customized views of the Core that reflect your organization's current state, target state, and priorities
- Tiers: A 1–4 scale describing the maturity and rigor of your cybersecurity risk management practices
CSF 2.0 also expanded the intended audience. Version 1.1 was written primarily for critical infrastructure sectors. CSF 2.0 explicitly targets all organizations — any size, any industry. That matters because it means government guidance, insurance underwriting frameworks, and state-level regulations that reference NIST CSF increasingly apply to businesses that never thought of themselves as critical infrastructure operators.
The six functions of NIST CSF 2.0
All six functions are meant to operate concurrently, not sequentially. You're not supposed to finish Identify before starting Protect. Think of them as six ongoing programs that your security team runs in parallel.
Govern
The new addition in CSF 2.0. Govern covers the organizational context, strategy, and oversight that shape how your security program operates. It includes six categories: Organizational Context, Risk Management Strategy, Cybersecurity Supply Chain Risk Management, Roles and Responsibilities, Policy, and Oversight.
Govern is where most organizations have the most gaps. It requires documenting your risk appetite and tolerance — not just saying "we take security seriously" but specifying what level of risk is acceptable for different asset categories. It also requires extending security requirements formally to third-party suppliers, which most organizations handle informally (or not at all). A 2026 analysis of 99 state cybersecurity bills enacted in 2025 found that 51% of new statutory requirements align to the Govern function — confirming this is where regulatory scrutiny is heading.
Identify
Know what you have and what you're protecting. Identify covers asset management (hardware, software, data, and personnel in scope for cybersecurity), risk assessment (identifying threats, vulnerabilities, and their potential impact), and improvement processes (using lessons learned to update your understanding of risk).
In practice: this means maintaining an accurate asset inventory, conducting regular risk assessments with documented outcomes, and understanding your data flows well enough to know what's sensitive and where it lives. Organizations that skip Identify usually discover the gaps at the worst time — during an incident or an audit.
Protect
Implement safeguards to limit or contain the impact of a cybersecurity incident. Protect covers identity management and access control, awareness and training, data security, platform security (formerly Information Protection Processes and Procedures), and technology infrastructure resilience.
This is the largest function in terms of scope — it covers everything from MFA and least-privilege access to data classification, encryption, change management, and secure configuration baselines. Most organizations have reasonably strong Protect coverage for the obvious controls (MFA, patching, antivirus) and weaker coverage for the process controls (change management, configuration management, and documented security training with completion tracking).
Detect
Identify the occurrence of cybersecurity events in a timely manner. Detect covers Continuous Monitoring (monitoring your systems and networks for anomalies) and Adverse Event Analysis (investigating detected events to determine whether they constitute security incidents).
The Detect function is thinner in the CSF 2.0 structure than you might expect — NIST consolidated it to two categories. What it requires in practice is logging, SIEM or equivalent tooling, and a defined process for triaging alerts into incidents. The hard part isn't the technology; it's building the human processes around it — who reviews alerts, when, and how they escalate.
Respond
Take action regarding a detected cybersecurity incident. Respond covers Incident Management (establishing an incident response process), Incident Analysis (understanding the scope and impact), Incident Response Reporting and Communication (notifying stakeholders and authorities as required), Mitigation (containing and eradicating the incident), and Improvements (updating the program based on what you learned).
Most organizations have a written incident response plan. Far fewer have actually tested it — run a tabletop exercise, verified their notification obligations under GDPR, HIPAA, or state breach notification laws, or updated their plan after the last real incident. Auditors under every major framework ask specifically about IR testing records, not just the plan document itself.
Recover
Restore capabilities or services impaired by a cybersecurity incident. Recover covers Incident Recovery Plan Execution (actually restoring from backups and rebuilding systems) and Incident Recovery Communication (coordinating restoration with stakeholders and communicating the recovery timeline).
This function sounds straightforward until you try to exercise it. Backup restoration times are almost always longer than expected. Recovery Time Objectives on paper don't match what actually happens when you're recovering a database at 2am. If your Recover function has never been tested with a real restoration exercise, the documented RTO is fiction.
See how your security policies map to NIST CSF
PolicyAudit analyzes your security policy documents against the NIST Cybersecurity Framework, identifying gaps by function and category. Free for up to 3 documents — no credit card required.
Check your policies against NIST CSF →Implementation tiers: measuring your CSF maturity
NIST CSF uses four implementation tiers to describe how well an organization's cybersecurity risk management practices align with the framework's principles. Tiers are about rigor and integration, not a compliance score.
| Tier | Label | What it actually means |
|---|---|---|
| Tier 1 | Partial | Cybersecurity risk management is ad hoc and reactive. No formal risk management process. Security practices aren't consistently applied. No supply chain risk management. |
| Tier 2 | Risk Informed | Risk management practices are approved at the senior level but not organization-wide. Security activities are prioritized based on risk but coordination across the organization is inconsistent. |
| Tier 3 | Repeatable | Formal risk management processes exist, are regularly updated, and are consistently applied across the organization. Supply chain risk is managed. Security information is shared internally. |
| Tier 4 | Adaptive | The organization actively adapts its security practices based on real-time threat intelligence and lessons learned. Cybersecurity is integrated into business processes at all levels. Supply chain partners are monitored continuously. |
Most small and mid-sized organizations operating without a dedicated security team sit at Tier 1 or Tier 2. Tier 3 is achievable for most companies of any size — it requires documented processes and consistent application, not enterprise-grade tooling. Tier 4 is where well-resourced organizations with mature security operations centers operate.
The goal isn't to reach Tier 4. NIST explicitly says that higher tiers aren't necessarily better — the right tier is whatever's appropriate given your organization's risk, resources, and threat environment. A dental practice and a defense contractor should be at different tiers.
A realistic self-assessment for most small businesses: Tier 1 or low Tier 2 in Govern (no documented risk appetite, informal supplier security), Tier 2-3 in Protect (MFA and patching exist, change management is informal), and Tier 1 in Detect and Recover (logging exists but isn't reviewed; backups are taken but never tested). That honest picture is where you build from — not where you pretend to be for a questionnaire.
How NIST CSF maps to SOC 2 and ISO 27001
If you're planning to pursue SOC 2 or ISO 27001, mapping your controls to NIST CSF first is a smart way to organize the work. The frameworks share substantial overlap.
NIST CSF ↔ SOC 2: SOC 2's Common Criteria (CC) map most directly to the Protect and Respond functions. CC6 (Logical and Physical Access Controls) aligns with CSF Protect's identity management and access control categories. CC7 (System Operations) aligns with Detect and Respond. CC9 (Risk Mitigation) aligns with Govern's supply chain risk management categories. NIST provides an official informative reference mapping between CSF 2.0 and the AICPA Trust Service Criteria.
NIST CSF ↔ ISO 27001: ISO 27001's Annex A controls map extensively to Protect and Identify. ISO 27001 A.5 (Organizational Controls) maps heavily to Govern — risk management, supplier relationships, and roles/responsibilities. ISO 27001's ISMS requirements (Clauses 4-10) map directly to the Govern function's oversight and policy categories. Organizations that build their ISO 27001 ISMS using CSF as a structural guide find the mapping intuitive.
CISA released its Cross-Sector Cybersecurity Performance Goals 2.0 in December 2025, explicitly aligning all CPG controls to NIST CSF 2.0 functions. For organizations in critical infrastructure sectors (or their supply chains), the CPG 2.0 acts as a prioritized, measurable baseline for CSF implementation — specifying which subcategories to tackle first for the most risk reduction per effort.
Using CSF as a foundation for your security program
The best use of NIST CSF isn't as a compliance checklist — it's as a language for organizing your security program and having coherent conversations with leadership about risk.
A practical starting sequence for organizations new to the framework:
- Create a Current Profile: Map your existing security controls to CSF categories. Don't inflate your current state — be honest about what's actually implemented and consistently operating. This is your baseline.
- Create a Target Profile: Decide where you want to be in 12 months. You don't have to address every gap simultaneously. Prioritize based on your actual threat environment and business risk.
- Identify the gaps: The distance between your Current Profile and Target Profile is your remediation roadmap. Size each gap by estimated effort and risk reduction, then sequence the work.
- Document the Govern function first: Before implementing new technical controls, make sure leadership has formally approved a risk management strategy and documented your risk tolerance. Security tools without governance context can't be prioritized correctly.
- Revisit annually: CSF profiles aren't one-time documents. Your threat environment changes, your business changes, and new attack techniques emerge. Treat the framework as a living assessment, not a box you check once.
The policy documentation work required to map your security program to CSF is also exactly the work that prepares you for SOC 2 or ISO 27001. Organizations that build their written policies and procedures around CSF categories tend to have an easier time in compliance audits — the policy structure maps cleanly to what auditors look for.
Know where your policy gaps are before an audit finds them
PolicyAudit scans your security policies and documentation against NIST CSF, SOC 2, ISO 27001, HIPAA, and 9 other frameworks simultaneously — showing you which functions and categories your policies don't address. Free tier available, no credit card required.
Scan your policies for free →