Wissensraum · Deep Dive 8 von 27

Business Continuity & ICT Continuity Testing unter DORA

Warum „wir haben Backups“ kein Resilienzkonzept ist

📋 17 Min 🎯 BC & ICT Continuity
Deep Dive 8 von 27

Was dieser Deep Dive Ihnen zeigt

Wie Business Continuity und ICT Continuity Testing unter DORA zusammenhängen, was die Testanforderungen konkret bedeuten – und warum Continuity kein IT-Thema allein ist.

RegulierungDORA
ThemaKontinuitätsansätze, RTO/RPO, Continuity Testing, Resilienz
KernfrageWas unterscheidet eine Backup-Strategie von einem Resilienzkonzept?
RelevanzOperations, IT, Management, Compliance
DORA-ArtikelArt. 11 DORA – Business Continuity Policy, Art. 24–26 – Testing

Business Continuity wurde lange vor allem technisch verstanden: als Backup-Strategie oder als Wiederherstellung von Daten und Systemen. DORA erweitert diesen Ansatz deutlich.

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. Gängige Continuity-Ansätze – und ihre Grenzen

A) Backup-zentrierter Ansatz

Daten sind vorhanden

Prozesse bleiben dennoch funktionsunfähig

Keine End-to-End-Betrachtung

Einordnung

Backups sichern Daten, aber nicht automatisch die Fähigkeit, Leistungen zu erbringen.

B) RTO-zentrierter Ansatz

Fokus auf Wiederanlaufzeiten

Häufig abstrakt oder unrealistisch definiert

Keine funktionalen Tests

Einordnung

RTOs sind sinnvoll, verlieren aber ohne Tests und Prozessbezug ihre Aussagekraft.

C) Prozessbasierte Business Continuity (DORA-orientierter Ansatz)

Definition kritischer Geschäftsprozesse

Sichtbarmachung technischer und organisatorischer Abhängigkeiten

Getestete Wiederanlaufszenarien

Klare Verantwortlichkeiten

Tests unter realistischen Bedingungen

2. Welche Anforderungen sich aus DORA ergeben

End-to-End-Betrachtung kritischer Prozesse

Klare RTO- und RPO-Werte für kritische oder wesentliche Prozesse

Technische und organisatorische Wiederanlaufpläne

Regelmäßige, realistische Tests

Testergebnisse dokumentiert

Lessons Learned systematisch eingearbeitet

Verknüpfung mit Incident Management und ICT Risk Management

3. Fallstudie

Fallstudie · Das erfolgreiche Backup, das nichts gebracht hat

Ausgangssituation

Ein Cybervorfall führt zur Verschlüsselung des Kernsystems eines Finanzdienstleisters. Das IT-Team reagiert beruhigt: „Die Backups sind vorhanden.“

Was tatsächlich passiert

Das Backup lässt sich technisch wiederherstellen

Das System startet jedoch nicht

Ein abhängiges Altsystem wurde nie getestet

Schnittstellen funktionieren nicht

Datenhistorien sind inkonsistent

Das Kundenportal bleibt offline

Ergebnis

Drei Tage Betriebsunterbrechung.

Ursachen

Backups wurden nie in realistischen Betriebsumgebungen getestet

Test- und Produktionsumgebung unterschieden sich wesentlich

Abhängigkeiten zu weiteren Systemen nicht dokumentiert

Entscheidungs- und Eskalationswege unklar

4. Wie Business Continuity unter DORA wirksam gestaltet wird

End-to-End-Prozessanalyse: Welche Systeme müssen verfügbar sein, damit der Prozess funktioniert?

Klare Verantwortlichkeiten: Einbindung von IT, Operations, Legal und Management.

Tests in realistischen Umgebungen: Nicht nur Daten-Restore, sondern funktionaler Wiederanlauf.

Systematische Lessons Learned: Ergebnisse werden strukturell in Prozesse und Architektur zurückgeführt.

Dokumentiertes Resilienzsystem: Nicht nur Pläne, sondern ein nachvollziehbares Zusammenspiel aus Architektur, Prozessen und Verantwortlichkeiten.

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?

Vier zentrale Learnings
1
Business Continuity und ICT Continuity Testing unter DORA sind nicht zwei separate Regime – sie sind integriert, und die Tests müssen beide Dimensionen abdecken.
2
Tabletop-Exercises genügen nicht mehr: DORA verlangt technische Failover-Tests, die tatsächliche Wiederherstellung demonstrieren, nicht nur Szenarien durchsprechen.
3
Das häufigste Problem ist die fehlende Test-Kadenz: Einmal pro Jahr reicht nicht aus. Moderne RTO/RPO-Anforderungen verlangen mindestens halbjährliche oder sogar quartalsweise Tests.
4
Continuity ist kein IT-Thema allein – der Board und die Geschäftsführung müssen in Test-Szenarien eingebunden sein, um ihre Entscheidungen unter Druck zu prüfen.

Weiter vertiefen

← Deep Dive 7Alle Deep DivesDeep Dive 9 →
← Wissensraum