Disaster Recovery Plan nach NIS2: Vorlage + RTO/RPO

Ein Disaster Recovery Plan (DR-Plan) ist eines der zentralen Pflicht-Dokumente nach NIS2. Art. 21 Abs. 2 Buchst. c NIS-2-Richtlinie verlangt Maßnahmen zur „Aufrechterhaltung des Betriebs, etwa Backup-Management und Wiederherstellung nach Vorfällen, sowie Krisenmanagement". § 30 Abs. 2 Nr. 3 BSIG übernimmt diese Formulierung. Ohne DR-Plan ist NIS2-Compliance nicht möglich. Dieser Leitfaden zeigt die geforderte Struktur, fünf typische Szenarien, RTO/RPO-Werte pro Service-Klasse und die Test-Frequenz.

1. Was NIS2 Art. 21(2)(c) und § 30 Abs. 2 Nr. 3 BSIG verlangen

Art. 21 Abs. 2 Buchst. c der NIS-2-Richtlinie lautet im deutschen Wortlaut: „Aufrechterhaltung des Betriebs, etwa Backup-Management und Wiederherstellung nach Vorfällen, sowie Krisenmanagement". § 30 Abs. 2 Nr. 3 BSIG übernimmt diese Formulierung sinngemäß.

Konkret bedeutet das drei Pflicht-Bausteine:

1. Backup-Management: dokumentierte Strategie, regelmäßige Sicherungen, Test der Wiederherstellbarkeit
2. Wiederherstellung nach Vorfällen: technische und organisatorische Verfahren für die Recovery
3. Krisenmanagement: Krisenstab, Kommunikation, Entscheidungs- und Eskalationswege

Der DR-Plan ist die operative Umsetzung dieser drei Bausteine. Er wird flankiert vom BCM-Plan (strategische Geschäftsfortführung), Backup-Konzept (technische Sicherungs-Strategie) und Incident-Response-Plan (Vorfallbewältigung). Querverweis: BCM Business Continuity nach NIS2.

Verhältnis zu DORA und sektor-spezifischen Anforderungen

Banken und Finanzdienstleister unterliegen zusätzlich DORA (Verordnung (EU) 2022/2554) mit eigenen ICT-Risk-Management-Anforderungen. Krankenhäuser haben zusätzliche Vorgaben aus dem KHZG. Energieversorger müssen die § 11 EnWG- und IT-Sicherheitskatalog-Vorgaben erfüllen. Der DR-Plan ist die gemeinsame Grundlage, sektor-Spezifika werden additiv abgedeckt.

2. DR-Plan-Struktur

Ein Audit-fester DR-Plan enthält folgende Abschnitte:

Abschnitt 1: Geltungsbereich und Aktivierung

