Harmonogramy przechowywania i usuwania danych

1) Cel i obszar

• zgodność z prawem/licencjami (RODO/ePrywatność/AML/akty lokalne);
• zminimalizować objętość PII;
• zapewnienie sprawności wykonania (artefakty/kłody);
• Zmniejszenie ryzyka incydentu i kosztów magazynowania

Zasięg: konto/profil, KYC/AML, płatności/PSP, telemetria gier, RG/SE, CRM/marketing, partnerzy, logi/AWP, analityka/DWH, kopie zapasowe/archiwa, dostawcy/sprzedawcy, wszystkie rynki docelowe.

2) Zasady

1. Zgodne z prawem i związane celami. Terminy są związane z podstawami prawnymi i celami przetwarzania.
2. Minimalizacja danych. Minimalne pola/daty; „anonimizacja zamiast trwałego przechowywania”.
3. Lokalna-pierwsza. Zatrzymanie jest obserwowane w regionie (rezydencja danych).
4. Polityka-as-Data. Wykresy są przechowywane jako zapisy czytelne maszynowo (diagramy), wersjonowane i stosowane przez automatyzację.
5. Nieudane zamknięcie. Wygasły/nieznany powód → wyłączenie/usunięcie wyzwalacza.
6. Słuchalność. Każde usunięcie/anonimizacja → artefakt w sklepie WORM.
7. Świadomi kopii zapasowych. Kopie zapasowe/archiwa podlegają tym samym terminom (segmenty crypto-shredding).

3) Role i RACI

Inspektor Ochrony Danych/Szef Zgodności (Właściciel) - polityka, rejestr, interpretacja norm, wyjątki. A)

Podstawy prawne/terminy dla rynków, posiadłości prawne. (R)

Bezpieczeństwo/Infra - KMS/szyfrowanie, crypto-shred, dostęp do dziennika. (R)

Platforma danych/analityka - de-PII/anonimizacja, zasady DWH/DL. (R)

Inżynieria/SRE - orkiestra retencji, kaskad, integracji z systemami/sprzedawcami. (R)

Produkt/CRM - zgodność funkcji i przepływów tłumienia z terminami. (C)

Menedżer dostawcy - DPA/SLA do usunięcia, potwierdzenie od dostawców. (R)

Audyt wewnętrzny - wybory, CAPA, niezależna weryfikacja. (C)

4) Taksonomia danych i ich podstawa

• KUS/Age/Biometria - dokumenty, selfie/żywotność, werdykty. (Uzasadnienie: prawo/licencja, interes publiczny; często 5-7 lat)
• Płatności/PCI - żetony, transakcje/rejestry, obciążenie zwrotne. (Powody: prawo umów/rachunkowość/PCI)
• Aktywność gry - zakłady/wygrane, bonusy, rabaty. (Uzasadnienie: umowa/licencja, interes operatora)
• RG/SE - statusy samodzielnego wykluczenia, kontrole dostępności/kontrole rzeczywistości. (Uzasadnienie: prawo/licencja, interes publiczny)
• CRM/Marketing - kontakty, zgody, historie kampanii. (Uzasadnienie: zgoda/uzasadniony interes)
• Partnerzy - kliknij-id, umieszczenie, warunki-hash (bez gracza PII). (Uzasadnienie: umowa, uzasadniony interes)
• Dzienniki/AWS - zdarzenia techniczne (domyślnie wolne od PII). (Powody: uzasadniony interes/bezpieczeństwo)
• Analityka/DWH - agregaty/pseudonimy, cechy ML. (Powody: uzasadniony interes/badania naukowe)

5) Macierz linii czasowej (ramy)

6) Wyjątki i bloki

Wymagania AML/licencji - pierwszeństwo nad aplikacją do usunięcia (DSAR-erase), ograniczenia i minimalizacji są stosowane.
Legal Hold/disputes/investigations - stop flag for removal; ustalamy podstawę i termin.
Prawa/tajemnice osób trzecich - edycja/depersonalizacja przy wydawaniu/wywozie.
Rejestry operacyjne (na przykład księgowość) - maskowanie zamiast usuwania kluczy podstawowych.

7) Profile regionalne (szablon)

