Disaster Recovery Plan nach NIS2: Vorlage + RTO/RPO

Hauptartikel: BCM nach NIS2 — Business Impact Analyse, Notfallplan und Krisenstab. Diese Seite ist die Vorlage für den technischen Teil daraus, den Disaster Recovery Plan.

Ein Disaster Recovery Plan (DR-Plan) beschreibt, wie eine Einrichtung IT-Systeme, Daten und Infrastruktur nach einem Notfall wiederherstellt. Diese Vorlage zeigt eine bewährte Gliederung in acht Abschnitten, fünf typische Szenarien, RTO/RPO-Werte pro Service-Klasse und einen Testplan. Den Gesamtüberblick über die NIS2-Pflichten gibt der NIS2-Leitfaden, weitere Vertiefungen stehen im NIS2-Wissensbereich.

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, wie Backup-Management und Wiederherstellung nach einem Notfall, und Krisenmanagement“. § 30 Abs. 2 Nr. 3 BSIG übernimmt diese Formulierung. Das Gesetz nennt damit drei Elemente:

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

Den Maßstab setzt § 30 Abs. 1 BSIG: Die Maßnahmen müssen geeignet, verhältnismäßig und wirksam sein, und die Einrichtung hat ihre Einhaltung zu dokumentieren. Einen „Disaster Recovery Plan“ oder RTO- und RPO-Werte schreibt das Gesetz nicht ausdrücklich vor; der DR-Plan ist aber der übliche Praxisstandard, mit dem sich Backup-Management und Wiederherstellung belegen lassen. Adressaten sind besonders wichtige und wichtige Einrichtungen; in Deutschland gilt das BSIG seit dem 06.12.2025 (BGBl. 2025 I Nr. 301) ohne allgemeine Übergangsfrist; die Pflichten nach § 30 BSIG gelten seither.

Der DR-Plan setzt die ersten beiden Elemente operativ um und stützt das dritte. Er steht neben BCM-Plan, Backup-Konzept und Incident-Response-Plan (Bewältigung von Sicherheitsvorfällen, § 30 Abs. 2 Nr. 2 BSIG). Die Einordnung in alle zehn Maßnahmenbereiche zeigt § 30 BSIG: 10 NIS2-Pflichtmaßnahmen.

Finanzsektor und Energie: andere Rechtsgrundlage

Für Finanzunternehmen nach Art. 2 Abs. 2 der Verordnung (EU) 2022/2554 (DORA) gelten die §§ 30, 31, 32, 35, 36, 38 und 39 BSIG nicht (§ 28 Abs. 6 Nr. 1 BSIG); ihre Pflichten zu Backup, Wiederherstellung und Krisenmanagement folgen nicht zusätzlich, sondern stattdessen aus DORA (Art. 11 und 12 der Verordnung (EU) 2022/2554) — dazu NIS2 + DORA für Banken und Finanzdienstleister. Wer Energieversorgungsnetze, Energieanlagen oder digitale Energiedienste nach dem Energiewirtschaftsgesetz betreibt und den §§ 5c bis 5e EnWG unterliegt, für den gelten die §§ 30, 31, 32, 35, 36, 38, 39, 61 und 62 BSIG nicht (§ 28 Abs. 5 Satz 1 Nr. 2 BSIG), außer wenn der Betrieb der Energieanlage nur eine Nebentätigkeit ist, beim Betrieb weiterer kritischer Anlagen oder bei weiteren Tätigkeiten einer anderen Einrichtungsart (§ 28 Abs. 5 Satz 2 und 4 BSIG) — dazu NIS2 in der Energieversorgung.

Österreich: dieselbe Pflicht im NISG 2026

