NIS2 Disaster Recovery Plan: Template + RTO/RPO

Main article: BCM under NIS2 — business impact analysis, emergency plan and crisis team. This page is the template for the technical part of it, the disaster recovery plan.

A disaster recovery plan (DR plan) describes how an entity restores IT systems, data and infrastructure after an emergency. This template shows a proven structure in eight sections, five typical scenarios, RTO/RPO values per service class and a test plan. The NIS2 guide gives the overall overview of the NIS2 obligations; further in-depth articles are in the NIS2 knowledge area.

1. What NIS2 Art. 21(2)(c) and § 30(2) no. 3 BSIG require

Art. 21(2)(c) of the NIS2 Directive reads: "business continuity, such as backup management and disaster recovery, and crisis management". § 30(2) no. 3 BSIG adopts this wording. The law thus names three elements:

1. Backup management: documented backup strategy, regular backups, testing that data can be restored
2. Disaster recovery: technical and organisational procedures for recovery
3. Crisis management: crisis team, communications, decision and escalation paths

The standard is set by § 30(1) BSIG: the measures must be appropriate, proportionate and effective, and the entity must document compliance with them. The law does not expressly prescribe a "disaster recovery plan" or RTO and RPO values; the DR plan is, however, the usual practice standard for evidencing backup management and recovery. The addressees are particularly important and important entities; in Germany the BSIG has applied since 6 December 2025 (BGBl. 2025 I No. 301) without a general transition period; the obligations under § 30 BSIG have applied since then.

The DR plan implements the first two elements operationally and supports the third. It stands alongside the BCM plan, the backup concept and the incident response plan (handling of security incidents, § 30(2) no. 2 BSIG). How it fits into all ten areas of measures is shown in § 30 BSIG: 10 mandatory NIS2 measures.

Financial sector and energy: a different legal basis

For financial entities under Art. 2(2) of Regulation (EU) 2022/2554 (DORA), §§ 30, 31, 32, 35, 36, 38 and 39 BSIG do not apply (§ 28(6) no. 1 BSIG); their obligations on backup, recovery and crisis management follow not additionally but instead from DORA (Art. 11 and 12 of Regulation (EU) 2022/2554) — see NIS2 + DORA for banks and financial services. For operators of energy supply networks, energy installations or digital energy services under the Energy Industry Act who are subject to §§ 5c to 5e EnWG, §§ 30, 31, 32, 35, 36, 38, 39, 61 and 62 BSIG do not apply (§ 28(5) sentence 1 no. 2 BSIG), except where operating the energy installation is only an ancillary activity, where further critical installations are operated or where further activities of another entity type are carried out (§ 28(5) sentences 2 and 4 BSIG) — see NIS2 in energy supply.

Austria: the same obligation in the NISG 2026

Austria (AT): in Austria the NISG 2026 (BGBl. I No. 94/2025) applies instead of the BSIG. § 32(4)(c) NISG 2026 requires, in the same wording, "business continuity, such as backup management and disaster recovery, and crisis management". The obligation has applied since 1 October 2026 (§ 51(2) NISG 2026). The entity reports significant cybersecurity incidents to the competent CSIRT (§ 34(2) NISG 2026). The management bodies must ensure and supervise compliance with the risk management measures (§ 31 NISG 2026); the competent authority is the Federal Office for Cybersecurity (§ 3a(1) NISG 2026). The structure of this template also fits there; reporting channels and references need to be adapted. More in the article NIS2 Austria (NISG 2026).

2. DR plan structure

A DR plan that holds up to review contains the following eight sections. The structure is practice; the law prescribes no sections.

Section 1: Scope and activation

• Which systems, processes and sites are covered?
• Who activates the plan (crisis team, IT management, executive management)?
• Activation criteria with measurable thresholds (e.g. "outage > 4 h", "confirmed data exfiltration", "more than 5 encrypted servers")
• Alerting procedure: 24/7 reachability, escalation phone list

Section 2: Roles and responsibilities

• Crisis team: lead, deputy, members, reachability
• IT recovery team: owners per system cluster
• Communications owners (internal, supervisory authority, customers, media)
• External partners: IT forensics, law firm, PR agency, cyber insurer

Section 3: Scenarios

Per scenario: trigger, impact, immediate measures, recovery approach, specifics (see section 3 of this article).

Section 4: RTO/RPO matrix

Per service or application: tier classification, RTO, RPO, dependent systems, restart sequence.

