Piano di business continuity

1) Obiettivo, ambito e principi

Obiettivo: garantire la prosecuzione di servizi critici (depositi, scommesse/giochi, conclusioni, KYC/AML, sapport) in caso di guasti e ripristino rapido senza violazione di licenze e contratti.
Area: piattaforma online, circuito di pagamento, antifrode/CUS, DWH/BI, zapport, funzioni operative e legali, venditori chiave (PSP/KYC/cloud/CDN/studi/aggregatori).
I principi sono: safety first, il giocatore prima di tutto, correttezza regolatoria, minimizzazione RTO/RPO, semplici modalità di degrado, dimostrabilità e esercitazioni regolari.

2) BIA - Analisi dell'impatto sul business

Definire processi critici, entrate/uscite, dipendenze, alternative manuali e RTO/RPO mirati.

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) Script/minacce (Risk → Impatto → Response)

Quelli sono la caduta della regione della nuvola, l'interruzione del database, la perdita del cluster, gli attacchi di DDoS, il guasto del CDN.
Vendor: degrado PSP/KYC, rottura con l'aggregatore di giochi, non disponibile antifrode/screening sanzionatorio.
Cyber - Compromissione di documenti/chiavi, ransomware, perdita di PII.
Processi/persone: scioperi/malattie, cura di professionisti chiave, errore di comunicazione.
Geo/forza maggiore: interruzioni di comunicazioni/energia, rischi militari/sanzioni, blocchi di domini/traffico.

Per ciascuno, trigger, soglia di escalation, controlli, degrado del servizio e modelli di comunicazione.

4) Architettura di sostenibilità e strategia

Active-active/active-standby per regione infrastruttura as code per sollevamento rapido.
Modalità di degrado: vetrine read-only, disattivazione dei provider di giochi non critici, limiti di pagamento, «solo depositi» con cassauti ritardati (se legalmente accettabile), riduzione della frequenza di analisi/ETL.
Gestione traffica: Anycast CDN, geo-bilanciamento, health-checks, canary-routing.
Dati: Becap PITR, registri delle modifiche, replica interregionale, integrità crittografica (hash/WORM).
Chiavi/segreti: KMS per-region indipendenti, break-glass con registro.
PSP/KYC multi-homing: faulter automatico, routing SLA/Latence.

5) Struttura di comando

ID - Un unico punto decisionale.
Ops Lead (SRE/Platform) - Processo, feelover, metriche.
Business Continuity Lead - Coordinamento dei processi/procedure manuali.
Comms Lead - notifiche esterne/interne (giocatori, partner, regolatori).
Sicurezza/DPO - cyber-idratanti/privacy, finestre di regolazione.
Payments/KYC Leader - Script PSP/KYC.
Liaisons: Legal, Support, VIP/CRM, Data/BI.

Regola: un IC per incidente, canali chiari e logici di soluzioni.

6) Piano di comunicazione

Collegamenti: war-room (chat/ponte), collegamenti di riserva (telefono/radio/alt-messaggistica), contatti PSP/KYC/banche preconfezionati.
Modelli di messaggi esterni: pagina di stato, social media, email/push; il tono - fatti, tempistiche, passo successivo.
Regolatori e partner: indirizzi predefiniti, notifiche SLA; Termini concordati.
Giocatori: trasparenti ETA, rimborsi/bonus (se applicabile), FAQ per il periodo di degrado.

7) Piani operativi (Runbooks)

7. 1 Feelover in un'altra regione

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 degrado

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 provider KYC non disponibile

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) Ripristino IT e dati (DR)

Categorie di sistemi: Tier-1 (piattaforma/pagamento/CUS), Tier-2 (giochi/analisi), Tier-3 (interni).
Ordine di sollevamento: set→sekrety/KMS→BD→kesh→API→front/CDN→integratsii→analitika.
Controlli di integrità: checksum, verifica dei registri/replica, verifica delle transazioni.
Test DR completi ogni anno (switch-over), parziali trimestrali; fissa RTO/RPO effettivi.

9) Persone, uffici e logistica