Österreich (AT): In Österreich gilt statt des BSIG das NISG 2026 (BGBl. I Nr. 94/2025). § 32 Abs. 4 lit. c NISG 2026 verlangt mit demselben Wortlaut die „Aufrechterhaltung des Betriebs, wie Backup-Management und Wiederherstellung nach einem Notfall, und Krisenmanagement“. Anwendbar ist die Pflicht seit dem 01.10.2026 (§ 51 Abs. 2 NISG 2026). Erhebliche Cybersicherheitsvorfälle meldet die Einrichtung an das zuständige CSIRT (§ 34 Abs. 2 NISG 2026). Die Leitungsorgane haben die Einhaltung der Risikomanagementmaßnahmen sicherzustellen und zu beaufsichtigen (§ 31 NISG 2026); zuständige Behörde ist das Bundesamt für Cybersicherheit (§ 3a Abs. 1 NISG 2026). Die Gliederung dieser Vorlage passt auch dort; anzupassen sind Meldewege und Fundstellen. Mehr im Artikel NIS2 Österreich (NISG 2026).

2. DR-Plan-Struktur

Ein prüffähiger DR-Plan enthält die folgenden acht Abschnitte. Die Gliederung ist Praxis; das Gesetz schreibt keine Abschnitte vor.

Abschnitt 1: Geltungsbereich und Aktivierung

• Welche Systeme, Prozesse und Standorte sind abgedeckt?
• Wer aktiviert den Plan (Krisenstab, IT-Leitung, Geschäftsführung)?
• Aktivierungskriterien mit messbaren Schwellenwerten (z. B. „Ausfall > 4 h“, „bestätigter Datenabfluss“, „mehr als 5 verschlüsselte Server“)
• Alarmierungsverfahren: 24/7-Erreichbarkeit, Eskalations-Telefonliste

Abschnitt 2: Rollen und Verantwortlichkeiten

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

Abschnitt 3: Szenarien

Pro Szenario: Auslöser, Auswirkungen, Sofortmaßnahmen, Recovery-Vorgehen, Besonderheiten (siehe Abschnitt 3 dieses Artikels).

Abschnitt 4: RTO/RPO-Matrix

Pro Service oder Anwendung: Tier-Klassifikation, RTO, RPO, abhängige Systeme, Reihenfolge des Wiederanlaufs.

Abschnitt 5: Recovery-Verfahren

• Technische Verfahren (Restore-Skripte, Failover-Prozeduren, Cloud-Failover)
• Reihenfolge der Abhängigkeiten (DNS → Active Directory → Datenbank → Anwendung)
• Validierungstests nach der Wiederherstellung
• Übergabe an den Normalbetrieb

Abschnitt 6: Kommunikation

• Interne Kommunikation: Beschäftigte, Betriebsrat
• Aufsicht: Einen erheblichen Sicherheitsvorfall (§ 2 Nr. 11 BSIG) meldet die Einrichtung gestuft (24 h / 72 h / 1 Monat, § 32 Abs. 1 BSIG) an die gemeinsame Meldestelle von BSI und BBK; Ablauf und Inhalte: NIS2-Meldewege.
• Datenschutz: Sind personenbezogene Daten betroffen, läuft parallel die Meldung an die Datenschutz-Aufsichtsbehörde — unverzüglich und möglichst binnen 72 Stunden nach Bekanntwerden, außer die Verletzung führt voraussichtlich nicht zu einem Risiko (Art. 33 Abs. 1 DSGVO). Das gilt auch ohne Datenabfluss, denn auch Verlust oder Vernichtung von Daten ist eine Verletzung (Art. 4 Nr. 12 DSGVO). Bei voraussichtlich hohem Risiko sind zusätzlich die Betroffenen zu benachrichtigen (Art. 34 Abs. 1 DSGVO).
• Notfallkommunikation unabhängig von der ausgefallenen Infrastruktur; § 30 Abs. 2 Nr. 10 BSIG nennt gegebenenfalls gesicherte Notfallkommunikationssysteme innerhalb der Einrichtung
• Kunden und Vertragspartner, Medien und Öffentlichkeit (bei großen Vorfällen)
• Vorbereitete Sprachregelungen (Holding-Statements)

Abschnitt 7: Tests und Übungen

• Testplan mit Frequenz pro Szenario
• Vorlage für das Testprotokoll
• Findings-Tracking und Plan für Korrekturmaßnahmen