Section 5: Recovery procedures

• Technical procedures (restore scripts, failover procedures, cloud failover)
• Dependency sequence (DNS → Active Directory → database → application)
• Validation tests after recovery
• Handover to normal operations

Section 6: Communications

• Internal communications: employees, works council
• Supervisory authority: the entity reports a significant security incident (§ 2 no. 11 BSIG) in stages (24 h / 72 h / 1 month, § 32(1) BSIG) to the joint reporting office of the Federal Office for Information Security (BSI) and the Federal Office of Civil Protection and Disaster Assistance (BBK); procedure and content: NIS2 incident reporting.
• Data protection: where personal data are affected, the notification to the data protection supervisory authority runs in parallel — without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to result in a risk (Art. 33(1) GDPR). This also applies without data exfiltration, because loss or destruction of data is also a breach (Art. 4 no. 12 GDPR). Where a high risk is likely, the data subjects must additionally be informed (Art. 34(1) GDPR).
• Emergency communications independent of the failed infrastructure; § 30(2) no. 10 BSIG names, where appropriate, secured emergency communication systems within the entity
• Customers and contractual partners, media and the public (for major incidents)
• Prepared wording (holding statements)

Section 7: Tests and exercises

• Test plan with frequency per scenario
• Template for the test record
• Findings tracking and corrective-action plan

Section 8: Maintenance and updates

• Review cycle (practice recommendation: at least annually)
• Triggers for event-driven updates (personnel changes, new systems, lessons learned)
• Owners for maintenance

3. 5 typical scenarios in detail

Scenario 1: Ransomware attack

The trigger is the encryption of critical systems, often combined with data exfiltration. The recovery source is immutable backups, not potentially infected snapshots; the restart begins only after forensic clearance. Isolation, forensics, reports and a criminal complaint are described in the Ransomware Recovery 72h plan.

Scenario 2: Data-centre outage

• Trigger: fire, power outage beyond UPS capacity, water, cooling failure, physical damage
• Impact: complete outage of locally operated systems
• Immediate measures: failover to the secondary data centre, inform employees, notify service providers
• Recovery strategy: active-active cluster (hot standby) or active-passive (warm standby) with a documented failover procedure
• Specifics: access lockdown and evidence preservation where arson is suspected

Scenario 3: Outage of a cloud provider

• Trigger: outage of a cloud provider's infrastructure, email or collaboration services in the region used
• Impact: depends on the degree of dependency — from partial (email briefly unavailable) to total (full SaaS dependency)
• Immediate measures: check the provider's status page, own status communications, activate workarounds (e.g. local tools, telephone instead of video conference)
• Recovery strategy: multi-region with the same provider or multi-cloud across providers — document the cost-benefit trade-off
• Specifics: check the provider's SLA, document damages claims

The provider's perspective is described in the article NIS2 for cloud providers and SaaS.

Scenario 4: Insider attack or unauthorised access

• Trigger: malicious employees, compromised privileged accounts, unauthorised access
• Impact: data manipulation, data exfiltration, sabotage
• Immediate measures: lock accounts, engage forensics, involve the works council where employees are concerned (in the public sector the staff council), coordinate with law enforcement authorities
• Recovery strategy: restore manipulated data from backups with preserved integrity, analyse audit trails in full
• Specifics: employment-law measures, co-determination, evidence preservation while safeguarding employee data protection (in Germany additionally § 26 BDSG)

Scenario 5: Natural event or force majeure

• Trigger: flood, storm, earthquake, pandemic, prolonged power outage
• Impact: regional outages, possibly loss of personnel, physical damage
• Immediate measures: safety of employees first, evacuation of the site where necessary, activate emergency workplaces
• Recovery strategy: geographically distributed data centres, cloud failover, home-office capability, alternative sites
• Specifics: file insurance claims early, communication with the local crisis teams

4. RTO/RPO per service class

RTO (Recovery Time Objective) is the maximum acceptable recovery duration, RPO (Recovery Point Objective) the maximum acceptable data loss, measured as the time between the last backup and the incident. How the values are derived from the business impact analysis, set below the maximum tolerable downtime and approved by management is described in the BCM guide in the section Defining RTO and RPO.

The tiers are a practice example. In its example matrix the BCM guide sets, for instance, an RTO of 1 h for an online shop; which tier a service receives in your organisation is decided solely by your business impact analysis.

Technical implications per tier

