Procedure di fuga dati

1) Obiettivo e ambito di applicazione

Obiettivo: ridurre al minimo i danni, soddisfare i requisiti legali e ripristinare rapidamente il normale funzionamento in caso di conferma o probabile perdita di dati personali/pagamenti/operativi.
Copertura: giocatori e dipendenti PII, manufatti di pagamento, loghi/token di accesso, documenti KYC/AML, dati di affiliati/partner, manufatti sensibili di prodotti e infrastrutture.

2) Definizioni e criteri di fuoriuscita

Data breach - Violazione della privacy, dell'integrità o della disponibilità dei dati personali (o di altre informazioni protette) a causa di un incidente di sicurezza o di un errore di processo.
Sospetto di vs confermato: qualsiasi indicatore (anomalie SIEM, messaggi da venditore/utente, siti web paste) avvia la procedura prima di essere smentito.

3) Classificazione della serietà (esempio)

4) SLA e «incidente bridge»

Iniziazione: in Medium + viene creata una war-room (chat/chiamata) e viene assegnata un'ID.
SLA: Low - 24 h· Medium - 4 h· High - 1 h· Critical - 15 min.
Cadence update: ogni 30-60 minuti (interni), ogni 2-4 ore (esterni interessati).

5) RACI (ingrandito)

6) Procedura di risposta (passo passo)

1. Identificazione e convalida primaria

Il segnale SIEM/EDR/antifrode/venditore/utente ha registrato il registro degli incidenti.
Raccolta dei fatti minimi: cosa/quando/dove/quanto, i tipi di dati e la giurisdizione interessati.

2. Containment (contenimento)

Disattivazione di endpoint/fich vulnerabili, geo-segmenti, limiti di tempo, congelamento dei rilasci.
Rotazione chiavi/token, recensione, blocco degli account compromessi.

3. Eradication (eliminazione)

Patch/config-fix, pulizia di manufatti malevoli, rivisitazione delle immagini, controllo dei sottoprocessori.

4. Recovery (ripristino)

Immissione di traffico canareo, monitoraggio delle regressioni, assegni di integrità.

5. Forensica e valutazione dell'impatto

Conteggio del volume, della sensibilità, della geografia, del rischio per i soggetti; conferma dei record interessati.

6. Notifiche e comunicazioni

DPO/Legale determinano l'obbligo e la data di notifica; Preparazione di testi Invio ai destinatari.

7. Post mortem e CAPA

Analisi delle cause (5 Whys), piano di misure correttive/preventive con proprietari e scadenze.

7) finestre di 72 ore e destinatari legali (indicazioni)

Controllo dati (DPA) - Notifica entro 72 ore dalla rilevazione di una fuoriuscita significativa, a meno che non sia escluso il rischio per i diritti/le libertà dei soggetti.
Gli utenti sono «senza ritardo eccessivo» ad alto rischio (con raccomandazioni comprensibili).
Regolatore del gioco d'azzardo - con impatto su giocatori/sostenibilità/rapporti.
Banche/PSP - in caso di rischi di pagamento/compromissione di token/transazioni sospette.
Partner/venditori - Se i flussi/dati comuni sono danneggiati o sono richiesti.

8) Forenzica e «catena di conservazione delle prove»

Istantanee di volumi/logi, esportazione di manufatti con hashtag (SHA-256).
Lavorare solo con copie/snapshot; i sistemi di origine sono read-only.
Protocollo di azione: chi/quando/cosa ha fatto, comandi/strumenti usati.
Storage in un archivio oggetti/WORM accesso limitato, controllo.

9) Comunicazioni (interne/esterne)

I principi sono i fatti, le misure, le raccomandazioni, il prossimo apdate.
Non possiamo pubblicare PII, fare ipotesi non verificate, promettere scadenze senza controllo.

• Che cosa è stato scoperto? Scala/categoria Le misure in corso sono Rischi· I seguenti passaggi sono il prossimo update in HH: MM.

10) Interazione con venditori/sottoprocessori

Controlla i loro registri di incidenti, login di accesso, notifiche SLA, elenco dei sottoprocessori.
Richiedi report (pentest/forensica), registra la conferma dell'eliminazione/restituzione dei dati.
Se la DPA non è compatibile, l'escalation e l'isolamento temporaneo o la sospensione dell'integrazione.

11) Modelli di notifica (sezioni)

11. 1 Autorità di controllo (DPA)

