NIST Cybersecurity Framework 2.0 Implementation Guide 2026

The NIST Cybersecurity Framework (CSF) is the most widely adopted cybersecurity management framework in the world. Originally released in 2014 and significantly revised in version 1.1 in 2018, NIST CSF 2.0 was published in February 2024 — the most substantial update in the framework’s history. The 2.0 revision adds a sixth core function, expands the framework’s applicability to all organizations (not just critical infrastructure), and elevates cybersecurity risk management to a board-level governance responsibility. For industrial control system and operational technology environments, CSF 2.0 — used in conjunction with NIST SP 800-82 Rev. 3 — provides the most comprehensive publicly available framework for managing cybersecurity risk in environments where availability and safety are paramount. This guide explains what changed in CSF 2.0, how the six functions work in practice, and how to implement CSF in your organization.

1. NIST CSF 2.0: What Changed from Version 1.1

NIST CSF 2.0 represents a significant evolution from version 1.1, reflecting six years of implementation experience, changes in the threat landscape, and lessons learned from applying the framework across diverse industries and organization sizes.

The New GOVERN Function

The most significant change in CSF 2.0 is the introduction of a sixth core function: GOVERN (GV). In version 1.1, cybersecurity governance was distributed across the five existing functions without a dedicated home. CSF 2.0 explicitly establishes that cybersecurity risk management must be treated as an organizational strategy and governance issue — not merely a technical one. The GOVERN function covers organizational context, risk management strategy, cybersecurity supply chain risk, roles and responsibilities, and policies. This directly parallels the NIS2 Article 20 management body accountability requirement and the board-level oversight requirements in TSA Directives.

Expanded Scope and Key Updates

• Universal applicability — CSF 2.0 explicitly applies to all organizations, not just critical infrastructure as was the original framing in v1.1
• Supply chain risk management elevated — supply chain risk considerations are now threaded throughout all six functions, not siloed in a single subcategory
• Improved integration — tighter cross-references to NIST SP 800-53, NIST SP 800-82, the NIST Privacy Framework, and the NIST AI RMF
• Community Profiles — NIST has published sector-specific Community Profiles for manufacturing, small businesses, enterprise IT, and other sectors to accelerate adoption
• Implementation Examples — CSF 2.0 includes concrete, actionable examples for each subcategory that were absent from v1.1

2. The Six NIST CSF 2.0 Functions Explained

CSF 2.0 organizes cybersecurity activities into six core functions. Each function is broken down into categories and subcategories with informative references pointing to specific controls in NIST SP 800-53, ISO 27001, CIS Controls, and other frameworks.

GOVERN (GV) — The New Addition

The GOVERN function establishes the organizational context for all cybersecurity activities. It covers: organizational context (understanding the organization’s mission, stakeholders, and regulatory environment), risk management strategy (the organization’s approach to cybersecurity risk tolerance), cybersecurity supply chain risk management, roles and responsibilities for cybersecurity, and cybersecurity policies, processes, and procedures. GOVERN is the enabling function — it sets the conditions under which the other five functions operate effectively.

IDENTIFY (ID) — Know What You Have

The IDENTIFY function covers asset management (a comprehensive inventory of hardware, software, data, and services), risk assessment (identifying and prioritizing risks to organizational assets), and improvement (learning from assessments and exercises). You cannot protect what you do not know you have. For OT environments, asset inventory is particularly challenging due to legacy systems, proprietary protocols, and the operational risk of active scanning — passive discovery tools are the standard approach.

PROTECT (PR) — Reduce the Likelihood of Harm

PROTECT covers identity management and access control, awareness and training, data security, platform security (configuration management, vulnerability management, patching), and technology infrastructure resilience (network segmentation, backup, recovery capabilities). In OT environments, PROTECT must be implemented with availability constraints in mind: controls that would be standard in IT (automatic patch deployment, aggressive access revocation) require careful validation before application to safety-critical systems.

DETECT (DE) — Find Incidents Faster