• Tier 1: synchronous replication, active-active cluster, hot standby — costly, but necessary for availability-critical systems
• Tier 2: asynchronous replication, warm standby, fast restore from a current backup
• Tier 3: daily backups (snapshot or cloud), cold restore possible
• Tier 4: weekly backup, tape or archive tier in the cloud

5. Quarterly tests and annual full scenario

Tests are the most important effectiveness control: § 30(2) no. 6 BSIG requires concepts and procedures to assess the effectiveness of the measures. The following plan is a practice recommendation, not a statutory deadline. It supplements the exercise rhythm of the BCM guide (restore test every quarter, tabletop exercise at least annually, live test every two years) with one focus per quarter.

Annual full scenario

• Realistic scenario (e.g. total data-centre outage, ransomware with data exfiltration)
• Full activation of the crisis team and the recovery team
• Simulation of communications with the supervisory authority and the media
• At least four hours of exercise time, for critical environments also several days
• External observation (auditor, insurer, adviser)
• Record with findings, lessons learned and corrective-action plan

Test documentation

Per test: date, participants, scenario, sequence, findings, measured RTO and RPO values, corrective actions with deadline and owner. These records are at the same time one piece of evidence for the documentation obligation under § 30(1) BSIG.

6. Ransomware: the most important special scenario

For ransomware the DR plan needs its own technical safeguards so that the backup survives the attack. The basics of the 3-2-1 rule and types of backup are in the glossary under Backup Strategy.

• Immutable backups: backups that cannot be overwritten or deleted during the retention period (e.g. hardened backup repositories or object storage with deletion lock) — active malware cannot alter them
• Backup isolation: backup infrastructure in its own administrative tier (separate Active Directory tier), without a trust relationship to the production domain
• Air-gap backups: copies regularly disconnected from the network (tape, external media in a safe)
• Recovery hardware on standby: clean systems for the restart after forensic clearance

The procedure in an emergency — isolate rather than power off, forensics before the restore, reports, criminal complaint and management's position on the ransom question documented in advance (practice recommendation: do not pay) — is described in the Ransomware Recovery 72h plan.

7. Documentation and audit evidence

§ 30(1) BSIG requires compliance with the measures to be documented. The BSI can order individual particularly important entities to undergo audits, inspections or certifications by independent bodies (§ 61(1) BSIG) and can require evidence from other particularly important entities three years after the Act's entry into force at the earliest (§ 61(3) BSIG). Where facts justify the assumption that an important entity is not implementing its obligations or not implementing them correctly, the BSI can review compliance and take measures under § 61 (§ 62 BSIG). Operators of critical installations provide evidence of implementation at a time set by the BSI, at the earliest three years after they were first classified as such, and every three years thereafter (§ 39(1) BSIG).

For an inspection, the following DR evidence should be available (practice recommendation):

1. Current DR plan (version less than 12 months old)
2. Business impact analysis with service classification
3. RTO/RPO matrix per service
4. Test records for the last 12 months (quarterly tests and annual exercise)
5. Backup concept with immutable component
6. Crisis-team list, current and with 24/7 reachability
7. Communication templates for supervisory authority, customers and media
8. Lessons learned from actual incidents in the last 24 months
9. Approval of the current version by management

Typical gaps are an outdated plan, tests only "on paper", roles not updated after personnel changes, missing immutable backups and a crisis team without 24/7 reachability. Such gaps are hard to evidence as an effective measure under § 30(1) BSIG. Infringements of the risk management obligations can be fined under § 65(5) BSIG with up to EUR 10 million for particularly important entities and up to EUR 7 million for important entities; only where total turnover exceeds EUR 500 million is a fine of up to 2% or 1.4% of the undertaking's worldwide total turnover possible instead (§ 65(6) to (8) BSIG). Management must implement the measures and supervise their implementation; if it breaches this duty, it is liable to the entity for culpably caused damage (§ 38(1) and (2) BSIG).

In Austria, § 45(2) and (3) NISG 2026 provide for up to EUR 10 million or 2% of worldwide annual turnover (essential entities) or up to EUR 7 million or 1.4% (important entities), whichever is higher. There, the risk management measures implemented must be submitted to the Federal Office for Cybersecurity by self-declaration within twelve months of the registration obligation arising (§ 33(1) NISG 2026).

The NIS2 Kit contains four Word templates in module 05 "Business Continuity and Crisis": Business Continuity Policy, Backup and Recovery Concept, Disaster Recovery Plan, and Crisis Management and Communication.