Löschung und Anonymisierung von Daten

1) Ziel und Bereich

Gewährleistung der rechtmäßigen, sicheren und nachweisbaren Löschung/Anonymisierung von Spielerdaten, Transaktionen und Betriebsprotokollen in allen Systemen (Produkt/Wallet, KYC/AML, RG, Marketing/CRM, Analytics/DWH, Logs/AWS), einschließlich Anbietern/Anbietern und Backups, unter Berücksichtigung der Lokalisierung nach Gerichtsbarkeit.

2) Grundsätze

1. Politik vor Praxis. Retention, Ziele und Lagerorte werden vor der Abholung festgelegt.
2. Minimierung und Trennung. Separate Speicher für PII, Tokenisierung in Events.
3. Löschung = Ereignis mit Nachweis. Jede Entfernung wird durch das Artefakt bestätigt.
4. Fail-Closed. Unbekannter Status/Region → Verbot von Transaktionen mit PII.
5. Backups-aware. Backups unterliegen den gleichen Regeln wie Kampfdaten.
6. „Anonymisierung statt unbefristeter Speicherung“. Wenn das Gesetz keine PII erfordert, übersetzen wir in Aggregate.

3) Rollen und RACI

DPO/Compliance (Owner) - Richtlinie für Retention/Löschung, Ausnahmen, Audit. (A)

Sicherheit/Infra - Verschlüsselung, Schlüssel, Krypto-Löschung, Backups/DR. (R)

Data Platform/Analytics - de-PII Pipelines, Aggregate, DWH/DL. (R)

Product/Engineering/SRE - Entfernungs-API, Kaskaden, Tests, Beobachtbarkeit. (R)

Legal - lokale Fristen und Einschränkungen (AML/lizenziert). (C)

Privacy Ops/DSAR Team - Benutzerdefinierte Löschungen/Korrekturen. (R)

Vendor Manager - Pflichten der Anbieter, Leistungsnachweise. (R)

Internal Audit - Stichproben, CAPA. (C)

4) Datentaxonomie und Retentionsstandard

5) Technische Methoden

5. 1 Löschung

Cascading Logic/Physical: Soft-delete → Job zum physischen Löschen.
Crypto-Shredding: Zerstörung des Segment-/Tenant-Verschlüsselungsschlüssels; gilt für Backups/Archive.
Token-Revocation: Widerruf von Zahlungs-/Tracker-Token bei Anbietern.
Nullify/Mask: für Felder, die eine formale Speicherung des Datensatzes erfordern (z.B. Buchhaltung).

5. 2 Pseudonymisierung

Ersetzen der primären IDs durch Token; die Entsprechungstabelle wird separat mit dem einzelnen KMS gespeichert.

5. 3 Anonymisierung

Aggregation/Cochorting, k- anonimnost/ℓ -Diversität, Binning, Beschneiden seltener Werte, differenzielle Privatsphäre in Berichten.

5. 4 Logmaskierung

Der Agent bearbeitet die PII in der Sammlung (e. g., E-Mail → hash/partial), Verbot von „rohen“ Identifikatoren im APM.

6) Lebenszyklus der Entfernung

1. Auslöser: Retentionsfrist, DSAR-Erase, Kontoschließung, Widerruf der Einwilligung, Vertrags-/Zweckabschluss.
2. Bewertung: Gibt es rechtliche Blockaden? (AML/legal-hold/Lizenz).
3. Orchestrierung: Ein Erasure-Paket nach Systemen/Anbietern wird gebildet.
4. Ausführung: Kaskaden, Revoke-Token, Krypto-Wipe für Archive.
5. Validierung: Datensatzabgleich, Rückstandskontrolle (orphaned data).
6. Artefakt: Bericht mit Partie-/Schlüssel-Hashes, Zeit und Volumen.
7. Reporting: KPI Dashboard, Zeitschrift für Audit/Regulator.

7) Besondere Schwerpunkte

7. 1 Backups/Archive/DR

Backups in der gleichen Region, Verschlüsselung und Schlüsselkatalogisierung.
Realistisch: Die physische Entfernung von immutable-backup ist schwierig → wir verwenden crypto-shredding segment, wenn die Frist erreicht ist.

7. 2 Protokolle und Telemetrie

Richtlinie PII-frei nach Standard; wenn PII unvermeidlich ist - lokale Protokolle, kurze Fristen, Maskierung auf dem Agenten.

7. 3 DWH/Analytik

Nur De-PII-Daten; falls erforderlich, die Historiker - zu anonymisieren und brechen die Verbindung mit der ursprünglichen PII.

7. 4 Anbieter und Anbieter

DPA/Zusatzvereinbarungen: Fristen, Löschmechanismen, Leistungsnachweis (Certificate of Destruction/Erase Evidence).