• Welche Systeme, Prozesse, Standorte sind abgedeckt?
• Wer aktiviert den Plan (Krisenstab, IT-Leitung, GF)?
• Aktivierungs-Kriterien: messbare Schwellenwerte (z. B. „Ausfall > 4h", „Bestätigte Datenexfiltration", „Verschlüsselte Server > 5")
• Alarmierungs-Verfahren: 24/7-Hotline, Eskalations-Telefonliste

Abschnitt 2: Rollen und Verantwortlichkeiten

• Krisenstab: Leitung, Stellvertretung, Mitglieder, Erreichbarkeit
• IT-Recovery-Team: Verantwortliche pro System-Cluster
• Kommunikations-Verantwortliche (interne / Aufsicht / Kunden / Medien)
• Externe Partner: IT-Forensik, Anwaltskanzlei, PR-Agentur, Cyberversicherer

Abschnitt 3: Szenarien

Pro Szenario: Auslöser, Auswirkungen, Sofortmaßnahmen, Recovery-Vorgehen, Spezial-Anforderungen.

Abschnitt 4: RTO/RPO-Matrix

Pro Service/Anwendung: Tier-Klassifikation, RTO, RPO, abhängige Systeme, Wiederanlauf-Reihenfolge.

Abschnitt 5: Recovery-Verfahren

• Technische Verfahren (Restore-Skripte, Failover-Prozeduren, Cloud-Failover)
• Abhängigkeits-Reihenfolge (DNS → AD → Datenbank → Anwendung)
• Validierungs-Tests nach Wiederherstellung
• Übergabe an Normalbetrieb

Abschnitt 6: Kommunikation

• Interne Kommunikation: Mitarbeiter, Betriebsrat
• Aufsichtsbehörden: BSI 24h/72h/1M-Frist nach Art. 23 NIS-2-Richtlinie und § 32 BSIG (Querverweis: NIS2 Meldewege)
• Kunden und Vertragspartner
• Medien, Öffentlichkeit (bei großen Vorfällen)
• Vorbereitete Sprachregelungen (Holding-Statements)

Abschnitt 7: Tests und Übungen

• Test-Plan mit Frequenz pro Szenario
• Test-Protokoll-Vorlage
• Findings-Tracking und Korrekturmaßnahmen-Plan

Abschnitt 8: Pflege und Aktualisierung

• Review-Zyklus (mindestens jährlich)
• Trigger für anlassbezogene Aktualisierungen
• Verantwortliche für Pflege

3. 5 typische Szenarien im Detail

Szenario 1: Ransomware-Angriff

• Auslöser: Verschlüsselung kritischer Systeme, oft kombiniert mit Datenexfiltration
• Auswirkungen: Produktions-/Geschäftsstillstand, Reputationsschaden, mögliche Lösegeld-Forderung
• Sofortmaßnahmen: Krisenstab aktivieren, infizierte Systeme isolieren (Netzwerk-Trennung, nicht ausschalten — Forensik!), IT-Forensik beauftragen, BSI-Meldung 24h
• Recovery-Strategie: Wiederherstellung aus Immutable Backups, NICHT aus möglicherweise infizierten Snapshots
• Spezial: Lösegeld-Politik vorab festgelegt (Empfehlung: nicht zahlen, aber im DR-Plan dokumentiert), Strafanzeige bei LKA Cybercrime

Details: Ransomware-Recovery 72h-Plan.

Szenario 2: Rechenzentrums-Ausfall

• Auslöser: Brand, Stromausfall > USV-Kapazität, Wasser, Klima-Ausfall, physische Beschädigung
• Auswirkungen: Komplettausfall lokal gehosteter Systeme
• Sofortmaßnahmen: Failover auf Sekundär-RZ aktivieren, Mitarbeiter informieren, Service-Provider benachrichtigen
• Recovery-Strategie: Aktiv-Aktiv-Cluster (hot standby) oder Aktiv-Passiv (warm standby) mit dokumentierter Failover-Procedure
• Spezial: physische Zutritts-Sperre und Beweissicherung bei Brand-Verdacht

Szenario 3: Cloud-Hyperscaler-Ausfall

• Auslöser: AWS-, Azure-, GCP- oder Microsoft-365-Ausfall in genutzter Region
• Auswirkungen: Abhängigkeitsgrad bestimmt Auswirkung — von partiell (E-Mail kurzzeitig down) bis Total (vollständige SaaS-Abhängigkeit)
• Sofortmaßnahmen: Status-Page des Anbieters prüfen, eigene Status-Kommunikation, Workaround-Aktivierung (z. B. lokale Tools, Telefon statt Teams)
• Recovery-Strategie: Multi-Region (innerhalb Anbieter), Multi-Cloud (über Anbieter hinweg) — Kosten/Nutzen-Abwägung dokumentieren
• Spezial: Cloud-Anbieter-SLA prüfen, Schadensersatz-Ansprüche dokumentieren

Querverweis: NIS2 für Cloud-Provider und SaaS-Anbieter.

Szenario 4: Insider-Angriff oder unberechtigter Zugriff

• Auslöser: böswilliger Mitarbeiter, Privileged-Account-Kompromittierung, unberechtigte Zugriffe
• Auswirkungen: Datenmanipulation, Datenexfiltration, Sabotage
• Sofortmaßnahmen: Konto-Sperre, Forensik einschalten, Personalrat einbeziehen (bei Mitarbeiter), Kommunikation mit Strafverfolgung
• Recovery-Strategie: Wiederherstellung manipulierter Daten aus integren Backups, vollständige Audit-Trail-Auswertung
• Spezial: arbeitsrechtliche Maßnahmen, Mitbestimmung, Beweissicherung mit Mitarbeiter-Schutz nach BDSG

Szenario 5: Naturkatastrophe oder höhere Gewalt

• Auslöser: Hochwasser, Erdbeben, Sturm, Pandemie, langanhaltender Stromausfall
• Auswirkungen: regionale Ausfälle, ggf. Personalausfall, physische Schäden
• Sofortmaßnahmen: Personal-Sicherheit zuerst, Standort-Räumung wenn nötig, Notfall-Arbeitsplätze aktivieren
• Recovery-Strategie: Geographisch verteiltes RZ, Cloud-Failover, Home-Office-Fähigkeit, alternative Standorte
• Spezial: Versicherungs-Anspruch frühzeitig anmelden, Behörden-Kommunikation (Krisenstab Stadt/Land)

4. RTO/RPO pro Service-Klasse

RTO (Recovery Time Objective) ist die maximale akzeptable Wiederherstellungs-Dauer. RPO (Recovery Point Objective) ist der maximale akzeptable Datenverlust (Zeit zwischen letzter Sicherung und Vorfall).

Die Zuordnung pro Service erfolgt in der Business-Impact-Analyse (BIA) als Vorstufe zum DR-Plan. Die BIA quantifiziert: Was kostet uns Stillstand pro Stunde? Welche Geschäftsprozesse hängen daran?

Technische Implikationen pro Tier

• Tier 1: synchrone Replikation, Active-Active-Cluster, Hot-Standby — teuer, aber für Verfügbarkeits-kritische Systeme nötig
• Tier 2: asynchrone Replikation, Warm-Standby, schnelles Restore aus heißem Backup
• Tier 3: tägliche Backups (Snapshot/Cloud), Cold-Restore möglich
• Tier 4: wöchentliches Backup, Tape oder Archive-Tier in Cloud

5. Quartals-Tests und jährliches Vollszenario

Tests sind die wichtigste Wirksamkeits-Kontrolle. Ohne dokumentierte Tests ist der DR-Plan im Audit wertlos.

Quartalsweise Teil-Tests

Jährliches Vollszenario

• Realistisches Szenario (z. B. RZ-Total-Ausfall, Ransomware mit Datenexfiltration)
• Vollständige Aktivierung Krisenstab und Recovery-Team
• Simulation von Aufsichts-Kommunikation und Medienanfragen
• Mindestens 4 Stunden Übungsdauer, idealerweise mehrere Tage über Wochenende
• Externe Beobachtung (Auditor, Versicherer, Berater)
• Protokoll mit Findings, Lessons Learned, Korrekturmaßnahmen-Plan

Test-Dokumentation

Pro Test: Datum, Teilnehmer, Szenario, Ablauf, Findings, gemessene RTO/RPO-Werte, Korrekturmaßnahmen mit Frist und Verantwortlichen.

6. Ransomware: das wichtigste Sonder-Szenario

Ransomware ist seit Jahren das Top-Bedrohungsszenario in BSI-Lageberichten. Der DR-Plan muss spezifische Mechanismen vorsehen:

• Immutable Backups: Veeam Hardened Repository, S3 Object Lock, Azure Immutable Blobs — nicht infizierbar durch laufende Schadsoftware
• Backup-Isolation: Backup-Infrastruktur in separatem AD-Tier, ohne Standard-Domain-Trust
• Air-Gap-Backups: regelmäßig offline-genommene Kopien (Tape, externe HDD im Tresor)
• Recovery-Hardware on standby: bereinigte Systeme für Wiederanlauf nach Forensik-Freigabe
• Forensische Prozesse: Indicators of Compromise (IoC) dokumentieren, kompromittierte Backups identifizieren
• Lösegeld-Politik: vorab Position der GF dokumentiert, ENISA-Empfehlung: keine Zahlung
• Krisenkommunikation: BSI 24h-Meldung, ggf. Aufsichtsbehörde Datenschutz (DSGVO Art. 33 — bei Datenexfiltration)

Detailliert: Ransomware-Recovery 72h-Plan.

7. Dokumentation und Audit-Nachweis

Im BSI-Audit nach § 31 BSIG werden folgende DR-Plan-Nachweise erwartet:

1. Aktueller DR-Plan (Version < 12 Monate alt)
2. Business-Impact-Analyse mit Service-Klassifikation
3. RTO/RPO-Matrix pro Service
4. Test-Protokolle der letzten 12 Monate (Quartals-Tests + Jahres-Übung)
5. Backup-Konzept mit Immutable-Komponente
6. Krisenstab-Liste aktuell, mit 24/7-Erreichbarkeit
7. Kommunikations-Vorlagen für Aufsicht, Kunden, Medien
8. Lessons-Learned aus tatsächlichen Vorfällen der letzten 24 Monate
9. Management-Freigabe aktueller Version

Häufigster Audit-Findings: veralteter Plan, Tests nur „auf dem Papier", fehlende Aktualität bei Personalwechsel, fehlende Immutable-Backup-Komponente, keine 24/7-Erreichbarkeit des Krisenstabs. Diese Mängel werden vom BSI als „strukturelle Defizite" gewertet und können nach § 38 BSIG mit Bußgeldern bis 10 Mio. EUR / 2 % Konzern-Umsatz sanktioniert werden.