IT-Notfallmanagement nach BAIT: Business Continuity und Recovery-Strategien

Ein wirksames IT-Notfallmanagement ist für Banken existenziell und aufsichtsrechtlich verpflichtend. Die BAIT fordern ein integriertes Notfallkonzept, das die Verfügbarkeit kritischer IT-Systeme auch in Krisensituationen sicherstellt. Im Zeitalter digitaler Bankdienstleistungen kann ein IT-Ausfall unmittelbar zu Reputationsschäden, finanziellen Verlusten und Kundenabwanderung führen.

Regulatorische Grundlagen

BAIT-Anforderungen an IT-Notfallmanagement

Die BAIT (Tz. 5) verlangen von Instituten:

• Notfallkonzept: Dokumentierte Strategie für Wiederanlauf und Wiederherstellung
• Business Impact Analyse (BIA): Systematische Identifikation kritischer IT-Systeme
• RTO/RPO-Definitionen: Klare Zielvorgaben für Wiederherstellungszeiten
• Notfallübungen: Regelmäßige Tests der Notfallpläne (mindestens jährlich)
• Notfallorganisation: Definierte Rollen, Eskalationswege, Krisenstab

Verknüpfung mit MaRisk und BCM

MaRisk AT 7.2: Anforderungen an IT-Systeme
    ↓
BAIT Tz. 5: IT-Notfallmanagement
    ↓
BCM-Rahmenwerk (DIN EN ISO 22301)
    ↓
IT-Notfallkonzept + IT-Notfallplan

Das IT-Notfallmanagement ist integraler Bestandteil des unternehmensweiten Business Continuity Management (BCM), das auch nicht-IT-Notfälle (z.B. Pandemie, Naturkatastrophen, Gebäudeausfall) abdeckt.

Phase 1: Business Impact Analyse (BIA)

Die BIA bildet die Grundlage für alle Notfallmaßnahmen. Ziel ist die Identifikation und Priorisierung kritischer Geschäftsprozesse und IT-Systeme.

Durchführung der BIA

Schritt 1: Geschäftsprozesse identifizieren

• Alle wesentlichen Geschäftsprozesse erfassen (z.B. Zahlungsverkehr, Kreditvergabe, Online-Banking)
• Abhängigkeiten zu IT-Systemen dokumentieren

Schritt 2: Auswirkungen bewerten

Auswirkungsbereich	Bewertungskriterien
Finanzielle Auswirkung	Direkte Verluste, Strafzahlungen, Opportunitätskosten
Regulatorische Auswirkung	Meldepflichten, Sanktionen, Lizenzrisiko
Reputationsschaden	Kundenvertrauen, Medienberichterstattung, Marktposition
Betriebliche Auswirkung	Prozessunterbrechung, Ressourcenbindung, Backlog

Schritt 3: Kritikalität festlegen

Klassifizierung nach Maximum Tolerable Period of Disruption (MTPD):

• Kritisch (Stufe 1): Ausfall > 2 Stunden nicht tolerierbar (z.B. Zahlungsverkehr, Online-Banking)
• Hoch (Stufe 2): Ausfall > 4 Stunden kritisch (z.B. Kreditbearbeitung, Risikosysteme)
• Mittel (Stufe 3): Ausfall > 24 Stunden tolerierbar (z.B. Reporting, Analytik)
• Niedrig (Stufe 4): Ausfall > 3 Tage tolerierbar (z.B. Archivierung, unkritische Backofficeprozesse)

Praxisbeispiel: BIA für Online-Banking

Geschäftsprozess: Online-Banking (Retail)
├─ IT-Systeme: Web-Frontend, Mobile App, API-Gateway, Core Banking
├─ Finanzielle Auswirkung: 50.000 EUR/Stunde (Transaktionsverluste)
├─ Reputationsschaden: Hoch (Social Media Shitstorm nach 30 Min.)
├─ Regulatorisch: Meldepflicht an BaFin nach 2h (§ 25h KWG)
└─ MTPD: 2 Stunden → Kritikalität: KRITISCH (Stufe 1)

