NIS2 vs DORA: which one applies to you, and how to avoid building two programs

Two EU files landed almost together and a lot of teams are still treating them as one blurry "EU cyber regulation" obligation. They are not interchangeable. One is a directive, one is a regulation, they hit different organizations, and there is a precedence rule that decides which one you actually answer to. Get that rule wrong and you either build a program you didn't need or skip one you did.

Start with who is in scope, not with the controls

NIS2 (Directive (EU) 2022/2555) targets medium and large entities operating in the sectors listed in its annexes: energy, transport, banking, health, drinking and waste water, digital infrastructure, public administration, space, plus a second tier covering postal, waste management, chemicals, food, manufacturing, digital providers and research. Inside those sectors you are classified as either an essential or an important entity, and the size threshold generally pulls in anyone at medium size or above, with carve-outs where certain providers are in scope regardless of headcount (DNS, TLD registries, and a few others).

DORA (Regulation (EU) 2022/2554) is narrower and deeper. It applies to financial entities. Around twenty categories: credit institutions, payment and e-money institutions, investment firms, insurers and intermediaries, crypto-asset service providers, central counterparties, trading venues, and so on. It also reaches the ICT third-party providers serving them, and the ones designated critical fall under direct EU oversight by the supervisory authorities.

If you are a SaaS company selling into hospitals, you are probably looking at NIS2. If you are a payment institution, DORA. If you are a cloud provider serving banks, you may be feeling both, from different directions, which is exactly where the precedence rule comes in.

The lex specialis rule that people miss

DORA is lex specialis to NIS2 for financial entities. Practically: where DORA sets ICT risk-management and incident-reporting requirements for an entity it covers, those DORA requirements apply instead of the equivalent NIS2 ones. A bank does not run NIS2 Article 21 measures and DORA Chapter II in parallel for the same ICT risk. It runs DORA.

This is the single most common scoping error I see. A financial entity reads NIS2, sees its sector mentioned, and starts a NIS2 program, when DORA is the regime that actually governs its ICT risk. The sector overlap is real, the obligation is not duplicated.

Reporting timelines are where the divergence is sharpest

NIS2 incident reporting is concrete and tight. For a significant incident: an early warning within 24 hours of becoming aware, a fuller incident notification within 72 hours, and a final report within one month. The early warning is deliberately low-friction, you flag that something significant is happening, even before you understand it. The 72-hour notification is where you commit to an initial assessment, severity, and indicators.

DORA also runs a staged model for major ICT-related incidents (initial, intermediate, final), but the exact clocks are set in the regulatory technical standards rather than in the level-1 text, and DORA adds incident classification criteria you have to apply before you even know whether a given event is reportable. That classification step is the operational tax. Your on-call and your reporting playbook need the thresholds wired in, because deciding "is this a major incident" at 2am, by hand, during an actual outage, does not work.

Both regimes also put accountability on the management body. NIS2 is explicit that management can be held liable and has to follow training. DORA pushes ICT risk into board-level governance. The era of treating this as purely the security team's problem is over in both.

How prescriptive each one is

NIS2 is a directive, so it is transposed into national law, and the details vary by member state. Transposition was due 17 October 2024 and a number of countries ran late, which means in practice you are implementing against your national transposition, not the directive text, and the supervisory and penalty specifics differ across borders. If you operate in several member states, you are reconciling several transpositions.

DORA is a regulation. It applies directly, the same text everywhere, from 17 January 2025, fleshed out by a thick layer of RTS and ITS. It is far more prescriptive: mandatory ICT risk framework, resilience testing including threat-led penetration testing for the more significant entities, a register of ICT third-party arrangements, and specific contractual provisions you must have with your ICT providers. If your vendor contracts do not contain DORA's required clauses, that is a finding regardless of how good your security is.

The part that lets you not build two programs

Underneath the differences, the control substance is the same security program you would build anyway. Risk management, access control, encryption, logging and detection, incident response, business continuity, supplier risk. Both NIS2 Article 21 and DORA's ICT risk chapter are, in effect, restatements of what ISO 27001 and the NIST Cybersecurity Framework already describe.

So the workable strategy is to run one control set and map it outward. Implement against ISO 27001 or NIST CSF, then crosswalk those controls to the specific NIS2 articles or DORA chapters you are accountable for, and keep the regulation-specific extras (DORA's third-party register and contractual clauses, NIS2's national reporting routes) as a thin layer on top rather than a separate program.

The overlap is concrete. NIS2 Article 21(2)(h) on cryptography and DORA Article 9 on protection both land on the same encryption controls you already run for ISO A.8.24. Incident handling under NIS2 Article 21(2)(b), DORA Article 17, and ISO's incident controls are the same response capability described three times. You can see the whole picture in the master crosswalk, and the per-regulation detail on the NIS2 and DORA pages.

Map once. Report to whichever regime owns you. Don't pay for the same control twice.