Abschnitt 8: Pflege und Aktualisierung

• Review-Zyklus (Praxisempfehlung: mindestens jährlich)
• Auslöser für anlassbezogene Aktualisierungen (Personalwechsel, neue Systeme, Lessons Learned)
• Verantwortliche für die Pflege

3. 5 typische Szenarien im Detail

Szenario 1: Ransomware-Angriff

Auslöser ist die Verschlüsselung kritischer Systeme, oft kombiniert mit Datenabfluss. Recovery-Quelle sind unveränderbare (immutable) Backups, nicht möglicherweise infizierte Snapshots; der Wiederanlauf beginnt erst nach forensischer Freigabe. Isolieren, Forensik, Meldungen und Strafanzeige beschreibt der Ransomware-Recovery 72h-Plan.

Szenario 2: Rechenzentrums-Ausfall

• Auslöser: Brand, Stromausfall über die USV-Kapazität hinaus, Wasser, Ausfall der Klimatisierung, physische Beschädigung
• Auswirkungen: Komplettausfall lokal betriebener Systeme
• Sofortmaßnahmen: Failover auf das Sekundär-Rechenzentrum, Beschäftigte informieren, Dienstleister benachrichtigen
• Recovery-Strategie: Aktiv-Aktiv-Cluster (Hot Standby) oder Aktiv-Passiv (Warm Standby) mit dokumentierter Failover-Prozedur
• Besonderheit: Zutrittssperre und Beweissicherung bei Brandverdacht

Szenario 3: Ausfall eines Cloud-Anbieters

• Auslöser: Ausfall von Infrastruktur-, E-Mail- oder Kollaborationsdiensten eines Cloud-Anbieters in der genutzten Region
• Auswirkungen: abhängig vom Grad der Abhängigkeit — von partiell (E-Mail kurzzeitig nicht erreichbar) bis total (vollständige SaaS-Abhängigkeit)
• Sofortmaßnahmen: Statusseite des Anbieters prüfen, eigene Statuskommunikation, Ausweichlösungen aktivieren (z. B. lokale Werkzeuge, Telefon statt Videokonferenz)
• Recovery-Strategie: Multi-Region beim selben Anbieter oder Multi-Cloud über Anbieter hinweg — Kosten-Nutzen-Abwägung dokumentieren
• Besonderheit: SLA des Anbieters prüfen, Schadensersatzansprüche dokumentieren

Die Anbietersicht beschreibt der Artikel NIS2 für Cloud-Provider und SaaS-Anbieter.

Szenario 4: Insider-Angriff oder unberechtigter Zugriff

• Auslöser: böswillige Beschäftigte, kompromittierte privilegierte Konten, unberechtigte Zugriffe
• Auswirkungen: Datenmanipulation, Datenabfluss, Sabotage
• Sofortmaßnahmen: Konten sperren, Forensik einschalten, bei Beschäftigten den Betriebsrat einbeziehen (im öffentlichen Dienst den Personalrat), Abstimmung mit den Strafverfolgungsbehörden
• Recovery-Strategie: manipulierte Daten aus integren Backups wiederherstellen, Audit-Trails vollständig auswerten
• Besonderheit: arbeitsrechtliche Maßnahmen, Mitbestimmung, Beweissicherung unter Wahrung des Beschäftigtendatenschutzes (in Deutschland ergänzend § 26 BDSG)

Szenario 5: Naturereignis oder höhere Gewalt

• Auslöser: Hochwasser, Sturm, Erdbeben, Pandemie, langanhaltender Stromausfall
• Auswirkungen: regionale Ausfälle, gegebenenfalls Personalausfall, physische Schäden
• Sofortmaßnahmen: Sicherheit der Beschäftigten zuerst, Räumung des Standorts wenn nötig, Notfall-Arbeitsplätze aktivieren
• Recovery-Strategie: geografisch verteilte Rechenzentren, Cloud-Failover, Homeoffice-Fähigkeit, Ausweichstandorte
• Besonderheit: Versicherungsansprüche frühzeitig anmelden, Kommunikation mit den örtlichen Krisenstäben

