Politici de păstrare

1) De ce politici de stocare

Politicile de retenție determină cât timp și de ce stocați fiecare tip de date, unde sunt plasate, cine răspunde și cum sunt șterse sau anonimizate datele. Fără ele, este imposibil să se mențină confidențialitatea, minimizarea și reproductibilitatea raportării, în special în iGaming cu PII/finanțe sensibile, reglementări și investigații.

• Respectarea legilor/licențelor și acordurilor cu furnizorii/PSP.
• Minimizați riscurile de scurgeri și amenzi.
• Costuri de stocare previzibile și performanța platformei.
• Suport pentru procesele DSAR, Legal Hold, audit și versioning.

2) Principii de bază

1. Limitarea scopului - Termenul este legat de un anumit obiectiv de prelucrare.
2. Minimizare: nu stocați „doar în caz”; la sfârșitul obiectivului - ștergeți/anonimizați.
3. Transparență și probabilitate: fiecare înregistrare trebuie să aibă un proprietar, o clasă, un termen și o bază.
4. Separarea mediilor: prod/stage/sandboxes cu date și seturi diferite de câmpuri.
5. Policy-as-Code: politica ca configurație în verificarea depozitului + CI.
6. Apărare în profunzime: stocare + backup-uri + jurnale de audit + Legal Hold sunt consecvente.

3) Clasificarea și temeiurile legale

Clase: Public/Intern/Confidential/Restricted (PII/finance) cu etichetele: 'pii', 'financiar', 'tokenized', 'backup', 'legal _ hold',' wip ',' dsar _ subject '.

• Obligație juridică/licențiere (ex. raportare și LMA).
• Executarea contractului (tranzacții/plăți).
• Interes legitim (securitate, antifraudă) - cu o evaluare a soldului.
• Consimțământ (marketing/personalizare) - cu termene și feedback separat.

4) Matrice de valabilitate (referință pentru iGaming)

cheie> Personalizați jurisdicțiile și licențele. Mai jos sunt categorii aproximative și ferestre tipice de stocare.

5) Legal Hold și congela

Legal Hold anulează temporar ștergerile/TTL-urile pentru seturi legate de anchetă/litigiu.
Sursa adevărului este registrul Legal Hold: proprietar, data, motivul, intervalul de date, data retragerii.
Îndepărtarea - în conformitate cu procesul aprobat; toate întârzierile întârziate sunt întârziate.

6) DSAR și „dreptul de a șterge”

Stocați jetoanele subiect (nu PII) pentru căutarea graficului.
Menţineţi distincţia dintre ştergere, aliasare şi anonimizare.
Nu ștergeți înregistrările care trebuie stocate prin lege - marcați limita de prelucrare; explică subiectul.
În backup-uri - ștergerea pe rotații viitoare + marcaje „subiect șters” în stratul activ.

7) Backup-uri, arhive și WORM

3-2-1: trei copii, două tipuri de medii/nori, unul offline/aer-gapped.
Criptare cu chei KMS/HSM independente de furnizor.
WORM pentru audit/raportare de reglementare.
Politica de rotație de rezervă: perioada de stocare a backup-urilor nu trebuie să depășească perioada de date active, dacă nu există excepții obligatorii.
Test de restaurare programat.

8) Transfrontalieră și geo-localizare

Geo-scoping: Cheile de date și de criptare sunt legate de regiune/licență.
Replicarea respectă perioadele de păstrare locale și limitele de transmisie.
Contractele furnizor/PSP/KYC sunt necesare pentru a reflecta locațiile de stocare și calendarul.

9) Arhitectura de stocare și automatizare

• Raw/Bronze (termen minim, fără PII, dacă este posibil).
• Argint (fapte șterse cu TTL și mascare).
• Aur (unități/afișaje pe termen lung).
• Feature Store/Model Registry (versioning și călătorie în timp fără PII).

• Politici de ciclu de viață/TTL în obiecte/tabele/subiecte.
• Politica ca cod: YAML/JSON cu 'scop', 'retention _ period',' post _ expiration _ action ',' legal _ hold _ override '.
• CI Linter: blochează PR dacă este nou set fără 'retention _ policy'.
• Programator: Zilnic „ce expiră mâine/în săptămână” verificați.
• Lucrări de ștergere: ștergere soft → verificare dependență → ștergere/ștergere cripto hard.

10) Ștergere, anonimizare, pseudonimizare

Ștergere dură - ștergere fizică (luați în considerare cascadele și descendența).
Soft delete - eticheta 'deleted _ at', ascunderea, planul pentru ștergerea ulterioară hard.
Crypto-șterge - ștergeți cheile pentru indisponibilitatea datelor.
Anonimizarea este o transformare ireversibilă; este permisă depozitarea unităților.
Pseudonimizare - înlocuire cu jetoane; politica cheie obligatorie/piper și interzicerea reversibilității în afara „zonei curate”.