7. 5 Lokalisierung nach Jurisdiktion

Die Entfernung erfolgt im regionalen Umkreis, der Export von PII darüber hinaus ist verboten; globale Berichte - nur Aggregate.

8) API/Events und Datenmodell

• `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) Kontrolle und Beobachtbarkeit

Erasure Coverage ist der Anteil der Systeme, die durch automatische Entfernung abgedeckt sind.
Time-to-Erase - Die mediane Zeit vom Trigger bis zum Abschluss.
Orphaned Data Rate - Entdeckte „verwaiste“ Datensätze.
Backup Crypto-Shred SLA - rechtzeitig zerstörte Schlüssel.
Vendor Ack Rate - Anteil der Bestätigungen von Streichungen von Anbietern innerhalb der Frist.
DSAR Erase SLA - Einhaltung der Fristen für benutzerdefinierte Löschungen.
Auditability Score - das Vorhandensein von Artefakten durch Proben.

10) Checklisten

A) Politik und Design

• Das Retentionsregister nach Kategorie/Markt wurde von Legal/DSB genehmigt.
• System-/Anbieterkarte mit PII/Regionen/Schlüsseln.
• Definierte Methoden: Kaskade/Krypto-Wipe/de-PII für die Analytik.
• DPA/Verträge aktualisiert (SLA löschen, Bestätigungen).

B) Technik und Betrieb

• Lösch-API und Job Orchestrator sind enthalten.
• PII-freie Protokolle/Agenten maskieren empfindliche Felder.
• Backups werden verschlüsselt, Schlüssel nach Märkten segmentiert.
• Autotests: DSAR-erase, cron retentions, orphan-scan.
• KPI/alert Dashboard.

C) Audits und Verbesserungen

• Vierteljährliche Stichproben von Systemen/Anbietern mit Löschartefakten.
• DR/Recovery-Test unter Berücksichtigung der gelöschten Segmente.
• CAPA für gefundene Rückstände/Unregelmäßigkeiten.

11) Vorlagen (Schnelleinfügungen)

A) Klause mit Verkäufer (Löschung/Retention)

B) Anonymisierungslösung (internes Formular)

C) Antwort an Benutzer (DSAR-erase abgeschlossen)

12) Häufige Fehler und Prävention

Entfernung aus der Kampf-DB, aber nicht aus Backups. → Crypto-Shredding und Schlüsselregistrierung.
PII in den Protokollen/APC. → Maskierung auf dem Mittel, kurze Retention.
Orphan-Aufzeichnungen (Cross-Services). → Orphan-Scans und Vertragskaskaden.
DWH mit PII-Tails. → De-PII-Pipelines vor dem Export, Verbot von rohen IDs.
Keine Artefakte. → Obligatorische Berichtserstellung und WORM-Speicher.
Der Anbieter hat → SLAs und Sanktionen/Hold-Zahlungen bis zur Bestätigung nicht entfernt.

13) 30-tägiger Implementierungsplan

Woche 1

1. Genehmigung des Retentionsregisters und der Methodenmatrix (Kaskade/Krypto/de-PII).
2. Erstellen Sie eine Karte der Systeme/Anbieter/Schlüssel, markieren Sie die regionalen Perimeter.
3. Spezifizieren Sie das Artefaktmodell und das KPI-Dashboard.

Woche 2

4) Implementieren Sie Orchestrator Löschungen, APIs und Ereignisse; DSAR-Links anschließen.
5) Aktivieren Sie die Logmaskierung und die „PII-free by default“ -Regeln.
6) Konfigurieren Sie Crypto-Shred für Backups, KMS-Segmentierung nach Märkten.

Woche 3

7) De-PII-Pipeline für DWH (Kohorten/k-Anonymität/Binning).
8) Pilotentnahmen: 20 DSAR-Fälle + 2 Retentionspartien; Schließen Sie die CAPA.
9) Aktualisieren Sie DPA mit Schlüsselanbietern (SLAs/Bestätigungen).

Woche 4

10) Vollständige Freigabe; Dashboards und Alerts ausführen (Time-to-Erase, Vendor Ack).
11) DR-Test mit Remote-Schlüsselsegment.
12) Plan v1. 1: diff. Privatsphäre in Berichten, Auto-Orphan-Scans nach Zeitplan.

14) Miteinander verbundene Abschnitte

DSGVO: Verwaltung der Einwilligung der Nutzer

Cookie-Richtlinie und CMP-Systeme

Privacy by Design: Gestaltungsprinzipien

Datenlokalisierung nach Jurisdiktion

DSAR: Benutzeranfragen nach Daten

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

Compliance Dashboards und Monitoring/Interne und externe Audits