NIS2 vs NIST CSF 2.0: The Function-by-Function Gap Map US Multinationals Need Before EU Enforcement Begins

When NIST released version 2.0 of its Cybersecurity Framework on 26 February 2024, security leaders at US-headquartered multinationals faced an immediate question: does our existing NIST CSF 2.0 implementation already satisfy NIS2? [7] The short answer is that it covers most of the technical security controls — but not the legal obligations that NIS2 imposes at the entity level. This article gives you the function-by-function mapping and identifies exactly what your NIST CSF programme leaves uncovered.

NIS2, formally Directive (EU) 2022/2555, imposes cybersecurity obligations on essential and important entities operating in the EU. Its technical requirements are specified in Article 21 [1] and — for cloud, DNS, CDN, managed service, and platform providers — further detailed in Commission Implementing Regulation (EU) 2024/2690 (CIR 2024/2690), which was published in October 2024 and applies directly across all member states without national transposition [6]. Penalties for non-compliance reach €10 million or 2% of global annual turnover for essential entities.

This article is written for CISOs and compliance officers at US-headquartered multinationals with EU operations. If you are already operating a NIST CSF 2.0 programme, you have a strong foundation. The goal here is to show you precisely where that foundation maps to NIS2 and where it does not.

Does NIS2 Apply to Your US-Headquartered Company?

Jurisdiction under NIS2 does not depend on where your company is incorporated — it depends on where you provide covered services. Article 26 of the directive establishes two tracks for determining which member state supervises your organisation [4].

Track 1 (standard rule): Entities with an EU legal establishment are supervised by the member state of that establishment.

Track 2 (main establishment rule): Cloud computing providers, DNS operators, CDN providers, managed service providers, managed security service providers, online marketplaces, search engines, social platforms, and trust service providers are supervised by the member state where their main establishment in the EU is located. If your US parent company provides intragroup IT managed services to EU affiliates, it qualifies as a managed service provider and falls within NIS2’s scope under this track [10].

The Three-Tier Test for Main Establishment

For Track 2 entities with EU operations, the supervisory member state is determined in sequence [4][10]:

1. Tier 1 — Where decisions are made: The member state where cybersecurity risk-management decisions are predominantly taken — typically where your CISO operates and where policies receive board approval.
2. Tier 2 — Where operations run: Where cybersecurity operations predominantly occur — your Security Operations Centre, primary network hubs.
3. Tier 3 — Backstop: The member state with the highest number of EU employees.

US Entity Type	NIS2 Scope?	Supervisory Track
US parent providing cloud SaaS to EU customers	Yes — cloud computing service provider	Track 2 (main establishment)
US parent providing IT managed services to EU affiliates	Yes — managed service provider	Track 2 (main establishment)
US company with EU subsidiary operating as an essential entity	Yes — via EU subsidiary	Track 1 (EU subsidiary’s member state)
US company with no EU establishment, EU revenue only	Yes (for covered services) — must designate EU representative	Track 2 + Art. 26(3) representative required

If your organisation has no EU legal establishment but provides covered services in the EU, Article 26(3) requires you to designate an EU-based representative before you can be properly supervised [4]. Without a designated representative, any member state where you provide services can initiate enforcement proceedings directly against your organisation.

Once you have confirmed NIS2 applies, the next step is assessing what your NIST CSF 2.0 implementation already covers. For a practical check on whether you qualify as essential or important, see our entity classification guide.

Where NIST CSF 2.0 and NIS2 Already Align

NIST CSF 2.0 organises cybersecurity outcomes across six core functions: Govern, Identify, Protect, Detect, Respond, and Recover [7][8]. The Govern function is new in version 2.0 — it encompasses how organisations make informed decisions on cybersecurity strategy, policy, roles, and supply chain risk.

