Business Continuity Plan

1) Zweck, Bereich und Grundsätze

Ziel: Sicherstellung der Fortsetzung kritischer Dienste (Einzahlungen, Wetten/Spiele, Schlussfolgerungen, KYC/AML, Sapport) bei Störungen und schnelle Wiederherstellung ohne Verletzung von Lizenzen und Verträgen.
Bereich: Online-Plattform, Zahlungsverkehr, Betrugsbekämpfung/CUS, DWH/BI, Saport, Betriebs- und Rechtsfunktionen, Schlüsselanbieter (PSP/KYC/Cloud/CDN/Studios/Aggregatoren).
Prinzipien: safety first, player first, regulatorische Korrektheit, RTO/RPO-Minimierung, einfache Degradationsmodi, Nachweisbarkeit und regelmäßige Übungen.

2) BIA - Business Impact Analysis

Identifizieren Sie kritische Prozesse, I/Os, Abhängigkeiten, „manuelle“ Alternativen und gezielte RTOs/RPOs.

yaml process: payouts owner: head_of_payments criticality: tier1 dependencies: [psp1, psp2, bank_api, kyc_service, ledger_db]
rto: "4h"
rpo: "15m"
manual_workaround: "limited manual VIP payments when the PSP is completely unavailable"
max_tolerable_downtime: "8h"
legal_constraints: ["AML/KYC check before payout," "regulatory notification windows"]

3) Risiko → Wirkung → Reaktion

Dazu gehören: Fall der Cloud-Region, DB-Ausfall, Cluster-Verlust, DDoS-Angriffe, CDN-Ausfall.
Anbieter: PSP/KYC Degradation, Bruch mit dem Spiele-Aggregator, Nichtverfügbarkeit von Anti-Fraud/Sanktionsscreening.
Cyber: Konto-/Schlüsselkompromittierung, Ransomware, PII-Leak.
Prozesse/Personen: Streiks/Krankheiten, Ausscheiden von Schlüsselspezialisten, Freigabefehler.
Geo/höhere Gewalt: Kommunikations-/Energieausfälle, militärische/Sanktionsrisiken, Domain-/Verkehrssperren.

Für jeden: Auslöser, Eskalationsschwelle, Kontrollmaßnahmen, Dienstdegradierung und Kommunikationsmuster.

4) Architektur der Nachhaltigkeit und Strategie

Aktiv-Aktiv/Aktiv-Standby nach Region; Infrastruktur als Code für einen schnellen Aufstieg.
Degradierende Modi: Read-only-Showcases, Herunterfahren von nicht-kritischen Spieleanbietern, Auszahlungslimits, „nur Einzahlungen“ mit verzögerten Kassen (wenn rechtlich zulässig), Reduzierung der Analytik/ETL-Frequenz.
Traffic Management: Anycast CDN, Geo-Balancing, Health-Checks, Canary-Routing.
Daten: PITR-Backups, Änderungsprotokolle, interregionale Replikation, kryptographische Integrität (Hashes/WORM).
Schlüssel/Geheimnisse: unabhängige KMS pro Region, „break-glass“ mit Logging.
PSP/KYC Multi-Homing: Automatischer Failover, Routing über SLA/Latenz.

5) Befehlsstruktur (Incident Command System)

Der Incident Commander (IC) ist ein zentraler Entscheidungspunkt.
Ops Lead (SRE/Platform) - Techstabilisierung, Failover, Metriken.
Business Continuity Lead - Koordination von Prozessen/manuellen Abläufen.
Comms Lead - externe/interne Benachrichtigungen (Spieler, Partner, Aufsichtsbehörden).
Sicherheit/DSB - Cyber-Vorfälle/Privatsphäre, regulatorische Fenster.
Zahlungen/KYC-Leads - PSP/KYC-Szenarien.
Liaisons: Legal, Support, VIP/CRM, Data/BI.

Regel: ein IC pro Vorfall, klare Kanäle und Entscheidungsprotokolle.

6) Kommunikationsplan

