Was dieser Deep Dive Ihnen zeigt
Wie Business Continuity und ICT Continuity Testing unter DORA zusammenhängen, welche Reifegrade es gibt – und warum Continuity kein IT-Thema allein ist. Von der statischen Planung zur realistischen Resilienz.
Business Continuity wurde lange vor allem technisch verstanden: als Backup-Strategie oder als Wiederherstellung von Daten und Systemen. DORA erweitert diesen Ansatz grundlegend und schafft damit einen neuen Erwartungshorizont.
Unternehmen müssen nachweisen, dass sie kritische Geschäftsprozesse auch bei Störungen aufrechterhalten oder innerhalb akzeptabler Zeit wieder aufnehmen können – unabhängig von Ursache und Ort der Störung. Backups bleiben notwendig, sind aber nur ein Baustein, nicht das Resilienzkonzept selbst.
1. Disaster Recovery vs. Business Continuity – Wo liegt der Unterschied?
Disaster Recovery (DR) beantwortet die technische Frage: Wie stellen wir Systeme und Daten wieder her?
Business Continuity (BC) beantwortet die operative Frage: Wie halten wir kritische Funktionen aufrecht oder stellen sie wieder her – unabhängig von den zugrunde liegenden Systemen?
Einordnung
DORA verlangt beides. Aber DR und BC sind nicht identisch. Ein erfolgreicher Daten-Restore garantiert nicht, dass die Geschäftsfunktion funktioniert.
2. Drei Reifegrade im Business Continuity Management
A) Dokumentiertes BCM (veraltet)
Formale Dokumente (z. B. Word-Dateien oder Notfallanhänge)
Statische Notfallpläne, selten aktualisiert
Keine technische Verzahnung mit realen Systemen
Keine realistischen Tests
Einordnung
Für die Anforderungen von DORA ist ein rein dokumentenbasiertes BCM nicht ausreichend.
B) Prozessbasiertes BCM (mittlerer Reifegrad)
Priorisierte Geschäftsprozesse definiert
Definierte RTO- und RPO-Werte
Punktuelle Übungen oder Simulationen
Häufig lückenhafte Verzahnung bei technischen Abhängigkeiten und realen Failover-Tests
Einordnung
Dieser Ansatz schafft Struktur, reicht für DORA-Prüfungen aber oft nicht aus, wenn Tests zu selten stattfinden oder zu theoretisch ausfallen.
C) Resilienzorientiertes BCM (DORA-orientierter Ansatz)
Eindeutiges Mapping auf kritische oder wichtige Funktionen
End-to-End-Betrachtung statt isolierter Maßnahmen
Einbindung von Cloud- und Systemarchitektur
Realistische Tests: Failover, Wiederanlauf, Krisenkommunikation – nicht nur Szenarien durchsprechen
Verzahnung mit IAM, Logging, Incident Management und Security Testing
Nachweis der Wirksamkeit, nicht nur der Existenz von Maßnahmen
3. Welche Anforderungen sich aus DORA ergeben
Kritische oder wesentliche Funktionen eindeutig identifiziert
Klare, realistische RTO- und RPO-Werte für diese Funktionen
End-to-End-Betrachtung kritischer Prozesse – von der Eingabe bis zur Ausgabe
Technische und organisatorische Wiederanlaufpläne
Regelmäßige, realistische Tests. DORA (Art. 11 Abs. 6) verlangt mindestens jährliche Tests der Business-Continuity- und Response-/Recovery-Pläne sowie zusätzliche Tests bei wesentlichen Änderungen. Häufiger (etwa halb- oder vierteljährlich) ist als risikobasierte Best Practice sinnvoll, aber keine allgemeine DORA-Pflicht.
Tabletop-Übungen sind ein sinnvoller Baustein, ersetzen aber dort keine technischen Wiederherstellungs- oder Failover-Tests, wo deren tatsächliche Funktionsfähigkeit nachgewiesen werden muss
Testergebnisse dokumentiert, Lessons Learned systematisch eingearbeitet
Einbindung von Cloud-Failover und Drittdienstleistern
Verknüpfung mit Incident Management und ICT Risk Management
4. RTO und RPO – Realistisch definieren
RTO (Recovery Time Objective) ist die maximale Zeit, die eine Geschäftsfunktion offline sein darf.
RPO (Recovery Point Objective) ist der maximale Datenverlust, den die Organisation akzeptiert.
Einordnung
RTO und RPO sind sinnvoll, verlieren aber ohne Tests und Prozessbezug ihre Aussagekraft. Ein RTO von 2 Stunden ist unrealistisch, wenn der Wiederanlauf noch nie getestet wurde.
Typischer Fehler: RTOs werden abstrakt oder übertrieben optimistisch definiert. Ähnlich wird bei RPO häufig vergessen, dass die Konsistenz der Daten nach dem Restore gewährleistet sein muss.
5. Fallstudie: Das erfolgreiche Backup, das nichts gebracht hat
Ausgangssituation
Ein Finanzdienstleister verfügt über Backups nach Best Practice: täglich, mit Aufbewahrung nach Compliance-Vorgaben, auf mehreren Standorten gelagert. Ein Cybervorfall führt zur Verschlüsselung des Kernsystems. Das IT-Team reagiert beruhigt: „Die Backups sind vorhanden.“
Was tatsächlich passiert
Ein Restore ist grundsätzlich möglich. Aber:
Das System startet jedoch nicht – oder nur mit Fehlern
Ein abhängiges Altsystem wurde nie im Kontext getestet
Schnittstellen funktionieren nicht
Datenhistorien sind inkonsistent
Das Kundenportal bleibt offline
Entscheidungs- und Eskalationswege sind unklar
Einzelne Sicherungsstände enthielten bereits beschädigte oder inkonsistente Daten – dies zeigte sich erst bei der Wiederherstellung
Ergebnis
Drei Tage Betriebsunterbrechung. Potenzielle Meldepflicht unter DORA, Kundenbeschwerden, Reputationsschäden.
Ursachen
Backups wurden nie in realistischen Betriebsumgebungen getestet
Test- und Produktionsumgebung unterschieden sich wesentlich
Abhängigkeiten zu weiteren Systemen nicht dokumentiert
Restore- und Wiederanlaufrollen nicht geübt
Keine Szenarien für einen beschleunigten oder partiellen Restore definiert
6. Typische Mängel in DORA-Prüfungen
Unrealistische RTO- und RPO-Vorgaben
Fehlende Einbindung der technischen Architektur in BC-Szenarien
Cloud-Failover nie oder nur theoretisch getestet
Ungeübte Notfall- und Krisenprozesse
Fehlende Verzahnung mit Incident Management
Unklare Rollen und Verantwortlichkeiten bei Ausfällen
Fehlende Fallbacks bei Drittdienstleistern
Test-Häufigkeit nur formal erfüllt: die gesetzliche Mindestkadenz (jährlich) wird eingehalten, aber ohne risikobasierte Anpassung an tatsächliche Änderungen und kritische Funktionen
Keine automatisierte Dokumentation von Test-Ergebnissen
7. Wie Business Continuity unter DORA wirksam gestaltet wird
End-to-End-Prozessanalyse: Welche Systeme, Daten, Personen und Entscheidungswege sind erforderlich, damit der kritische Prozess funktioniert?
Klare Verantwortlichkeiten: Einbindung von IT, Operations, Legal, Risk Management und Management. Nicht nur IT-Problem.
Tests in realistischen Umgebungen: Nicht nur Daten-Restore, sondern funktionaler Wiederanlauf unter Bedingungen, die dem Ernstfall entsprechen.
Systematische Lessons Learned: Ergebnisse werden strukturell in Prozesse und Architektur zurückgeführt, nicht nur als punktuelle Anmerkungen.
Dokumentiertes Resilienzsystem: Nicht nur Pläne, sondern ein nachvollziehbares Zusammenspiel aus Architektur, Prozessen und Verantwortlichkeiten, das unter Druck funktioniert.
Board- und Management-Involvement: Entscheidungen über RTO, RPO und Notfall-Kommunikation sind strategisch, nicht nur operational. Bewährte Governance-Übung: Das Leitungsorgan bzw. die Krisenleitung wird in ausgewählte Szenarien einbezogen und trifft unter Zeitdruck dokumentierte Entscheidungen.
Praxis-Impuls
Resilienz entsteht nicht durch Backups – sondern durch getestete Strukturen, klare Entscheidungen und gelebte Prozesse.
Stellen Sie die Frage: Haben wir unseren Wiederanlauf je unter realen Bedingungen durchgeführt – nicht als Theorie, sondern als Übung? Und musste der Board-Vorsitzende dabei eine echte Entscheidung treffen?
Was bleibt
1
Continuity ist nicht Backup. DORA unterscheidet zwischen Disaster Recovery (Wiederherstellung von Systemen) und Business Continuity (Aufrechterhaltung von Funktionen). Beides ist gefordert, aber es ist nicht dasselbe.
2
Business Continuity Management entwickelt sich von der dokumentengetriebenen zur operativen Steuerung – der Reifegradsprung von Papier zu gelebter Resilienz ist nicht optional.
3
Tabletop-Übungen sind wertvoll für Krisenorganisation, Eskalation und Kommunikation, reichen aber nicht als alleiniger Nachweis, wo technische Wiederherstellung oder Failover belegt werden müssen – je nach Funktion durch Restore, Wiederanlauf, Umschaltung oder Ersatzprozesse. Die gesetzliche Mindestkadenz ist jährlich (Art. 11 Abs. 6); häufigere Tests sind risikobasierte Best Practice.
4
Continuity-Testing muss realistisch sein – auch hinsichtlich der Datenqualität nach dem Restore. Ein Backup-Test, der die Infrastruktur gar nicht belastet oder Datenkonsistenz ignoriert, ist nicht aussagekräftig.
5
Governance-Dimension: Wer entscheidet über Continuity? Das ist nicht die IT-Abteilung allein. Business Continuity ist eine strategische Entscheidung mit Kostenfolgen, die bis zum Board reicht – und der Board muss unter Stress entscheiden können.