NIST CSF 2.0 and NIS2: one framework to satisfy both

Two live requirements, one programme

NIS2 became enforceable across EU member states in October 2024. NIST CSF 2.0 was published in February of that year. Both now apply to the same population: medium and large enterprises in regulated sectors with EU operations or customers.

The natural response is to treat them as separate projects, with separate gap assessments, separate remediation tracks, and separate reports. That duplication is avoidable. NIS2 Article 21 and NIST CSF 2.0 share a high degree of structural overlap, and the areas where they diverge are specific and manageable.

The case for using NIST CSF 2.0 as the working framework to address NIS2 is straightforward. CSF 2.0 is more operationally flexible than ISO 27001, easier to implement incrementally, and has a direct analogue for every Article 21 measure. Its new GOVERN function maps directly onto NIS2's management accountability requirements. The result is one evidence base that serves both frameworks rather than two parallel programmes producing the same controls twice.

What changed in NIST CSF 2.0

The original NIST Cybersecurity Framework had five functions: Identify, Protect, Detect, Respond, Recover. Version 2.0 adds a sixth: GOVERN.

GOVERN wraps around the other five functions. It addresses organisational context, risk management strategy, supply chain risk management, roles and responsibilities, and oversight mechanisms. Where version 1.1 described what controls to implement, GOVERN addresses who is accountable for those controls, how risk appetite is set, and how cybersecurity connects to wider business strategy.

This addition matters for NIS2 specifically. NIS2 Article 20 requires boards and management bodies to approve cybersecurity measures and oversee their implementation, with personal liability if they fail to do so. GOVERN provides the framework structure to document exactly that governance. CSF 2.0 is a meaningfully better fit for NIS2 than version 1.1 was.

Version 2.0 also expanded its intended audience beyond critical infrastructure operators. The original framework was aimed primarily at large infrastructure organisations. Version 2.0 addresses organisations of all sizes across all sectors, which aligns it with NIS2's expanded scope of approximately 160,000 EU entities.

The six CSF 2.0 functions briefly summarised:

• GOVERN (GV): Organisational context, risk strategy, supply chain, roles, oversight
• IDENTIFY (ID): Asset management, risk assessment, improvement
• PROTECT (PR): Access control, training, data security, platform security
• DETECT (DE): Continuous monitoring, adverse event analysis
• RESPOND (RS): Incident management, analysis, communication, mitigation
• RECOVER (RC): Recovery plan execution, recovery communication

How NIS2 Article 21 maps to CSF 2.0

Every NIS2 Article 21 measure has a corresponding function and subcategory in NIST CSF 2.0. The table below shows the primary CSF functions and subcategory codes for each of the 10 mandatory measures.

Most organisations already have partial controls across these areas. The common gap is not absent controls. It is controls that exist informally, processes that are undocumented, and recovery plans that have never been tested. A CSF 2.0 gap assessment surfaces exactly this: the difference between controls that exist on paper and controls that can be evidenced.

Where CSF 2.0 does not cover NIS2

Three NIS2 requirements fall outside what NIST CSF 2.0 directly addresses. These need to be built into your programme explicitly.

Incident notification timelines

CSF 2.0 covers incident response and reporting (RS.MA, RS.CO), but it does not mandate specific deadlines for notifying regulatory authorities. NIS2 does: an early warning to the relevant CSIRT or competent authority within 24 hours of becoming aware of a significant incident, a fuller notification within 72 hours, and a final report within one month.

Your incident response plan needs these steps explicitly documented, with named individuals responsible for regulatory communication at each stage. The 24-hour deadline in particular catches organisations off guard because incident response instincts focus on containment first, notification second. If regulatory notification is not a step in the first hour of your declared-incident process, it needs to be.

Entity classification

NIS2 classifies organisations as essential entities or important entities. This classification affects audit frequency, fine levels (up to €10 million or 2% of global turnover for essential entities; up to €7 million or 1.4% for important entities), and some procedural requirements. NIST CSF 2.0 has no equivalent tiering. You need to confirm your classification with the relevant national authority in each EU member state where you operate. In the Netherlands, the NCSC coordinates NIS2 sector registration.