Kanäle: Kriegsraum (Chat/Bridge), Backup-Verbindungen (Telefon/Radio/Alt-Messenger), PSP/KYC/Banken vorab verifizierte Kontakte.
Vorlagen für externe Nachrichten: Status-Seite, soziale Netzwerke, E-Mail/Push; Ton - Fakten, Termine, nächste Schritte.
Regulierungsbehörden und Partner: voreingestellte Adressen, Benachrichtigungs-SLAs; die vereinbarte Formulierung.
Spieler: transparente ETAs, Vergütungen/Boni (falls zutreffend), FAQs für den Zeitraum der Degradierung.

7) Betriebspläne (Runbooks)

7. 1 Failover in eine andere Region

yaml trigger: "loss of primary availability> = 5m, p95_latency>threshold"
steps:
- IC approves region_failover
- SRE: flip traffic via GSLB to secondary
- Data: verify replication lag < RPO
- Apps: switch env vars/secrets; warm caches
- QA: smoke tests; Business: announce status rollback: "switch-back on 60m stability"

7. 2 PSP Degradation

yaml trigger: "auth_rate_psp1 < baseline-3σ 15m"
steps:
- Payments: route X%→psp2, include limits
- Comms: banner at the checkout, status page
- Finance: reconciliation plan for T + 0
- Legal: notification log and SLA letter

7. 3 KYC-Anbieter nicht verfügbar

yaml trigger: "kyc_sla_breach 30m"
steps:
- Risk: time limits of deposits/rates
- Ops: VIP/High-risk manual check
- Comms: KYC Time Increase Notice
- Vendor: escalation, protection switch

8) Wiederherstellung von IT und Daten (DR)

Systemkategorien: Tier-1 (Plattform/Zahlungen/CUS), Tier-2 (Spiele/Analysen), Tier-3 (intern).
Reihenfolge des Aufstiegs: set→sekrety/KMS→BD→kesh→API→front/CDN→integratsii→analitika.
Integritätsprüfungen: Prüfsummen, Verifizierung von Protokollen/Replikation, Transaktionsabgleich (Reconciliation).
DR-Tests: jährlich vollständig (Switch-over), vierteljährlich teilweise; Festlegung der tatsächlichen RTOs/RPOs.

9) Menschen, Büros und Logistik

Remote-ready: redundante Notebooks/Modems, Zugriff über SSO/MFA, „roter“ Zugriff für ICs.
Alternative Standorte: Ersatzbüros/Coworking Spaces, Passlisten, Evakuierungsplan.
Schichtrotation: Kompetenzmatrix, Duplizierung von Schlüsselrollen, Ersatzplan.
Kritische Kommunikations-/Energieanbieter: Kontakte, SLAs, Generatoren/USVs (falls relevant).

10) Lieferanten und Lieferkette

BCP/DR-Anforderungen in Verträgen: RTO/RPO, obligatorische Tests, Prüfungsrecht und gemeinsame Übungen.
Register der Unterverarbeiter: Kontakte, Pläne für Outage, Bestätigungen für das Löschen/Exportieren von Daten beim Offboarding.
Tier-1 vierteljährliche Reviews: Vorfälle, DR-Protokolle, Status von Zertifikaten, SLAs.

11) Training, Übungen und Tests

Tabletop einmal pro Quartal: PSP/KYC/Cloud/Cyber-Szenarien.
Tech-Übungen: DR teilweise/vollständig; DDoS/CDN-Umschaltung; „kill-switch“ SDK der Anbieter.
Kommunikationsübungen: Pressemitteilung/Status-Updates/regulatorische Schreiben.
Retrospektiven: Timeline, RCA, CAPA, Runbooks Update und BIA.

12) Metriken (KPI/KRI)

