Operations & Management → Kontinuität der Geschäftsprozesse

Business Process Continuity (BCP)

1) Was ist BCP und warum wird es benötigt?

BCP (Business Continuity Planning) ist ein systematischer Ansatz, um die Nachhaltigkeit von Geschäftsprozessen bei Störungen zu gewährleisten: vom Ausfall eines Rechenzentrums bis hin zu einer Anbieterkrise, einem Datenleck oder einem plötzlichen Lastanstieg.
Bei hochbelasteten Produkten (iGaming, Fintech, Marktplätze) geht es nicht nur um Infrastruktur - es geht darum, Vertrauen zu bewahren, regulatorische Verpflichtungen einzuhalten und Einnahmen zu schützen.

• Aufrechterhaltung der Verfügbarkeit kritischer Dienste und Daten.
• Minimieren Sie Recovery Time (RTO) und Data Loss (RPO).
• Sicherstellung der Funktionsfähigkeit von Teams, Kommunikation und externen Partnern in der Krise.
• Standardisierung der Reaktion und Schulung des Personals.

2) Hauptkomponenten von BCP

1. BIA (Business Impact Analysis) - Bewertung der Auswirkungen von Fehlern auf Prozesse und Unternehmen.
2. Risiken und Szenarien - Bedrohungsmatrix (infrastrukturell, extern, menschlich).
3. RTO/RPO-Ziele - Wiederherstellungsziele und zulässige Verluste.
4. Recovery Plan (DRP) - Detaillierte Schritte zum Neustart von Systemen und Prozessen.
5. Kommunikation - interne und externe Kanäle, Benachrichtigungsvorlagen.
6. Prüfung und Revision - regelmäßige Kontrollen, Übungen, Post-Analyse.
7. Dokumentation und Versionskontrolle - zentraler Zugriff und Relevanz.

3) Wirkungsanalyse (BIA)

BIA bestimmt, welche Prozesse kritisch sind und wie schnell sie wiederhergestellt werden müssen.

1. Liste aller Geschäftsprozesse (Zahlungen, Wetten, Spiele, KYC, Support).

2. Definition von Abhängigkeiten (Dienste, Daten, Anbieter, Mitarbeiter).

3. Abschätzung der Auswirkungen der Ablehnung: finanziell, rechtlich, reputativ, operativ.

4. Installation von RTO/RPO für jeden Prozess.

5. Priorisierung: „Muss haben“, „Soll haben“, „Schön zu haben“.

4) Risikomatrix

5) RTO, RPO und Kritikalitätsstufen

RTO (Recovery Time Objective): Wie viel Zeit bis zur Wiederherstellung zulässig ist.
RPO (Recovery Point Objective): Wie viel Daten können verloren gehen?

6) DRP (Disaster Recovery Plan)

Das Ziel: eine schnelle und konsequente Wiederherstellung der Systeme zu ermöglichen.

1. Identifizieren Sie Szenarien (Rechenzentrumskatastrophe, PSP-Ausfall, Schlüsselkompromittierung, Netzwerkverlust).

2. Für jedes Szenario gibt es ein fertiges Schritt-für-Schritt-Playbook.

3. Unterstützung der DR-Infrastruktur: redundante Cluster, DB-Replikate, CDN/Edge.

4. RTO/RPO und Failover-Verfahren regelmäßig testen.

5. Speichern Sie alle Anweisungen in einem einzigen Speicher mit Versionskontrolle.

Scenario: EU region falls
RTO: 30 min    RPO: 5 min
Actions:
1. Activate plan DR # EU
2. Switch DNS → AP Region
3. Verify database consistency (replication lag ≤ 60s)
4. Update Status on StatusPage
5. Perform API benchmarking

7) Organisation von Teams und Rollen

BCP-Koordinator: Programmbesitzer, organisiert Revisionen und Tests.
DR lead: verantwortlich für die technische Umsetzung der DR-Pläne.
Domain Owners: sorgen für die Kontinuität ihrer Prozesse (Payments, Games, KYC).
Kommunikationsteam: Verantwortlich für interne/externe Benachrichtigungen und Status-Plattformen.
HR/Admin: BCP für Mitarbeiter (Remote, Links, Zugänge).
Legal/Compliance: Regulatorische Hinweise und rechtliche Maßnahmen.

8) Kommunikation in der Krise

• Klare Kanäle und Backup-Kontakte.
• Das erste Update ist innerhalb von 15 Minuten nach dem Vorfall.
• Einheitlicher Ton von Kommunikation, Fakten und ETA.
• Updates alle N Minuten bis zum Ende des Vorfalls.
• Nach der Wiederherstellung - Bericht und Postmortem.

[HH: MM] PSP-X failed. Impact: Deposits in EU region.
Measures: feilover on PSP-Y. ETA stabilization: 30 min.
The next update is at 15:00.