4. RTO/RPO pro Service-Klasse

RTO (Recovery Time Objective) ist die maximal hinnehmbare Wiederherstellungsdauer, RPO (Recovery Point Objective) der maximal hinnehmbare Datenverlust, gemessen als Zeit zwischen letzter Sicherung und Vorfall. Wie die Werte aus der Business Impact Analyse abgeleitet, unter der maximal tolerierbaren Ausfallzeit angesetzt und von der Geschäftsleitung freigegeben werden, beschreibt der BCM-Leitfaden im Abschnitt RTO und RPO definieren.

Die Stufen sind ein Praxisbeispiel. Der BCM-Leitfaden setzt in seiner Beispielmatrix etwa für einen Online-Shop ein RTO von 1 h an; welche Stufe ein Service bei Ihnen erhält, entscheidet allein Ihre Business Impact Analyse.

Technische Folgen pro Tier

• Tier 1: synchrone Replikation, Aktiv-Aktiv-Cluster, Hot Standby — aufwendig, aber für verfügbarkeitskritische Systeme nötig
• Tier 2: asynchrone Replikation, Warm Standby, schnelles Restore aus einem aktuellen Backup
• Tier 3: tägliche Backups (Snapshot oder Cloud), Cold Restore möglich
• Tier 4: wöchentliches Backup, Band oder Archivstufe in der Cloud

5. Quartals-Tests und jährliches Vollszenario

Tests sind die wichtigste Wirksamkeitskontrolle: § 30 Abs. 2 Nr. 6 BSIG verlangt Konzepte und Verfahren zur Bewertung der Wirksamkeit der Maßnahmen. Der folgende Plan ist eine Praxisempfehlung, keine gesetzliche Frist. Er ergänzt den Übungsrhythmus des BCM-Leitfadens (Restore-Test jedes Quartal, Tabletop-Übung mindestens jährlich, Live-Test alle zwei Jahre) um einen Schwerpunkt je Quartal.

Jährliches Vollszenario

• Realistisches Szenario (z. B. Totalausfall des Rechenzentrums, Ransomware mit Datenabfluss)
• Vollständige Aktivierung von Krisenstab und Recovery-Team
• Simulation der Kommunikation mit Aufsicht und Medien
• Mindestens vier Stunden Übungsdauer, bei kritischen Umgebungen auch mehrere Tage
• Externe Beobachtung (Prüfer, Versicherer, Berater)
• Protokoll mit Findings, Lessons Learned und Plan für Korrekturmaßnahmen

Test-Dokumentation

Pro Test: Datum, Teilnehmende, Szenario, Ablauf, Findings, gemessene RTO- und RPO-Werte, Korrekturmaßnahmen mit Frist und Verantwortlichen. Diese Protokolle sind zugleich ein Beleg für die Dokumentationspflicht nach § 30 Abs. 1 BSIG.

6. Ransomware: das wichtigste Sonder-Szenario

Für Ransomware braucht der DR-Plan eigene technische Vorkehrungen, damit die Sicherung den Angriff übersteht. Die Grundlagen zu 3-2-1-Regel und Sicherungsarten stehen im Glossar unter Backup-Strategie.

• Immutable Backups: Sicherungen, die im Aufbewahrungszeitraum nicht überschrieben oder gelöscht werden können (z. B. gehärtete Backup-Repositories oder Objektspeicher mit Löschsperre) — laufende Schadsoftware kann sie nicht verändern
• Backup-Isolation: Backup-Infrastruktur in einer eigenen Verwaltungsebene (eigener Active-Directory-Tier), ohne Vertrauensstellung zur Produktiv-Domäne
• Air-Gap-Backups: regelmäßig vom Netz getrennte Kopien (Band, externe Datenträger im Tresor)
• Recovery-Hardware in Bereitschaft: bereinigte Systeme für den Wiederanlauf nach forensischer Freigabe

