Planul de continuitate a afacerii

1) Scop, domeniu de aplicare și principii

Scopul: asigurarea continuității serviciilor critice (depozite, pariuri/jocuri, concluzii, KYC/AML, suport) în caz de eșecuri și recuperare rapidă fără încălcarea licențelor și contractelor.
Zona: platformă online, buclă de plată, antifraudă/CUS, DWH/BI, suport, funcții operaționale și juridice, furnizori cheie (PSP/KYC/cloud/CDN/studios/agregatori).
Principii: siguranța în primul rând, jucătorul în primul rând, corectitudinea de reglementare, minimizarea RTO/RPO, moduri simple de degradare, provabilitate și exerciții regulate.

2) BIA - Analiza impactului asupra afacerilor

Identificați procese critice, intrări/ieșiri, dependențe, alternative manuale și țintă RTO/RPO.

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) Risc → impact → răspuns

Acestea: prăbușirea regiunii cloud, eșecul bazei de date, pierderea clusterului, atacurile DDoS, eșecul CDN.
Furnizori: degradare PSP/KYC, rupere cu agregator de jocuri, inaccesibilitate de screening anti-fraudă/sancțiune.
Cyber: Cont/compromis cheie, ransomware, scurgere PII.
Procese/Oameni: Greve/Boli, Plecări de specialitate cheie, Eroare de lansare.
Geo/forţă majoră: întreruperi de comunicaţii/energie, riscuri militare/sancţiuni, blocaje de domeniu/trafic.

Pentru fiecare: declanșatoare, prag de escaladare, măsuri de control, șabloane de degradare a serviciilor și de comunicare.

4) Arhitectură și strategii de sustenabilitate

Activ-activ/activ-standby în funcție de regiune; infrastructura ca cod pentru ascensiune rapidă.
Moduri de degradare: vitrine numai pentru citire, deconectarea furnizorilor de jocuri non-critice, limite de plată, „doar depozite” cu retrageri amânate (dacă sunt permise din punct de vedere legal), frecvență mai mică de analiză/ETL.
Managementul traficului: Anycast CDN, geo-echilibrare, controale de sănătate, canar-rutare.
Date: backup PITR, jurnale de schimbare, replicare inter-regiune, integritate criptografică (hashes/WORM).
Chei/secrete: KMS independent pe regiune, „pauză-sticlă” cu exploatare forestieră.
PSP/KYC multi-homing: failover automat, rutare SLA/latență.

5) Sistemul de comandă incident

Incident Commander (IC) - un singur punct de decizie.
Ops Lead (SRE/Platform) - stabilizare tehnică, feilover, metrică.
Business Continuity Lead - coordonarea proceselor/procedurilor manuale.
Comms Lead - notificări externe/interne (jucători, parteneri, autorități de reglementare).
Securitate/DPO - incidente cibernetice/confidențialitate, ferestre de reglementare.
Plăți/KYC Leads - scenarii PSP/KYC.
Legături: Legal, Suport, VIP/CRM, Date/BI.

Regulă: un IC pe incident, canale clare și jurnalele de decizie.

6) Planul de comunicații

Canale: war-room (chat/bridge), conexiuni de backup (telefon/radio/alt-messenger), pre-verificate PSP/KYC/contacte bancare.
Șabloane de mesaje externe: pagină de stare, rețele sociale, e-mail/push; ton - fapte, sincronizare, următorii pași.
Autorități de reglementare și parteneri: adrese presetate, notificări SLA; formulare convenită.
Jucători: ETA transparente, compensații/bonusuri (dacă este cazul), întrebări frecvente pentru perioada de degradare.

7) Planuri operaționale (Runbooks)

7. 1 Feilover într-o altă regiune

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 degradare

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 Furnizor KYC indisponibil

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) IT și de recuperare de date (DR)

Categorii de sistem: Tier-1 (platformă/plăți/CCM), Tier-2 (jocuri/analiză), Tier-3 (intern).
Procedura de ridicare: set→sekrety/KMS→BD→kesh→API→front/CDN→integratsii→analitika.
Controale de integritate - sume de control, verificare jurnal/replicare, reconciliere tranzacție.

Teste DR: anual complet (switch-over), trimestrial parțial; Angajarea RTO-urilor/RPO-urilor reale

9) Oameni, birouri și logistică