11) Metrics și SLO

Acoperire de retenție% seturi cu politica aprobată.
Ștergerea la timp - procentul de ștergeri finalizate la timp.
Zero-PII în jurnale: busteni de mascare.
Legal Hold Precizie: coincidență registru cu înghețuri reale.
Backup Restore-Rate: testul de succes restabilește.
SLA DSAR Timpul mediu de execuție a interogării (după tip).
Cost vs Retenție: Economii de agregare/TTL.

12) RACI (exemplu)

Politici și standarde: CDO/DPO (A), Consiliul de guvernanță (R/A), Juridic (C), Securitate (C).
Directory and labels: Stewards de date (R), Proprietarii de domenii (A), Platforma (C).
Automatizare/TTL: Platformă/SRE (R), Sec (C).
Legal Hold/DSAR: DPO/Legal (A/R), Domenii (C).
Audit și backup-uri: SecOps/SRE (R), Audit intern (C).

13) Șabloane (gata de utilizare)

13. 1 Politica de păstrare (miniatură)

Domeniul de aplicare: enumerarea domeniilor și a excepțiilor.
Motive: datorie legală/contract/consimțământ/interes legitim.
Date: tabelul 'dataset → perioada → acțiune'.
Legal Hold: Procesul de incluziune/retragere.
DSAR căutare/ștergere/limită ordine.
Backup-uri/WORM: termene limită, chei, test de recuperare.
Control: valori, revizuire anual, proprietarul politicii.

13. 2 Cardul de apelare de retenție

Set de date: "plăți. tranzacții "

Clasa: Restricționat (Finanțe)

Baza: datorie legală/contabilitate

Termen: N ani de la data funcționării

Acțiune după termenul limită: anonimizarea agregatelor, ștergerea pieselor

Reținere legală: да

Responsabil: Proprietar/Steward, DPO

Etichete/contracte: „pii”, „tokenized”, „retention: N”, referinta contract

13. 3 Politica YAML (politică ca cod, fragment)

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 Lista de verificare de pornire

• Fiecare set de date are un card și o politică YAML
• Reguli TTL/ciclu de viață activat în seifuri
• Datele/motivele/proprietarii sunt afișate în catalog
• Configurați alerte de expirare și raport de ștergere la timp
• Legal Hold registry sincronizat cu steaguri de stocare
• Tabelul-top DSAR script/șterge în backup-uri

14) Foaia de parcurs privind implementarea

0-30 zile (MVP)

1. Stabilește inventarul și clasificarea; atribuie proprietari.
2. Adăugați câmpul „reținere” la contract/director; creați cărți de top set.
3. Activați TTL/ciclu de viață pentru bușteni și strat brut; Interdicția PII în jurnale.
4. Legal Hold Registry and Process; Rapoarte de acoperire/ștergere la timp.

30-90 zile

1. Implementarea politicilor-as-code (YAML) și CI linter; Unitate de PR fără „reținere”.
2. Implementarea anonimizării/pseudonimizării post-termen; automatizarea lucrărilor de ștergere.
3. Aduceți copii de rezervă în conformitate cu termenele limită; Activați WORM pentru audit.
4. Asociați DSAR cu Retench și Tokenization; Rapoarte SLA.

3-6 luni

1. Geo-localizarea seturilor și cheilor; politicile transfrontaliere.
2. Costuri avansate de stocare și analiza efectului TTL.
3. Revizuiri trimestriale pe termen cu juridice/domenii; audit extern.
4. Scalarea către parteneri/furnizori (cerințe contractuale pentru recalificare).

15) Anti-modele

„Păstrăm totul pentru totdeauna” - fără motiv și un plan de îndepărtare.
Inconsecvență: activul este șters, iar în backup-uri - pentru totdeauna.
Absența Legal Hold: ștergerea probelor.
Termeni uniformi pentru toate domeniile „pentru simplitate”.
DSAR fără îndepărtarea reală în vitrine/caracteristici derivate.
Cutii de nisip cu copii ale prod-PII și termen nesfârșit.

16) Secțiuni conexe

Gestionarea datelor, controlul accesului, tokenizarea datelor, securitatea și criptarea, originea și calea datelor, auditarea și versioning, deținerea legală și DSAR, ML confidențial.

Total

Politicile de stocare transformă un „depozit haotic” într-o arhivă gestionată: fiecare domeniu își cunoaște propriul termen, fundație și destin. Pentru iGaming, aceasta este baza conformității, economiei și încrederii în date: stocați suficient, dar nu prea mult, știți cum să ștergeți și să dovediți rapid și, în același timp, nu rupeți rapoarte, ML și procese operaționale.