Notfallmanagement und Business Continuity für Banken nach BAIT

Einleitung

Die Fähigkeit, auch im Krisenfall den Geschäftsbetrieb aufrechtzuerhalten, ist für Banken existenziell. Die BAIT fordern ein umfassendes Notfallmanagement, das sowohl technische Ausfälle als auch externe Krisen adressiert. Dieser Artikel beleuchtet die regulatorischen Anforderungen und praktische Umsetzung eines Business Continuity Management Systems (BCMS).

Regulatorische Anforderungen

BAIT-Anforderungen

Ziffer 4 BAIT - Notfallmanagement:

Die BAIT fordern:

• Notfallkonzept für kritische IT-Systeme und Geschäftsprozesse
• Business Impact Analyse (BIA)
• Definition von Recovery Time Objectives (RTO) und Recovery Point Objectives (RPO)
• Dokumentierte Wiederanlaufpläne
• Regelmäßige Notfalltests (mindestens jährlich)
• Lessons Learned Prozess

MaRisk-Anforderungen

MaRisk AT 7.3 - Notfallmanagement:

Ergänzend zu BAIT verlangt MaRisk:

• Institutsspezifisches Notfallkonzept
• Einbeziehung von Auslagerungen
• Krisenmanagement-Organisation
• Krisenkommunikationspläne

Zeitliche Vorgaben

BaFin-Erwartungen:

• Kritische Prozesse: RTO max. 4 Stunden
• Wichtige Prozesse: RTO max. 24 Stunden
• Normale Prozesse: RTO nach individuellem Risiko

Business Impact Analyse (BIA)

Methodik

Zielsetzung: Identifikation und Bewertung der Kritikalität von Geschäftsprozessen sowie deren IT-Abhängigkeiten.

Durchführungsschritte:

1. Prozessinventarisierung:

• Vollständige Erfassung aller Geschäftsprozesse
• Dokumentation der IT-Systeme pro Prozess
• Zuordnung von Verantwortlichkeiten (Process Owner)

2. Kritikalitätsbewertung:

Bewertungskriterien:

Kriterium	Beschreibung	Messgröße
Finanzielle Auswirkung	Verluste pro Ausfalltag	EUR
Regulatorische Relevanz	Verstöße gegen Aufsichtsrecht	Ja/Nein
Reputationsschaden	Image-Schädigung	Hoch/Mittel/Gering
Kundenbeeinträchtigung	Anzahl betroffener Kunden	Anzahl
Rechtliche Konsequenzen	Vertragsverletzungen, Strafen	EUR

3. Kritikalitätsklassifikation:

Kritikalitätsstufen:

KRITISCH:
- Existenziell für Geschäftsbetrieb
- Regulatorisch verpflichtend
- RTO: < 4 Stunden
- Beispiel: Zahlungsverkehr, Online Banking

WICHTIG:
- Wesentlich für Geschäftsbetrieb
- Kundenrelevant
- RTO: 4-24 Stunden
- Beispiel: Kreditbearbeitung, Meldewesen

NORMAL:
- Unterstützende Prozesse
- Verzögerung tolerierbar
- RTO: 1-3 Tage
- Beispiel: Reporting, interne Tools

4. Abhängigkeitsanalyse:

• Identifikation kritischer IT-Systeme
• Mapping zu Infrastruktur (Server, Netzwerk, Rechenzentren)
• Identifikation von Single Points of Failure
• Dokumentation von Abhängigkeiten zu Drittdienstleistern

5. Definition RTO/RPO:

Recovery Time Objective (RTO): Maximale tolerierbare Ausfallzeit eines Prozesses.

Recovery Point Objective (RPO): Maximaler tolerierbarer Datenverlust (Zeitspanne zwischen letztem Backup und Ausfall).

Beispiel:

Prozess: Online-Banking
- RTO: 2 Stunden (nach 2h muss System wieder verfügbar sein)
- RPO: 15 Minuten (max. 15 Min. Transaktionsdatenverlust akzeptabel)

Technische Implikation:
- Hochverfügbare Infrastruktur (HA-Cluster)
- Synchrone Datenreplikation ins DR-Rechenzentrum
- Automatisiertes Failover

BIA-Workshop

Teilnehmer:

• Fachbereichsleiter (Process Owner)
• IT-Verantwortliche
• Risk Manager
• BCM-Koordinator

Agenda:

1. Erläuterung der BIA-Methodik
2. Bewertung der Geschäftsprozesse
3. Diskussion der Abhängigkeiten
4. Konsensbildung zu RTO/RPO
5. Identifikation kritischer Ressourcen (Personal, Räumlichkeiten)

Notfallkonzept

Struktur eines BAIT-konformen Notfallkonzepts

1. Management Summary:

• Zielsetzung und Scope
• Verantwortlichkeiten
• Review-Zyklus

2. Notfallorganisation:

Krisenmanagementteam (KMT):

Rolle	Verantwortung	Erreichbarkeit
Krisenstabsleiter	Gesamtverantwortung, Entscheidungen	24/7 Rufbereitschaft
IT-Koordinator	Technische Wiederherstellung	24/7 Rufbereitschaft
Kommunikationsverantwortlicher	Interne/externe Kommunikation	24/7 Rufbereitschaft
Fachbereichsvertreter	Fachliche Expertise, Priorisierung	On-demand
Facility Manager	Infrastruktur, alternative Standorte	On-demand

3. Eskalationsprozess:

Stufe 0: Störung (IT-Betrieb löst selbst)
    ↓ nicht gelöst innerhalb 30 Min.
Stufe 1: Incident (IT-Manager informiert)
    ↓ kritisches System betroffen
Stufe 2: Crisis (Krisenstab aktiviert)
    ↓ Bank-weite Auswirkung
Stufe 3: Disaster (Geschäftsleitung, BaFin-Meldung)

4. Wiederanlaufpläne:

Pro kritischem Prozess/System:

• Voraussetzungen für Wiederanlauf
• Schritt-für-Schritt-Anleitung
• Benötigte Ressourcen (Personal, Hardware)
• Verantwortlichkeiten
• Checklisten
• Rollback-Szenarien

Beispiel: Wiederanlauf Online-Banking:

1. Failover auf DR-Rechenzentrum initiieren (IT-Koordinator)
   - Dauer: 15 Minuten
   - Tools: Failover-Script ausführen

2. Funktionstest durchführen (Testmanager)
   - Login-Prozess
   - Transaktion (Testumgebung)
   - Dauer: 10 Minuten

3. Freigabe durch Fachbereich (Process Owner)
   - Go/No-Go Entscheidung

4. Aktivierung Produktivbetrieb (IT-Koordinator)
   - DNS-Umschaltung
   - Monitoring aktivieren

5. Kommunikation (Kommunikationsverantwortlicher)
   - Interne Information an Mitarbeiter
   - Externe Kommunikation (Website, Social Media)

5. Kommunikationspläne:

Interne Kommunikation:

• Mitarbeiter-Information (Intranet, E-Mail, SMS)
• Führungskräfte-Briefings
• Betriebsrat-Information

Externe Kommunikation:

• Kunden-Information (Website, App, Medien)
• BaFin-Meldung (bei wesentlichen Störungen)
• Presse-Kommunikation (vorbereitet Statements)
• Partner-/Dienstleister-Information

6. Alternative Betriebsstätten:

Rechenzentren:

• Primäres RZ (Production)
• Disaster Recovery RZ (geographisch getrennt, min. 200km)
• Datenreplikationsmechanismus (synchron/asynchron)

Bürostandorte:

• Homeoffice-Fähigkeit (seit COVID-19 Standard)
• Alternative Bürostandorte (Cold/Warm/Hot Sites)
• Mobile Working Infrastructure

IT-Disaster Recovery

DR-Strategien

1. Cold Site:

• Leere Räumlichkeit mit Grundinfrastruktur
• Hardware wird im Notfall beschafft
• RTO: Mehrere Tage
• Kosten: Niedrig
• Eignung: Unkritische Systeme

2. Warm Site:

• Vorkonfigurierte Hardware vorhanden
• Daten werden im Notfall eingespielt
• RTO: 24-48 Stunden
• Kosten: Mittel
• Eignung: Wichtige Systeme

3. Hot Site:

• Vollständig gespiegelte Infrastruktur
• Daten in Echtzeit repliziert
• RTO: < 4 Stunden (oft < 1 Stunde)
• Kosten: Hoch
• Eignung: Kritische Systeme