Management body accountability

CSF 2.0 GOVERN addresses roles and responsibilities and oversight (GV.RR). NIS2 Article 20 goes further: it creates personal liability for individual board members and C-suite executives who do not fulfil their cybersecurity governance obligations. Regulators can hold named individuals responsible and, for essential entities, temporarily prohibit them from exercising managerial responsibilities.

Satisfying Article 20 requires documented evidence. Board minutes noting approval of the cybersecurity risk management measures, attendance records for board-level cybersecurity training, and written sign-off on the programme. A CSF profile document alone does not satisfy this. A structured training programme with records does.

Running one compliance programme for both

A four-step approach to integrating both frameworks into a single programme:

1. Run a CSF 2.0 profile assessment. Map your current-state controls against all six functions. Produce a current profile and a target profile. This is the baseline document for both frameworks and the starting point for everything that follows.
2. Overlay NIS2 Article 21 onto your CSF gaps. Using the mapping above, identify which Article 21 measures correspond to each CSF gap. Most NIS2 requirements will already appear as gaps in your CSF current profile. Prioritise remediation by NIS2 enforcement risk, not just CSF implementation tier.
3. Address the three NIS2-specific gaps. Update your incident response plan to include the 24h/72h/1-month notification steps with named owners. Confirm your entity classification. Create a board training and sign-off record for Article 20.
4. Maintain a unified compliance document. One document showing your CSF current and target profiles alongside your NIS2 Article 21 status gives you the internal management view and the regulatory evidence set in a single place. When a new control is implemented, it updates both frameworks at once.

Notes for healthcare, financial services, and hospitality

Healthcare

Healthcare organisations are essential entities under NIS2. In the UK, NHS trusts also need to meet DSPT requirements, which overlap with several NIS2 Article 21 measures including incident handling, access control, and data security. In the Netherlands, specific obligations apply to medical device security and clinical system resilience under both NIS2 and sector-specific regulation. A NIST CSF 2.0 programme with the three NIS2-specific gaps addressed provides a common baseline for all of these, reducing the number of separate compliance tracks running in parallel.

Financial services

Financial entities subject to DORA face additional requirements alongside NIS2. DORA's ICT risk management framework, incident classification requirements, and TLPT (threat-led penetration testing) regime are more prescriptive than NIS2 in several areas. A CSF 2.0 programme covering NIS2 provides a strong foundation, but DORA requires supplementary documentation for ICT third-party risk management and the incident classification categories that differ from NIS2's definition of significant incidents. Running a combined CSF/NIS2 programme first, then layering DORA-specific overlays, is the most efficient sequencing for firms subject to all three.

Hospitality

Hotels, restaurant groups, and travel companies typically qualify as important entities under NIS2. PCI DSS compliance, already required for card-taking businesses, provides a meaningful head start. PCI DSS controls map closely to the PROTECT and DETECT functions in CSF 2.0. The areas that need specific attention for NIS2 are the governance documentation (GOVERN), incident notification procedures, and supply chain security clauses in vendor contracts, particularly with property management system and payment platform providers.

What to do next

If your organisation is subject to NIS2 and has not yet adopted a working cybersecurity framework, NIST CSF 2.0 is the practical choice for 2026. The GOVERN function gives you the governance structure NIS2 Article 20 requires, and the mapping to Article 21 is direct enough that one programme covers both.

If you already operate under CSF 1.1, upgrading to 2.0 is worth doing for GOVERN alone. The additions are incremental rather than a rewrite, so the lift is manageable and the benefit for NIS2 compliance is immediate.

The CSF 2.0 profiles approach, where you document current state and target state separately, also works well as a board-level communication tool. It makes clear what has been approved and what remains to be addressed, which is precisely the kind of documented evidence Article 20 requires.

If you are unsure where to start, a combined CSF 2.0 and NIS2 gap assessment is the most efficient first step. It establishes your baseline, identifies your priority gaps, and produces the evidence set you need for both frameworks in a single piece of work.