The DETECT function encompasses continuous monitoring (establishing baselines, monitoring for deviations, alerting on anomalous behavior) and adverse event analysis (analyzing events to determine whether they constitute an incident). Faster detection directly reduces mean time to respond (MTTR) and limits the blast radius of a successful attack. In OT environments, DETECT requires protocol-aware monitoring tools that understand industrial protocols such as Modbus, DNP3, EtherNet/IP, and PROFINET without disrupting communications.

RESPOND (RS) — Contain and Learn

RESPOND covers incident management (executing the incident response plan), analysis (understanding the scope and impact of the incident), mitigation (containing and eradicating the threat), and communication (internal and external notification to stakeholders, regulators, and affected parties). The RESPOND function is the one most directly tested by tabletop exercises, and it is where regulatory reporting timelines — TSA’s 12/24-hour requirements, NIS2’s 24/72-hour requirements — must be embedded as documented procedures.

RECOVER (RC) — Restore Capabilities

The RECOVER function covers recovery planning (restore systems and services to normal operations), improvements (incorporating lessons learned into future resilience planning), and communications (coordinating recovery activities and managing stakeholder expectations during recovery). In OT environments, RECOVER must address the challenge that restoring an OT system is fundamentally different from restoring an IT system: operational validation, safety checks, and coordination with operations teams are required before returning systems to service.

3. Using NIST CSF Tiers to Benchmark Your Maturity

CSF Implementation Tiers describe the degree to which an organization’s cybersecurity risk management practices exhibit the characteristics defined in the framework. Tiers range from Partial (Tier 1) to Adaptive (Tier 4). They are not a compliance score — they describe an organization’s approach to cybersecurity risk management, and moving from Tier 1 to Tier 4 is not always appropriate or necessary for every organization.

Tier 1 — Partial

Cybersecurity risk management practices are ad hoc and reactive. The organization has limited awareness of cybersecurity risk and has no formalized approach to sharing cybersecurity information internally or with external parties. Most small organizations and those new to structured cybersecurity begin at Tier 1.

Tier 2 — Risk Informed

Risk management practices exist but are not formalized as organization-wide policy. Awareness of cybersecurity risk is present at the management level, and some cybersecurity activities are performed, but they are not consistently applied across the organization. Many mid-sized organizations operate at Tier 2.

Tier 3 — Repeatable

Cybersecurity risk management practices are formally approved as organizational policy and are consistently implemented across the enterprise. Risk management is an integrated part of organizational operations. Tier 3 is the target for most regulated organizations, including those subject to TSA Directives, NIS2, and NERC CIP.

Tier 4 — Adaptive

The organization continuously improves its cybersecurity risk management practices based on lessons learned from current and previous activities, evolving threats, and changing technology. Threat intelligence is actively incorporated into practice updates. Tier 4 is the target for critical infrastructure operators facing sophisticated, persistent adversaries.

Using Tiers in Board-Level Reporting

CSF Tiers provide a straightforward vocabulary for translating cybersecurity maturity into business language for board reporting. A statement such as “We currently operate at Tier 2 and are targeting Tier 3 by Q4 2026, with the following investments and milestones” is far more actionable for a board than a list of technical controls. The GOVERN function in CSF 2.0 explicitly calls for this kind of leadership-level communication.

4. Creating NIST CSF Profiles for Your Organization

A CSF Profile is a customized alignment of the framework’s categories and subcategories to your organization’s specific business objectives, risk tolerance, and resource constraints. Profiles are the primary tool for translating the generic framework into actionable, organization-specific requirements.

Current Profile vs. Target Profile

A Current Profile represents your organization’s cybersecurity outcomes as they exist today — an honest assessment of which CSF subcategories are fully implemented, partially implemented, or absent. A Target Profile represents the outcomes your organization needs to achieve based on its risk tolerance, regulatory requirements, and strategic objectives. The gap between Current and Target Profile is the input to your remediation roadmap.

Sector-Specific Profiles

