Criteri di storage

1) Perché i criteri di conservazione

I criteri di conservazione determinano per quanto tempo e perché memorizzare ogni tipo di dati in cui è posizionato, chi risponde e come i dati vengono eliminati o anonimi. Senza di essi, è impossibile mantenere la privacy, la minimizzazione e la riproducibilità dei rapporti, specialmente in caso di PI/finanza sensibili, regolazione e indagini.

• Conformità a leggi/licenze e contratti con provider/PSP.
• Ridurre al minimo i rischi di perdite e multe.
• Prevedibilità dei costi di storage e delle prestazioni della piattaforma.
• Supporto per processi DSAR, Legali Hold, verifiche e versioni.

2) Principi di base

1. Storage di destinazione (purpose limitation) - La durata è associata a uno specifico scopo di elaborazione.
2. Minimizzazione: non conservare «per sicurezza»; Al termine dell'obiettivo, eliminare/anonimizzare.
3. Trasparenza e prova: ogni record deve avere un proprietario, una classe, una durata e una base.
4. Separazione degli ambienti: protesi/stage/arenili con scadenze e set di campi diversi.
5. Policy-as-Code: criterio come configurazione nel repository + convalida CI.
6. Defense in Depth - Memorizzazione + backup + registri di controllo + Legale Hold concordati tra di loro.

3) Classificazione e fondamento legale

Classi: Public/Internal/Confidential/Restringted (PII/Finanza) con i tag «pii», «financial», «tokenized», «backup», «legale _ hold», «wip», «dsar _ subject».

• Obblighi legali/licenze (ad esempio rapporti e AML).
• Esecuzione del contratto (transazioni/pagamenti).
• Interesse legittimo (sicurezza, antifrode) - con la valutazione dell'equilibrio.
• Consenso (marketing/personalizzazione) - con tempi e feedback separati.

4) Matrice di conservazione (manuale per iGaming)

5) Legale Hold e congelamento

Legale Hold annulla temporaneamente le cancellazioni/TTL per gli insiemi relativi a indagini/controversie.
La fonte della verità è il registro Legale Hold: proprietario, data, base, intervallo di dati, data di ritiro.
Ritiro - in base al processo approvato; tutte le rimozioni ritardate vengono avviate come giacche ritardate.

6) DSAR e «diritto di eliminazione»

Memorizzare i token dei soggetti (non PII) per la ricerca del grafico.
Mantenere la differenza tra eliminazione, alias e anonimizzazione.
Non rimuovere i record che sono obbligati a conservare in base alla legge - contrassegnare il vincolo di elaborazione; spiegate l'S.I.
Nei bacapi, eliminare le rotazioni future + contrassegnare «subject erased» nel livello attivo.

7) Backup, archivi e WORM

3-2-1: tre copie, due tipi di supporti/cloud, uno offline/air-gapped.
Crittografia con chiavi KMS/HSM indipendenti dal provider.
WORM per i report di controllo/regolazione.
Criteri di rotazione dei backup: la conservazione dei backup non deve superare i tempi dei dati attivi, a meno che non vi siano eccezioni obbligatorie.
Test di ripristino pianificato.

8) Transfrontaliera e geo-localizzazione

Geo-scoping - I dati e le chiavi di crittografia sono collegati alla regione/licenza.
La replica rispetta i tempi di conservazione e i limiti di trasferimento locali.
I contratti con i provider/PSP/KYC sono obbligati a riflettere i luoghi di stoccaggio e le scadenze.

9) Architettura di storage e automazione

• Raw/Bronze (tempo minimo, senza PII se possibile).
• Silver (fatti cancellati con TTL e maschera).
• Gold (unità/vetrine a lungo termine).
• Feature Store/Model Registry (versioning e time-travel senza PII).

• Lifecycle policies/TTL in oggetti/tabelle/argomenti.
• Criterio come codice: YAML/JSON con'purpose ',' retention _ period ',' post _ expery _ action ',' legale _ hold _ override '.
• CI-linter - Blocca il PR se il nuovo set è privo dì retence _ policy ".
• Controllo giornaliero «cosa scade domani/settimana».
• Delation jobs - Rimozione morbida, controllo delle dipendenze, rimozione solida/crittostirale.

10) Eliminazione, anonimizzazione, alias

Hard delete - Rimozione fisica (tenere conto delle cascate e della linea).
Soft delete - etichetta deleted _ at, nascondi, piano successivo hard delete.
Crypto-erase - Rimozione delle chiavi per l'indisponibilità dei dati.
L'anonimato è una trasformazione irreversibile; È possibile memorizzare le unità.
Alias - Sostituzione con token è obbligatorio il criterio chiavi/pepper e il divieto di reversibilità fuori dalla «zona pulita».

