Wissensraum · Deep Dive 13 von 27
Wann Business Continuity heute als „ausreichend“ gilt
Was dieser Deep Dive Ihnen zeigt
Wann Business Continuity heute als „ausreichend“ gilt – und wo DORA die Messlatte höher legt.
Business Continuity Management (BCM) wurde lange als formale Pflicht verstanden – häufig in Form statischer Dokumente. DORA verschiebt diesen Ansatz grundlegend.
Unter DORA entwickelt sich BCM zu einem operativen Steuerungs- und Führungsinstrument. Im Mittelpunkt steht nicht mehr allein der Wiederanlauf nach einer Störung, sondern die Aufrechterhaltung kritischer Funktionen – auch unter Stress und in komplexen Ausfallszenarien. Resilienz wird damit zur Frage der tatsächlichen Handlungsfähigkeit, nicht der Dokumentation.
Formale Dokumente (z. B. Word-Dateien)
Statische Notfallpläne
Keine technische Verzahnung
Keine realistischen Tests
Einordnung
Für die Anforderungen von DORA ist ein rein dokumentenbasiertes BCM in der Regel nicht ausreichend.
Priorisierte Geschäftsprozesse
Definierte RTO- und RPO-Werte
Punktuelle Übungen oder Simulationen
Häufig lückenhaft bei technischen Abhängigkeiten und realen Tests
Einordnung
Dieser Ansatz schafft Struktur, reicht für DORA-Prüfungen jedoch oft nicht aus.
Eindeutiges Mapping auf kritische oder wesentliche Funktionen
End-to-End-Betrachtung statt isolierter Maßnahmen
Einbindung von Cloud- und Systemarchitektur
Realistische Tests (Failover, Wiederanlauf, Krisenkommunikation)
Verzahnung mit IAM, Logging, Incident Management und Testing
Nachweis der Wirksamkeit, nicht nur der Existenz von Maßnahmen
Kritische oder wesentliche Funktionen identifiziert
Klare RTO- und RPO-Werte für diese Funktionen
Operative Resilienz regelmäßig getestet
Interne und externe Krisenkommunikation berücksichtigt
Drittdienstleister einbezogen
Kontinuierliche Überprüfung und Verbesserung
Unrealistische RTO- und RPO-Vorgaben
Fehlende Einbindung der technischen Architektur
Cloud-Failover nie oder nur theoretisch getestet
Ungeübte Notfall- und Krisenprozesse
Fehlende Verzahnung mit Incident Management
Unklare Rollen und Verantwortlichkeiten
Fehlende Fallbacks bei Drittdienstleistern
Ausgangssituation
Ein FinTech speichert Kundendaten in einer Cloud-Datenbank mit täglichem Backup.
Was passiert
Im Rahmen eines Incidents müssen Daten wiederhergestellt werden. Dabei zeigt sich: Das Backup ist beschädigt. Der Recovery-Prozess wurde nie getestet. Verantwortlichkeiten sind unklar. Das Team verlässt sich auf einen vermeintlich automatischen Restore.
Konsequenzen
Daten sind über mehrere Stunden nicht verfügbar
Kritische Prozesse geraten ins Stocken
Potenzielle Meldepflicht unter DORA
Kundenbeschwerden und Reputationsschäden
Was gefehlt hat
Regelmäßige Restore- und Wiederanlauftests
Klare Verantwortlichkeiten im Krisenfall
Definierte Szenarien für Cloud- und Systemausfälle
Transparenz über technische Abhängigkeiten
Praxis-Impuls
Als „ausreichend“ gilt heute nur ein BCM, das im Ernstfall funktioniert, getestet ist und nachvollziehbar gesteuert wird. BCM wird operativ steuerbar – statt dokumentengetrieben. Die wichtigste Frage: Haben wir unsere kritischen Wiederanlaufszenarien je wirklich durchgespielt?
Was bleibt
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.
ICT Continuity ist nicht optional. Finanzinstitute müssen nachweisen, dass kritische ICT-Funktionen unter DORA auch bei Ausfall verfügbar bleiben – mit dokumentierten RTO und RPO.
Continuity-Testing muss realistisch sein. Ein Backup-Test, der die Infrastruktur gar nicht belastet, ist nicht aussagekräftig. DORA verlangt realistische Szenarien – inklusive Konsequenzen für die Geschäftstätigkeit.
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.