Phase 2: RTO und RPO definieren

Auf Basis der BIA werden für jedes System konkrete Wiederherstellungsziele festgelegt:

Recovery Time Objective (RTO)

Definition: Maximale tolerierbare Ausfallzeit bis zur Wiederherstellung der Funktionsfähigkeit.

Typische RTO-Werte:

Systemkategorie	RTO	Beispiel
Tier 1 (Kritisch)	< 4 Stunden	Zahlungsverkehr, Online-Banking, Target2
Tier 2 (Wichtig)	< 24 Stunden	Kreditprozesse, Risikomanagement, Treasury
Tier 3 (Standard)	< 72 Stunden	Reporting, Controlling, Data Warehouse
Tier 4 (Unkritisch)	> 1 Woche	Archivdaten, historische Analysen

Recovery Point Objective (RPO)

Definition: Maximaler tolerierbarer Datenverlust (Zeitspanne zwischen letztem Backup und Störungseintritt).

Umsetzung:

• RPO = 0 (Zero Data Loss): Synchrone Replikation (z.B. für Kernbankensystem)
• RPO < 15 Min.: Asynchrone Replikation mit geringem Lag
• RPO < 24h: Tägliche Backups (für unkritische Systeme)

Trade-off Kosten vs. RTO/RPO:

RTO ↓ + RPO ↓ = Kosten ↑ (Infrastruktur, Lizenzen, Betrieb)

Beispiel:
- RTO 4h, RPO 1h: Warm Standby, asynchrone Replikation (ca. 50k EUR/Jahr)
- RTO 1h, RPO 0: Hot Standby, synchrone Replikation (ca. 200k EUR/Jahr)

Phase 3: Notfallstrategien und -maßnahmen

Technische Recovery-Strategien

1. Backup & Restore

• Einsatz: Tier 3/4-Systeme mit RTO > 24h
• Technik: Tägliche/wöchentliche Vollbackups + inkrementelle Backups
• Kosten: Niedrig (Storage, Backup-Software)
• Risiko: Lange Wiederherstellungszeit, manueller Aufwand

2. Warm Standby

• Einsatz: Tier 2-Systeme mit RTO 4-24h
• Technik: Parallele Infrastruktur, regelmäßige Datenreplikation, manueller Failover
• Kosten: Mittel (redundante Server, Netzwerk, Storage)
• Risiko: Manuelle Umschaltung erforderlich

3. Hot Standby / High Availability (HA)

• Einsatz: Tier 1-Systeme mit RTO < 4h
• Technik: Aktiv-Passiv-Cluster, automatischer Failover, synchrone Replikation
• Kosten: Hoch (doppelte Infrastruktur, Cluster-Software, Betrieb)
• Risiko: Automatisierung kann fehlschlagen

4. Aktiv-Aktiv-Betrieb (Disaster Recovery as a Service)

• Einsatz: Hochkritische Systeme (Zahlungsverkehr)
• Technik: Load-Balancing über mehrere Rechenzentren, synchrone Replikation
• Kosten: Sehr hoch
• Risiko: Komplexe Orchestrierung

Organisatorische Notfallmaßnahmen

Notfallorganisation:

IT-Notfall erkannt
    ↓
1. IT-Notfallkoordinator informiert (24/7-Bereitschaft)
    ↓
2. Notfallteam zusammenrufen (vordefinierte Rollen)
    ↓
3. Lagebeurteilung: Kategorie 1-3 (Schweregrad)
    ↓
4. Eskalation an Krisenstab (bei Kat. 1)
    ↓
5. Notfallmaßnahmen umsetzen (gemäß Runbook)
    ↓
6. Kommunikation: Intern, Kunden, BaFin, Öffentlichkeit
    ↓
7. Dokumentation und Lessons Learned

Rollen im IT-Notfall:

• IT-Notfallkoordinator: Zentrale Anlaufstelle, Eskalation, Koordination
• System Owner: Fachliche Verantwortung für betroffenes System
• IT-Operations: Technische Wiederherstellung
• Kommunikation: Interne und externe Krisenkommunikation
• Geschäftsleitung: Entscheidungen bei Kategorie-1-Vorfällen