11) Metriche e SLO

Ritorno Coverage:% di set con criteri approvati.
On-time Delation - Percentuale di rimozioni effettuate entro la data di scadenza.
Zero-PII in Logs - Copertura dei loghi con maschera.
Legale Hold Accuracy: corrispondenza del Registro di sistema con congelamenti effettivi.
Backup Restore-Rate: test di ripristino completati.
DSAR SLA - Tempo medio di esecuzione delle query (per tipo).

Risparmio da aggregazione/TTL

12) RACI (esempio)

Criteri e standard: CDO/DPO (A), Governance Council (R/A), Legale (C), Security (C).
Directory e etichette: Data Stewards (R), Domain Owners (A), Platform (C).
Automazione/TTL: Platform/SRE (R), Sec (C).
Legale Hold/DSAR: DPO/Legale (A/R), Domini (C).
Controllo e backup: SecOps/SRE (R), Internal Auditel (C).

13) Modelli (pronto per l'uso)

13. 1 Criteri di conservazione (sketch)

Area - Elenca i domini e le eccezioni.
Motivi: obbligo legale/contratto/consenso/legittimo interesse.
Tempistica: tabella "dataset" period action ".
Legale Hold: processo di attivazione/ritiro.
DSAR: ordine di ricerca/rimozione/vincolo.
Backup/WORM: tempi, chiavi, test di ripristino.
Controllo: metriche, geloso ogni anno, proprietario della politica.

13. 2 Scheda set con retenzion

Dataset: `payments. transactions`

Classe Restrited (finanza)

Base: obbligo legale/contabilità

Periodo: N anni dalla data dell'operazione

Azione successiva alla scadenza: anonimizzazione di aggregazioni, hard delete parti

Legal Hold override: да

Responsabili: Owner/Steward, DPO

Tag/contratti: «pii», «tokenized», «retrazione: N», link al contratto

13. 3 criteri YAML (policy-as-code, frammento)

yaml dataset: payments. transactions purpose: accounting_and_aml class: restricted retention_period: P{N}Y    # ISO 8601 duration post_expiry_action: anonymize_then_delete legal_hold_override: true geo_scope: EU backups:
retention_period: P{N}Y worm: true audit:
enabled: true destination: worm://audit/payments

13. 4 Foglio di assegno di avvio

• Ogni dataset ha una carta e un criterio YAML
• Le regole di storage TTL/lifecycle sono abilitate
• Nella directory vengono visualizzati tempi/basi/proprietari
• Gli alert di scadenza e il report On-time Delation sono stati configurati
• Registro legale Hold sincronizzato con le bandiere di storage
• Script DSAR/Rimozione in backup

14) Road map di implementazione

0-30 giorni (MVP)

1. Inventario dei set e classificazione Assegnare i proprietari.
2. Aggiungi il campo Retention al contratto/directory; Avere le carte dei top set.
3. Abilita TTL/lifecycle per i fogli e i livelli raw; Divieto del PII nei cassetti.
4. Registro Legale Hold e processi; Report di base Coverage/On-time Delation.

30-90 giorni

1. Espandi policy-as-code (YAML) e CI-linter; Unità PR senza retenzion.
2. Implementare l'anonimato/alias post-scadenza automatizzare delation jobs.
3. Allineare i bacap ai tempi; Abilitare WORM per il controllo.
4. Collegare DSAR a ritensh e tornitura Report SLA.

3-6 mesi

1. Localizzazione geo di insiemi e chiavi politiche transfrontaliere.
2. Analisi avanzata dei costi di storage e degli effetti TTL.
3. Scadenza trimestrale con Legali/Domini; Controllo esterno.
4. Scalabilità su partner/provider (requisiti contrattuali per la riscossione).

15) Anti-pattern

«Conserviamo tutto per sempre», senza fondamento né piano di rimozione.
L'incongruenza è che l'asset è stato rimosso, e nei bacapi per sempre.
Assenza di Legale Hold, cancellazione delle prove.
Tempi uniformi per tutti i domini per semplicità.
DSAR senza effettiva rimozione in vetrine/fitch derivate.
Arenili con copie di prod-PII e una durata infinita.

16) Partizioni correlate

Gestione dei dati, Controllo degli accessi, Tokenizzazione dei dati, Sicurezza e crittografia, Origine e percorso dati, Controllo e versioni, Legale Hold e DSAR, Privacy ML.

Totale

Le politiche di conservazione trasformano il «magazzino caotico» in un archivio gestito: ogni campo conosce la data, la base e il destino. Per iGaming è la base della compilazione, del risparmio e della fiducia nei dati: si conserva abbastanza, ma non troppo, si è in grado di eliminare e dimostrare rapidamente, senza interrompere report, ML e processi operativi.