Eliminazione e anonimato dei dati

1) Obiettivo e area

Assicurarsi che i dati dei giocatori, le transazioni e i registri operativi vengano eliminati/anonimizzati in modo legale, sicuro e sicuro in tutti i sistemi (prodotto/portafoglio, KYC/AML, RG, marketing/CRM, analista/DWH, logi/ARM), inclusi vendor/provider e bacap, tenendo conto della localizzazione per giurisdizione.

2) Principi

1. La politica è prima della pratica. La retensione, gli obiettivi e i luoghi di stoccaggio sono definiti prima della raccolta.
2. Minimizzazione e separazione. Storage per PII separato, tornitura in eventi.
3. Elimina = evento di prova. Qualsiasi rimozione è confermata da un artefatto.
4. Fail-Closed. Stato/regione sconosciuto impedito transazioni con PII.
5. Backups-aware. I Becap seguono le stesse regole dei dati di guerra.
6. «Anonimato anziché conservare a tempo indeterminato». Se la legge non richiede la PII, la tradurremo in aggregazioni.

3) Ruoli e RACI

DPO/Compliance (Owner) - Regola di ritenzione/rimozione, esclusione, controllo. (A)

Sicurezza/Infra - crittografia, chiavi, crittografia, backap/DR. (R)

Data Platform/Analytics - de-PII pipline, unità, DWH/DL. (R)

Product/Engineering/SRE - API rimozione, cascate, test, osservabilità. (R)

Legale - Tempi e limiti locali (AML/licenza). (C)

Privacy Ops/DSAR Team - Rimozioni/correzioni personalizzate. (R)

Vendor Manager - Obblighi dei venditori, convalida dell'esecuzione. (R)

Controllo internazionale - campionamento, CAPA. (C)

4) Tassonomia dei dati e standard di retensione

5) Tecniche tecniche

5. 1 Eliminazione

Logico/fisico a cascata: soft-delete → job per l'eliminazione fisica.
Crypto-cancellazione (crypto-shredding) - Distrugge la chiave di crittografia del segmento/tenante; si applica ai backap/archivi.
Revocation token: ritiro dei token di pagamento/tracker presso i provider.
Nullify/Mask: per i campi che richiedono il salvataggio formale di un record (ad esempio, contabilità).

5. 2 Alias

Sostituzione degli ID primari con i token la tabella di corrispondenza è memorizzata separatamente da un singolo KMS.

5. 3 Anonimato

Aggregazione/cocorting, K- Diversity, binning, ritaglio di valori rari, privacy differenziale nei rapporti.

5. 4 Maschera dei tubo

L'agente modifica il PII durante la raccolta (e. g., e-mail → hash/partial), inibizione degli identificatori crudi nell'APM.

6) Ciclo di vita di eliminazione

1. Trigger: timeout, DSAR-erase, chiusura dell'account, revoca del consenso, completamento del contratto/scopo.
2. Valutazione: ci sono blocchi legali? (AML/legal-hold/licenza).
3. Orchestrazione: viene generato un pacchetto erasure per sistemi/venditori.
4. Esecuzione: cascate, token revoke, cripto-wipe per gli archivi.
5. Convalida - Comprimere i record, controllare i residui (orphaned data).
6. L'artefatto è un resoconto con hash di partiture/chiavi, tempo e volume.
7. Reportage: dashboard KPI, registro di controllo/controllo.

7) Zone di attenzione speciali

7. 1 Backap/archivi/DR

Becap nella stessa regione, crittografia e catalogazione delle chiavi.
Realisticamente, l'eliminazione fisica dall'immutabile-backup è difficile da applicare al termine del segmento crypto-shredding.

7. 2 Logi e telemetria

Criterio PII-free by default; se il PII è inevitabile - logi locali, tempi brevi, occultamento su un agente.

7. 3 DWH/analista

Solo dati de-PII; Se necessario, gli storici devono anonimizzare e interrompere il legame con il PII originale.

7. 4 Venditori e provider

DPA/supplemento: tempi, meccanismi di rimozione, convalida di esecuzione (Certificate of Descrizione/Erase Evidence).

7. 5 Localizzazione per giurisdizione

La rimozione avviene in un perimetro regionale e l'esportazione PII non è consentita. i report globali sono solo aggregazioni.

8) API/ivent e modello di dati

