Disaster Recovery Banking: Wenn Systeme ausfallen, zählt jede Sekunde

Disaster Recovery im Banking ist kein Thema für graue Theoriepapiere im Compliance-Ordner. Es ist das Szenario, das IT-Leiter nachts wachhält: Ein Rechenzentrum brennt, ein Ransomware-Angriff verschlüsselt die Kernbankendatenbank, oder ein simpler Konfigurationsfehler legt den Zahlungsverkehr lahm. Was dann passiert, entscheidet sich nicht im Notfall – sondern lange vorher.

Schauen wir uns an, was wirklich zählt.

Was ist Disaster Recovery im Banking – und warum ist es so kritisch?

Disaster Recovery (DR) im Banking bezeichnet den strukturierten Prozess, mit dem Finanzinstitute ihre IT-Systeme, Daten und Geschäftsprozesse nach einem unvorhergesehenen Ausfall wiederherstellen. Es ist der operative Kern jeder Business-Continuity-Strategie im Finanzsektor.

Banken und Finanzdienstleister sind dabei in einer besonders exponierten Lage. Kein anderer Sektor ist so stark auf Echtzeit-Datenverfügbarkeit angewiesen. Überweisungen, Wertpapierhandel, Kreditentscheidungen, Geldautomaten – alles hängt an Systemen, die rund um die Uhr laufen müssen. Ein Ausfall von vier Stunden ist für eine Produktionsfirma unangenehm. Für eine Bank kann er existenzbedrohend sein.

Hinzu kommt der regulatorische Druck. Mit der EU-Verordnung DORA (Digital Operational Resilience Act), die seit Januar 2025 verbindlich gilt, müssen alle Finanzunternehmen in der EU nachweisen, dass sie digitale Betriebsstörungen erkennen, bewältigen und sich davon erholen können. Wer das nicht kann, riskiert empfindliche Bußgelder.

RTO und RPO: Die zwei Kennzahlen, die alles entscheiden

Bevor man über Technologie spricht, muss man über Ziele sprechen. Zwei Begriffe dominieren jede seriöse DR-Planung im Finanzbereich:

• RTO (Recovery Time Objective): Die maximale Zeitspanne, in der ein System nach einem Ausfall wiederhergestellt sein muss. Beispiel: „Unser Kernbankensystem muss innerhalb von 2 Stunden wieder laufen."
• RPO (Recovery Point Objective): Der maximale Datenverlust, der toleriert werden kann – gemessen in Zeit. Beispiel: „Wir dürfen maximal 15 Minuten an Transaktionsdaten verlieren."

Diese Ziele klingen abstrakt, haben aber sehr konkrete Konsequenzen für die Infrastruktur. Ein RPO von 15 Minuten erfordert nahezu kontinuierliche Datenreplikation. Ein RTO von 30 Minuten macht einen Hot-Standby-Betrieb mit automatischem Failover nahezu zwingend.

Für kritische Bankensysteme – Zahlungsverkehr, Kernbankensystem, Wertpapierhandel – ist Tier 1 oder Tier 2 der Industriestandard. Für Nebensysteme wie interne HR-Tools kann Tier 3 ausreichen. Die Kunst liegt in der richtigen Klassifizierung.

Regulatorische Anforderungen: DORA, BaFin und was das konkret bedeutet

Regulatorik ist im Banking kein Hintergrundthema – sie ist der Treiber. Und seit 2025 hat sich die Lage nochmals verschärft.

DORA: Der neue Maßstab für digitale Resilienz

Der Digital Operational Resilience Act verpflichtet Finanzunternehmen zu einem ganzheitlichen ICT-Risikomanagement. Das umfasst explizit: Backup-Strategien, Wiederherstellungspläne, regelmäßige Tests dieser Pläne und die Meldung schwerwiegender IT-Vorfälle an die zuständige Aufsichtsbehörde. Kein Institut kann sich mehr darauf berufen, einen Plan zu haben – es muss nachweisen, dass der Plan auch funktioniert.