NIST has published Community Profiles for manufacturing, financial services, healthcare, and small businesses that provide starting points for organizations in those sectors. For OT and ICS environments, aligning your profile with NIST SP 800-82 Rev. 3 — the Guide to Operational Technology Security — provides the OT-specific subcategory implementations that the generic CSF 2.0 does not detail.

Documenting a Profile

A practical CSF profile document organizes findings by function, then category, then subcategory. For each subcategory, document: the current state (implemented/partial/not implemented), the target state, the priority (high/medium/low based on risk), any applicable regulatory mapping (NIS2, TSA, NERC CIP), and notes on specific gaps or implementation challenges. This format enables a single profile document to serve simultaneously as a gap analysis, a regulatory compliance map, and a board-level risk summary.

Using Profiles for Regulatory Mapping

One of the most powerful applications of CSF profiles is multi-framework compliance management. A single well-constructed CSF Target Profile can be mapped simultaneously to NERC CIP, TSA Directives, NIS2, and ISO 27001. Organizations subject to multiple regulatory frameworks no longer need to manage each compliance program independently — the CSF profile serves as the master control framework, with regulatory mappings showing which CSF subcategories address which specific regulatory requirements.

5. NIST CSF 2.0 for OT/ICS Environments

Applying NIST CSF to operational technology environments requires adaptation. The fundamental security properties in OT differ from IT: availability and safety take precedence over confidentiality, legacy systems cannot be patched or upgraded on IT timelines, and many OT systems cannot tolerate the network disruption caused by standard IT security tools. NIST SP 800-82 Rev. 3 is the essential companion document for OT CSF implementations.

Why CSF Needs Adaptation for OT

In a corporate IT environment, a compromised server can typically be taken offline, reimaged, and restored within hours. In an OT environment, taking a historian server or a DCS controller offline can halt production, trigger safety system activations, or in extreme cases create physical safety hazards. Every CSF control implementation in OT must be evaluated against the question: “What is the operational impact if this control causes an unexpected system state?” This requires involving operations and safety engineering in the cybersecurity implementation process — not just IT and information security.

Applying DETECT in OT: Passive Monitoring

Active network scanning — standard in IT environments — is generally inappropriate for OT. Industrial protocols were not designed to handle the volume and variety of probe packets generated by active scanners, and unexpected network traffic can trigger fault states in some legacy PLCs and RTUs. Passive OT monitoring tools (Claroty, Dragos, Nozomi Networks) capture and analyze traffic without injecting probe packets, building asset inventories and detecting anomalies through traffic analysis alone. This is the accepted approach for CSF DETECT implementation in OT environments.

RESPOND in OT: The Isolation Decision

One of the most challenging OT incident response decisions is when to isolate a compromised system. In IT, isolation is the default response: take the system offline, contain the threat, investigate. In OT, isolating a system that is actively controlling a physical process — a pipeline pump, a furnace, a rail switch — may cause more immediate harm than allowing the compromised system to continue operating while the threat is assessed. CSF RESPOND implementations for OT must include documented decision frameworks that define: under what conditions should OT systems be isolated, who has authority to make that decision, and what are the alternative containment measures when isolation is not immediately feasible.

6. Mapping NIST CSF to Other Regulatory Frameworks

One of NIST CSF’s greatest practical strengths is its design as a unifying framework that bridges multiple regulatory standards. NIST publishes mapping documents that show the relationships between CSF subcategories and specific controls or requirements in the major regulatory frameworks.

CSF → NIST SP 800-53

NIST SP 800-53 is the detailed control catalog that underpins CSF — it provides hundreds of specific controls organized by control family (AC, AU, CM, IA, IR, etc.). For federal agencies and federal contractors subject to FISMA, achieving CSF alignment typically means implementing the NIST SP 800-53 controls mapped to the relevant CSF subcategories at the appropriate impact level (Low, Moderate, or High).

CSF → NERC CIP

NERC has published a complete CSF-to-CIP mapping. NERC CIP standards CIP-002 through CIP-014 map directly to the IDENTIFY, PROTECT, DETECT, RESPOND, and RECOVER functions. Organizations subject to both CSF and NERC CIP can use a single CSF profile that references specific CIP standard numbers for each subcategory, enabling unified compliance tracking and reporting.