NIS2’s technical requirements are structured around Article 21(2)’s ten security measures [1] and the CIR 2024/2690 Annex’s 13 thematic sections [6][9]. The table below maps NIST CSF 2.0 functions to the corresponding CIR Annex sections and indicates the coverage quality. For entities not covered by the CIR (sectors such as energy, water, and healthcare follow Article 21 directly without CIR-specific methodology), the mapping still applies — the CIR Annex sections represent the most rigorous articulation of each Article 21 requirement.

NIST CSF 2.0 Function	Key Categories	CIR 2024/2690 Annex Section	Coverage Assessment
Govern	GV.RM — Risk Management Strategy; GV.PO — Policy	Points 1–2: Security Policy, Risk Management (Art. 21(2)(a))	Strong — documented risk analysis, security policy, residual risk acceptance
Govern	GV.SC — Supply Chain Risk Management	Point 5: Supply Chain Security (Art. 21(2)(d))	Partial — NIST addresses supply chain risk; NIS2 mandates contractual security clauses with each direct supplier, plus a supplier directory with criticality classification
Govern	GV.OV — Oversight; GV.RR — Roles and Responsibilities	(Covered by Art. 20 governance, not CIR Annex)	Partial — NIST frames oversight as a maturity dimension; NIS2 Art. 20 makes board approval and personal liability mandatory. See Gap 2 below.
Identify	ID.AM — Asset Management	Point 12: Asset Management (Art. 21(2)(i))	Strong — asset inventory, classification, removable media policy, secure disposal
Identify	ID.RA — Risk Assessment	Point 2: Risk Management (Art. 21(2)(a))	Strong — risk identification, analysis, treatment plan, residual risk approval
Protect	PR.AA — Identity Management, Authentication, Access Control	Point 11: Access Control including MFA (Art. 21(2)(i),(j))	Strong — NIST PR.AA maps directly to CIR’s access control and MFA requirements for critical and remote access
Protect	PR.AT — Awareness and Training	Point 13: Cyber Hygiene and Training (Art. 21(2)(g))	Strong — basic cyber hygiene practices, security awareness programme for all personnel
Protect	PR.DS — Data Security	Point 9: Cryptography (Art. 21(2)(h))	Strong — algorithm selection, key management (generation, storage, rotation, destruction)
Protect	PR.PS — Platform Security	Point 6: ICT Acquisition and Secure Development (Art. 21(2)(e))	Strong — secure development, configuration management, change control, patch management
Protect	PR.IR — Technology Infrastructure Resilience	Points 4, 7: Business Continuity, Network Security (Art. 21(2)(c))	Strong — BCP/DR requirements, network segmentation and protection measures
Detect	DE.CM — Continuous Monitoring; DE.AE — Adverse Event Analysis	Point 3: Incident Handling — detection and analysis phase (Art. 21(2)(b))	Strong — event detection, log analysis, anomaly identification prior to response
Respond	RS.MA — Incident Management; RS.AN — Analysis; RS.MI — Mitigation	Point 3: Incident Handling — response and recovery phase (Art. 21(2)(b))	Strong — containment, eradication, post-incident review with defined roles
Respond	RS.CO — Incident Reporting and Communication	(Art. 23 — mandatory timelines; no CIR Annex equivalent)	Partial — NIST recommends coordinating with stakeholders; NIS2 Art. 23 mandates specific 24h/72h/1-month timelines to a designated competent authority. See Gap 1.
Recover	RC.RP — Recovery Plan Execution	Point 4: Business Continuity and Disaster Recovery (Art. 21(2)(c))	Strong — BCP based on Business Impact Analysis, disaster recovery plan, crisis management
Recover	RC.CO — Recovery Communication	(Art. 23 — progress updates for ongoing incidents)	Partial — NIST does not specify regulatory recipients or statutory update intervals for prolonged incidents

NIST CSF 2.0 provides strong coverage for the majority of CIR 2024/2690 Annex sections — the technical security controls that sit under Article 21(2). Where organisations running a mature NIST CSF 2.0 programme will find gaps is not in their security practices, but in the legal obligations that NIS2 imposes at the entity and governance level, which no technical framework can satisfy on its own.