4. Active-Active (Geo-Redundant):

• Beide RZs parallel im Betrieb
• Last-Verteilung über Standorte
• RTO: Sekunden bis Minuten (automatisches Failover)
• Kosten: Sehr hoch
• Eignung: Ultra-kritische Systeme (Core Banking, Zahlungsverkehr)

Backup-Strategien

3-2-1-Regel:

• 3 Kopien der Daten
• 2 verschiedene Medientypen (z.B. Disk + Tape)
• 1 Kopie offsite (geographisch getrennt)

Backup-Methoden:

Methode	Beschreibung	RPO	Speicherbedarf	Restore-Zeit
Full Backup	Komplettsicherung	Hoch	Sehr hoch	Schnell
Incremental	Nur Änderungen seit letztem Backup	Niedrig	Gering	Langsam
Differential	Änderungen seit letztem Full Backup	Mittel	Mittel	Mittel
Continuous Data Protection (CDP)	Echtzeit-Replikation	Sehr niedrig	Hoch	Sehr schnell

BAIT-Anforderung: Halbjährliche Restore-Tests für kritische Systeme.

Automatisierung

Infrastructure as Code (IaC):

• Terraform/CloudFormation für automatisierte DR-Umgebung
• Versionierte Konfigurationen
• Schnelle Provisionierung im Notfall

Runbook Automation:

• Ansible/Puppet für orchestrierte Wiederanlauf-Prozesse
• Minimierung manueller Fehlerquellen
• Dokumentation durch Code

Notfalltests

BAIT-Testanforderungen

Frequenz:

• Kritische Systeme: Mindestens jährlich
• Wichtige Systeme: Alle 2 Jahre
• Gesamte Notfallorganisation: Jährlich

Testarten:

1. Tabletop Exercise:

• Durchsprache von Szenarien am Tisch
• Teilnehmer: Krisenmanagementteam
• Dauer: 2-4 Stunden
• Ziel: Prozessverständnis prüfen, Kommunikation üben

2. Structured Walkthrough:

• Schritt-für-Schritt Durchgang der Wiederanlaufpläne
• Teilnehmer: IT-Teams und Process Owner
• Dauer: 4-8 Stunden
• Ziel: Vollständigkeit der Dokumentation prüfen

3. Simulation:

• Realitätsnahe Simulation ohne tatsächliches Failover
• Teilnehmer: Alle relevanten Rollen
• Dauer: 1 Tag
• Ziel: Zusammenspiel testen, Timings validieren

4. Full-Scale Test:

• Tatsächliches Failover auf DR-Umgebung
• Teilnehmer: Gesamte Organisation
• Dauer: 1-2 Tage
• Ziel: Ende-zu-Ende-Validierung, RTO/RPO-Nachweis

WICHTIG: Full-Scale Tests außerhalb der Geschäftszeiten oder mit Ankündigung an Kunden.

Test-Dokumentation

Test-Protokoll muss enthalten:

• Testziel und -scope
• Teilnehmer
• Testszenario
• Tatsächliche RTO/RPO
• Abweichungen vom Plan
• Identifizierte Schwachstellen
• Maßnahmenplan zur Verbesserung

Lessons Learned: Nach jedem Test:

• Debriefing mit allen Teilnehmern
• Identifikation von Verbesserungspotentialen
• Update der Wiederanlaufpläne
• Follow-up zu Maßnahmen

Krisenszenarien

Typische Notfallszenarien

1. Rechenzentrumsausfall:

• Ursachen: Brand, Überflutung, Stromausfall, Klimaausfall
• Maßnahme: Failover auf DR-RZ
• Betroffene Systeme: Alle im primären RZ

2. Cyber-Angriff (Ransomware):

• Ursache: Verschlüsselung durch Malware
• Maßnahme: Isolation, Wiederherstellung aus Backups
• Besonderheit: Forensik vor Wiederanlauf

3. Pandemie:

• Ursache: Krankheit (z.B. COVID-19)
• Maßnahme: Homeoffice-Aktivierung, Split-Team-Betrieb
• Besonderheit: Langanhaltende Situation

4. Ausfall kritischer Dienstleister:

