DORA vs NIS2 is a question a lot of EU organizations are asking right now — usually because they suspect both apply. Both are EU cybersecurity regimes with mandatory incident reporting, but DORA and NIS2 aim at different targets and run on different clocks, and where they overlap a specific rule decides which one governs. This guide sets out how the two differ, where they meet, and how to tell which binds you.
DORA and NIS2 are parallel EU cybersecurity regimes — NIS2 sets baseline cybersecurity and incident-reporting duties across a broad set of essential and important entities, while DORA sets more detailed digital operational-resilience rules for the financial sector and, for those entities, generally takes precedence as the more specific law.
The cleanest way to hold the two apart is by target. NIS2 is a horizontal cybersecurity regime: it raises the baseline for a broad sweep of the economy, sorting organizations into essential and important entities and imposing risk-management and incident-reporting duties across many sectors. DORA is vertical: it applies to the financial sector and its ICT providers, and goes deeper — on ICT risk management, resilience testing, third-party oversight, and a fast incident-reporting clock — than a horizontal regime would.
There is also a legal-form difference that has practical consequences. NIS2 is a directive, so each member state transposes it into national law and the specifics — thresholds, recipients, extra duties — vary by country. DORA is a regulation, directly applicable across the EU, so its requirements are far more uniform from one member state to the next.
NIS2's reach is deliberately wide: energy, transport, health, water, digital infrastructure, public administration, space, manufacturing, food, chemicals, postal and waste services, and digital providers, among others. DORA's reach is narrower but dense — banks, payment and e-money institutions, investment firms, insurers and intermediaries, crypto-asset service providers, trading venues, and critical ICT third-party providers to them, among many other financial entities.
The overlap is real and specific. A bank sits inside NIS2's banking sector and squarely inside DORA. That is the case the two regimes anticipate — and resolve — through the rule in the next section.
NIS2 was written in the knowledge that sector-specific EU laws would sit alongside it. Its answer is a lex specialis arrangement: where a sector-specific Union act requires essential or important entities to adopt cybersecurity risk-management measures or to notify significant incidents, and those requirements are at least equivalent in effect to NIS2's, the sector act's provisions apply to those entities instead of the corresponding NIS2 ones. DORA is the leading example for the financial sector.
In practice that means an in-scope financial entity manages ICT risk and reports ICT-related incidents under DORA, not under NIS2 as well — it does not report the same incident twice under two regimes. The detail of that DORA route is in DORA incident reporting. This is the EU baseline; national transposition varies. It's informational, not legal advice — verify the specifics that bind you with qualified counsel.
The reporting clocks are where the difference is most visible day to day. Both start from awareness or classification of a qualifying incident — not from when it began — but the sequences differ:
DORA's first step is the tighter of the two, which is one reason financial entities invest so heavily in fast, accurate classification. The full mechanics live in DORA incident reporting and NIS2 incident reporting, and all three EU clocks — including GDPR's — are laid side by side in our incident clocks guide.
The practical test starts with entity type. If you are an in-scope financial entity, DORA is very likely your governing regime for ICT risk and incident reporting, with NIS2 stepping back under lex specialis. If you are an essential or important entity outside the DORA perimeter, NIS2 governs. Some group structures manage to sit in both worlds across different legal entities — a financial subsidiary under DORA, a manufacturing arm under NIS2 — which is precisely where a clear map of which regime binds which entity earns its keep.
That mapping is exactly what Polestead's CIIC is built to hold, so that when an incident is classified the right clock — and only the right clock — starts, with the right report drafted for the right authority.
Polestead's Critical Incident Intelligence Center maps your business profile to the regimes that bind you — DORA, NIS2, GDPR, and their interactions — and on incident classification it produces the next-step plan, the clock schedule, and every regulator-ready report in parallel.
How CIIC works →NIS2 is a broad horizontal cybersecurity directive covering essential and important entities across many sectors. DORA is a financial-sector regulation with deeper operational-resilience and ICT incident-reporting rules. NIS2 is transposed nationally and varies by country; DORA is directly applicable and more uniform.
They can appear to, because a financial entity sits inside NIS2's banking sector and inside DORA. In practice DORA acts as lex specialis, so that entity manages ICT risk and reports ICT incidents under DORA rather than under both regimes.
Where a sector-specific EU act like DORA imposes cybersecurity or incident-reporting requirements at least equivalent to NIS2's, those provisions apply to the affected entities instead of the corresponding NIS2 ones — so they are not reported twice.
DORA: an initial notification roughly four hours after classification, then intermediate and final reports. NIS2: a 24-hour early warning, 72-hour notification, and one-month final report. This is the EU baseline; national transposition varies, and this is informational, not legal advice.