The Map That Most NIS2 Programmes Are Missing
The organisations that will navigate NIS2 most effectively are the ones that understand it as part of a system rather than in isolation. European cybersecurity regulation in 2023 is not a single framework. It is a set of overlapping directives and regulations with distinct scopes, different enforcement authorities, and specific interaction rules that determine which framework governs which obligation when they overlap.
Getting this wrong has operational and financial consequences. A financial services organisation that runs its NIS2 programme independently of its DORA programme will discover, in the compliance assessment, that the two programmes have duplicated effort in some areas and left gaps in others. A critical infrastructure operator that does not understand the relationship between NIS2 and CER will have an incomplete picture of its operational resilience obligations. And any organisation deploying high-risk AI systems that treats NIS2 and the EU AI Act as separate concerns will miss the intersecting obligations that govern AI security in the European regulatory framework.
This article maps the landscape that EMEA enterprise technology leaders need to understand.
DORA Supersedes NIS2 for Financial Entities
The most important regulatory interaction for financial services organisations is the relationship between NIS2 and DORA, the Digital Operational Resilience Act, which enters into force on 17 January 2025.
NIS2 applies to financial entities as essential entities within the banking and financial market infrastructure sectors. DORA also applies to financial entities: credit institutions, investment firms, insurance undertakings, crypto-asset service providers, and a range of other financial sector participants.
The relationship is explicit: DORA is lex specialis relative to NIS2, meaning that DORA takes precedence for financial entities within its scope. Article 1(2) of NIS2 states that where sector-specific acts of EU law impose requirements on the cybersecurity of network and information systems that are at least equivalent to NIS2, the sector-specific act prevails. DORA has been assessed as meeting this equivalence threshold.
The practical implication is that financial entities within DORA’s scope do not need to implement NIS2 requirements separately from DORA requirements. They need to implement DORA requirements, which are more specific and in some respects more demanding than NIS2, and they will have satisfied their NIS2 obligations in the process. Running a separate NIS2 compliance programme alongside a DORA programme in a financial services organisation is duplication of effort based on a misunderstanding of the regulatory relationship.
For financial entities, the priority is DORA compliance, with NIS2 confirmed as satisfied through the DORA programme. For non-financial entities within NIS2 scope, DORA is not relevant and NIS2 governs.
NIS2 and CER for Critical Infrastructure Operators
The Critical Entities Resilience Directive, CER, applies to entities in critical sectors and focuses on the physical resilience of critical infrastructure: the ability to prevent, protect against, and respond to incidents that affect physical infrastructure, not just digital systems.
NIS2 addresses digital resilience. CER addresses physical resilience. For operators of critical infrastructure in the energy, transport, drinking water, and similar sectors, both apply simultaneously. An energy grid operator needs to meet NIS2 requirements for the digital security of its operational technology networks and meets CER requirements for the physical security of its infrastructure.
The two directives are designed to be complementary and non-duplicative. They have different supervisory authorities in most member states: NIS2 falls under the national cybersecurity authority, while CER falls under a competent authority designated for critical entity resilience, often a sector regulator. Coordinating between these supervisory relationships is an organisational and governance question that operators in relevant sectors need to address explicitly.
The practical implication for critical infrastructure operators is that both programmes need to be managed in coordination, with clear accountability for each and a single view of the organisation’s overall resilience posture that bridges the digital-physical boundary.
The EU AI Act’s Intersection with NIS2 Cybersecurity Requirements
The EU AI Act, which reached political agreement in December 2023, introduces specific cybersecurity requirements for high-risk AI systems that intersect with NIS2 in important ways.
Article 15 of the EU AI Act requires that high-risk AI systems achieve appropriate levels of accuracy, robustness, and cybersecurity. It specifically addresses adversarial robustness: the requirement that AI systems remain operationally reliable when attempts are made to alter their outputs through inputs designed to deceive, manipulate, or exploit the system. This requirement maps to the AI-specific attack surfaces that conventional security controls do not address.
NIS2’s Article 21 minimum measures include policies on the use of cryptography and secure communications, access control, and policies on network security. For organisations deploying high-risk AI systems that are within NIS2 scope, these requirements intersect with the AI Act’s cybersecurity provisions. The security architecture for the AI system needs to satisfy both the NIS2 minimum measures applicable to the organisation’s networks and systems and the AI Act’s specific cybersecurity requirements for the AI system itself.
The practical implication is that organisations within NIS2 scope that are deploying high-risk AI systems need a security architecture that integrates AI-specific security requirements rather than treating NIS2 and AI Act compliance as separate workstreams. The security assessment of the AI system needs to address both the network and system security measures required by NIS2 and the model-level security requirements of the AI Act.
Non-EU Organisations Are Not Outside the Scope
One of the most frequently misunderstood elements of the NIS2 regulatory landscape is its jurisdictional reach. NIS2 does not only apply to organisations established in the EU.
Digital providers, including DNS service providers, TLD name registries, cloud computing services, data centre services, content delivery networks, online marketplaces, online search engines, and social networking service platforms, must comply with NIS2 if they offer services to EU customers above the size thresholds, regardless of where they are established. These providers must designate a representative in the EU.
For non-EU technology organisations with significant European customer bases or European operations, NIS2 obligations may apply directly rather than indirectly through their EU-based customers. The supply chain security provisions of Article 21 also extend NIS2’s effective reach: an in-scope EU organisation assessing its suppliers’ cybersecurity posture under Article 21 is effectively imposing NIS2-derived requirements on those suppliers through commercial relationships, even if those suppliers are not directly in scope.
Managing the Regulatory Portfolio
The practical implication of this regulatory landscape for enterprise technology leaders is that NIS2 compliance cannot be managed in isolation. It needs to be managed as part of a regulatory portfolio that includes DORA for financial entities, CER for critical infrastructure operators, AI Act for AI system deployers, and GDPR for all data processors.
The organisations that manage this portfolio effectively are the ones that have a clear mapping of which regulation applies to which of their activities, which regulation governs when there is overlap, and which supervisory authority they report to under each. This mapping is the foundation for a compliance programme that serves multiple regulatory obligations efficiently rather than running four separate compliance programmes that overlap and leave gaps between them.
The third article in this series examines the board accountability provisions of Article 20 in operational detail. The regulatory landscape is clear. The accountability that follows from it, and what it means for the individuals at the top of in-scope organisations, is the subject of the next conversation.