DORA and NIS2 cloud recoverability: the evidence security leaders should prepare

What do DORA and NIS2 cover?

The Digital Operational Resilience Act, Regulation (EU) 2022/2554, entered into force on 16 January 2023 and has applied since 17 January 2025. EIOPA describes its aim as strengthening the digital resilience of financial entities so they "can withstand, respond to, and recover from ICT disruptions, such as cyberattacks or system failures". The regulation is organized around six areas: ICT risk management, ICT third-party risk management, digital operational resilience testing, ICT-related incidents and their reporting, information sharing, and oversight of critical third-party providers.

NIS2, Directive (EU) 2022/2555, sets a common cybersecurity framework across 18 critical sectors. Member States had until 17 October 2024 to transpose it. The European Commission's summary says covered entities must take "appropriate cybersecurity risk-management measures" and notify national authorities of significant incidents.

This briefing is not legal advice. It sets out what the public regulator pages say and what that implies for cloud disaster recovery tooling.

What did EU supervisors report about incidents in 2025?

On 3 June 2026 the Joint Committee of the European Supervisory Authorities published its report on major ICT-related incidents for 2025, the first full year of DORA reporting. It counts 3,383 major incidents reported by financial entities, with system failures as the leading cause.

On 31 July 2026 the ESAs followed with a statement on ICT risks from frontier AI models. It asks financial entities to adjust their risk management across prevention, detection and management, and expects the management body to be "fully committed" to mitigating these risks with clear governance and accountability.

For a security leader, the two documents point the same way: incidents are frequent, and supervisors expect the board to own the response.

Why is a data backup not enough evidence?

A backup shows that data can be restored. It does not show that the service can run again. A cloud application also needs its accounts, networks, identity, DNS and managed-service settings, and after a control-plane compromise those may be the parts that were changed or deleted. AWS's own guidance says that in a recovery "you must redeploy the infrastructure, configuration, and application code", and CISA's #StopRansomware guide recommends using infrastructure as code for cloud resources and keeping template backups offline.

If the only evidence is a successful data restore test, the question "could you bring this service back in a clean account" is still open.

What evidence can a security leader prepare for cloud infrastructure?

Our editorial suggestion, built from the regulator pages above and from what vendors publish, is a short evidence pack per critical service:

1. Inventory and coverage: which cloud resources and SaaS configurations the service depends on, and which of them have configuration captured.
2. Capture frequency: how often configuration and data are captured, stated separately, against the RPO the business set.
3. Isolation: where recovery copies live, and whether production administrator credentials can alter or delete them.
4. Tested rebuild: the date, target (region or clean account), measured time to a working service and the list of manual steps from the last test.
5. Change history and drift: a record of who changed what, and whether the running environment still matches the state you would recover to.
6. Third-party dependencies: which recovery steps depend on a cloud provider, a backup vendor or a SaaS provider, which ties into DORA's third-party risk area.

A continuous view of items 1, 2 and 5 is what vendors call cloud recovery posture management (sometimes called cloud resilience posture management). Our guide to the term explains what it measures and which vendors offer scoring. Item 4 needs an actual test; our how-to briefing sets one out.

Which vendors talk about DORA and NIS2?

Firefly's cyber resilience page lists DORA, NIS2, SOC 2, ISO 27001, HIPAA, CRA and PCI-DSS in its compliance messaging and describes rebuilding into a clean, isolated region or account from versioned IaC snapshots. Mentioning a regulation is not the same as satisfying it; ask any vendor which evidence it can export for your auditors, and in what format. Question 20 of our buyer's checklist covers this.

Who should own the evidence pack?

DORA and the ESAs place accountability on the management body, so the CISO office is a natural owner of the pack, with the platform or SRE team producing the tests. The split matters less than having one named owner and a date for the next test. The ranking method explains how we score the tools that produce this evidence.