• Ursache: Cloud-Provider-Ausfall, Netzwerk-Provider-Störung
• Maßnahme: Aktivierung Backup-Provider, manuelle Workarounds
• Herausforderung: Begrenzte Einflussmöglichkeit

5. Personalausfall (Key Person Risk):

• Ursache: Krankheit, Kündigung von Schlüsselpersonen
• Maßnahme: Aktivierung Backup-Ressourcen, Dokumentation
• Prävention: Wissensmanagement, Shadowing

Szenario-Planung

Szenario-Matrix:

                    Wahrscheinlichkeit
                    Niedrig | Mittel | Hoch
Auswirkung Kritisch    A2       A1      A1
           Hoch        B2       A2      A1
           Mittel      C1       B2      A2

A1 = Detaillierter Plan + jährlicher Test erforderlich
A2 = Detaillierter Plan + Test alle 2 Jahre
B2 = Grundplan + regelmäßiges Review
C1 = Awareness ausreichend

BCM-Lifecycle

Kontinuierliche Verbesserung:

1. PLANEN
   - BIA durchführen
   - Strategien entwickeln
   - Pläne erstellen

2. IMPLEMENTIEREN
   - DR-Infrastruktur aufbauen
   - Personal schulen
   - Dokumentation erstellen

3. PRÜFEN
   - Notfalltests durchführen
   - Audits durchführen
   - Lessons Learned

4. VERBESSERN
   - Pläne aktualisieren
   - Schwachstellen beheben
   - Training anpassen

↺ (Zyklus wiederholt sich jährlich)

Change Management: Wesentliche Änderungen (neue Systeme, Prozesse, Dienstleister) müssen in BCM-Dokumentation einfließen:

• Standardprozess: Change Request muss BCM-Impact bewerten
• Bei kritischen Änderungen: Update der BIA und Wiederanlaufpläne

Governance und Reporting

BCM-Verantwortlichkeiten:

• Geschäftsleitung: Strategische Entscheidungen, Budget, Genehmigung Notfallkonzept
• BCM-Koordinator: Zentrale Steuerung, Überwachung, Reporting
• Process Owner: Fachliche Verantwortung für Geschäftsprozesse
• IT-Verantwortliche: Technische DR-Umsetzung
• Risk Management: Integration in Risikolandschaft

Reporting:

• Quartalsweise: BCM-KPIs an Risk Committee
• Jährlich: BCM-Jahresbericht an Geschäftsleitung/Aufsichtsrat
• Ad-hoc: Nach Notfällen und Tests

BCM-KPIs:

• RTO/RPO-Einhaltung in Tests
• Testfrequenz (Plan vs. Ist)
• Zeit für Maßnahmenumsetzung aus Tests
• BCM-Schulungs-Completion-Rate
• Anzahl Single Points of Failure

Integration mit DORA

DORA-Anforderungen ab 2025:

• Erweiterte IKT-Resilienz-Tests (inklusive Threat-Led Penetration Testing)
• Detaillierte Berichtspflichten bei IKT-Vorfällen
• Stärkere Einbindung des Managements
• Harmonisierte EU-weite Anforderungen

Vorbereitung:

• Gap-Analyse BAIT-Notfallkonzept vs. DORA
• Erweiterung Test-Szenarien um TLPT
• Anpassung Meldeprozesse

Best Practices

1. Business-Driven: BCM aus Geschäftssicht, nicht als IT-Projekt
2. Executive Sponsorship: Sichtbares Commitment der Geschäftsleitung
3. Realistische RTOs: Erreichbare Ziele setzen, nicht Wunschdenken
4. Regelmäßiges Training: Krisenteam muss Prozesse kennen
5. Dokumentation aktuell halten: Review bei jeder wesentlichen Änderung
6. Automatisierung: Manuelle Prozesse sind fehleranfällig und langsam
7. Third-Party einbeziehen: Dienstleister müssen in BCM integriert sein

Fazit

Ein wirksames Business Continuity Management ist regulatorische Pflicht und wirtschaftliche Notwendigkeit. Die Investition in Redundanz, Planung und Testing zahlt sich im Ernstfall vielfach aus. BAIT-konforme BCM-Prozesse erfordern eine ganzheitliche Betrachtung von Geschäftsprozessen, IT-Systemen und externen Abhängigkeiten sowie ein gelebtes Risikobewusstsein auf allen Ebenen.