Zeitpläne für die Speicherung und Löschung von Daten

1) Ziel und Bereich

• Einhaltung der Gesetze/Lizenzen (DSGVO/ePrivacy/AML/lokale Gesetze);
• Minimierung des PII-Volumens;
• Sicherstellung der Nachweisbarkeit der Ausführung (Artefakte/Zeitschriften);
• Verringerung der Risiken von Vorfällen und der Kosten für die Lagerung.

Reichweite: Konto/Profil, KYC/AML, Zahlungen/PSP, Gaming-Telemetrie, RG/SE, CRM/Marketing, Affiliates, Protokolle/AWS, Analytics/DWH, Backups/Archive, Anbieter/Anbieter, alle Zielmärkte.

2) Grundsätze

1. Lawful & Purpose-bound. Die Fristen sind an die gesetzlichen Grundlagen und Zwecke der Verarbeitung gebunden.
2. Data Minimization. Minimale Felder/Fristen; „Anonymisierung statt unbefristeter Speicherung“.
3. Local-first. Die Retention wird innerhalb der Region eingehalten (Datenresidenz).
4. Policy-as-Data. Graphen werden als maschinenlesbare Einträge (Schemata) gespeichert, versioniert und automatisiert angewendet.
5. Fail-Closed. Abgelaufen/unbekannter Grund → Nutzungsverbot/Löschauslöser.
6. Auditability. Jede Löschung/Anonymisierung → ein Artefakt im WORM-Speicher.
7. Backups-aware. Backups/Archive unterliegen denselben Fristen (Crypto-Shredding-Segmente).

3) Rollen und RACI

DPO/Head of Compliance (Owner) - Richtlinien, Register, Interpretation von Normen, Ausnahmen. (A)

Legal - rechtliche Grundlagen/Fristen für Märkte, Legal Holds. (R)

Sicherheit/Infra - KMS/Verschlüsselung, Crypto-Shred, Log-Zugriff. (R)

Data Platform/Analytics - de-PII/Anonymisierung, DWH/DL-Regeln. (R)

Engineering/SRE - Orchestrator von Retention, Kaskaden, System-/Vendor-Integrationen. (R)

Produkt/CRM - Einhaltung von Terminen und Suppression von Streams. (C)

Vendor Manager - DPA/SLA zum Löschen, Bestätigungen von Anbietern. (R)

Internes Audit - Stichproben, CAPA, unabhängige Prüfung. (C)

4) Datentaxonomie und Grundlagen

• KUS/Alter/Biometrie - Dokumente, Selfies/Lebendigkeit, Urteile. (Gründe: Gesetz/Lizenz, öffentliches Interesse; häufig 5-7 Jahre)
• Zahlungen/PCI - Token, Transaktionen/Ledger, Chargeback. (Begründung: Vertrag/Rechnungslegungsgesetz/PCI)
• Spielaktivität - Wetten/Gewinne, Boni, Rabatte. (Gründe: Vertrag/Lizenz, Interesse des Betreibers)
• RG/SE - Selbstausschlussstatus, Verfügbarkeitsprüfungen/Reality Checks. (Gründe: Recht/Lizenz, öffentliches Interesse)
• CRM/Marketing - Kontakte, Zustimmungen, Kampagnengeschichten. (Gründe: Einwilligung/berechtigtes Interesse)
• Affiliates - Click-Id, Platzierung, Terms-Hash (ohne PII des Spielers). (Gründe: Vertrag, berechtigtes Interesse)
• Protokolle/AWS - technische Ereignisse (PII-frei standardmäßig). (Gründe: berechtigtes Interesse/Sicherheit)
• Analytik/DWH - Aggregate/Pseudonyme, fichi ML. (Gründe: berechtigtes Interesse/Forschung)

5) Terminmatrix (Rahmen)

6) Ausnahmen und Blöcke

AML/Lizenzanforderungen - Vorrang vor dem Antrag auf Löschung (DSAR-erase), Anwendung von Beschränkung und Minimierung.
Legal Hold/Streitigkeiten/Untersuchungen - Stop-Flag für die Entfernung; Wir fixieren den Grund und die Frist.
Rechte Dritter/Geheimnisse - Bearbeitung/Anonymisierung bei Auslieferung/Export.
Betriebsregister (z.B. Buchhaltung) - Maskieren statt Primärschlüssel löschen.

7) Regionale Profile (Vorlage)

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

8) Policy-as-Data: das Modell des Zeitplans

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
}

Versionierung ist obligatorisch: Jede Bearbeitung → neue Version + Migrationsplan.

9) Arbeitsabläufe (Skizze)

1. Erkennung: 'retention _ due _ detected' (cron/stream nach Erstellungsereignissen).
2. Eligibility: Überprüfung von Ausnahmen (AML/hold/residency).
3. Orchestration: Ein Paket von Systemen/Anbietern wird gebildet, eine Strategie (erase/anonymize).
4. Ausführung: Cascading delete jobs, revoke tokens, crypto-shred segment keys in backups.
5. Validierung: Datensatzabgleich, Orphan-Scan, DWH/Logs stichprobenartig prüfen.
6. Evidence: Bericht (Scheckbeträge, Schlüssel-ID, Zeit, Volumen) in WORM; Link zum Dashboard.
7. Reporting: KPIs, Alerts, CAPAs bei Ausfällen.

10) Backups, Archive und DR

Lokalisierung: Backups in der gleichen Region/Block.
Verschlüsselung: per-region KMS/HSM; Schlüssel sind nach Märkten/Tenanten segmentiert.
Crypto-Shredding: wenn die Frist erreicht ist - Zerstörung des Segmentschlüssels, Bericht mit 'kms _ key _ id'.
Immutable Tresore: Der Hinweis „wartet auf crypto-shred“ im Planer.

