NIS2 Disaster Recovery Plan: Template + RTO/RPO

A disaster recovery plan (DR plan) is one of the central mandatory documents under NIS2. Article 21(2)(c) NIS2 Directive requires measures for "business continuity, such as backup management and disaster recovery, and crisis management". Section 30(2) no. 3 BSIG transposes this. NIS2 compliance is not possible without a DR plan. This guide shows the required structure, five typical scenarios, RTO/RPO values per service class, and test frequency.

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

Article 21(2)(c) of the NIS2 Directive reads: "business continuity, such as backup management and disaster recovery, and crisis management". Section 30(2) no. 3 BSIG transposes this in substance.

Concretely this means three mandatory building blocks:

1. Backup management: documented strategy, regular backups, verifiable restore
2. Disaster recovery: technical and organisational procedures for recovery
3. Crisis management: crisis team, communications, decision and escalation paths

The DR plan is the operational implementation of these three blocks. It is flanked by the BCM plan (strategic business continuity), backup concept (technical backup strategy) and incident response plan (incident handling). Cross-reference: BCM Business Continuity under NIS2.

Interplay with DORA and sector-specific requirements

Banks and financial-services firms are additionally subject to DORA (Regulation (EU) 2022/2554) with its own ICT risk-management requirements. Hospitals have additional rules from the German KHZG. Energy suppliers must meet Section 11 EnWG and the IT-Security Catalogue. The DR plan is the common foundation; sector specifics are covered additively.

2. DR plan structure

An audit-grade DR plan contains the following sections:

Section 1: Scope and activation

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

Section 2: Roles and responsibilities

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

Section 3: Scenarios

Per scenario: trigger, impact, immediate measures, recovery approach, special requirements.

Section 4: RTO/RPO matrix

Per service/application: tier classification, RTO, RPO, dependent systems, recovery sequence.

Section 5: Recovery procedures

• Technical procedures (restore scripts, failover procedures, cloud failover)
• Dependency sequence (DNS → AD → database → application)
• Validation tests post-recovery
• Handover to normal operations

Section 6: Communications

• Internal communications: staff, works council
• Supervisory authorities: BSI 24h/72h/1M under Article 23 NIS2 Directive and Section 32 BSIG (cross-reference: NIS2 reporting channels)
• Customers and contractual partners
• Media, public (for major incidents)
• Pre-prepared holding statements

Section 7: Tests and exercises

• Test plan with frequency per scenario
• Test record template
• Findings tracking and corrective-action plan

Section 8: Maintenance and updates

• Review cycle (at least annual)
• Triggers for event-driven updates
• Owner for maintenance

3. 5 typical scenarios in detail

Scenario 1: Ransomware attack

• Trigger: encryption of critical systems, often combined with data exfiltration
• Impact: production/business standstill, reputational damage, possible ransom demand
• Immediate measures: activate crisis team, isolate infected systems (network disconnection, do not power off — forensics!), engage IT forensics, BSI notification within 24h
• Recovery strategy: restore from immutable backups, NOT from potentially infected snapshots
• Specifics: ransom policy predefined (ENISA recommendation: do not pay, but document in DR plan), report to law enforcement

Details: Ransomware Recovery 72h Plan.

Scenario 2: Data-centre outage

• Trigger: fire, power outage exceeding UPS capacity, water, cooling failure, physical damage
• Impact: complete outage of locally hosted systems
• Immediate measures: activate failover to secondary DC, inform staff, notify service providers
• Recovery strategy: active-active cluster (hot standby) or active-passive (warm standby) with documented failover procedure
• Specifics: physical access lockdown and evidence preservation on suspected arson

Scenario 3: Cloud hyperscaler outage

• Trigger: AWS, Azure, GCP or Microsoft 365 outage in the region used
• Impact: depth depends on dependency — from partial (email briefly down) to total (full SaaS dependency)
• Immediate measures: check provider status page, own status communication, activate workarounds (e.g. local tools, phone instead of Teams)
• Recovery strategy: multi-region (within provider), multi-cloud (across providers) — cost/benefit trade-off documented
• Specifics: check cloud provider SLA, document damages claims

Cross-reference: NIS2 for cloud providers and SaaS.

Scenario 4: Insider attack or unauthorised access

• Trigger: malicious employee, privileged-account compromise, unauthorised access
• Impact: data manipulation, data exfiltration, sabotage
• Immediate measures: account lockout, engage forensics, involve works council (if employee), engage law enforcement
• Recovery strategy: restore manipulated data from integrity-preserved backups, full audit-trail analysis
• Specifics: labour-law measures, co-determination, evidence preservation with employee data protection (BDSG)

Scenario 5: Natural catastrophe or force majeure

• Trigger: flood, earthquake, storm, pandemic, prolonged power outage
• Impact: regional outages, possibly personnel loss, physical damage
• Immediate measures: personnel safety first, site evacuation if necessary, activate emergency workplaces
• Recovery strategy: geographically distributed DC, cloud failover, home-office capability, alternative sites
• Specifics: early insurance claims, authority communications (city/state crisis team)

4. RTO/RPO per service class

RTO (Recovery Time Objective) is the maximum acceptable recovery duration. RPO (Recovery Point Objective) is the maximum acceptable data loss (time between last backup and incident).

Service-level assignment happens in the business impact analysis (BIA) ahead of the DR plan. The BIA quantifies: what does downtime per hour cost us? Which business processes depend on it?

Technical implications per tier

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

5. Quarterly tests and annual full scenario

Tests are the most important effectiveness control. Without documented tests the DR plan is worthless in an audit.

Quarterly partial tests

Annual full scenario

• Realistic scenario (e.g. total DC outage, ransomware with data exfiltration)
• Full activation of crisis team and recovery team
• Simulation of supervisory communications and media inquiries
• At least 4 hours of exercise time, ideally multiple days over a weekend
• External observation (auditor, insurer, advisor)
• Minutes with findings, lessons learned, corrective-action plan

Test documentation

Per test: date, participants, scenario, sequence, findings, measured RTO/RPO values, corrective actions with deadlines and owners.

6. Ransomware: the most important special scenario

Ransomware has been the top threat scenario in BSI situation reports for years. The DR plan must provide for specific mechanisms:

• Immutable backups: Veeam Hardened Repository, S3 Object Lock, Azure Immutable Blobs — non-infectable by active malware
• Backup isolation: backup infrastructure in a separate AD tier, no default domain trust
• Air-gap backups: regularly taken offline copies (tape, external HDD in safe)
• Recovery hardware on standby: clean systems for restart after forensic clearance
• Forensic processes: document Indicators of Compromise (IoC), identify compromised backups
• Ransom policy: management position predefined; ENISA recommendation: no payment
• Crisis communications: BSI 24-hour notification, where relevant data-protection supervisor (GDPR Art. 33 in case of exfiltration)

Details: Ransomware Recovery 72h Plan.

7. Documentation and audit evidence

In a BSI audit under Section 31 BSIG the following DR-plan evidence is expected:

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

Most common audit findings: outdated plan, paper-only tests, lack of currency after personnel changes, missing immutable backup component, no 24/7 reachability of the crisis team. BSI treats these as "structural deficiencies" which can be sanctioned under Section 38 BSIG with fines up to EUR 10 million / 2% group turnover.