• `retention_due_detected`, `erasure_job_started`, `erasure_job_completed`, `crypto_shred_done`, `vendor_erasure_ack_received`, `erase_validation_failed`, `dsar_erase_linked`, `audit_artifact_saved`.

erasure_job {
id, subject_id_hash    scope{cohort    partition}, trigger{retention    dsar    contract_end    consent_withdrawn},
market, region, systems[], vendors[],
started_at_utc, completed_at_utc, status{ok    partial    failed},
method{cascade    crypto_shred    nullify    token_revoke},
counts{records, tables, bytes}, checksum{before, after},
keys_destroyed[{kms_key_id, destroyed_at_utc, evidence_id}],
validation{orphan_scan:passed    failed, sample_checks[]},
linked_cases{dsar_case_id?}, owner, approvers{dpo, security}, audit_artifacts[]
}

9) Controllo e osservazione

Erasure Coverage è la quota di sistemi coperti da rimozione automatica.
Time-to-Erase - Tempo medio dal trigger al completamento.
Orphaned Data Rate - Registrazioni «orfane» rilevate.
Backup Crypto-Shred SLA - Chiavi cancellate in tempo.
Vendor Ack Rate - Percentuale di conferma di distanza dai venditori entro il termine.
DSAR Erase SLA - Rispetto dei tempi di eliminazione personalizzati.
Auditability Score - La presenza di manufatti selezionati.

10) Assegno fogli

A) Politica e progettazione

• Il Registro delle retenze per categoria/mercato è approvato da Legale/DPO.
• Mappa dei sistemi/venditori con indicazione PII/regioni/chiavi.
• Metodi definiti: cascata/cripto-wipe/de-PII per gli analisti.
• DPA/contratti aggiornati (SLA rimozione, conferma).

B) Tecnica e operazioni

• L'API di rimozione e l'orchestratore di operazioni sono attivati.
• I logi/agenti PII-free mascherano i campi sensibili.
• Bacap criptati, chiavi segmentate nei mercati.
• Autostop: DSAR-erase, cron retence, orphan-scan.
• Dashboard KPI/alert.

C) Controllo e miglioramenti

• Campionamenti trimestrali di sistemi/venditori con manufatti di rimozione.
• Test DR/ripristino in base ai segmenti remoti.
• CAPE per i residui/violazioni trovati.

11) Modelli (inserimento rapido)

A) Clausola con venditore (rimozione/retenza)

B) Soluzione di anonimizzazione (modulo interno)

C) Risposta all'utente (DSAR-erase completato)

12) Errori frequenti e prevenzione

Rimozione dal database di guerra, ma non dai backup.
PII nei →/ARM.
Registrazioni orfane (servizi crociati), → Orphan scan e cascate contrattuali.
DWH con code PII. Pipline De-PII prima dell'esportazione.
Nessun artefatto. Generazione di report obbligatoria e archiviazione WORM.
Wendor non ha cancellato.

13) Piano di implementazione di 30 giorni

Settimana 1

1. Approva il registro delle retenze e la matrice dei metodi (cascata/cripto/de-PII).
2. Mappare sistemi/venditori/chiavi, segnare perimetri regionali.
3. Specializzare il modello di manufatti e dashboard KPI.

Settimana 2

4) Realizzare l'orchestratore di rimozione, l'API e gli eventi; Collegare i links DSAR.
5) Includi la mascheratura dei logi e le regole «PII-free by default».
6) Configura crypto-shred per i backup, segmentazione KMS sui mercati.

Settimana 3

7) Di-PII catena di montaggio per DWH (kohort/k-anonimato/binning).
8) Rimozione pilota: 20 valigette DSAR + 2 partenze di retenza; chiudi CAPE.
9) Aggiorna la DPA con i venditori chiave (SLA/conferma).

Settimana 4

10) Rilascio completo; avvia dashboard e alert (Time-to-Erase, Vendor Ack).
11) Test DR con segmento di chiavi remote.
12) Piano v1. 1: diff. privacy nei rapporti, auto-orphan-scan pianificati.

14) Sezioni interconnesse

Gestione del consenso utente GDPR

Cookie e sistemi CMP

Ideazione di Privacy by Design

Localizzazione dei dati per giurisdizione

Query dati DSAR

Crittografia At Rest/In Transit, KMS/BYOK/HYOK

Dashboard compilazione e monitoraggio/Verifiche interne ed esterne