NIS2 Guide · 8 min
NIS2 vs DORA: how they differ, where they overlap, and which one applies to you
NIS2 and DORA are the two EU cyber-resilience regimes most likely to land on the same desk in 2026, and they get confused constantly. They chase the same goal (operational and cyber resilience) and lean on many of the same controls, but they aim at different organisations, and for the financial sector one of them wins where they collide. This guide lays out the difference, the overlap, and how to tell which one is yours, with a straight answer for the supply-chain and third-party teams who end up serving customers under both.
Key takeaways
- NIS2 is broad and cross-sector; DORA is the financial sector's ICT-specific regime.
- For financial entities DORA is lex specialis. It takes precedence over the overlapping NIS2 provisions.
- Either way, both put you on the hook for third-party risk and expect assurance that's continuous, not annual.
What each one is
Both came out of the same 2022 EU resilience package, yet they're different instruments pointed at different populations.
NIS2: broad, cross-sector
A directive (transposed into national law, deadline 17 October 2024) covering essential and important entities across energy, transport, health, water, digital infrastructure, public administration, manufacturing and more. It sets a baseline of risk-management measures (Art. 21) and incident reporting (Art. 23).
DORA: financial sector, ICT-focused
A regulation (directly applicable, in force from 17 January 2025) for the EU financial sector (banks, insurers, investment firms, crypto-asset providers and more) plus oversight of their critical ICT third-party providers. It sets detailed rules for ICT risk management, resilience testing and third-party governance.
Where they overlap
Implement one well and much of the other will feel familiar. Both ask for:
- Management accountability: leadership has to own and oversee cyber/ICT risk, and can be held responsible for it.
- Risk-management measures: documented, proportionate controls across the security lifecycle.
- Incident reporting: structured notification to the authorities on defined timelines.
- Third-party and supply-chain risk. You answer for the cyber risk your providers bring with them.
- Testing and continuous improvement: resilience is judged over time, not certified once and shelved.
The key rule: DORA is lex specialis for financial entities
The two regimes were drafted not to double-regulate. For a financial entity, DORA is lex specialis: the more specific law that takes precedence. Where DORA and NIS2 would both cover the same ICT risk-management or incident-reporting ground, DORA's requirements apply and the equivalent NIS2 provisions don't stack on top.
In practice that means a bank doesn't run two parallel cyber programmes. It follows DORA for ICT risk, testing, incident reporting and third-party oversight. NIS2 still shapes the wider ecosystem around it (many of its suppliers included) but on the overlapping topics the financial entity itself is governed by DORA.
Lex specialis applies where the sector-specific act imposes requirements at least equivalent to NIS2. The boundary can get nuanced for mixed groups; confirm your status with your competent authority.
See how your suppliers actually score
7-day free trial · no credit card · cancel anytime
Which applies to you?
A quick decision aid. For a lot of organisations the honest answer is 'one directly, the other through your customers.'
A financial entity (bank, insurer, investment firm, crypto-asset provider…)
DORA applies as lex specialis for your ICT risk; NIS2's equivalent provisions don't apply on top.
A critical-sector entity outside finance (energy, health, transport, water, digital infrastructure, public administration…)
NIS2 applies. Check the Annex I/II sectors and the size thresholds to confirm your tier.
An ICT provider to financial entities
DORA's third-party regime reaches you through your clients' contracts, and the largest providers can be designated critical and overseen directly by the ESAs. If you're also an Annex I ICT or managed-service provider, you may be in NIS2 scope too.
A supplier to a NIS2 entity
NIS2's supply-chain duty (Art. 21(2)(d)) reaches you through your customers' due diligence (questionnaires, evidence requests, continuous monitoring) even when you're not designated yourself.
The bottom line for supply-chain teams
Whether your customer answers to DORA or to NIS2, the demand on you converges. Both make organisations responsible for their providers' cyber risk, and both treat resilience as something assessed continuously rather than attested once a year. So the question for a supplier is rarely 'NIS2 or DORA?'. It's 'can I show, on demand, that my security holds up?'
That's why third-party assurance is going continuous on both sides of the line. A bank's DORA register of information and a manufacturer's NIS2 supplier programme are asking their suppliers for the same thing: current, evidence-backed proof of security posture, not a spreadsheet that was true last spring.
Sources: Regulation (EU) 2022/2554 (DORA) and Directive (EU) 2022/2555 (NIS2). Confirm the overlap boundary with your national competent authority and the relevant ESA guidance.
How norppa.io helps
norppa.io gives you the continuous, evidence-backed assurance over suppliers and ICT providers that both NIS2 and DORA now expect. Every monitored domain is checked across more than a hundred control points daily, the time-sensitive ones every six hours, with findings ready to export into your DORA register of information or your NIS2 supplier file.
Self-assessment questionnaires capture the process and contractual controls, and each answer is set against the live technical profile, so whether your customer's auditor cites DORA or NIS2, you can show current, corroborated evidence instead of assertions.