Remote-ready: notebook/modem ridondanti, accesso SSO/MFA, accesso «rosso» per IC.
Località alternative: uffici di riserva/coworking, liste dei pass, piano di evacuazione.
Rotazione dei turni: matrice di competenze, duplicazione dei ruoli chiave, piano di sostituzione.
Provider di comunicazione/energia critici: contatti, SLA, generatori/UPS (se rilevanti).

10) Venditori e catena di fornitura

Requisiti BCP/DR nei contratti: RTO/RPO, test obbligatori, verifiche e esercitazioni congiunte.
Registro dei sottoprocessori: contatti, piani di outage, conferma di eliminazione/esportazione dei dati durante l'offboarding.
Cadute trimestrali Tier-1: incidenti, protocolli DR, stato dei certificati, SLA.

11) Formazione, esercitazione e test

Tabletop una volta al trimestre: PSP/KYC/cloud/cyber script.
Le esercitazioni sono DR parziali/completi; DDoS/failover CDN; «kill-switch» dei provider SDK.
Esercitazioni di comunicazione: comunicato stampa/stato-aggiornamento/email di regolazione.
Retrospettive: timeline, RCA, CAPA, aggiornamento runbooks e BIA.

12) Metriche (KPI/KRI)

RTO/RPO dato (Tier-1) - Corrispondono agli obiettivi del 95%.
MTTD/MTTR: trend al ribasso; L'MTTR ha avuto incidenti critici.
Successo del feelover senza perdita di dati/ordini/scommesse, X-min di degrado.
L'esercitazione di Coverage è di 2 test DR completi/anno + 4 tavoletop.
Il tempo fino al primo update è di 15 minuti, frequenza di aggiornamento secondo la politica.
Vendor resilience: percentuale di Tier-1 con test DR confermati per 12 mes - 100%.

13) RACI (ingrandito)

14) Assegno fogli

14. 1 Ready-to-Failover

• Contatti aggiornati IC/venditori/regolatori
• Replica sana, bap PITR regolare
• Convalidato «kill-switch» per SDK/webhoop
• Gestore di traffico (GSLB/CDN) con health-checks verificati
• Modelli di stato/lettere e diritti di pubblicazione
• Runbooks e accessibilità (SSO/MFA) verificati mensilmente

14. 2 Durante l'incidente

• L'IC è stato assegnato, la war-room è aperta, l'avvio dei fogli di soluzioni
• Classificazione (P1/P2), selezione di script e degrado
• Prestazioni (faulover/limiti/disattivazione)
• Primo apdate pubblico 15 minuti
• Notifiche SLA regolatorie/partner
• Cattura di manufatti per il post mortem

14. 3 Dopo l'incidente

• Post mortem con RCA e CAPE
• Aggiornati BIA/soglie/routine
• Allenamento/retest di fissaggio, report borgo
• Incrociamento finanziario/riconducibile

15) Modelli (sezioni)

15. 1 Scheda 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 Messaggio di stato

[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) Gestione di documenti e versioni

Versioning BCP/Runbooks nel repository, change-log, proprietario del documento.
Tempi di revisione (trimestrale per Tier-1), controllo della disponibilità delle copie offline.
Stoccaggio di manufatti di esercitazioni/incidenti e metriche di efficienza.

17) Road map di implementazione (6-8 settimane)

Settimane 1-2: BIA e processi critici, obiettivi RTO/RPO, elenco di script e proprietari.
Settimane 3-4: architettura di stabilità e modalità di degrado, runbooks, modelli di comunicazione, contatti.
Settimane 5-6: integrazione con i venditori (PSP/KYC/cloud), esercitazioni pilota (tabletop + part DR), regolazioni.
Settimane 7-8: test DR completo (se possibile), avvio del ciclo di esercizio trimestrale, report borghi e pacchetto regolatore (se necessario).

18) Sezioni wiki collegate

Registro dei rischi, Incidenti e fuoriuscite, test DR/BCP, TPRM e SLA, ISO, SOCC, PCI DSS, IGA/RBAC/Least Privilege, Loga/WORM - per un unico tracciato di stabilità e prova

TL; DR

Efficiente BCP = BIA→RTO/RPO→stsenarii e degradatsii→multi/regione multi + chiaro Incent Comment, comunicazioni e esercitazioni. Mantenere il documento vivo, testare regolarmente, e anche un guasto grave non fermerà il business o colpirà le licenze.