The partial coverages in supply chain (GV.SC), incident reporting (RS.CO), and board oversight (GV.OV) each point to a specific NIS2 article that requires separate action. Those four obligations are described in the next section — and they apply to every NIS2 entity, regardless of which security framework underpins their programme.

The Four Structural Gaps NIST CSF 2.0 Cannot Fill

NIST CSF 2.0 is a voluntary standard built on risk-based best practices. NIS2 is binding EU law with mandatory penalties, supervisory authority enforcement, and personal liability for executives. The four gaps below are not security control deficiencies that a better NIST CSF implementation can solve — they are legal obligations that exist entirely outside any technical framework’s scope.

Gap 1 — Mandatory Incident Reporting Timelines (Article 23)

NIST CSF 2.0’s Respond function includes RS.CO (Incident Reporting and Communication), which addresses coordinating with stakeholders and communicating effectively during incidents. There is no mandated timeframe and no specified regulatory recipient in any NIST category.

NIS2 Article 23 replaces that flexibility with a statutory cascade [2]:

• 24 hours: An early warning must reach your CSIRT or national competent authority upon becoming aware of a significant incident, indicating suspected malicious cause or cross-border potential.
• 72 hours: A full incident notification must follow, including a severity assessment and, where available, indicators of compromise.
• One month: A final report is required, covering a detailed incident description, threat analysis, mitigation measures taken, and cross-border impact assessment [2].

An incident qualifies as significant when it causes or risks severe operational disruption or financial loss for the reporting entity, or causes considerable material or non-material damage to other parties [2]. For entities covered by CIR 2024/2690, the financial threshold is quantified: a direct financial loss exceeding €500,000 or 5% of annual turnover, whichever is lower, is one trigger for the mandatory reporting cascade [6].

If your incident response plan currently specifies a 48-hour notification window to internal stakeholders, you are not compliant with NIS2 regardless of how mature your NIST CSF Respond function is. Closing this gap requires adding the 24h/72h/1-month obligations to your IR policy, naming the CSIRT or competent authority in your jurisdiction as the recipient, and documenting a significant-incident classification procedure. See our Article 23 incident notification guide for the full requirements.

Gap 2 — Board Personal Liability and Mandatory Training (Article 20)

NIST CSF 2.0’s Govern function includes GV.OV (Oversight) and GV.RR (Roles, Responsibilities, and Authorities), which address senior leadership accountability in the context of cybersecurity risk management. In the NIST framework, governance maturity is a dimension of programme sophistication.

NIS2 Article 20 converts governance from a maturity indicator into a mandatory legal obligation with personal consequences [3]:

• Management bodies must formally approve the organisation’s cybersecurity risk-management measures — a board resolution, not delegation to the CISO.
• Management bodies must oversee implementation and can be held personally liable for compliance failures. Competent authorities may, as an enforcement measure, temporarily prohibit individuals from exercising managerial responsibilities in the entity [3].
• All management body members must receive cybersecurity training sufficient to assess risks and evaluate cybersecurity risk-management practices — and this training must be documented.

A NIST CSF programme at any maturity tier generates no mechanism for documenting board approval of specific cybersecurity measures, no training completion records for board members, and no basis for personal liability tracking. Closing this gap requires three artefacts that NIST alone cannot produce: a board resolution approving the cybersecurity risk-management programme, evidence of completed board-level training, and a defined accountability structure naming who in the management body bears oversight responsibility. Our board governance guide covers what each of these documents must contain.

Gap 3 — Entity Registration and Self-Classification (Article 27)

NIST CSF 2.0 has no concept of a regulatory entity registry. The framework is organisation-agnostic — it says nothing about what supervisory authorities need to know about your organisation’s existence.

