NIST Cybersecurity Framework: What It Is, How It Works, and How to Implement It
The NIST Cybersecurity Framework is a voluntary set of guidelines published by the National Institute of Standards and Technology to help organizations manage cybersecurity risk. Version 2.0, released on February 26, 2024, is the current version. It is free to download, requires no license, produces no certificate, and does not mandate any specific tool or vendor.
This guide covers what the framework is, the complete structure of CSF 2.0 (the 6 functions, 22 categories, and 106 subcategories sourced directly from NIST CSWP 29), how implementation tiers and profiles work, a step-by-step implementation approach, and how the framework maps to ISO 27001 and SOC 2.
TL;DR
- NIST CSF 2.0, published February 26, 2024, organizes cybersecurity outcomes across 6 functions: GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND, and RECOVER. The full structure contains 22 categories and 106 subcategories.
- The biggest change from version 1.1 is the addition of GOVERN, which makes board-level oversight and supply chain risk management explicit requirements of the framework.
- CSF is not a certification. There is no auditor, no annual fee, and no badge. You self-assess, build a profile, and use the gap between your current and target state as your roadmap.
- The framework applies to organizations of all sizes, sectors, and countries. It is sector-neutral and technology-neutral by design.
- CSF is commonly paired with SOC 2 (for US SaaS), ISO 27001 (for international operations), and HIPAA (for healthcare). It is preparation for those attestations, not a substitute.
Who this is for
This guide is for security leaders, compliance managers, and IT directors who need to understand how CSF 2.0 actually works — not a high-level summary but a working knowledge of the structure, enough to brief an executive team, scope an implementation, or evaluate a vendor's CSF alignment claim.
If you are looking for the specific control-level depth of NIST 800-53 or the CMMC requirements for defense contractors, see NIST 800-53 controls guide and NIST 800-171 compliance.
What the NIST Cybersecurity Framework is
The framework is a taxonomy of high-level cybersecurity outcomes. According to NIST CSWP 29, it "provides guidance to industry, government agencies, and other organizations to manage cybersecurity risks. It offers a taxonomy of high-level cybersecurity outcomes that can be used by any organization — regardless of its size, sector, or maturity — to better understand, assess, prioritize, and communicate its cybersecurity efforts."
NIST is explicit that the framework does not prescribe how outcomes are achieved. It tells you what areas your security program must address. How you address them is left to you, and supplementary resources (informative references, implementation examples, Quick Start Guides) point toward existing standards that can fill in the how.
Three components make up the framework:
- CSF Core: A hierarchy of Functions, Categories, and Subcategories that describe desired cybersecurity outcomes. This is the substance of the framework.
- CSF Organizational Profiles: A mechanism for describing your current and target cybersecurity posture in terms of Core outcomes. A Current Profile documents what you are achieving now. A Target Profile documents where you want to be.
- CSF Tiers: Four characterizations of how rigorous your cybersecurity risk governance and management practices are, from ad hoc (Tier 1) to continuously adaptive (Tier 4). Tiers inform profiles but do not replace maturity assessments.
Framework history: from 1.0 to 2.0
The original framework (CSF 1.0) was published in February 2014. It was created in response to Executive Order 13636, "Improving Critical Infrastructure Cybersecurity," signed February 12, 2013, which directed NIST to develop a voluntary framework that critical infrastructure operators could adopt. Version 1.1 followed in April 2018, adding supply chain risk management guidance and clarifying the relationship between the framework and risk management processes.
CSF 2.0, released February 26, 2024, made two structural changes with lasting implications:
- The framework's original title was "Framework for Improving Critical Infrastructure Cybersecurity." CSF 2.0 dropped that title and expanded the intended audience to all organizations, not just critical infrastructure.
- A new function, GOVERN, was added. Before 2024, governance topics were distributed across the other five functions. NIST pulled them into a single function and placed it at the center of the wheel, explicitly framing board oversight and supply chain risk management as first-order concerns.
The 6 Functions, 22 Categories, and 106 Subcategories
All structure in this section is sourced directly from NIST CSWP 29, Appendix A.
The CSF Core is organized into Functions at the top level, then Categories within each Function, then Subcategories within each Category. NIST describes Functions as "cybersecurity outcomes at their highest level." The 22 categories and 106 subcategories sit below the functions and get progressively more specific.
GOVERN (GV) — 6 categories
GOVERN is the new function in CSF 2.0. NIST places it at the center of the framework wheel because it "informs how an organization will implement the other five Functions." Without governance, the other five functions drift.
From NIST CSWP 29: "The organization's cybersecurity risk management strategy, expectations, and policy are established, communicated, and monitored."
The six categories in GOVERN:
| Category | Identifier | What it covers |
|---|---|---|
| Organizational Context | GV.OC | Mission, stakeholder expectations, legal and regulatory requirements surrounding cybersecurity decisions |
| Risk Management Strategy | GV.RM | Risk tolerance, appetite statements, strategic direction for risk response |
| Roles, Responsibilities, and Authorities | GV.RR | Accountability structures, leadership ownership of cyber risk, human resources integration |
| Policy | GV.PO | Written cybersecurity policy, its review cycle, and enforcement |
| Oversight | GV.OV | Using cybersecurity risk management results to adjust strategy |
| Cybersecurity Supply Chain Risk Management | GV.SC | Managing risks from suppliers, third parties, and the technology product life cycle |
GV.SC is the supply chain category that grew significantly after the SolarWinds incident. It has 10 subcategories covering everything from supplier criticality ranking (GV.SC-04) to what happens after a supplier relationship ends (GV.SC-10).
Starting a CSF 2.0 program without completing GOVERN first is the most common failure pattern. If the board cannot articulate a risk appetite statement (GV.RM-02) and senior leadership has not accepted accountability for cyber risk (GV.RR-01), the assessments and controls work in the other five functions will not receive consistent support or resources.
IDENTIFY (ID) — 3 categories
IDENTIFY covers understanding what you have and what threatens it. NIST describes it as: "The organization's current cybersecurity risks are understood."
| Category | Identifier | What it covers |
|---|---|---|
| Asset Management | ID.AM | Hardware, software, data, services, and people inventories; life cycle management |
| Risk Assessment | ID.RA | Vulnerability identification, threat intelligence, likelihood and impact analysis, risk response prioritization |
| Improvement | ID.IM | Identifying opportunities to improve policies, processes, and practices across all six functions |
ID.AM is where most organizations discover their first serious gap. Without an accurate hardware inventory (ID.AM-01), a software inventory (ID.AM-02), and a data flow map (ID.AM-03), risk assessments under ID.RA are built on guesswork.
PROTECT (PR) — 5 categories
PROTECT covers the safeguards that reduce the likelihood and impact of cybersecurity incidents. NIST: "Safeguards to manage the organization's cybersecurity risks are used."
| Category | Identifier | What it covers |
|---|---|---|
| Identity Management, Authentication, and Access Control | PR.AA | User and device identity management, MFA, least privilege, physical access |
| Awareness and Training | PR.AT | Security awareness for all personnel; specialized training for security roles |
| Data Security | PR.DS | Confidentiality, integrity, and availability of data at rest, in transit, and in use; backups |
| Platform Security | PR.PS | Configuration management, software and hardware maintenance, log generation, secure SDLC |
| Technology Infrastructure Resilience | PR.IR | Network segmentation, environmental protection, resilience mechanisms, capacity management |
PR.AA is where MFA lives. PR.DS-01 and PR.DS-02 cover encryption requirements. PR.PS-01 covers configuration baselines. These are the categories most frequently referenced when enterprise procurement teams review a vendor's security posture.
DETECT (DE) — 2 categories
DETECT covers finding incidents before they become disasters. NIST: "Possible cybersecurity attacks and compromises are found and analyzed."
| Category | Identifier | What it covers |
|---|---|---|
| Continuous Monitoring | DE.CM | Network, physical environment, personnel activity, external service providers, and computing hardware monitoring |
| Adverse Event Analysis | DE.AE | Correlating events from multiple sources, estimating impact and scope, declaring incidents when criteria are met |
DE.CM-01 through DE.CM-09 represent the continuous monitoring requirements that feed a SIEM. DE.AE-08 is the subcategory that defines when an adverse event becomes a declared incident — the trigger point for the RESPOND function.
RESPOND (RS) — 4 categories
RESPOND covers what you do once an incident is declared. NIST: "Actions regarding a detected cybersecurity incident are taken."
| Category | Identifier | What it covers |
|---|---|---|
| Incident Management | RS.MA | Executing the incident response plan, triaging and validating incident reports, escalation criteria |
| Incident Analysis | RS.AN | Root cause analysis, preserving investigation records, estimating incident magnitude |
| Incident Response Reporting and Communication | RS.CO | Notifying internal and external stakeholders, sharing information with designated parties |
| Incident Mitigation | RS.MI | Containing and eradicating incidents |
RS.CO-02 (notifying stakeholders) is where regulatory notification timelines become relevant — HIPAA's 60-day breach notification rule, SEC's four-business-day material incident disclosure requirement, and state breach notification laws all operationalize this subcategory.
RECOVER (RC) — 2 categories
RECOVER covers restoring operations after an incident. NIST: "Assets and operations affected by a cybersecurity incident are restored."
| Category | Identifier | What it covers |
|---|---|---|
| Incident Recovery Plan Execution | RC.RP | Executing the recovery plan, verifying backup integrity before use, confirming normal operations |
| Incident Recovery Communication | RC.CO | Communicating recovery progress to internal and external stakeholders, including public updates |
RC.RP-03 — verifying backup integrity before use — is the subcategory that catches organizations that assume their backups work without testing them. RC.RP-06 formalizes the end of incident recovery, which matters for insurance claims and post-incident reporting.
Implementation Tiers
The four tiers in CSF 2.0 characterize "the rigor of an organization's cybersecurity risk governance and management practices," according to NIST CSWP 29, Appendix B. They are not a maturity ladder you are required to climb; they are a way to set context for how integrated cybersecurity risk management is across your organization.
| Tier | Name | Governance posture | Management posture |
|---|---|---|---|
| Tier 1 | Partial | Ad hoc, reactive. Prioritization is informal and not aligned to objectives or threat environment. | Limited organizational awareness of cyber risk. Irregular, case-by-case implementation. |
| Tier 2 | Risk Informed | Risk-informed practices approved by management but not yet organization-wide policy. Prioritization is linked to risk objectives. | Organizational awareness exists but is not uniform. Risk assessments occur but are not repeatable. |
| Tier 3 | Repeatable | Formally approved risk management practices expressed as policy. Practices are implemented consistently and reviewed regularly. | Organization-wide approach. Consistent methods for responding to risk changes. Senior leaders communicate regularly about cybersecurity. |
| Tier 4 | Adaptive | Cybersecurity risk management is part of organizational culture. Budget reflects current and predicted risk environment. | Organization adapts in real time based on lessons learned and predictive indicators. Cybersecurity information is shared continuously. |
NIST is explicit that progression to higher tiers "is encouraged when risks or mandates are greater or when a cost-benefit analysis indicates a feasible and cost-effective reduction of negative cybersecurity risks." A well-run 20-person company with strong governance and documented processes can reach Tier 2 or Tier 3. A large enterprise with extensive tooling but no board-level ownership of cyber risk is functionally operating at Tier 1.
Profiles: Current and Target State
A CSF Organizational Profile, as defined in NIST CSWP 29 Section 3.1, "describes an organization's current and/or target cybersecurity posture in terms of the Core's outcomes."
Every profile includes one or both of:
- Current Profile: The Core outcomes you are achieving now and to what extent.
- Target Profile: The outcomes you have selected and prioritized for your next planning period, considering your risk management objectives, new threats, and regulatory requirements.
The gap between your Current Profile and Target Profile is your roadmap. NIST's five-step process for creating and using a profile: scope it, gather information, create the profile, analyze gaps and build an action plan, implement and update.
Community Profiles are pre-built baselines for specific sectors or use cases. NIST hosts a repository on the CSF website. If your sector has a published Community Profile (financial services, manufacturing, healthcare, elections, energy), start there. The mapping work between CSF outcomes and sector-specific requirements is already done.
How to Implement NIST CSF Step by Step
Implementation is iterative. NIST's guidance in Section 3.1 of CSWP 29 describes a continuous improvement loop. In practice, a first-pass implementation works like this:
Step 1: Define scope
Decide what part of the organization is in scope. Smaller organizations typically scope the entire business. Larger organizations often scope a specific system, business unit, or product line. Document the scope in writing, including any regulatory or contractual obligations that constrain it (HIPAA for protected health information, PCI DSS for cardholder data, CMMC for controlled unclassified information in DoD contracts).
Step 2: Take stock of what you have
List every asset, supplier, regulation, and existing control in scope. The most common discovery at this step: no hardware inventory, no data flow map, and no list of third-party vendors who touch sensitive data. These gaps must be closed before the risk assessment is meaningful.
Step 3: Build your Current Profile
Walk through the 22 categories in the CSF Core. For each, note whether the outcomes are achieved, partially achieved, or not achieved. Use a simple spreadsheet — NIST provides organizational profile templates on the CSF website. The goal is to find the obvious gaps, not to produce an audit-grade assessment.
Step 4: Conduct a risk assessment
Identify what could cause harm, how likely it is, and what the impact would be. Score each risk on likelihood and impact. Sort by score. Address the highest-scoring risks first. For deeper guidance on risk assessment methodology, see the NIST Risk Management Framework guide.
Step 5: Build your Target Profile
Decide what you want each category's outcomes to look like at the end of your planning horizon. Set a tier target. Be honest about budget and capacity. A seed-stage startup targeting Tier 3 in year one will almost certainly underdeliver; Tier 2 with a documented roadmap to Tier 3 is more credible.
Step 6: Close gaps in priority order
The difference between Current and Target Profile is your gap list. Sort gaps by risk score and implementation effort. Quick wins — documented access control policy, MFA rollout, asset inventory — go first. Multi-quarter items (SIEM deployment, SBOM readiness for GV.SC, full incident response tabletop program) get phased timelines.
Step 7: Measure, reassess, repeat
Review the profile quarterly against your action plan. Reassess the full profile annually or when material changes occur (acquisitions, new product lines, new regulatory requirements). The framework is a continuous operating system, not a one-time project.
NIST CSF Compared to ISO 27001 and SOC 2
These three are frequently confused or incorrectly treated as equivalent. They are not.
| Framework | What it is | Relationship to CSF |
|---|---|---|
| NIST CSF 2.0 | Voluntary outcome-based framework, no certification | The operating model. Use it to organize and govern your security program. |
| ISO 27001 | International standard, third-party certification by an accredited body | Certification, not just alignment. Requires a documented ISMS, an internal audit, a management review, and a two-stage audit by an accredited certification body. ~80% of ISO 27001 controls map to CSF outcomes. |
| SOC 2 | Attestation report issued by a licensed CPA firm (AICPA) | Output, not framework. A SOC 2 report says an auditor tested your controls over a period of time. NIST CSF is the program underneath it. Most companies pursuing SOC 2 find their CSF work accelerates readiness. |
| NIST 800-53 | Federal control catalog (~1,000+ controls across 20 families) | Detail layer under CSF. CSF tells you what outcomes to achieve; 800-53 tells you which controls to implement to achieve them. Required for federal systems. |
| NIST 800-171 | Subset of 800-53 for protecting CUI in non-federal systems | Required for DoD contractors handling controlled unclassified information. Maps to CSF outcomes. |
| HIPAA | U.S. federal healthcare privacy and security regulation | CSF is the most common technical baseline used to meet the HIPAA Security Rule. |
| PCI DSS | Payment card industry standard, mandatory if you process cards | Prescriptive and mandatory. CSF can frame your overall program, but PCI DSS controls are not optional if you are in scope. |
| CIS Controls | 18 prioritized security controls | A tactical starting point. CIS maps its controls to CSF outcomes. Many small organizations use CIS Implementation Group 1 as their starting point before expanding to full CSF coverage. |
The key distinction between ISO 27001 and SOC 2 that the CSF comparison often obscures: ISO 27001 is a certification issued by an accredited certification body (third-party auditor who verifies your ISMS meets the standard). SOC 2 is an attestation issued by a CPA firm under AICPA standards. Certifications result in a certificate. Attestations result in an opinion report. Neither is the same as CSF alignment, which you self-declare.
For organizations choosing between ISO 27001 and SOC 2, see SOC 2 vs ISO 27001. For a three-way comparison, see ISO 27001 vs SOC 2 vs NIST.
Sector Profiles and Quick Start Guides
NIST has published nine Quick Start Guides for CSF 2.0, available on the NIST CSF website. The most useful ones for implementation:
- Small Business: Resources specifically tailored to small businesses with modest or no existing cybersecurity plans.
- Organizational Profiles: A spreadsheet-based approach for creating and using CSF profiles.
- Cybersecurity Supply Chain Risk Management: Guidance for becoming a more prepared acquirer and supplier of technology products and services.
- Tiers: How to apply tiers to organizational profiles.
- Enterprise Risk Management: How ERM practitioners can use CSF outcomes in their broader risk programs.
Several sectors have published Community Profiles that pre-fill the Core with sector-specific context. If your organization operates in manufacturing, financial services, energy, healthcare, or election infrastructure, check the NIST CSF website for a Community Profile before building your own from scratch.
Common Implementation Pitfalls
After watching implementations fail in predictable ways, these five problems appear most often:
1. Treating the framework as a checklist. Going through every subcategory and marking it done without evidence of the underlying practice. Auditors, breach investigators, and enterprise procurement teams all ask for evidence, not self-attestation.
2. Launching CSF as a CISO project without board engagement. GOVERN explicitly requires senior leadership ownership (GV.RR-01: "Organizational leadership is responsible and accountable for cybersecurity risk"). A program that the board does not own will not get consistent funding or prioritization.
3. Overscoping the first implementation. Covering the entire business in one pass leads to shallow assessments across the board. A focused first pass on one system or business unit, done well, is more valuable than a broad pass done poorly.
4. Confusing tiers with tooling quality. Organizations with expensive security tools but weak governance practices operate at Tier 1. Organizations with modest tooling but strong, documented, board-reviewed policies operate at Tier 2 or Tier 3. The tier reflects governance rigor, not budget.
5. One-and-done assessments. NIST designed the framework for continuous improvement. Organizations that do one assessment, build a roadmap, and never revisit it are not implementing the framework; they are generating documentation.
Frequently Asked Questions
Is NIST CSF mandatory?
No. NIST CSF is voluntary at the federal level. However, several state laws explicitly reference it as a basis for affirmative defense in breach litigation, including Ohio Senate Bill 220, Connecticut Public Act 21-119, and Utah's Cybersecurity Affirmative Defense Act. Several federal agencies reference CSF alignment in contractor requirements. Most enterprise procurement teams treat it as a baseline expectation.
What is the difference between NIST CSF and NIST 800-53?
NIST CSF defines outcomes across 6 functions, 22 categories, and 106 subcategories. NIST 800-53 Rev. 5 is a control catalog covering over 1,000 individual controls across 20 control families, published by NIST as SP 800-53 Rev. 5. CSF tells you what areas to address; 800-53 tells you what specific controls address them. CSF maps to 800-53 through its informative references.
Do I need a consultant?
For a small business starting from zero, the NIST Small Business Quick Start Guide and a spreadsheet-based profile can get you through a useful first assessment in two to four weeks. Larger organizations, regulated entities, and those responding to enterprise customer questionnaires usually benefit from an outside perspective on the initial gap assessment to avoid blind spots.
How long does CSF implementation take?
A first-pass assessment that produces a credible Current Profile and a prioritized action plan takes two to four weeks for a 50-person company. Reaching Tier 3 governance and management practices realistically takes 12 to 24 months from a Tier 1 starting point. The framework is designed to be worked continuously.
Can NIST CSF replace SOC 2 or ISO 27001?
No. NIST CSF is a framework you adopt and operate internally. SOC 2 is an audit attestation issued by a licensed CPA firm. ISO 27001 is a certification issued by an accredited certification body. When an enterprise customer or investor asks for proof of your security posture, CSF alignment alone is not the same as a SOC 2 report or an ISO 27001 certificate. CSF is the program; SOC 2 and ISO 27001 are third-party verifications of that program.
Is there a NIST CSF certification?
No. NIST does not issue certificates, and no third-party certification exists for CSF alignment. An organization can self-attest, can engage an independent third party to conduct an assessment (which produces a report, not a certificate), or can use CSF as the basis for obtaining SOC 2 or ISO 27001. Anyone selling "NIST CSF certification" is selling something NIST does not recognize.
What is the CSF 2.0 Reference Tool?
NIST maintains a searchable online tool at csrc.nist.gov/Projects/cybersecurity-framework that allows users to explore the CSF Core, filter by function and category, view informative references, and export the framework in machine-readable and human-readable formats.
Where to go next
For the control-level depth that underpins CSF outcomes, see NIST 800-53 controls. For DoD contractor requirements, see NIST 800-171 compliance. For a side-by-side comparison with ISO 27001, see NIST CSF vs ISO 27001. For organizations starting a security program from scratch, the cybersecurity compliance checklist covers the first practical steps before a full CSF assessment makes sense.
The framework does not build your security program for you. It gives you a common vocabulary, a structured way to assess gaps, and a recognized set of outcomes that regulators, customers, and insurers understand. The evidence of what you have done is still yours to produce.
Sources used
- NIST CSWP 29 — accessed 2026-05-12
- NIST CSF website — accessed 2026-05-12
- SP 800-53 Rev. 5 — accessed 2026-05-12
- csrc.nist.gov/Projects/cybersecurity-framework — accessed 2026-05-12
Last reviewed: 2026-05-12. This article was prepared by the Security Compliance Guide Editorial Team. We use AI to draft initial summaries of publicly available cybersecurity compliance documentation, then verify every claim against primary sources before publication. We are not licensed auditors, attorneys, or compliance consultants. For binding decisions, consult a qualified professional. See our editorial standards for full sourcing rules.