BaFin-Anforderungen (BAIT/VAIT)

Die Bankaufsichtlichen Anforderungen an die IT (BAIT) der BaFin fordern seit Jahren ein dokumentiertes Notfallmanagement. Konkret verlangt die BaFin: Notfallkonzepte für alle zeitkritischen Aktivitäten, regelmäßige Notfalltests und eine klare Eskalationskette. Wer die BAIT-Anforderungen erfüllt, hat eine gute Basis für DORA – aber nicht automatisch alle Lücken geschlossen.

Wer tiefer in die IT-Sicherheitsarchitektur einsteigen möchte, findet in unserem Artikel zu Cybersecurity im Banking wertvolle Ergänzungen – denn DR und Cybersecurity sind zwei Seiten derselben Medaille.

Technische Bausteine einer robusten DR-Architektur

Theorie ist gut. Aber was steckt technisch hinter einer wirklich belastbaren Disaster-Recovery-Lösung im Finanzsektor?

Georedundante Rechenzentren

Das Fundament jeder ernsthaften DR-Strategie im Banking ist die geografische Trennung. Zwei Rechenzentren im selben Gebäude schützen nicht vor Feuer oder Stromausfall. Die Mindestanforderung: zwei physisch getrennte Standorte, mindestens 50 Kilometer voneinander entfernt, mit unabhängiger Stromversorgung und Netzanbindung.

Viele Institute setzen inzwischen auf drei Standorte: Primär, Sekundär und ein Cloud-basierter Tertiary-Standort. Das erhöht die Resilienz erheblich – und macht gleichzeitig die Cloud-Infrastruktur zu einem strategischen Bestandteil der DR-Architektur.

Datenreplikation und Backup-Strategien

Synchrone Replikation überträgt jeden Schreibvorgang gleichzeitig auf beide Standorte – kein Datenverlust, aber höhere Latenz. Asynchrone Replikation ist schneller, akzeptiert aber ein kleines Datenverlust-Fenster. Für Kernbankensysteme ist synchrone Replikation Standard; für weniger kritische Systeme reicht oft asynchrone.

Backups allein sind keine DR-Strategie. Sie sind die letzte Verteidigungslinie – nicht die erste.

Netzwerk-Resilienz

Ein DR-Rechenzentrum nützt nichts, wenn die Netzwerkverbindung zum Primärstandort der einzige Weg dorthin ist. Redundante Netzwerkpfade über verschiedene Provider, automatisches Routing-Failover und dedizierte WAN-Verbindungen sind Pflicht. Mehr dazu erklärt unser Artikel zur Netzwerk-Infrastruktur im Banking.

Den Business Continuity Plan aufbauen: Schritt für Schritt

Ein Business Continuity Plan (BCP) ist das übergeordnete Dokument, das beschreibt, wie das Unternehmen im Krisenfall weiterarbeitet. Der Disaster Recovery Plan ist ein Teil davon – der technische Teil. So baut man beides strukturiert auf:

1. Business Impact Analysis (BIA) durchführen: Identifiziere alle kritischen Geschäftsprozesse und bewerte, welche Auswirkungen ein Ausfall hätte – finanziell, operativ und regulatorisch. Priorisiere danach.
2. RTO und RPO je System festlegen: Basierend auf der BIA definierst du für jedes System konkrete Wiederherstellungsziele. Diese Ziele sind die Grundlage für alle technischen Entscheidungen.
3. DR-Architektur entwerfen: Wähle den passenden DR-Tier für jedes System. Plane georedundante Standorte, Replikationsmechanismen und Failover-Prozesse.
4. Notfallprozesse dokumentieren: Erstelle detaillierte Runbooks für jeden Ausfallszenario. Wer macht was, in welcher Reihenfolge, mit welchen Zugangsdaten? Diese Dokumente müssen auch offline verfügbar sein.
5. Kommunikationsplan erstellen: Wer informiert wen? Kunden, Regulatoren, Presse – alle brauchen unterschiedliche Informationen zu unterschiedlichen Zeitpunkten. Definiere Eskalationsstufen und Verantwortlichkeiten.
6. Tests planen und durchführen: Tabletop-Übungen, Backup-Restore-Tests, partielle Failover-Tests und vollständige DR-Tests – in aufsteigender Frequenz und Komplexität. Mindestens einmal jährlich ein vollständiger Test.
7. Kontinuierlich verbessern: Jeder Test liefert Erkenntnisse. Jede Änderung an der IT-Infrastruktur muss im DR-Plan reflektiert werden. BCP und DRP sind lebende Dokumente, keine Einmalaufgabe.

