Operazioni e Gestione dei processi Business Continuity

BCP

1) Cos'è BCP e perché è necessario

BCP (Business Continuity Planning) è un approccio di sistema per garantire la sostenibilità dei processi aziendali in caso di guasti, dall'interruzione del datacentro alla crisi del provider, alla perdita dei dati o all'aumento improvviso del carico di lavoro.
Nei prodotti ad alto consumo (iGaming, fintech, marketplace) non si tratta solo di infrastrutture, ma di mantenere la fiducia, rispettare gli obblighi regolatori e proteggere i ricavi.

• Mantenere la disponibilità di servizi e dati critici.
• Ridurre i tempi di ripristino (RTO) e la perdita di dati (RPO).
• Garantire l'operatività di comandi, comunicazioni e partner esterni in crisi.
• Standardizzare la risposta e la formazione del personale.

2) Componenti principali BCP

1. BIA - Valutazione dell'impatto dei guasti su processi e business.
2. I rischi e gli scenari sono la matrice delle minacce (infrastrutture, esterne, umane).
3. Obiettivi RTO/RPO - Obiettivi di ripristino e perdite consentite.
4. Piano di ripristino (DRP) - Operazioni dettagliate per riavviare sistemi e processi.
5. Comunicazioni - canali interni ed esterni, modelli di notifica.
6. Test e revisione - controlli regolari, esercitazioni, post-analisi.
7. Documentazione e controllo delle versioni - Accesso centralizzato e rilevanza.

3) Analisi dell'impatto (BIA)

BIA determina quali processi sono critici e la rapidità con cui devono essere ripristinati.

1. Elenco di tutti i processi aziendali (Payments, Bets, Games, KYC, Support).

2. Definizione delle dipendenze (servizi, dati, provider, dipendenti).

3. Valutazione dell'impatto del rifiuto: finanziario, legale, reputazionale, operativo.

4. Imposta RTO/RPO per ogni processo.

5. La priorità è Must Have, Should Have, Nice to Have.

4) Matrice dei rischi

5) RTO, RPO e livelli di criticità

RTO (Recovery Time Objective) - Quanto tempo è consentito prima del ripristino.
RPO (Recovery Point Objective) - Quale quantità di dati è possibile perdere.

6) DRP (Disaster Recovery Plan)

Obiettivo: ripristinare i sistemi in modo rapido e coerente.

1. Identificare gli script (disastro del centro dati, guasto del PSP, compromissione delle chiavi, perdita della rete).

2. Ogni script è un playbook passo passo.

3. Supporto dell'infrastruttura DR: cluster di backup, repliche database, CDN/edge.

4. Test regolarmente RTO/RPO e procedure failover.

5. Conserva tutte le istruzioni in un unico archivio con controllo versione.

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) Organizzazione di comandi e ruoli

Coordinatore BCP: proprietario del programma, organizza revisioni e test.
DR lead: responsabile dell'implementazione tecnica dei piani DR.
Domain Owners garantisce la continuità dei processi (Payments, Games, KYC).
Comando comunicazione - Responsabile delle notifiche interne/esterne e delle piattaforme di stato.
HR/Ammin: BCP per il personale (remoto, comunicazioni, accessibilità).
Legale/Compliance: notifiche regolatorie e misure legali.

8) Comunicazioni in crisi

• Canali chiari e contatti di riserva.
• Il primo update è nei 15 minuti successivi all'incidente.
• Un unico tono di comunicazione, i fatti e l'ETA.
• Aggiornamenti ogni N minuti prima della chiusura dell'incidente.
• Dopo il recupero, un rapporto e un secondo passo.

[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) Test e esercitazioni

Test tecnici: failover, recupero del database, simulazioni di DDoS.
Operazioni operative: handover/cambio di ruolo comandi.
Esercizi BCP completi: script «blackout» o non disponibile per il provider.

• Test DR - trimestrale;
• L'insegnamento BCP completo è 1-2 volte l'anno.
• Documentazione: risultati, deviazioni da RTO/RPO, azioni di miglioramento.

10) Metriche e KPI

RTO compliance:% dei processi ripristinati dall'obiettivo.
RPO compliance:% di processi senza perdita di dati> target.
DR test success rate: convalida corretta delle procedure di ripristino.
BCP coverage - Percentuale di processi con piani aggiornati (> 90%).
Comms SLA: primo riepilogo di 15 min, aggiornamenti per ETA.

Postmortem SLA: 100% eventi critici con analisi ≤ 72 ore

11) Documentazione e gestione delle conoscenze

Un unico archivio BCP (versioni, proprietari, date di revisione).
Revisione delle versioni, almeno una volta ogni 6 mesi.
Disponibilità: copie offline e collegamenti di backup (inclusi TV/messaggistica).
Integrazioni: collegamento a BCP in SOP, workflow e dashboard operativi.
Sincronizza con Risk Registrer e Security Policies.

12) Piano di implementazione 30/60/90

• Identificare il proprietario BCP e i processi critici.
• Esegui BIA di base e classificazione (RTO/RPO).
• Creare una matrice di rischio e una directory di script di incidente.
• Sviluppare il modello DRP e la prima versione per i servizi prioritari.

• Eseguire un test pilota DR (failover, ripristino del database).
• Preparare modelli di comunicazione e distribuzione di ruolo.
• Creare un unico archivio di documenti BCP e un'integrazione SOP.
• Inizia la formazione dei team e dello staff on-call.

• Fare un insegnamento BCP interoperabile.
• Controlla la corrispondenza RTO/RPO e le metriche KPI.
• Finalizzare il piano di revisione e l'automazione dei processi BCP.
• Includi BCP nei controlli di sicurezza trimestrali e interni.

13) Anti-pattern

«BCP solo per spunta»: nessun test o proprietario effettivo.
Istruzioni DR obsolete che non sono compatibili con le architetture correnti.
Canali di comunicazione e contatti non verificati.
Dipendenze non registrate (PSP, CDN, KYC provider).
Nessuna postmortem dopo un guasto.
Nessun accesso offline al BCP quando la rete crolla.

14) Struttura documento BCP di esempio

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) Integrazione con altre sezioni

Analista operativo: metriche di headroom e degrado prima degli incidenti.
Sistema di notifiche e alert: segnali iniziali per l'avvio delle procedure BCP.
Gestione etica: report trasparenti e test onesti.
Assistenti AI - Preparazione automatica di dashboard BCP e DR-CHECK.
Cultura della responsabilità: formazione, «game days», retrospettive.

16) FAQ

Q: Qual è la differenza tra BCP e DRP?
A: BCP - più ampio - comprende persone, processi, comunicazioni, partner e infrastrutture. DRP è un piano tecnico per il ripristino dei sistemi IT.

Q: Quanto spesso aggiornare BCP?
A: Dopo ogni grande cambiamento di architettura, incidente o almeno 1 volta ogni 6 mesi.

È necessario includere i partner?
A: Sì. PSP, KYC e studi fanno parte della catena di continuità, devono avere i propri accordi OLA e BCP.