Юрисдикция: ______
KYC/биометрия: срок ___; особые запреты/форматы: ___
Платежи/бухучет: срок ___; маскирование: ___
Игровая активность: срок ___; анонимизация: k≥__
RG/SE: срок ___; политика хранения флага: ___
CRM/согласия: неактивность ≤ __ мес; double opt-in: да/нет
Логи/APM: __ дней; PII-free: да/нет
Бэкапы/архивы: локализация ___; crypto-shred SLA ___
Исключения/легал-холд: условия ___

8) Dane dotyczące polityki: model wykresu

retention_rule {
rule_id, version, market, data_class{KYC    PCI    GAME    RG    CRM    LOG    ANON},
lawful_basis{consent    contract    legal_obligation    legit_interest    public_interest},
retention_days, grace_days, action_after{erase    anonymize    mask    revoke_token},
pii{yes/no}, residency_region, backups_policy{crypto_shred:true, kms_key_scope:region},
dsar_applicable{yes/no}, exceptions{aml:true, legal_hold:true},
owner{dpo    legal    security    data}, approved_at_utc, next_review_at_utc
}

Wersioning jest wymagany: każda edycja → nowa wersja + plan migracji.

9) Przepływy pracy (szkic)

1. Wykrywanie: 'retention _ due _ detected' (cron/stream by creation events).
2. Kwalifikowalność: sprawdzenie wyjątków (AML/holding/rezydencja).
3. Orkiestra: powstaje pakiet systemów/sprzedawców, strategia (wymazanie/anonimizacja).
4. Wykonanie: kaskadowe usuwanie zadań, cofanie żetonów, klucze segmentu crypto-shred w kopiach zapasowych.
5. Walidacja: uzgodnienie zapisów, skanowanie osierocone, selektywna weryfikacja DWH/dzienników.
6. Dowody: raport (kwoty kontroli, identyfikator klucza, czas, woluminy) w WORM; link do deski rozdzielczej.
7. Sprawozdawczość: KPI, wpisy, CAPA w przypadku awarii.

10) Kopie zapasowe, archiwa i DR

Lokalizacja: kopie zapasowe w tym samym regionie/bloku.
Szyfrowanie: na region KMS/HSM; klucze są segmentowane przez rynek/najemcę.
Crypto-shredding: przy dotarciu do terminu - zniszczenie klucza segmentu, raport z 'kms _ key _ id'.
Niezmienne magazyny: znak „czekając na krypto-shred” w harmonogramie.

11) Analityka/DWH i anonimizacja

Rurociąg de-PII: przed wywozem do DWH - tokenizacja/okrawanie/k-anon, daty opróżniania/geo, tłumienie rzadkich wartości, diff. prywatność raportów.
Raporty globalne - tylko agregaty; zakaz „surowego” PII poza regionem.
Los historyków: po określeniu - zerwanie więzi z podstawowymi identyfikatorami.

12) Integracja z DSAR/CMP/lokalizacja

DSAR-erase: wykorzystuje te same mechanizmy orkiestrowe/artefakt; w przypadku konfliktów z AML, → ograniczenie zamiast usuwania.
CMP/Zgoda: wycofanie zgody → natychmiastowe zaprzestanie przetwarzania i włączenie timera retencji danych marketingowych.
Miejsce zamieszkania: wykresy są stosowane na obwodzie regionalnym, wywóz PII jest podporządkowany mechanizmom transgranicznym.

13) Model artefaktów usuwania

erasure_artifact {
job_id, rule_version, market, region, scope{subject    partition    cohort},
systems[], vendors[], method{cascade    crypto_shred    anonymize    mask    revoke_token},
started_at_utc, completed_at_utc, status{ok    partial    failed},
counts{records, tables, bytes}, checksum{before, after},
kms_keys_destroyed[{id, destroyed_at_utc}], orphan_scan{passed    failed},
dsar_case_id?, approvers{dpo, security}, evidence_uri(WORM)
}

14) KPI/KRI i deska rozdzielcza

Wskaźnik zgodności zatrzymywania - odsetek zapisów, które dotrzymały terminu i zostały przetworzone w SLA.
Czas do usunięcia - mediana/95 percentyl od spustu do zakończenia.
Kopia zapasowa Crypto-Shred SLA - proporcja segmentów z zniszczonymi klawiszami na czas.
Osierocony wskaźnik danych - osierocone rekordy/repliki nonsynchroniczne.
Sprzedawca Erasure Ack - potwierdzenie od sprzedawców na czas.
DSAR Linkage - odsetek usunięć związanych z przypadkami DSAR.
Auditability Score -% zadań z pełnym pakietem artefaktów.
Wyjątki Mix - odsetek rekordów przechowywanych przez AML/hold.

