What NIS2 Expects You to Prove About Recovery
NIS2 lists backup management, disaster recovery, and business continuity as measures you are required to have. The directive moved cybersecurity risk management into law for essential and important entities across the EU. Member States had to bring NIS2 into national law by 17 October 2024, so the transposition deadline has passed.
Enforceability runs through each Member State’s implementing law and competent authority, and transposition has moved unevenly. The Commission opened infringement proceedings in late 2024 and, by May 2025, had escalated to reasoned opinions against 19 Member States that still had not notified full transposition. The obligations are in force; the national rulebooks that carry them are still landing.
What NIS2 actually requires of recovery
Article 21(2) sets the baseline measures. Two of them carry the recovery weight. Point (b) requires incident handling. Point (c) requires “business continuity, such as backup management and disaster recovery, and crisis management.”
That wording is broad on purpose. It tells you to manage backups and plan disaster recovery. It does not define a standard for proving a recovery point is safe to restore, which means the assessor reads the policy you wrote and the test evidence you can show.
A documented backup policy clears the first bar. It does not answer the question a ransomware incident asks, which is whether the newest recovery point predates the intrusion. RPO and RTO targets are still useful here, and RPO Is Not Enough for Ransomware Recovery walks through why a healthy backup schedule can still hide an unrecoverable estate.
The 72-hour clock turns recovery into a disclosure problem
Article 23 sets a three-stage reporting obligation for any significant incident. An early warning is due within 24 hours of becoming aware of it. A fuller notification is due within 72 hours, and it has to include an initial assessment of the incident, “including its severity and impact.” A final report follows within one month, per Article 23.
The 72-hour notification is the trap. You cannot honestly describe how bad an incident is until you know which systems have a clean recovery point and how far back it sits.
A team that is still testing restores at hour 60 is not assessing impact. It is discovering it, against the clock, in front of a regulator.
Management signs for this
NIS2 does not leave accountability with the security team. Article 20 requires management bodies to approve the cybersecurity risk-management measures, to oversee their implementation, and it provides that they “can be held liable” for the entity’s failures. Members of management bodies are also required to follow training.
Approval without evidence is the exposure. How that liability is enforced is shaped by each Member State’s transposing law, so the specifics vary. The underlying problem does not: signing off on a recovery posture you cannot see evidence for means endorsing a control you could not defend if it failed.
What you actually have to be able to prove
The gap between a NIS2-compliant policy and a defensible one is evidence. Each required measure maps to something an assessor, a regulator, or your own incident commander can ask for and you should be able to produce.
Picture an important entity with a tidy backup and continuity policy. Ransomware dwells for nine days before detonation. Every nightly job in that window succeeded, so the policy looks honored. At hour 48 of the Article 23 clock, the team cannot say which recovery point is clean, and it spends the rest of the window restoring candidates one at a time to find out.
That is the gap proactive recovery-point inspection closes. The Active Cyber Resilience Platform inspects backups, snapshots, and object versions for ransomware and malware and names the most recent recovery point confirmed clean, which is the artifact Article 21(2)(c) circles without defining. Ransomware recovery starts with a provable clean recovery point walks through how that copy gets identified and held. For the board and regulator side, the security-leader view covers the recovery attestation that makes the Article 20 sign-off defensible.
The supply-chain measure extends the proof to your vendors
Article 21(2)(d) requires supply-chain security, and it is one of the measures NIS2 emphasizes. For an essential or important entity, a meaningful share of operational risk sits in suppliers: the managed service provider, the SaaS platform, the backup vendor itself.
If a supplier that holds or processes your critical data is hit, your continuity depends on their recovery as much as your own. The evidence standard does not change at the contract boundary. A supplier that cannot show which of your recovery points is clean is a gap in your own Article 21 posture.
The practical move is to ask vendors for the same artifact you hold yourself: the most recent clean recovery point and the test result behind it. A supplier attestation that stops at backup-job success has the same blind spot a green dashboard does.
How this differs from DORA
If you operate in financial services, you are likely managing both. DORA is the sector-specific regime for financial entities and runs deeper on testing and third-party risk; DORA: What CISOs Must Prove About Recovery in 2026 covers that obligation. NIS2 is the broad baseline across eighteen sectors. Where both apply, the sector-specific financial rules generally govern under NIS2’s treatment of equivalent sector-specific acts, but the recovery evidence each one wants is the same artifact.
Map your in-scope services to a current clean recovery point now, not during the next incident. A Recovery Posture Assessment shows which in-scope services have a clean recovery point you could actually name before hour 72.
Know your clean recovery point before hour 72
A Recovery Posture Assessment shows which in-scope services have a recovery point you could name today, not discover under the Article 23 clock.
References
[1] European Union, Directive (EU) 2022/2555 (NIS2 Directive), Official Journal of the European Union, 27 December 2022. Articles 20 (governance), 21 (cybersecurity risk-management measures), and 23 (reporting obligations).
[2] Elastio, The Active Cyber Resilience Platform.
[3] Elastio, Active Cyber Resilience for Security Leaders.
[4] Elastio, RPO Is Not Enough for Ransomware Recovery.
[5] Elastio, Ransomware Recovery Starts With a Provable Clean Recovery Point.
[6] Elastio, DORA: What CISOs Must Prove About Recovery in 2026.
[7] European Commission, Commission calls on 19 Member States to fully transpose the NIS2 Directive, reasoned opinions, 7 May 2025.
[8] Elastio, Recovery Posture Assessment.
Can you prove your recovery points are clean?
Your board will ask if you can recover clean. This checklist lets you answer with evidence.
