For many European financial institutions, 2025 was the year two digital resilience regimes began to coexist in day-to-day operations: Regulation (EU) 2022/2554, known as DORA, applicable since 17 January 2025, and Directive (EU) 2022/2555, NIS2, whose deadline for transposition into national law passed on 17 October 2024.
The most common reading is that DORA "replaces" NIS2 in the financial sector. That is a useful simplification, but an incomplete one. For groups with several entities, service providers operating in more than one sector and teams that answer to different supervisors, the overlap is real and it has a cost: controls documented twice, evidence collected in different formats and incident reports written in a hurry, with figures that do not always match. This article proposes a different approach: build a single evidence layer that serves both regimes.
Where NIS2 ends and DORA begins
Article 4 of NIS2 provides that where a sector-specific Union legal act requires cybersecurity risk-management measures or incident notification with an effect at least equivalent, the corresponding provisions of the directive do not apply to the entities covered by that act. The recitals of NIS2 identify DORA as one such sector-specific act for financial entities.
In practice, this means that a bank, an investment firm or an insurance undertaking covered by DORA meets its obligations on ICT risk management, incident classification and reporting, and resilience testing through DORA. But the boundary is not always clean:
- Mixed groups. A financial group may include entities that are not financial entities within the meaning of DORA but that operate in sectors covered by NIS2, such as managed ICT services or digital infrastructure.
- ICT service providers. A cloud computing provider may be an essential entity under NIS2 and, at the same time, a third-party ICT service provider subject to DORA's oversight framework.
- National transposition. NIS2 is a directive; each Member State has transposed the text with its own authorities, deadlines and specificities. DORA, being a regulation, applies directly.
- Cooperation between authorities. Even where DORA applies, the regimes provide for cooperation and information sharing between financial supervisory authorities and national authorities and CSIRTs.
What the two regimes have in common
Despite the different wording, the two texts essentially require the same capabilities. The table below shows some correspondences between DORA requirements and the minimum measures in Article 21 of NIS2.
| Capability | DORA | NIS2 |
|---|---|---|
| Governance and management accountability | Art. 5 | Art. 20 |
| Risk management framework | Art. 6 | Art. 21(2)(a) |
| Asset inventory and identification | Art. 8 | Art. 21(2)(i) |
| Incident detection and management | Arts. 10 and 17 | Art. 21(2)(b) |
| Backup, restoration and continuity | Arts. 11 and 12 | Art. 21(2)(c) |
| Third-party and supply chain risk | Art. 28 et seq. | Art. 21(2)(d) |
| Reporting of major / significant incidents | Art. 19 | Art. 23 |
The correspondence is not perfect: DORA is more prescriptive on resilience testing, including threat-led penetration testing for certain entities, and on the register of information on contractual arrangements with ICT providers. But the common ground is large enough to justify a single evidence architecture.
The real problem: duplicated, diverging evidence
When each regime is treated as a separate project, predictable patterns emerge. The risk team keeps one asset inventory for DORA; the security team keeps another for NIS2. Restore tests are documented in a spreadsheet for one audit and in a different report for another. During an incident, the timeline is reconstructed from the logs of different systems, each with its own clock and its own format.
The risk is not only one of efficiency. Reporting deadlines are demanding under both regimes. NIS2 provides for an early warning within 24 hours of becoming aware of a significant incident, a notification within 72 hours and a final report within one month. DORA and its technical standards define an initial notification, intermediate reports and a final report for major ICT-related incidents. Under that pressure, two versions of the same facts are a serious problem: in front of a supervisor, a discrepancy between reports is treated as a question of credibility.
Dual compliance does not require dual evidence. It requires a single source of facts that can be read through two regulatory frameworks.
Designing a single evidence layer
1. Separate evidence from reports
A report is an interpretation; evidence is the underlying fact. The first step is to collect evidence once, at the point of origin, and only then produce different views for each regime. A restore test run at a given time, with a given result, is the same fact whether it is presented under Article 12 of DORA or Article 21(2)(c) of NIS2.
2. Make every record verifiable
For the same evidence to be accepted by different supervisors, it has to withstand independent scrutiny. That means reliable timestamps, clear attribution (who or which system produced the record) and demonstrable integrity: the ability to prove that the record has not been altered since it was created.
3. Map controls once
Instead of maintaining two control matrices, maintain one capability matrix, like the table above, and link each capability to the relevant provisions of each regime. When a technical standard is updated or a national transposition introduces a specificity, you update the mapping, not the evidence.
4. Prepare reporting before the incident
The notification templates of both regimes ask for similar information: time of detection, affected systems, impact, measures taken. If those fields are fed automatically from the evidence layer, reporting stops being a reconstruction exercise and becomes an export.
5. Bring third parties into the same model
Third-party risk is one of the areas where the two regimes come closest. Evidence about critical suppliers, including the integrity of the data they exchange with the organisation, should live in the same layer and follow the same verifiability rules.
An example workflow
Imagine an unauthorised change to a table in a production database. In a single evidence layer, the change is detected by comparison with the sealed state; the alert records the exact moment of detection; the response team documents its actions on the same trail; the restore is made from a point verified as intact and the result is recorded. When the time comes to notify, the same timeline serves the financial supervisory authority and, where applicable, the national cybersecurity authority, with the same facts, the same times and the same proof.
How ROOTKey helps
ROOTKey works as that evidence layer. Every file, record and policy is anchored to a cryptographic proof, and every action is sealed with a cryptographic timestamp and signature, forming a chain of custody that is ready for auditors and exportable for regulators.
Continuous monitoring detects changes against the sealed record, recovery points make it possible to restore only the state verified as intact, and NIS2, DORA and GDPR compliance reports are generated on demand from the same base of facts. Learn more on the dedicated pages for DORA and NIS2, or assess your gap with the NIS2 Simulator.