Die digitale Transformation im Finanzsektor macht diesen Prozess gleichzeitig komplexer und dringlicher. Neue Systeme, neue Abhängigkeiten, neue Angriffsflächen – der BCP muss Schritt halten.

Die häufigsten Fehler – und wie man sie vermeidet

Nach Jahren in der Branche sieht man immer wieder dieselben Muster. Hier sind die fünf teuersten Fehler bei der DR-Planung im Banking:

• Fehler 1 – Backups testen, aber keinen Failover: Viele Institute wissen, dass ihre Backups funktionieren. Aber ob das DR-Rechenzentrum wirklich den Betrieb übernehmen kann? Ungetestet. Das ist wie eine Feuerwehr, die zwar Wasser hat, aber nie geübt hat, den Schlauch anzuschließen.
• Fehler 2 – Drittanbieter vergessen: Kernbankensysteme hängen an Dutzenden externer Dienstleister. Wenn der Zahlungsabwickler ausfällt, hilft das eigene DR-Rechenzentrum wenig. DORA adressiert das explizit: Auch Drittanbieter-Risiken müssen gemanagt werden.
• Fehler 3 – Dokumentation veraltet: Der DR-Plan wurde vor drei Jahren geschrieben. Seitdem hat sich die Infrastruktur grundlegend verändert. Im Ernstfall folgt das Team einem Plan, der nicht mehr zur Realität passt.
• Fehler 4 – Menschliche Faktoren ignorieren: Technik kann perfekt sein – wenn aber im Ernstfall niemand weiß, wer die Entscheidung trifft, den Failover auszulösen, verliert man wertvolle Zeit. Klare Verantwortlichkeiten und Entscheidungsbefugnisse sind genauso wichtig wie die Technik.
• Fehler 5 – Kosten vor Risiko stellen: DR kostet Geld. Aber der Vergleich muss lauten: Was kostet ein ungeplanter Ausfall von 24 Stunden? Gegen diese Zahl sieht jedes DR-Budget vernünftig aus.

Cloud und Hybrid-Ansätze: Moderne DR-Strategien für Finanzunternehmen

Die klassische DR-Architektur mit zwei eigenen Rechenzentren ist teuer und wartungsintensiv. Cloud-basierte DR-Ansätze – oft als „Disaster Recovery as a Service" (DRaaS) bezeichnet – bieten eine attraktive Alternative.

Der Vorteil: Keine Investitionskosten für ein zweites Rechenzentrum, flexible Skalierung, und moderne Cloud-Plattformen bieten native Replikations- und Failover-Funktionen. Der Nachteil: Regulatorische Anforderungen an Datensouveränität und Auslagerungsmanagement müssen sorgfältig geprüft werden. Nicht jede Cloud-Lösung erfüllt die BaFin-Anforderungen ohne zusätzliche Maßnahmen.

Der Hybrid-Ansatz – eigenes Primär-Rechenzentrum plus Cloud-DR – ist für viele mittelgroße Finanzinstitute der pragmatische Mittelweg. Er kombiniert Kontrolle mit Flexibilität und lässt sich schrittweise einführen.