NIS2 Article 27 requires essential and important entities to register with their competent authority [5]. The registration deadline was 17 January 2025 — a date that has already passed. Required information includes: entity name, sector and subsector classification, Annex I or II designation (Essential or Important), main establishment address or EU representative details, current contact information, and IP address ranges. Changes to registered information must be notified within three months [5].

Germany’s Federal Office for Information Security (BSI) began issuing formal compliance notices to entities in late 2025 for failure to register, making entity registration one of the first NIS2 enforcement actions to materialise. An organisation with a perfectly mapped NIST CSF 2.0 implementation that has not registered is already in direct breach of a NIS2 obligation. If your organisation has not yet registered, do so immediately — late registration is substantially better than no registration.

Gap 4 — EU Representative Designation for Non-EU Entities (Article 26)

If your US-headquartered company provides covered NIS2 services to EU customers or affiliates but has no legal establishment in any EU member state, Article 26(3) requires designating an EU-based representative [4]. The representative must be established in one of the member states where your organisation provides services. Their member state becomes the supervisory jurisdiction anchor.

Without a designated representative, any EU member state in which you provide services may take enforcement action against your organisation directly, without coordination with any lead authority [4]. This is an administrative and legal obligation with no NIST CSF category equivalent. No framework implementation closes it — it requires engaging an EU-based legal entity, executing a representative designation agreement, and notifying the relevant competent authority.

A Three-Step Bridge Plan for US Multinationals

For organisations with a mature NIST CSF 2.0 implementation, the path to NIS2 compliance is narrower than starting from scratch. The work is largely one of documentation translation and gap-filling, not rebuilding security controls.

Step 1: Document the Crosswalk

Use the mapping table above to document how each element of your NIST CSF 2.0 implementation satisfies the corresponding CIR 2024/2690 Annex section and NIS2 Article 21(2) sub-paragraph. Each of your existing security policies, procedures, and technical controls needs to be annotated with the NIS2 article reference it satisfies.

The effort is low to medium: your access control policy, incident handling procedures, and risk assessment methodology do not need to be rewritten. They need to be labelled with NIS2 citations and approved under the Art. 20 governance process. This crosswalk document, signed by the CISO and approved by the management body, is your primary audit artefact.

For organisations also operating an ISO 27001:2022 management system, the path is shorter still: ISO 27001 Annex A controls align closely with both NIST CSF 2.0 categories and CIR 2024/2690 Annex sections. A three-way NIST–ISO–NIS2 crosswalk covering all technical controls can often be built from existing documentation. See our NIS2 vs ISO 27001 guide for the specific overlaps.

Step 2: Resolve the Four Structural Gaps

Gap	Required Action	Effort	Output Document
Art. 23 — Mandatory incident reporting timelines	Amend IR policy to specify 24h/72h/1-month obligations, name the CSIRT or competent authority as recipient, add a significant-incident classification procedure	Medium	Updated Incident Handling Policy + Notification Form
Art. 20 — Board approval and personal liability	Convene a board-level cybersecurity approval session, produce a Board Resolution approving the risk-management programme, schedule and log mandatory training for all management body members	Medium	Board Resolution + Training Completion Records
Art. 27 — Entity registration	Register with the competent authority in your lead member state immediately; self-classify as Essential or Important under NIS2 Annex I or II; record IP ranges and contact details	Low	NCA Registration Confirmation + Entity Classification Record
Art. 26(3) — EU representative	Engage an EU-based legal entity as representative, execute representative agreement, notify the competent authority in the representative’s member state	Medium (legal input required)	Representative Designation Agreement + Authority Notification

Step 3: Keep the Crosswalk Current

NIS2 is a living compliance obligation, not a one-time certification. As your NIST CSF 2.0 implementation evolves — controls added, policies updated, security architecture changed — the crosswalk must be updated. When the CIR 2024/2690 is reviewed or ENISA publishes updated technical guidance, the crosswalk absorbs those changes too. Many organisations schedule a quarterly review aligned to their existing NIST CSF assessment cycle.