Den Ablauf im Ernstfall — Isolieren statt Ausschalten, Forensik vor dem Restore, Meldungen, Strafanzeige und die vorab dokumentierte Position der Geschäftsleitung zur Lösegeldfrage (Praxisempfehlung: nicht zahlen) — beschreibt der Ransomware-Recovery 72h-Plan.

7. Dokumentation und Audit-Nachweis

§ 30 Abs. 1 BSIG verlangt, die Einhaltung der Maßnahmen zu dokumentieren. Das BSI kann gegenüber einzelnen besonders wichtigen Einrichtungen Audits, Prüfungen oder Zertifizierungen durch unabhängige Stellen anordnen (§ 61 Abs. 1 BSIG) und von anderen besonders wichtigen Einrichtungen frühestens drei Jahre nach Inkrafttreten des Gesetzes Nachweise verlangen (§ 61 Abs. 3 BSIG). Rechtfertigen Tatsachen die Annahme, dass eine wichtige Einrichtung ihre Pflichten nicht oder nicht richtig umsetzt, kann das BSI die Einhaltung überprüfen und Maßnahmen nach § 61 treffen (§ 62 BSIG). Betreiber kritischer Anlagen weisen die Umsetzung zu einem vom BSI festgelegten Zeitpunkt, frühestens drei Jahre nach ihrer erstmaligen Einstufung, und danach alle drei Jahre nach (§ 39 Abs. 1 BSIG).

Bei einer Prüfung sollten folgende DR-Nachweise vorliegen (Praxisempfehlung):

1. Aktueller DR-Plan (Version jünger als 12 Monate)
2. Business Impact Analyse mit Service-Klassifikation
3. RTO/RPO-Matrix pro Service
4. Testprotokolle der letzten 12 Monate (Quartals-Tests und Jahresübung)
5. Backup-Konzept mit Immutable-Komponente
6. Krisenstab-Liste, aktuell und mit 24/7-Erreichbarkeit
7. Kommunikationsvorlagen für Aufsicht, Kunden und Medien
8. Lessons Learned aus tatsächlichen Vorfällen der letzten 24 Monate
9. Freigabe der aktuellen Fassung durch die Geschäftsleitung

Typische Lücken sind ein veralteter Plan, Tests nur „auf dem Papier“, nicht nachgeführte Rollen nach Personalwechseln, fehlende Immutable-Backups und ein Krisenstab ohne 24/7-Erreichbarkeit. Solche Lücken sind schwer als wirksame Maßnahme nach § 30 Abs. 1 BSIG zu belegen. Verstöße gegen die Risikomanagementpflichten können nach § 65 Abs. 5 BSIG mit bis zu 10 Mio. EUR bei besonders wichtigen und bis zu 7 Mio. EUR bei wichtigen Einrichtungen geahndet werden; nur bei einem Gesamtumsatz von mehr als 500 Mio. EUR ist stattdessen eine Geldbuße bis 2 % bzw. 1,4 % des weltweiten Gesamtumsatzes des Unternehmens möglich (§ 65 Abs. 6 bis 8 BSIG). Die Geschäftsleitung muss die Maßnahmen umsetzen und ihre Umsetzung überwachen; verletzt sie diese Pflicht, haftet sie der Einrichtung für schuldhaft verursachte Schäden (§ 38 Abs. 1 und 2 BSIG).

In Österreich drohen nach § 45 Abs. 2 und 3 NISG 2026 bis 10 Mio. EUR oder 2 % des weltweiten Jahresumsatzes (wesentliche Einrichtungen) bzw. bis 7 Mio. EUR oder 1,4 % (wichtige Einrichtungen), je nachdem, welcher Betrag höher ist. Die umgesetzten Risikomanagementmaßnahmen sind dort binnen zwölf Monaten nach Eintritt der Registrierungspflicht per Selbstdeklaration an das Bundesamt für Cybersicherheit zu übermitteln (§ 33 Abs. 1 NISG 2026).

Das NIS2-Kit enthält im Modul 05 „Business Continuity und Krise“ vier Word-Vorlagen: Business Continuity Policy, Backup- und Wiederherstellungskonzept, Disaster Recovery Plan sowie Krisenmanagement und Kommunikation.