15) Listy kontrolne

A) Projekt i polityka

• Kategoria i rejestr rynku zatwierdzone przez DPO/Legal.
• Podstawę prawną i action_after określa się dla każdego zapisu.
• Aktualizacja harmonogramu i następna data rewizji.
• System/Sprzedawca/Mapa klucza i obwodów lokalizacji.

B) Technika i operacje

Orkiestrator prezentacji jest podłączony do wszystkich systemów.

• Testowane kaskadowe usunięcia/maskowanie/anonimizacja.
• Crypto-shred dla kopii zapasowych: klawisze są segmentowane, raporty są generowane.
• Skanowanie sierocych i zaplanowane próbki walidacyjne.
• Sklep artefaktowy WORM jest dostępny dla audytu.

C) Sprzedawcy

• DPA/SLA: okres usunięcia, format potwierdzeń, kary.
• Potwierdzenia kwartalne, skreślenia testów.
• Czarna lista dostawców z naruszeniami.

16) Szablony (szybkie wkładki)

A) Rekord harmonogramu (przykład YAML)

yaml
- rule_id: CRM-MKT-EMAIL version: 1.3 market: EU data_class: CRM lawful_basis: consent retention_days: 730  # ≤24 мес неактивности grace_days: 30 action_after: erase pii: true residency_region: EU backups_policy: { crypto_shred: true, kms_key_scope: region }
dsar_applicable: true exceptions: { aml: false, legal_hold: true }
owner: dpo

B) Klauzula dostawcy (skreślenie/potwierdzenie)

C) Decyzja w sprawie anonimizacji (DWH)

klucz> Poszczególne wydarzenia wygasły. Zapisujemy tylko agregaty z k ≥ 20, daty bining (tydzień), geo - do „region”, tłumienie rzadkich kategorii <0. 5%.

17) Częste błędy i zapobieganie

Usunięto z bazy danych produkcji, ale nie z kopii zapasowych. → Crypto-shred, kluczowa księgowość według rynku.
PII należy do AWS/logs. → domyślnie wolny od PII, maskowanie na agencie, krótka retencja.
DWH z ogonami PII. → Obowiązkowy rurociąg de-PII przed wywozem.
Brak artefaktów. → Obowiązkowe generowanie 'erasure _ artifact' i magazynowanie WORM.
Sprzedawca nie potwierdził usunięcia. → Wstrzymaj płatności/sankcje, eskalację i offboarding.

18) 30-dniowy plan realizacji

Tydzień 1

1. Zatwierdzenie taksonomii/podstaw i głównego rejestru zatrzymań według kategorii.
2. Przygotowanie profili regionalnych (UE/UK/...): terminy, wyjątki, kopie zapasowe.
3. Określić model „retention _ rule” i „erasure _ artifact”.

Tydzień 2

4) Wdrożyć orkiestrę prezentacji (cron/stream), podłączyć systemy kluczy.
5) Skonfigurować krypto-shred (KMS według rynku), dziennik kluczowych operacji.
6) Należy włączyć rurociąg de-PII do DWH/raportów.

Tydzień 3

7) Pilot: 2 kategorie (CRM/logs) + 1 część wydarzeń gry → anonimizacja.
8) Testy sprzedawcy: żądania usunięcia i potwierdzenia.
9) Deska rozdzielcza KPI/KRI i wpisy (Time-to-Erase, Sierota Rate).

Tydzień 4

10) Pełne zwolnienie; kwartalne przeglądy harmonogramów i profili regionalnych.
11) CAPA w przypadku stwierdzonych pozostałości/naruszeń.
12) Plan v1. 1: automatyczne skanowanie sierot i raporty sprzedawcy.

19) Sekcje wzajemnie powiązane

Usuwanie i anonimizacja danych

DSAR: żądanie danych przez użytkownika

Lokalizacja danych według jurysdykcji

RODO: Zarządzanie zgodami/pliki cookie i polityka CMP

Prywatność według projektu

W czasie odpoczynku/tranzytu, szyfrowanie KMS/BYOK/HYOK

Zgodność Deska rozdzielcza i monitorowanie/audyt wewnętrzny i zewnętrzny