Disaster Recovery — Definition und Bedeutung für die Cybersicherheit
Disaster Recovery ist die geplante technische Wiederherstellung von IT-Systemen, Daten und Infrastruktur nach einem schwerwiegenden Ausfall oder Cybervorfall. Für Unternehmen ist Disaster Recovery relevant, weil Art. 21 Abs. 2 Buchst. c der NIS2-Richtlinie Backup, Wiederherstellung nach Notfällen und Krisenmanagement ausdrücklich verlangt.
Was ist Disaster Recovery?
Disaster Recovery bezeichnet den technischen Teil der Notfallvorsorge nach einem Totalausfall. Gemeint sind konkrete Wiederanlaufpläne für Server, Anwendungen, Netzwerke, Cloud-Dienste, Identitätssysteme und Datenbanken, damit kritische Prozesse nach Brand, Stromausfall, Ransomware oder einem Ausfall des Rechenzentrums geordnet zurückkehren.
Im Unterschied zur Business Continuity konzentriert sich Disaster Recovery auf IT und Technik. Business Continuity organisiert den Geschäftsbetrieb insgesamt, also Ausweichprozesse, Kommunikation, Rollen und Prioritäten. Disaster Recovery beantwortet dagegen die operative Frage, welche Systeme zuerst wieder starten, welche Abhängigkeiten bestehen und wie lange die Wiederherstellung dauern darf.
Warum Disaster Recovery für NIS2-betroffene Unternehmen wichtig ist
Im Rahmen der NIS2-Richtlinie in Deutschland ist Disaster Recovery relevant, weil die Mindestmaßnahmen aus Art. 21 Abs. 2 Buchst. c nicht bei Backups enden. Die Vorschrift nennt Business Continuity, Backup-Management, Wiederherstellung nach Notfällen und Krisenmanagement ausdrücklich zusammen. Unternehmen müssen also nachweisen, dass sie Ausfälle nicht nur erkennen, sondern kritische IT auch kontrolliert wiederherstellen können.
Für die deutsche Umsetzung ist derselbe Gedanke in § 30 Abs. 2 Nr. 3 BSIG angelegt: Gefordert sind Backup-Management, Wiederherstellung nach Notfällen und Krisenmanagement als Teil des Risikomanagements. Fachlich passt dazu der BSI-Standard 200-4, der Business Continuity Management strukturiert und Disaster-Recovery-Verfahren als technischen Wiederanlauf konkretisiert.
Welche Bestandteile ein Disaster-Recovery-Plan enthalten sollte
Ein wirksamer Disaster-Recovery-Plan beschreibt nicht nur Sicherungen, sondern den tatsächlichen Wiederanlauf. Typische Bausteine sind:
- Kritische Systeme und Reihenfolge: Domain-Services, Netzwerk, Identitätsmanagement, ERP, E-Mail, Produktionssysteme oder Kundenportal werden nach definierter Priorität gestartet.
- RTO und RPO: Das Recovery Time Objective legt die maximal tolerierbare Ausfallzeit fest, das Recovery Point Objective den maximal akzeptablen Datenverlust.
- Verantwortlichkeiten und Eskalation: Es muss klar sein, wer entscheidet, wer technische Wiederherstellung ausführt und wann Dienstleister eingebunden werden.
- Wiederherstellungswege: On-Premises-Backups, Offsite-Sicherungen, Cloud-Snapshots, Ersatzhardware und Notfallzugänge müssen dokumentiert und erreichbar sein.
- Tests und Übungen: Ein Plan ohne Restore-Test ist kein belastbarer Nachweis. Erst Tests zeigen, ob RTOs realistisch sind.
Für mittelständische Unternehmen sind unterschiedliche RTOs üblich. Ein Kundenportal oder ein zentrales ERP kann ein Ziel von vier Stunden haben, E-Mail acht Stunden und ein internes Dateisystem 24 Stunden. Entscheidend ist nicht eine pauschale Zahl, sondern die Ableitung aus Geschäftsrisiken, Risikoanalyse und Abhängigkeiten.
Cloud-DR, Geo-Redundanz und reale Betriebsrisiken
Cloud-Hosting ersetzt Disaster Recovery nicht automatisch. Auch bei SaaS, IaaS oder Kubernetes-Umgebungen bleibt die Verantwortung bestehen, Wiederanlauf, Datenexporte, Identitäten, Konfigurationen und Abhängigkeiten zu planen. Cloud-DR bedeutet in der Praxis oft Multi-Region-Setups, replizierte Daten, Infrastruktur als Code und dokumentierte Failover-Abläufe.
Geo-Redundanz ist dabei ein wichtiges, aber kein ausreichendes Mittel. Zwei Regionen helfen nur, wenn Anwendungen zustandsfähig betrieben werden, Zugänge im Notfall verfügbar bleiben und die Wiederanlaufreihenfolge tatsächlich getestet wurde. Disaster Recovery hängt deshalb eng mit Backup-Strategie und Incident Response zusammen.
Praxisbeispiel aus einem deutschen Unternehmen
Ein deutscher Medizinproduktehersteller mit 280 Beschäftigten betreibt ERP, Qualitätsmanagement, CAD-Daten und ein Serviceportal für Kliniken. Nach einem Ransomware-Vorfall sind File-Server und virtuelle Maschinen verschlüsselt. Ohne dokumentierte Reihenfolge würden IT und Fachbereiche parallel an allem arbeiten und wertvolle Stunden verlieren.
Mit einem belastbaren Disaster-Recovery-Plan startet das Unternehmen dagegen zuerst Identitätsdienste, Netzwerk und Backup-Infrastruktur, danach ERP und Qualitätsmanagement, anschließend das Serviceportal. Für ERP gilt ein RTO von vier Stunden, für E-Mail acht Stunden und für das Intranet 24 Stunden. Genau diese Priorisierung reduziert Betriebsunterbrechung, erleichtert Kommunikation und verbessert die Nachweisfähigkeit gegenüber Aufsicht, Kunden und Versicherern.
Häufig gestellte Fragen
Was ist Disaster Recovery einfach erklärt?
Disaster Recovery ist der technische Wiederanlaufplan für den Ernstfall. Er legt fest, wie Systeme, Daten und Infrastruktur nach einem schweren Ausfall wiederhergestellt werden, in welcher Reihenfolge das geschieht und welche Zeiten dabei eingehalten werden müssen.
Welche Rolle spielt Disaster Recovery unter NIS2?
Disaster Recovery spielt unter NIS2 eine zentrale Rolle, weil Art. 21 Abs. 2 Buchst. c Business Continuity, Backup, Wiederherstellung nach Notfällen und Krisenmanagement ausdrücklich nennt. Für betroffene Unternehmen gehört DR daher zum Mindestniveau der Cybersicherheitsorganisation.
Disaster Recovery ist kein Zusatzdokument für Audits, sondern die technische Grundlage dafür, dass Ihr Unternehmen nach einem schweren Vorfall handlungsfähig bleibt. Wenn Sie NIS2-Pflichten, Rollenverständnis und Umsetzungswissen strukturiert aufbauen möchten, ist die NIS2-Schulung der passende nächste Schritt.