---
title: "Disaster Recovery: Definition und Compliance-Leitfaden"
description: "Erfahren Sie, wie Sie Disaster-Recovery-Pläne erstellen und testen, die ISO 27001, SOC 2, NIS2 und DORA erfüllen. Behandelt RPO, RTO, DR-Strategien, Cloud-DR, Testansätze und Auditnachweise."
canonical: https://www.orbiqhq.com/de/glossar/disaster-recovery
html: https://www.orbiqhq.com/de/glossar/disaster-recovery
publisher: Orbiq GmbH
language: en
---
# Disaster Recovery: Definition und Compliance-Leitfaden

Erfahren Sie, wie Sie Disaster-Recovery-Pläne erstellen und testen, die ISO 27001, SOC 2, NIS2 und DORA erfüllen. Behandelt RPO, RTO, DR-Strategien, Cloud-DR, Testansätze und Auditnachweise.


## Was ist Disaster Recovery?

Disaster Recovery (DR) ist der strukturierte Ansatz zur Wiederherstellung von IT-Systemen, Anwendungen und Daten nach einem störenden Ereignis — ob Cyberangriff, Hardwareausfall, Naturkatastrophe oder menschlicher Fehler. Es verwandelt die Frage "Was passiert, wenn Systeme ausfallen?" in einen dokumentierten, getesteten und auditierbaren Prozess.

Ein ausgereiftes DR-Programm geht über Backup-Bänder in einem Safe hinaus. Es definiert Wiederherstellungsziele für jedes kritische System, implementiert angemessene technische Strategien, testet regelmäßig und liefert die Compliance-Nachweise, die Frameworks verlangen.

## Zentrale DR-Konzepte

| Konzept | Definition | Warum es wichtig ist |
| --- | --- | --- |
| **RPO (Recovery Point Objective)** | Maximal akzeptabler Datenverlust gemessen in Zeit | Bestimmt Backup-Häufigkeit und Replikationsstrategie |
| **RTO (Recovery Time Objective)** | Maximal akzeptable Ausfallzeit bis zur Wiederherstellung | Bestimmt Wiederherstellungsstrategie und Infrastrukturinvestition |
| **MTPD (Maximum Tolerable Period of Disruption)** | Längste Zeit, die das Unternehmen ohne ein System überleben kann | Setzt die obere Grenze für RTO |
| **BIA (Business Impact Analysis)** | Bewertung der Auswirkungen von Systemunverfügbarkeit | Treibt RPO/RTO-Entscheidungen und Systemkritikalitätsstufen |
| **DR-Plan** | Dokumentierte Verfahren zur Systemwiederherstellung | Operativer Leitfaden und Compliance-Nachweis |
| **Failover** | Umschalten des Betriebs auf die Standby-Umgebung | Eigentlicher Wiederherstellungsmechanismus |
| **Failback** | Rückkehr des Betriebs in die Primärumgebung | Wiederherstellung nach Behebung des Disasters |

## DR-Strategie-Stufen

| Strategie | RPO | RTO | Kosten | Funktionsweise |
| --- | --- | --- | --- | --- |
| **Backup und Restore** | Stunden bis Tage | Stunden bis Tage | Niedrigste | Regelmäßige Backups auf neuer Infrastruktur wiederherstellen |
| **Pilot Light** | Minuten bis Stunden | Stunden | Niedrig-mittel | Minimale Kerndienste laufen, bei Bedarf hochskalieren |
| **Warm Standby** | Minuten | Minuten bis Stunden | Mittel | Herunterskaliertes Replikat mit aktuellen Daten |
| **Hot Standby** | Sekunden bis Minuten | Minuten | Hoch | Vollständiges Replikat mit Echtzeit-Replikation |
| **Active-Active** | Nahezu null | Nahezu null | Höchste | Mehrere aktive Standorte teilen Last, automatisches Failover |

## Systemkritikalitäts-Klassifizierung

| Stufe | Beschreibung | Typisches RPO | Typisches RTO | Beispiele |
| --- | --- | --- | --- | --- |
| **Stufe 1 — Geschäftskritisch** | Systeme, deren Ausfall sofortigen Umsatzverlust oder Regulierungsverstoß verursacht | < 1 Stunde | < 1 Stunde | Zahlungsverarbeitung, Kerndatenbank, Authentifizierung |
| **Stufe 2 — Betriebskritisch** | Systeme, die den Betrieb erheblich beeinträchtigen | < 4 Stunden | < 4 Stunden | ERP, CRM, E-Mail, Primäranwendungen |
| **Stufe 3 — Betriebswichtig** | Systeme für den täglichen Betrieb, aber mit Workarounds | < 24 Stunden | < 24 Stunden | Dateifreigabe, interne Tools, Berichterstattung |
| **Stufe 4 — Unkritisch** | Systeme mit minimaler sofortiger Geschäftsauswirkung | < 72 Stunden | < 72 Stunden | Entwicklungsumgebungen, Archive |

## DR-Testansätze