9) Tests und Übungen

Technisch: Failover-Tests, DB-Wiederherstellung, DDoS-Simulationen.
Operativ: handover/Rollenwechsel von Teams.
Vollständige BCP-Übungen: „Blackout“ -Szenario oder Nichtverfügbarkeit des Anbieters.

• DR-Tests - vierteljährlich;
• BCP-Full-Scale-Training - 1-2 mal pro Jahr.
• Dokumentation: Ergebnisse, Abweichungen von RTO/RPO, Verbesserungsmaßnahmen.

10) Metriken und KPIs

RTO-Compliance:% der Prozesse, die ≤ Ziel wiederhergestellt wurden.
RPO-Compliance:% der Prozesse ohne Datenverlust> Ziel.
DR-Testerfolgsrate: Erfolgreiche Überprüfungen von Wiederherstellungsverfahren.
BCP-Abdeckung: Anteil der Prozesse mit aktuellen Plänen (> 90%).
Comms SLA: Erste Zusammenfassung ≤ 15 Minuten, ETA-Updates.

Postmortem SLA: 100% der kritischen Ereignisse mit einer Analyse ≤ 72 Stunden

11) Dokumentation und Wissensmanagement

Ein einziger BCP-Speicher (Versionen, Besitzer, Revisionsdaten).
Versionskontrolle: Revision mindestens alle 6 Monate.
Verfügbarkeit: Offline-Kopien und Backup-Kommunikationskanäle (einschließlich Telekom/Messenger).
Integrationen: Verweis auf BCP in SOPs, Incident-Prozessen und operativen Dashboards.
Synchronisation mit Risikoregister und Sicherheitsrichtlinien.

12) 30/60/90 - Umsetzungsplan

• Identifizieren Sie den BCP-Eigentümer und kritische Prozesse.
• Führen Sie eine grundlegende BIA und Klassifizierung (RTO/RPO) durch.
• Erstellen Sie eine Risikomatrix und einen Incident-Scenario-Katalog.
• Entwicklung einer DRP-Vorlage und einer ersten Version für priorisierte Dienste.

• Durchführung von DR-Pilottests (Failover, OBD-Wiederherstellung).
• Bereiten Sie Kommunikationsmuster und Rollenverteilung vor.
• Erstellen Sie einen einzigen Speicher für BCP-Dokumente und SOP-Integration.
• Beginnen Sie mit der Schulung von Teams und On-Call-Mitarbeitern.

• Führen Sie eine teamübergreifende BCP-Übung durch.
• Führen Sie ein RTO/RPO-Compliance-Audit und KPI-Metriken durch.
• Finalisierung des Revisionsplans und Automatisierung der BCP-Prozesse.
• BCP in vierteljährliche OKRs und interne Sicherheitsüberprüfungen einbeziehen.

13) Anti-Muster

„BCP nur zum Abhaken“: Keine echten Tests und Besitzer.
Veraltete DR-Anweisungen, die nicht mit den aktuellen Architekturen übereinstimmen.
Ungetestete Kommunikationskanäle und Kontakte.
Nicht gemeldete Abhängigkeiten (PSP, CDN, KYC-Anbieter).
Keine Post-Mortems nach Abstürzen.
Kein Offline-Zugriff auf BCPs, wenn das Netzwerk abstürzt.

14) Beispiel BCP Dokumentstruktur

1. Objectives and Scope
2. Critical Processes (BIA)
3. Risk Matrix
4. Target RTO/RPO
5. DRP (by scenario)
6. Contacts and Roles
7. Communication templates
8. Schedule of tests and exercises
9. Reporting and auditing
10. Version and update history

15) Integration mit anderen Abschnitten

Operational Analytics: Metriken von Headroom und Degradation zu Incidents.
Benachrichtigungs- und Alert-System: Frühe Signale für die Auslösung von BCP-Verfahren.
Managementethik: Transparente Berichte und faire Tests.
KI-Assistenten: Automatische Erstellung von BCP-Zusammenfassungen und DR-Checklisten.
Verantwortungskultur: Trainings, „Game Days“, Retrospektiven.

16) FAQ

Q: Wie unterscheidet sich BCP von DRP?
A: BCP - breiter: umfasst Menschen, Prozesse, Kommunikation, Partner und Infrastruktur. DRP ist ein technischer Plan zur Wiederherstellung von IT-Systemen.

Q: Wie oft BCP aktualisieren?
A: Nach jeder größeren Architekturänderung, Vorfall oder mindestens 1 Mal in 6 Monaten.

F: Muss ich Partner einbeziehen?
A: Ja. PSPs, KYCs und Studios sind Teil der Kontinuitätskette und müssen ihre OLA- und BCP-Vereinbarungen haben.