11) Analytik/DWH und Anonymisierung

De-PII Pipeline: vor dem Export nach DWH - Tokenisierung/Kürzung/k-Anon, Datumsbindung/Geo, Unterdrückung seltener Werte, Diff. Privatsphäre auf Berichten.
Globale Berichte: nur Aggregate; Verbot von „rohen“ PII außerhalb der Region.
Das Schicksal der Historiker: nach der Amtszeit - der Bruch der Verbindungen mit den primären Identifikatoren.

12) Integrationen mit DSAR/CMP/Lokalisierung

DSAR-erase: verwendet die gleichen Orchestrierungs-/Artefakt-Mechanismen; bei Konflikten mit AML → Einschränkung statt Löschung.
CMP/Consent: Widerruf der Zustimmung → sofortiges Stop-Processing und Aktivierung des Marketingdaten-Retentionszeitgebers.
Wohnsitz: Die Zeitpläne gelten im regionalen Umkreis, die PII-Exporte unterliegen grenzüberschreitenden Mechanismen.

13) Modell der Löschartefakte

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 und Dashboard

Retention Compliance Rate - Der Anteil der Datensätze, die das Fälligkeitsdatum erreicht haben und im SLA verarbeitet wurden.
Time-to-Erase - Median/95. Perzentil vom Auslöser bis zur Fertigstellung.
Backup Crypto-Shred SLA - Anteil der Segmente mit zerstörten Schlüsseln auf Zeit.
Orphaned Data Rate - „verwaiste“ Datensätze/nicht-synchrone Replikate.
Vendor Erasure Ack - Bestätigungen von Anbietern rechtzeitig.
DSAR Linkage - Anteil der Löschungen im Zusammenhang mit DSAR-Fällen.
Auditability Score -% der Aufgaben mit einem vollständigen Artefakt-Paket.
Exceptions Mix - Anteil der von AML/hold gehaltenen Datensätze.

15) Checklisten

A) Design und Politik

• Das Retentionsregister nach Kategorie und Markt wurde vom DSB/Legal genehmigt.
• Für jeden Eintrag werden eine lawful Basis und action_after definiert.
• Versionierung der Zeitpläne und Datum der nächsten Überarbeitung.
• System/Vendor/Key-Karte und Lokalisierungsumfänge.

B) Technik und Betrieb

• Der Retentionsorchester ist mit allen Systemen verbunden.
• Kaskadierte Löschungen/Maskierung/Anonymisierung getestet.
• Crypto-Shred für Backups: Schlüssel werden segmentiert, Berichte generiert.
• Orphan-Scans und Validierungsproben nach Zeitplan.
• Der WORM-Speicher für Artefakte steht dem Audit zur Verfügung.

C) Anbieter

• DPA/SLA: Löschfrist, Format der Bestätigungen, Bußgelder.
• Vierteljährliche Bestätigungen, Testentnahmen.
• Schwarze Liste der Anbieter mit Verstößen.

16) Vorlagen (Schnelleinfügungen)

A) Aufzeichnung des Graphen (YAML-Beispiel)

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) Klause nach Anbieter (Löschung/Bestätigung)

C) Anonymisierungsentscheidung (DWH)

17) Häufige Fehler und Prävention

Aus Prod-DB entfernt, aber nicht aus Backups. → Crypto-Shred, Schlüsselbuchhaltung nach Märkten.
PIIs fallen in APCs/Logs. → PII-frei standardmäßig, Maskierung auf Agent, kurze Retention.
DWH mit PII „Tails“. → Obligatorische de-PII-Pipeline vor dem Export.
Keine Artefakte. → Obligatorische Erzeugung von 'erasure _ artifact' und WORM-Speicherung.
Der Anbieter hat die Löschung nicht bestätigt. → Hold Zahlungen/Sanktionen, Eskalation und Offboarding.

18) 30-tägiger Implementierungsplan

Woche 1

1. Genehmigung der Taxonomie/Gründung und des primären Retentionsregisters nach Kategorie.
2. Erstellung regionaler Profile (EU/UK/...): Fristen, Ausnahmen, Backups.
3. Spezifizieren Sie das Modell 'retention _ rule' und 'erasure _ artifact'.

Woche 2

4) Erweitern Sie den Retentionsorchester (cron/stream), verbinden Sie die Schlüsselsysteme.
5) Konfigurieren Sie crypto-shred (KMS nach Märkten), das Protokoll der Schlüsseloperationen.
6) Enable de-PII pipeline for DWH/reports.

Woche 3

7) Pilot: 2 Kategorien (CRM/Protokolle) + 1 Partei des Spielereignisses → Anonymisierung.
8) Anbieter-Tests: Löschanfragen und Bestätigungen.
9) KPI/KRI Dashboard und Alerts (Time-to-Erase, Orphan Rate).

Woche 4

10) Vollständige Freigabe; vierteljährliche Reviews von Charts und regionalen Profilen.
11) CAPA für gefundene Rückstände/Unregelmäßigkeiten.
12) Plan v1. 1: Automatische Orphan-Scans und Vendor-Berichte.

19) Miteinander verbundene Abschnitte

Löschung und Anonymisierung von Daten

DSAR: Benutzeranfragen nach Daten

Datenlokalisierung nach Jurisdiktion

GDPR: die Verwaltung des Einverständnisses / Politik cookies und CMP

Privacy by Design

Verschlüsselung bei Rest/In Transit, KMS/BYOK/HYOK

Compliance Dashboards und Monitoring/Interne und externe Audits