Phase 4: Notfallübungen und Tests

BAIT-konforme Testanforderungen

• Häufigkeit: Mindestens jährlich für kritische Systeme (Tier 1/2)
• Umfang: Vollständiger Test der Notfallpläne, nicht nur Backups
• Dokumentation: Protokollierung der Testergebnisse, Lessons Learned
• Verbesserung: Anpassung der Notfallpläne basierend auf Testerfahrungen

Test-Szenarien

Testszenario	Beschreibung	Aufwand
Tabletop Exercise	Theoretische Durchsprache des Notfallplans	Niedrig (2-4h)
Backup-Restore-Test	Wiederherstellung aus Backup auf Testsystem	Mittel (1 Tag)
Failover-Test	Umschaltung auf Standby-System (außerhalb Betrieb)	Mittel (4-8h)
Disaster-Recovery-Drill	Vollständiger Notfalltest inkl. Organisation	Hoch (2-3 Tage)
Cyber-Attack-Simulation	Ransomware-Angriff simulieren	Hoch (mit externen Experten)

Praxistipp: Planungskalender

Q1: Tabletop Exercise (alle kritischen Systeme)
Q2: Backup-Restore-Test (Kernbankensystem)
Q3: Failover-Test (Online-Banking)
Q4: Full Disaster Recovery Drill (Gesamtbank)

Meldepflichten bei IT-Notfällen

BaFin-Meldung gemäß § 25h KWG

Institute müssen IT-Notfälle unverzüglich an die BaFin melden, wenn:

• Wesentliche Geschäftsprozesse beeinträchtigt sind
• Ausfall > 2 Stunden (für kritische Systeme)
• Reputationsschäden zu erwarten sind
• Cyber-Angriffe stattgefunden haben

Meldeformat: Via BaFin-Portal, strukturierte Daten (Incident-Details, Auswirkungen, Maßnahmen)

DORA-Verschärfung ab 2025

Mit DORA wird das Incident-Reporting europäisch harmonisiert:

• Erstmeldung: Innerhalb 4 Stunden nach Erkennung (schwere Vorfälle)
• Zwischenbericht: Nach 72 Stunden (Update zu Maßnahmen)
• Abschlussbericht: Nach Abschluss der Wiederherstellung (Ursachenanalyse)

Dokumentation: IT-Notfallhandbuch

Mindestinhalte gemäß BAIT:

1. Notfallstrategien: Überblick über Ansätze und Priorisierung
2. BIA-Ergebnisse: Kritikalität aller IT-Systeme, RTO/RPO
3. Notfallpläne: System-spezifische Runbooks mit Wiederherstellungsschritten
4. Notfallorganisation: Rollen, Verantwortlichkeiten, Eskalationswege
5. Kontaktlisten: 24/7-Erreichbarkeit aller Notfallteam-Mitglieder
6. Testprotokolle: Dokumentation aller Notfallübungen

Aktualisierung: Mindestens jährlich oder bei wesentlichen Änderungen (neue Systeme, Prozesse, Personal).

Best Practices

Top 5 Empfehlungen:

1. Automatisierung: Automatische Failover-Mechanismen reduzieren RTO drastisch
2. Geo-Redundanz: Rechenzentren in verschiedenen Risikozonen (> 200 km Abstand)
3. Immutable Backups: Vor Ransomware geschützte Backups (WORM, Air-Gap)
4. Regelmäßige Drills: Nur durch Übung wird Routine erreicht
5. Lessons Learned: Jeder Vorfall ist eine Chance zur Verbesserung

---

Fazit: IT-Notfallmanagement ist kein Projekt, sondern ein kontinuierlicher Prozess. Die BAIT setzen klare Mindeststandards, die mit strukturierter BIA, definierten RTO/RPO und regelmäßigen Tests erfüllt werden. Mit DORA werden die Anforderungen weiter steigen – Banken sollten ihr Notfallmanagement proaktiv stärken.