NIST Cybersecurity Framework Explained

Introduction

In 2015, one year after NIST published the first version of its Cybersecurity Framework, adoption surveys found that 30% of US organizations were already using it. By 2022, that figure had climbed to over 40% of all US organizations and the framework had been adopted by governments and regulators in more than 30 countries. Then in February 2024, NIST released version 2.0 — the most significant update since the framework’s inception — adding a sixth core function and expanding its scope from critical infrastructure sectors to “all organizations regardless of size, sector, or maturity.” If a framework started by executive order as a critical infrastructure protection tool is now the global de facto standard for enterprise cybersecurity risk management, understanding it is no longer optional for anyone in security, compliance, or executive leadership.

The NIST Cybersecurity Framework (CSF) is a voluntary guidance document that provides a common language and structured approach for managing cybersecurity risk. Unlike compliance mandates that prescribe specific technical controls, the CSF is outcomes-based: it tells you what to achieve, not how to achieve it. This design makes it applicable to any technology environment — whether you run on-premises servers, multicloud infrastructure, industrial control systems, or IoT devices. The framework provides a way to communicate about cybersecurity risk in language that bridges technical teams and executive leadership, which is why it has become the standard reference for board-level cybersecurity reporting.

This article explains the six core functions of CSF 2.0, how the implementation tiers and profiles work in practice, how CSF maps to other frameworks your organization may already be using — including ISO 27001, FISMA, and PCI DSS — and what the “Govern” function added in version 2.0 means for how security programs must now be structured.

What Is the NIST Cybersecurity Framework?

The NIST Cybersecurity Framework is a set of guidelines, standards, and practices designed to help organizations manage and reduce cybersecurity risk. Published by the National Institute of Standards and Technology under the US Department of Commerce, it was originally developed in response to a 2013 executive order after attacks on critical infrastructure demonstrated the absence of a common security baseline.

The CSF is built on three components that work together: the Core, the Tiers, and the Profiles. The Core defines the security outcomes every organization should address. The Tiers characterize the maturity and rigor of an organization’s risk management practices. The Profiles allow an organization to map the Core’s outcomes to its specific business requirements, risk tolerance, and resources — creating a customized security roadmap rather than a generic checklist.

The framework is not a compliance audit checklist and does not certify organizations. Instead, it provides a shared vocabulary that security leaders can use to communicate with boards, regulators, and partners about the organization’s current security state and desired target state. This communication function is why auditors, regulators, and cyber insurers increasingly reference CSF alignment as a proxy for reasonable security practice.

How the NIST Cybersecurity Framework Works

The CSF 2.0 Core is organized into six Functions — the highest-level categories in the framework. Each function is subdivided into Categories (specific security outcomes) and Subcategories (more granular activities). At the lowest level, Implementation Examples suggest how to achieve each outcome, often referencing other NIST publications, ISO standards, and industry guidelines.

Govern (GV). The newest function in CSF 2.0, added in the February 2024 release. Govern is the umbrella function that establishes and monitors the context for all other functions. It addresses: organizational context (what do we protect and why?), risk management strategy (how much risk is acceptable?), roles and responsibilities (who owns what?), policies and procedures (what are the rules?), and supply chain risk (are our vendors and partners secure?). Before 2.0, these governance activities were distributed across other functions without a clear owner. The explicit Govern function reflects the reality that cybersecurity risk management must be led from the top, with executive sponsorship and board visibility.

Identify (ID). Understanding your attack surface. This function covers asset management (what hardware, software, and data do you have?), business environment (which systems are critical to operations?), risk assessment (what are the likely threats and their consequences?), and improvement activities (how do you learn from past incidents?). You cannot protect what you cannot see — the Identify function is the foundation on which all other functions rest.

Protect (PR). Implementing safeguards to limit the impact of incidents. This covers access control (who can access what?), awareness and training, data security (encryption at rest and in transit — connecting directly to our encryption at rest vs in transit coverage), platform security (secure configuration of infrastructure), and technology resilience (backups, redundancy, and recovery capacity).

Detect (DE). Discovering cybersecurity events in a timely manner. Covers continuous monitoring of assets, networks, and user activity; analysis of events to identify anomalies; and monitoring of the effectiveness of protective measures. The time from compromise to detection — the “dwell time” — is a key metric this function addresses. Industry data consistently shows organizations taking weeks to months to detect breaches; the Detect function provides the framework for reducing that window.

Respond (RS). Managing incidents after detection. Covers response planning, communications (notifying affected parties, regulators, and partners), analysis (understanding root cause and scope), containment and eradication, and improvement (post-incident review). A breach without a tested response plan is significantly more damaging and expensive than one handled with practiced procedures.

Recover (RC). Restoring systems and services after an incident. Covers recovery planning, execution of recovery procedures, and communications to relevant stakeholders. Business continuity and disaster recovery (BC/DR) programs live within this function. The NIST framework positions Recovery as co-equal with the other five functions — not an afterthought — because resilience and time-to-recovery directly determine the business impact of any incident.