CSF → TSA Directives

CISA has published a CSF-to-TSA Directives mapping specifically for pipeline operators. The mapping shows how TSA requirements for IT/OT segmentation, access controls, continuous monitoring, IRP testing, and incident reporting map to specific CSF subcategories. Aviation and rail operators can use this mapping as a starting point and adapt it to the specific requirements of their applicable directive versions.

CSF → NIS2 and ISO 27001

European regulators broadly accept CSF implementation as a methodology for meeting NIS2 Article 21 requirements. The CSF’s six functions map conceptually to NIS2’s required security measures, and ENISA has published guidance on using CSF for NIS2 compliance. For ISO 27001, there is approximately 80% conceptual overlap between CSF subcategories and ISO 27001 Annex A controls — the primary difference is that ISO 27001 adds a management system structure (policies, objectives, audits, management review) that CSF does not prescribe, while CSF provides more OT-specific guidance than ISO 27001.

7. Implementing NIST CSF in Your Organization

NIST provides a formal seven-step implementation process for CSF. The steps are designed to be iterative — an organization can begin at any step and cycle back as understanding deepens and circumstances change.

1. Scope. Define which systems, business units, and processes are in scope for your CSF implementation. For OT environments, scope typically includes all industrial control systems, SCADA networks, historian systems, and the IT/OT boundary infrastructure (DMZs, jump servers, firewalls). Define the organizational context as required by the GOVERN function: mission, stakeholders, regulatory obligations, and risk tolerance.
2. Orient. Identify applicable regulatory requirements, contractual obligations, and internal risk tolerance statements that will shape your Target Profile. For a pipeline operator, this includes TSA SD-02E, CISA CPG 4.D, and NIST SP 800-82 Rev. 3. Understanding the full landscape of obligations prevents compliance gaps and redundant work.
3. Create a Current Profile. Conduct an honest assessment of your organization’s current cybersecurity outcomes for each CSF category and subcategory. Use evidence: policy documents, configuration standards, network diagrams, training records, and monitoring tool dashboards. Self-declared maturity without evidence will not withstand regulatory scrutiny.
4. Conduct a Risk Assessment. Identify cybersecurity risks to your in-scope systems and prioritize them by likelihood and impact. In OT environments, safety impact is an additional risk dimension: a cybersecurity incident that triggers a safety system activation or a physical process disruption has consequences beyond the IT domain. Use threat intelligence sources specific to your sector (CISA ICS-CERT advisories, sector ISACs).
5. Create a Target Profile. Define the cybersecurity outcomes your organization needs to achieve, informed by the risk assessment results, regulatory requirements, and leadership risk tolerance. The Target Profile should be achievable within a defined timeframe with realistic resources — it is a planning tool, not a wish list.
6. Determine, Analyze, and Prioritize Gaps. Compare the Current Profile to the Target Profile and produce a prioritized gap list. Rank gaps by risk level and feasibility of remediation. This step produces your actionable remediation roadmap, which should be presented to and approved by leadership as required by the GOVERN function.
7. Implement Action Plan. Execute the prioritized remediation roadmap. Measure progress against defined milestones. Critically, use tabletop exercises at this stage to test controls before relying on them in a real incident — particularly for RESPOND and RECOVER function implementations. Update the Current Profile as controls are implemented and validated.

Frequently Asked Questions

Next Steps & Related Resources

The most direct next step after creating your NIST CSF Current Profile and identifying gaps in the RESPOND and RECOVER functions is to run tabletop exercises that test those gaps under realistic conditions. Tabletop exercises are the primary validation mechanism for CSF RESPOND/RECOVER implementation maturity — they surface gaps in notification workflows, OT isolation decision-making, and stakeholder communications that documentation reviews alone cannot reveal. The CyberICS Solutions platform includes ICS-specific scenarios aligned to NIST CSF and NIST SP 800-82, with automatic after-action report generation that can be used directly as CSF compliance evidence.