RTO/RPO Fakt (nach Tier-1): Entspricht den Zielen ≥ 95%.
MTTD/MTTR: Abwärtstrend; MTTR kritische Vorfälle ≤ Ziel.
Failover-Erfolg: kein Datenverlust/Aufträge/Gebote, ≤ X Minen Degradation.
Coverage-Übungen: ≥ 2 komplette DR-Tests/Jahr + 4 Tabletop.
Kommunikation: Die Zeit bis zum ersten Update ≤ 15 Minuten, die Häufigkeit der Updates gemäß der Richtlinie.
Vendor resilience: Tier-1-Anteil mit bestätigten DR-Tests in 12 Monaten - 100%.

13) RACI (vergrößert)

14) Checklisten

14. 1 Ready-to-Failover

• Aktuelle IC/Vendor/Regulator Kontakte
• Replikationsgesundheit, regelmäßige PITR-Sicherung
• Verifizierter „Kill-Switch“ für SDK/Webhooks
• Traffic Manager (GSLB/CDN) mit validierten Gesundheitschecks
• Status-/Briefvorlagen und Veröffentlichungsrechte
• Runbooks und Zugriffe (SSO/MFA) monatlich geprüft

14. 2 Während des Vorfalls

• IC zugewiesen, Kriegsraum geöffnet, Entscheidungslogs starten
• Klassifizierung (P1/P2), Szenarioauswahl und Degradation
• Technische Aktionen (Failover/Limits/Blackouts)
• Erstes öffentliches Update ≤ 15 Minuten
• Regulatorische/Affiliate-Mitteilungen zu SLAs
• Erfassung von Artefakten für Post-Mortem

14. 3 Nach dem Vorfall

• Post-Mortem mit RCA und CAPA
• Aktualisierte BIA/Schwellenwerte/Routineverfahren
• Training/Retest Fixes, Bericht an das Board
• Finanzielle/gegebene Überleitung (Reconciliation)

15) Muster (Fragmente)

15. 1 Skriptkarte

yaml scenario: "Region outage: cloud-eu1"
triggers: ["error_rate>5%", "loss of quorum", "cdn health fail"]
degradation: ["disable live-casino", "payments=psp2 only", "payouts=VIP manual"]
rto_target: "30m"
rpo_target: "15m"
contacts: {cloud: "...", isp: "...", regulator: "..."}
comms_templates: ["status_page_v1", "partner_notice_v2"]

15. 2 Nachricht an die Status-Seite

[UTC + 02] We are seeing the degradation of payments through PSP # 1. Transactions are automatically routed through an alternative provider. Player funds are safe. The next update is in 15 minutes.

16) Dokumenten- und Versionsverwaltung

BCP/Runbooks im Repository versionieren, Änderungsprotokoll, Dokumentbesitzer.
Zeitpunkt der Überarbeitung (vierteljährlich für Tier-1), Kontrolle der Verfügbarkeit von Offline-Kopien.
Speicherung von Übungsartefakten/Incidents und Leistungsmetriken.

17) Umsetzungsfahrplan (6-8 Wochen)

Wochen 1-2: BIA und kritische Prozesse, RTO/RPO-Ziele, Liste der Szenarien und Eigentümer.
Woche 3-4: Architektur der Resilienz und Degradierung, Runbooks, Kommunikationsmuster, Kontakte.
Woche 5-6: Vendor Integration (PSP/KYC/Cloud), Pilotübungen (Tabletop + partielle DR), Anpassungen.
Woche 7-8: vollständiger DR-Test (wenn möglich), Start des vierteljährlichen Übungszyklus, Bordbericht und regulatorisches Paket (falls erforderlich).

18) Verwandte Wiki-Abschnitte

Risikoregister, Vorfälle und Lecks, DR/BCP-Tests, TPRM und SLA, ISO 27001/27701, SOC 2, PCI DSS, IGA/RBAC/Least Privilege, Log Policy/WORM - für einen einheitlichen Nachhaltigkeits- und Nachweiskreis.

TL; DR

Effektive BCP = BIA→RTO/RPO→stsenarii und degradatsii→multi -vender/Multi-Region + klare Incident Command, Kommunikation und Lehre. Halten Sie das Dokument am Leben, testen Sie es regelmäßig - und selbst ein großer Ausfall wird das Geschäft nicht stoppen oder die Lizenzen treffen.