VIDEO · READY 16:9

PLAY

The NIST Cybersecurity Framework (CSF) 2.0

NIST CSF vs Other Frameworks

The most important takeaway from this table is that CSF and ISO 27001 are complementary, not competing. CSF provides the outcomes; ISO 27001 provides the management system and external certification. Organizations that need both US market credibility (CSF) and international certification (ISO 27001) can maintain a single security program and map it to both frameworks simultaneously. NIST publishes an official CSF-to-ISO 27001 mapping on csrc.nist.gov.

Real-World Use Cases

Executive and board reporting. The CSF’s six-function structure gives CISOs a language for communicating risk to non-technical leaders. Instead of reporting on the number of patches applied, a CISO can present a Current Profile score against a Target Profile, frame gaps in business-risk terms, and request investment in specific functions. The Govern function explicitly calls for board-level oversight of cybersecurity risk management, making CSF the natural framework for documenting governance activities that satisfy SEC cybersecurity disclosure rules for public companies.

Federal contractor compliance. FISMA requires federal agencies to implement NIST security guidelines. NIST SP 800-53 provides the control catalog; the CSF provides the organizational framework for selecting and implementing those controls. Defense contractors pursuing CMMC certification and cloud service providers pursuing FedRAMP authorization both work within ecosystems where CSF alignment is a prerequisite. Our FISMA compliance guide explains how these frameworks intersect in practice.

Supplier risk management assessments. The CSF’s Govern function includes specific subcategories for supply chain risk management — evaluating third-party vendors’ security programs before granting them access to your systems or data. Security teams use CSF profiles as a structured questionnaire format for vendor assessments: does the vendor have documented policies? Do they perform continuous monitoring? What is their incident response plan? CSF provides the structure; the vendor’s answers reveal their actual security posture.

Common Mistakes to Avoid

Treating CSF tier advancement as the goal. The implementation tiers (Partial, Risk Informed, Repeatable, Adaptive) describe how your risk management practices are organized — not how secure you are. A Tier 4 organization that manages risk in a highly adaptive, data-driven way can still have critical vulnerabilities. Conversely, a Tier 2 organization that knows its highest-priority risks and protects against them consistently may be far better positioned than a Tier 4 organization with a sophisticated program that covers the wrong threats. Target tiers should align to your actual risk tolerance, not to a score.

Skipping the Identify function because it seems administrative. Organizations often want to jump straight to “protecting” — deploying tools, hardening configurations, enabling encryption like the BYOK cloud controls. But without a complete asset inventory and risk assessment, protection efforts are arbitrary. The Identify function is not paperwork; it is the intelligence that determines where to spend every security dollar. Protecting systems you do not know you have is impossible.

Ignoring the Govern function as “not technical.” The addition of Govern in CSF 2.0 reflects a decade of incident analysis showing that technical controls fail when governance is absent: security programs without executive buy-in lose budget at the wrong moment; incident responses without pre-approved authority frameworks stall at critical decision points; supply chain attacks succeed because vendor risk management was no one’s explicit job. The Govern function is where cybersecurity becomes a business discipline, not just a technical function.

Creating a CSF profile and never updating it. A Profile that describes your security state from two years ago is not just useless — it is misleading. CSF Profiles are living documents that should be updated after major infrastructure changes, significant incidents, new regulatory requirements, and on a scheduled review cycle. The Target Profile should also evolve as your organization’s risk tolerance, budget, and threat environment changes.

Getting Started

Start with an honest Current Profile. Before you can improve, you need to know where you stand. Work through the CSF core functions and rate your organization’s current state for each subcategory using a simple Red/Yellow/Green scale — not Tier scores. Involve the business owners of each function, not just the security team. The Identify function’s asset inventory is the hardest part of this exercise; the data often does not exist and must be gathered specifically for this purpose.

Set a Target Profile based on your actual risk. Your target should be driven by threat modeling — who would attack you, through what vectors, and what would they gain? — not by what competitors are doing. A healthcare organization protecting ePHI under HIPAA has different target outcomes than a SaaS startup. Use the NIST CSF reference tools at nist.gov/cyberframework to explore the subcategories relevant to your industry and risk profile.

Map your existing controls to CSF subcategories. Before buying new tools, identify which CSF subcategories your existing controls already satisfy. Most mature security programs cover large portions of the framework without realizing it. The gap analysis between your mapped Current Profile and Target Profile reveals where new investment is genuinely needed versus where you have coverage gaps in documentation only.

Use CSF as the bridge between encryption controls and business risk. Many of the CSF’s Protect function subcategories directly address encryption: data in transit (PR.DS-2), data at rest (PR.DS-1), and cryptographic key management (PR.DS-8 in CSF 2.0). These subcategories link your technical encryption controls — the key management services configuration, the HIPAA security rule encryption requirements — to the business-level outcome that your board and auditors care about: sensitive data is protected even if systems are compromised.