Breve descrizione dell'evento e dell'orario di rilevamento, categorie/quantità approssimativa di dati, gruppi di soggetti, geografia, effetti e rischi, azioni prese/pianificate, contatto DPO, applicazioni (timeline, hash dashboard).

11. 2 Utenti

Cos'è successo; quali dati potrebbero essere stati danneggiati; quello che abbiamo fatto; cosa si può fare (cambio della password, controllo delle transazioni, consigli di phishing); come contattare; collegamento a FAQ/centro di supporto.

11. 3 Partner/PSP/Regolatore

I fatti e le interfacce interessate le azioni previste del partner deadline Contatti.

12) Registro degli incidenti (minimo campi)

ID Tempo di Rilevamento/Conferma La Gravità La Fonte I Sistemi/Dati Il Volume/Le Categorie Di Geografie I Venditori Coinvolti Le Misure Adottate (in ordine di tempo) Le notifiche (In/Quando) I RESPONSABILI· I Riferimenti agli Artefatti SARA/Tempistica.

13) Metriche e target

MTTD/MTTC/MTTR.
% di notifiche a 72 ore - 100%.
La percentuale di incidenti alla causa principale è pari al 90%.
La CAPA è chiusa entro il 95%.
Incidenti ripetuti per una ragione: 5%.
La percentuale di incidenti chiusi nella SLA (Medium/High/Critical) è del 90/95/99%.

14) Assegno fogli

14. 1 Partenza (primi 60 minuti)

• L'IC è stato assegnato e la war-room è aperta
• Misure di stabilizzazione (interruzioni/limiti/rotazione delle chiavi)
• Raccolta dei fatti minimi e degli screenshot/logi
• È stato notificato il DPO/Legale, è stata definita la classe proliminary
• Congelamento di lanci e protocolli di pulizia

14. 2 Fino a 24 ore

• Forenzica: volume/categorie/geografia (draft)
• Risoluzione delle notifiche, preparazione dei testi
• Piano di recovery/verifica integrità
• Pacchetto prove in WORM, timeline eventi

14. 3 Fino a 72 ore

• Invio di notifiche DPA/Regolatori/PSP (se necessario)
• Comm per gli utenti (ad alto rischio)
• Piano CAPE aggiornato, proprietari e scadenze

15) Tipi di script e misure

A) Esportazione di zapport chat in un segmento di storage aperto

Misure: chiusura dell'accesso, inventario dei download, notifica ai soggetti interessati, rafforzamento dei criteri S3/ACL, regole DLP per l'esportazione.

B) Compromettere i token di accesso all'API

Azioni: rotazione immediata, ritiro dei token refresh, controllo del registro delle chiamate, e-firma webhoop, segmentazione del traffico.

C) Fuga di scene KYC attraverso il venditore

Misure: isolamento dell'integrazione, conferma dell'eliminazione, revisione manuale dei client high-risk, revisione DPA/trattenute.

D) Pubblicare il digiuno nel paraurti

Le misure sono: fissazione dei manufatti (hashtag), rimozione legale dei collegamenti (takedown), notifiche, monitoraggio di ulteriori pubblicazioni.

16) Integrazione con la compliance e la privacy

Collegamento con processi GDPR: DSAR, RoPA, DPIA/DTIA; Aggiorna Criteri e cookie/CMR quando i fornitori o gli obiettivi cambiano.
Includere l'incidente nella matrice dei rischi e rivedere le soglie/controlli.

17) CAPE e post mortem (≤ 72 ore dopo la stabilizzazione)

Struttura del report: fatti/timeline· impatto· causa primaria che ha funzionato/no l'elenco CAPA (proprietario, data di scadenza, criterio di successo)· data di convalida dell'efficacia (tra 30-60 giorni).

18) Road map per la maturità del processo

Mese 1 - Aggiornare playbook, contatti, modelli, archivio WORM, test di notifica.
Mese 2: esercitazioni tabletop (perdita di PII/vendor/token), playbook SOAR.
Mese 3 +: retrospettive trimestrali, verifiche dei venditori, test bias antifrode/rilevamento, revisione regolare delle soglie.

TL; DR

In caso di perdita: stabilizziamo rapidamente (containment), confermiamo (forensica), notifichiamo in tempo (DPA/utenti/partner), documentiamo in modo trasparente (registro, timeline, prove) e correggiamo la causa principale (CAPA). Risultato: meno danni, conformità e fiducia ripristinata di giocatori e partner.