Gata de la distanță: laptopuri/modemuri redundante, acces prin SSO/MFA, acces „roșu” pentru IC.
Locatii alternative: birouri de rezerva/spatii de coworking, liste de trecere, plan de evacuare.
Rotația schimburilor: matricea competenței, duplicarea rolurilor cheie, planul de înlocuire.
Furnizori critici de comunicare/energie: contacte, SLA, generatoare/UPS (dacă este cazul).

10) Furnizori și lanțul de aprovizionare

Cerințe BCP/DR în contracte: RTO/RPO, teste obligatorii, drepturi de audit și exerciții comune.
Registrul subprocesorilor: contacte, planuri de întrerupere, confirmarea ștergerii/exportului datelor la offboarding.
Recenzii trimestriale de nivel 1: incidente, protocoale DR, stare de certificare, SLA.

11) Instruire, exerciții și testare

Tabletop o dată pe sfert: scenarii PSP/KYC/cloud/cyber.
Exerciții tehnice: DR parțială/completă; Comutare DDoS/CDN; „kill-switch” furnizori SDK.
Exerciții de comunicare: comunicat de presă/actualizări de stare/scrisori de reglementare.
Retrospective: cronologie, RCA, CAPA, actualizarea runbooks și BIA.

12) Valori (KPI/KRI)

RTO/RPO efectiv (conform nivelului 1): îndeplinirea obiectivelor ≥ 95%.
MTTD/MTTR: tendință descendentă; MTTR de incidente critice ≤ vizate.
Succes Feilover: fără pierderi de date/comenzi/rate, ≤ X minute de degradare.
Exerciții de acoperire: ≥ 2 teste DR complete/an + 4 tabletop.
Comunicații: timpul până la prima actualizare ≤ de 15 minute, frecvența actualizărilor în funcție de politică.
Rezistența furnizorului: ponderea Tier-1 cu teste DR confirmate în 12 luni este de 100%.

13) RACI (mărită)

14) Liste de verificare

14. 1 Ready-to-Failover

• Contacte actuale IC/Furnizor/Regulator
• Sănătatea replicării, backup PITR regulat
• SDK/Webhook kill-switch verificat
• Manager de trafic (GSLB/CDN) cu verificări de sănătate validate
• Șabloane de stare/litere și drepturi de publicare
• Runbooks and access (SSO/MFA) revizuite lunar

14. 2 În timpul incidentului

• IC atribuite, război-cameră deschisă, jurnalele de decizie începe
• Clasificare (P1/P2), selecție scenariu și degradare
• Acțiuni tehnice (feilover/limite/deconectări)
• Prima actualizare publică ≤ 15 minute
• SLA Notificări de reglementare/Partener
• Capturarea artefactelor pentru post-mortem

14. 3 După incident

• Post-mortem cu RCA și CAPA
• Actualizat BIA/praguri/rutine
• Remedieri de formare/retestare, raport de bord
• Financiar/reconciliere

15) Șabloane (fragmente)

15. 1 carte de script

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 Mesaj la pagina de stare

[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) Gestionarea documentelor și a versiunilor

Versioning BCP/Runbooks în depozit, schimbare-log, proprietarul documentului.
Perioada de revizuire (trimestrială pentru nivelul 1), controlul disponibilității copiilor offline.
Depozitarea artefactelor de foraj/incident și a măsurătorilor de performanță.

17) Foaie de parcurs de implementare (6-8 săptămâni)

Săptămânile 1-2: BIA și procesele critice, obiectivele RTO/RPO, lista scenariilor și proprietarilor.
Săptămânile 3-4: arhitectura modurilor de stabilitate și degradare, runbooks, șabloane de comunicare, contacte.
Săptămânile 5-6: integrarea furnizorilor (PSP/KYC/cloud), exerciții pilot (tabletop + DR parțial), ajustări.
Săptămânile 7-8: testul complet DR (dacă este posibil), lansarea ciclului de exerciții trimestriale, raportul consiliului și pachetul de reglementare (dacă este necesar).

18) Secțiuni wiki conexe

Registrul de risc, incidente și scurgeri, teste DR/BCP, TPRM și SLA, ISO 27001/27701, SOC 2, PCI DSS, IGA/RBAC/Log Policy/WORM - pentru o singură buclă de robustețe și probabilitate.

TL; DR

Eficient BCP = BIA→RTO/RPO→stsenarii și degradatsii→multi -vendor/multi-regiune + clar Incident Command, comunicații și exerciții. Păstrați documentul în viață, testați în mod regulat - și chiar și un accident mare nu va opri afacerea sau a lovit licențe.