| Testtyp | Umfang | Aufwand | Häufigkeit | Was validiert wird |
| --- | --- | --- | --- | --- |
| **Tabletop-Übung** | DR-Plan als Gruppendiskussion durchsprechen | Niedrig | Vierteljährlich | Planvollständigkeit, Teambewusstsein |
| **Walkthrough-Test** | Verfahren schrittweise durchgehen ohne Ausführung | Niedrig-mittel | Halbjährlich | Verfahrensgenauigkeit, Rollenzuweisungen |
| **Funktionstest** | Einzelne Wiederherstellungskomponenten testen | Mittel | Halbjährlich | Backup-Wiederherstellung, Failover-Mechanismen |
| **Vollständiger Failover-Test** | Kompletter Wechsel zur DR-Umgebung | Hoch | Jährlich | Ende-zu-Ende Wiederherstellungsfähigkeit |

## Compliance-Anforderungen

### Framework-Zuordnung

| Anforderung | ISO 27001 | SOC 2 | NIS2 | DORA |
| --- | --- | --- | --- | --- |
| DR/Kontinuitätsrichtlinie | A.5.29 | A1.2 | Art. 21(2)(c) | Art. 11(1) |
| Business Impact Analysis | A.5.29 | A1.2 | Art. 21(2)(c) | Art. 11(2) |
| Wiederherstellungsziele (RPO/RTO) | A.5.29 | A1.2 | Art. 21(2)(c) | Art. 11(3) |
| DR-Plan-Dokumentation | A.5.30 | A1.2 | Art. 21(2)(c) | Art. 11(4) |
| Regelmäßige DR-Tests | A.5.30 | A1.3 | Art. 21(2)(c) | Art. 11(6) |
| DR-Plan-Überprüfung und -Aktualisierung | A.5.30 | A1.3 | Art. 21(2)(c) | Art. 11(7) |
| Kommunikationsplan | A.5.30 | A1.2 | Art. 23 | Art. 14 |

### Auditnachweise

| Nachweistyp | Beschreibung | Framework |
| --- | --- | --- |
| Business Impact Analysis | Dokumentierte BIA mit Systemkritikalitätsstufen | Alle Frameworks |
| DR-Plan | Vollständiger, aktueller Plan mit Verfahren und Kontakten | Alle Frameworks |
| RPO/RTO-Definitionen | Dokumentierte Ziele pro System mit Geschäftsgenehmigung | Alle Frameworks |
| DR-Testergebnisse | Testberichte mit Ergebnissen, gefundenen Problemen, Behebung | Alle Frameworks |
| Backup-Verifizierung | Regelmäßige Backup-Wiederherstellungs-Testaufzeichnungen | ISO 27001, SOC 2 |
| Kommunikationsplan | Dokumentierte Eskalations- und Benachrichtigungsverfahren | NIS2, DORA |
| DR-Plan-Überprüfungsaufzeichnungen | Nachweis jährlicher Überprüfung und Aktualisierung | Alle Frameworks |

## Häufige Fehler

| Fehler | Risiko | Lösung |
| --- | --- | --- |
| Kein getesteter DR-Plan | Ungetesteter Plan versagt bei tatsächlichem Disaster | DR jährlich testen, gefundene Probleme beheben |
| RPO/RTO nicht geschäftsausgerichtet | Über- oder Unterinvestition in Wiederherstellungsfähigkeit | BIA mit Geschäftsverantwortlichen durchführen |
| Backup ohne Wiederherstellungstest | Backups können korrupt oder unvollständig sein | Backup-Wiederherstellung monatlich testen |
| Abhängigkeiten ignorieren | Wiederherstellung scheitert an nicht wiederhergestellten Abhängigkeiten | Alle Systemabhängigkeiten abbilden und dokumentieren |
| Kein Kommunikationsplan | Chaos während des Disasters, regulatorische Meldeversäumnisse | Kommunikationsverfahren dokumentieren und üben |
| DR-Plan nicht aktualisiert | Veralteter Plan referenziert stillgelegte Systeme | DR-Plan nach jeder größeren Änderung überprüfen und aktualisieren |

## Wie Orbiq Disaster-Recovery-Compliance unterstützt

Orbiq hilft Ihnen, Disaster-Recovery-Kontrollen nachzuweisen:

- **Evidenzsammlung** — BIA-Dokumente, DR-Pläne, Testergebnisse und Backup-Verifizierungsaufzeichnungen zentralisieren
- **Kontinuierliche Überwachung** — DR-Kontrolleffektivität und Testzeitpläne verfolgen
- **Trust Center** — Ihre Disaster-Recovery-Lage über Ihr [Trust Center](/de/glossar/trust-center) teilen
- **Compliance-Mapping** — DR-Kontrollen auf ISO 27001, SOC 2, NIS2 und DORA abbilden
- **Audit-Bereitschaft** — Vorgefertigte Evidenzpakete für die Auditorenprüfung

## Weiterführende Artikel

- [Business Continuity Planning](/de/glossar/business-continuity-planning) — Umfassendere organisatorische Resilienz
- [Incident Response](/de/glossar/incident-response) — Von der Vorfallerkennung zur Disaster-Erklärung
- [Verschlüsselung](/de/glossar/encryption) — Schutz von Backup-Daten und DR-Replikation
- [Cloud Security Posture Management](/de/glossar/cloud-security-posture-management) — Sicherheit der Cloud-DR-Infrastruktur
- [Risikomanagement-Frameworks](/de/glossar/risikomanagement-frameworks) — Risikokontext für DR-Investitionsentscheidungen