NIS2 vs DORA: Key Differences and How to Comply With Both

NIS2 vs DORA comes down to one core distinction: NIS2 is a broad EU cybersecurity directive that raises the security baseline across nearly every critical sector, while DORA is a finance-specific regulation that governs how banks, insurers, and investment firms manage ICT and operational resilience. NIS2 is the general rule for the whole economy; DORA is the specialist rule for the financial system. Where they overlap, DORA takes precedence for the entities it covers. Understanding that relationship is the difference between duplicating work and complying efficiently.

Both instruments landed in the EU Official Journal in December 2022 and are now live obligations, not future planning items. Yet we still see organisations treat them as interchangeable, or assume that being in scope for one exempts them from the other. Neither assumption is safe. Let us walk through what each does, who it binds, and how to run a single programme that satisfies both.

What NIS2 Is

NIS2 is Directive (EU) 2022/2555, the successor to the original 2016 Network and Information Security Directive. As a directive, it is not directly binding on organisations — each member state had to transpose it into national law, with the transposition deadline set for 17 October 2024. That means the precise obligations you face depend on your national implementing act, though the directive sets a common floor across the EU.

NIS2 dramatically widens the net compared with its predecessor. It applies across roughly 18 sectors, splitting organisations into essential entities and important entities based on sector and size. It mandates risk-management measures, supply-chain security, and — significantly — personal accountability for senior management, who can be held liable for compliance failures. Incident reporting follows a three-stage clock under Article 23: a 24-hour early warning, a 72-hour incident notification, and a final report within one month. We cover the operational detail in our guide on what organisations need to do for the NIS2 directive, and the sector-by-sector question of who counts as an essential service in our NIS2 essential services readiness piece.

What DORA Is

DORA is Regulation (EU) 2022/2554, the Digital Operational Resilience Act. Because it is a regulation rather than a directive, it applies directly and uniformly across every member state with no national transposition required — the same text binds a bank in Dublin and one in Frankfurt. It has been fully applicable since 17 January 2025. There is no local variation to interpret; the obligations are the obligations.

DORA targets the financial sector exclusively, reaching around 21 categories of financial entity — banks, insurers, investment firms, payment institutions, crypto-asset service providers, and more — plus, critically, the ICT third-party providers that serve them. It is built on five pillars: ICT risk management, ICT incident reporting, digital operational resilience testing, third-party risk oversight, and information sharing. Its incident-reporting clock is even tighter than NIS2's: an initial notification within 4 hours of classifying a major incident (and no later than 24 hours after becoming aware), an intermediate report within 72 hours, and a final report within one month.

Two DORA features have no direct NIS2 equivalent. The first is threat-led penetration testing (TLPT): significant financial entities must undergo intelligence-driven, real-world attack simulations at least every three years, with critical ICT providers pulled into scope. The second is the EU-level oversight framework for critical ICT third-party providers, which lets the European Supervisory Authorities directly supervise the hyperscalers and vendors the financial system depends on. Our dedicated overview of the Digital Operational Resilience Act unpacks all five pillars in depth.

NIS2 vs DORA: The Key Differences

The two regulations share a common purpose — hardening Europe against cyber and operational disruption — but differ in legal form, reach, and precision. The clearest way to see it:

• Legal instrument: NIS2 is a directive (transposed into national law); DORA is a regulation (directly applicable, identical everywhere)
• Scope: NIS2 spans ~18 critical sectors economy-wide; DORA covers only the financial sector and its ICT providers
• Effective date: NIS2 transposition deadline was 17 October 2024; DORA applies since 17 January 2025
• Incident reporting: NIS2 uses 24h / 72h / 1 month; DORA uses 4h (initial) / 72h / 1 month, with a harder initial deadline
• Resilience testing: DORA mandates threat-led penetration testing (TLPT) every three years; NIS2 has no equivalent prescriptive testing regime
• Third-party oversight: DORA introduces direct EU-level supervision of critical ICT providers; NIS2 addresses supply chain but without a central oversight body
• Accountability: both impose management responsibility, but NIS2 is explicit about personal liability for senior leaders

Who Must Comply With Each

For NIS2, the test is sector plus size. If you operate in one of the covered sectors — energy, transport, health, digital infrastructure, ICT service management, public administration, water, waste, food, manufacturing, digital providers, and others — and you meet the size threshold (broadly, medium and large organisations), you are almost certainly in scope as either an essential or important entity. Some entities are captured regardless of size where they are critical to a member state.

For DORA, the test is simpler: are you a financial entity as defined by the regulation, or a third-party providing ICT services to one? If yes, DORA applies in full. A bank is squarely a DORA entity. A cloud provider hosting that bank's core systems is captured through DORA's third-party provisions. The grey zone is organisations that sit in both worlds — a large insurer, for instance, is a financial entity under DORA and could also be swept up by NIS2's broad reach. That overlap is exactly where the rules interact.

How They Overlap — and Which Prevails

This is the question that matters most for financial firms, and the EU legislators anticipated it. DORA is explicitly designed as lex specialis to NIS2 — the specialist law that overrides the general one where the two address the same subject. Article 1(2) of DORA makes this relationship clear. In practice, for financial entities, DORA's requirements on ICT risk management, incident reporting, and resilience testing replace the equivalent NIS2 obligations, so firms are not forced to report the same incident twice under two conflicting clocks.

So the mental model is: if you are a financial entity, DORA is your primary rulebook for ICT and operational resilience, and NIS2 recedes into the background for those matters — but it does not vanish entirely. If you are not a financial entity, DORA is irrelevant and NIS2 is your governing regime. And if you are an ICT provider serving the financial sector, you can find yourself pulled into DORA's orbit contractually even though you would otherwise sit only under NIS2.

How to Comply With Both

The good news is that NIS2 and DORA rest on the same foundations: identify your critical assets and functions, manage ICT risk systematically, detect and report incidents on a clock, test your resilience, and govern your third parties. An organisation that builds those capabilities once can map them to both regimes rather than running two parallel programmes. The trap is treating each regulation as a standalone project with its own team, tooling, and evidence base.

• Scope first: determine precisely which entities in your group are financial (DORA), which are in a NIS2 sector, and which are both
• Build one control framework: map a single set of ICT risk, incident, testing, and third-party controls to the requirements of each regulation
• Reconcile the incident clocks: design a reporting workflow that meets DORA's 4-hour trigger, which automatically satisfies the more relaxed NIS2 24-hour early warning
• Consolidate third-party registers: maintain one inventory of ICT suppliers that serves DORA oversight and NIS2 supply-chain obligations
• Fix accountability at board level: NIS2 personal liability and DORA management-body duties both point to documented senior ownership
• Close the gaps DORA leaves: check NIS2 for obligations (such as certain physical and organisational measures) DORA does not cover

This is where a unified governance, risk, and compliance approach pays for itself. Rather than maintaining separate NIS2 and DORA silos, mature organisations run a single control library, a shared incident-response function, and one third-party register that feed evidence to whichever regime asks for it. Our guide to building a unified GRC operating model sets out how to structure that once and reuse it many times — the same logic that keeps NIS2 and DORA from becoming two full-time jobs instead of one.

The bottom line: NIS2 and DORA are complementary, not competing. NIS2 raises the whole economy's cyber baseline; DORA hardens the financial system specifically and prevails where the two meet. Know which entities you are, build your resilience capabilities once, and map them deliberately to both. That is how you comply with two regulations without doing twice the work.