The most common failure pattern for US multinationals is not security control gaps — it is documentation gaps. A penetration test exists but is not labelled as satisfying Art. 21(2)(e). An MFA rollout is complete but not referenced in the Art. 21(2)(j) context. The crosswalk turns good security practice into provable NIS2 compliance.

Frequently Asked Questions

Does implementing NIST CSF 2.0 at a high maturity tier satisfy NIS2 Article 21?

As a general guideline, a mature NIST CSF 2.0 implementation provides documented evidence that can satisfy most of the technical controls under NIS2 Article 21(2). However, NIS2 does not recognise NIST CSF as a formal equivalency path — it is not listed as a presumption of conformity. Competent authorities will ask for NIS2-labelled evidence, which means a crosswalk that translates your NIST controls into CIR 2024/2690 Annex language is necessary regardless of your NIST maturity tier.

Which member state competent authority supervises our US company?

For Track 2 entities, the supervisory authority is the competent authority of the member state where your main EU establishment is located, determined by the three-tier test above. If you have no EU establishment, your designated EU representative’s member state becomes your jurisdiction anchor under Article 26(3) [4]. Given the complexity of the main establishment test and its dependency on CISO location, operational footprint, and employee count, legal review in your target member state is strongly recommended.

We missed the 17 January 2025 registration deadline. What now?

Register immediately with the competent authority in your lead member state. Late registration is substantially preferable to no registration — competent authorities have treated good-faith remediation as a mitigating factor in early enforcement activity, while continued non-registration is a stand-alone breach regardless of how well your security programme performs. There is no formal grace period in the directive [5]. Consult a qualified legal professional in your lead member state about the specific registration process and the appropriate way to communicate the late submission to the competent authority.

Do we need separate EU-specific cybersecurity policies, or can we use our global NIST-based policies?

You can use global NIST-based policies, provided they are annotated with NIS2 Article 21 and CIR 2024/2690 Annex references and have received the mandatory board approval required under Article 20. CIR 2024/2690 Point 1 requires a “documented network and information systems security policy approved by management” — the approval must cover your NIS2-scoped services specifically [6]. Many organisations maintain a single global security policy with an EU annex that documents the NIS2-specific requirements and the board-approval record.

How does the NIST CSF 2.0 Govern function relate to NIS2 Article 20?

They address the same governance territory but with different force. NIST CSF 2.0’s Govern function (GV.OV, GV.RR) describes governance structures and oversight as maturity dimensions: the more mature your programme, the more clearly defined your governance. NIS2 Article 20 imposes specific legal obligations: board approval of cybersecurity measures, mandatory training completion with documentation, and personal liability for management body members. A Tier 4 NIST CSF Govern implementation demonstrates strong governance practice — but it does not produce the board resolution or training records that Article 20 requires as evidence.

---

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

1. NIS2 Directive (EU) 2022/2555 — Article 21: Cybersecurity Risk-Management Measures
2. NIS2 Directive (EU) 2022/2555 — Article 23: Reporting Obligations
3. NIS2 Directive (EU) 2022/2555 — Article 20: Governance
4. NIS2 Directive (EU) 2022/2555 — Article 26: Jurisdiction and Territoriality
5. NIS2 Directive (EU) 2022/2555 — Article 27: Registry of Entities
6. Commission Implementing Regulation (EU) 2024/2690 — Technical and Methodological Requirements for Cybersecurity Risk-Management Measures (EUR-Lex)
7. NIST — NIST Releases Version 2.0 of Landmark Cybersecurity Framework (26 February 2024)
8. Isora GRC — NIST CSF 2.0 Functions, Categories, and Tiers
9. Nisd2.eu — CIR 2024/2690: Technical Measures Wiki
10. NIS2 Templates — Article 26 Jurisdiction: Which EU Authority Supervises Your Organisation?