DORA or NIS2? What Applies When Your Organization Is Caught by Both

The DORA vs NIS2 question has a clear answer, and it is not ‘comply with both’. Financial entities are not required to satisfy both regimes on the same ground — one displaces the other. Knowing which governs, and which clock starts when an incident is declared, is the difference between a defensible notification and a late one.

Organizations in scope of both frequently plan for the harder reading: comply with everything, twice. That is expensive and unnecessary. The relationship between the two instruments is settled in the legislation itself.

DORA displaces NIS2, on a specific basis

The legal mechanism

NIS2 Article 4 provides that where a sector-specific Union legal act requires cybersecurity risk-management or incident-reporting measures at least equivalent in effect to those in the directive, the relevant NIS2 provisions do not apply. DORA Recital 28 states the corresponding position directly: the regulation constitutes lex specialis to NIS2 with regard to the financial sector.

The practical effect is that a financial entity in scope of DORA follows DORA on ICT risk management and incident reporting, and does not separately discharge the equivalent NIS2 obligations.

Who this covers

The displacement applies to the financial entities listed in DORA Article 2(1) — 21 categories including credit institutions, investment firms, insurers and reinsurers, payment and electronic money institutions, fund managers, crypto-asset service providers, central counterparties, central securities depositories, and trading venues.

Where it stops

Displacement is not exemption, and this is where planning most often goes wrong. It covers the overlapping subject matter — risk management and incident reporting. It does not switch NIS2 off entirely. National transposition of NIS2 can impose requirements that sit outside DORA’s scope. And entities elsewhere in a group that are not financial entities under DORA Article 2(1) may be in scope of NIS2 in their own right, on their own national timetable.

A banking group with a logistics subsidiary, a data centre operator, or a shared services company inside the same corporate structure can therefore be running two regimes at once — just not on the same entity for the same obligation.

The clocks are not the same, and that is the operational problem

The substantive overlap between DORA vs NIS2 is genuine. The reporting timetables are not.

Four hours is the number that changes operational design. A 24-hour early warning can, at a stretch, be assembled by people working the incident and writing it up afterwards. Four hours from classification cannot. It has to come out of the response as it happens, while the picture is still forming and the people who know what happened are still busy handling it.

That deadline is also conditional on something easy to overlook: the clock starts at classification, not at detection. Which means the classification decision — is this major or is it not — is itself on the critical path, and someone has to make it, record it, and be able to justify it later.

What this means in practice

RAYVN removes the reconstruction problem. As an incident unfolds, every declaration, classification, mobilisation, escalation, and decision is logged the moment it happens. When the four-hour deadline hits, the notification is already there in a live, time-stamped record — nothing has to be pieced together from memory while the clock runs. The same record then answers the regulator’s follow-up questions, and for groups running both regimes, it evidences the NIS2 obligations on the entities where those still apply.

This article summarises DORA and NIS2 for general information and reflects our reading of the regulations as they stand. It is not legal advice and should not be relied on as such. For a definitive view on how these regimes apply to your organisation, consult a qualified legal adviser.