Privacy by Design: Gestaltungsprinzipien
1) Warum es notwendig ist (Zweck und Bereich)
PbD stellt sicher, dass die Privatsphäre standardmäßig in das Produkt integriert ist und nicht von oben „geklebt“ wird. Für iGaming reduziert dies regulatorische Risiken (DSGVO/ePrivacy/lokale Gesetze), schützt gefährdete Nutzer, erhöht das Vertrauen und reduziert die Kosten von Vorfällen. Reichweite: Web/Mobile, KYC/AML/RG, Zahlungen, Marketing/CRM, Analytics/DWH, Logs/AWS, Partner/Anbieter.
2) Sieben Prinzipien (und wie man sie in Operationen landet)
1. Proaktiv, nicht reaktiv
Bedrohungsmodellierung (LINDDUN/STRIDE) in der Entdeckungsphase.
Privacy-acceptance Kriterien in Jira/PR-Vorlagen.
2. Standard-Datenschutz (Privacy by Default)
Alle Marketing/Personalisierungs-Kippschalter sind aus, solange es keine Einigung gibt.
Sammeln Sie nur die „unbedingt erforderlichen“ Standard-IDs.
3. Privatsphäre ist in das Design eingebettet
Die PII wird im Regionalkreis (Datenresidenz) gespeichert, die Steuerebene ohne PII.
Tokenisierung/Pseudonymisierung von Schlüsseln in Serviceereignissen.
4. Volle Funktionalität (Win-Win)
Modi der „anonymen Analyse“ und „Personalisierung mit Zustimmung“.
Gleiche UX ohne Diskriminierung von Tracking-Verweigerern.
5. Sicherheit durch den Lebenszyklus
Verschlüsselung bei Rest/in Transit; BYOK/HYOK; Segmentierung der Netze; Geheimnis-Management.
WORM-Protokolle für Nachweise und Audits.
6. Durchsichtigkeit
Kurze Richtlinien und „Zusammenfassung Box“ der wichtigsten Bedingungen; Privatsphäre-Panel im Profil.
Reporting: wer/was/wann/warum auf die Daten zugegriffen wurde.
7. Benutzerorientierung
Einfache Texte, keine dunklen Muster, WCAG AA + Verfügbarkeit.
Einfacher Widerruf der Zustimmung und bequeme DSAR-Kanäle.
3) Rollen und RACI
DPO/Head of Compliance - PbD-Richtlinie, DPIA/TRA, Risikokontrolle. (A)
Sicherheit/Infra Lead - Kryptographie, Zugriffe, Protokolle, Anbieter. (R)
Produkt/UX - Privacy-Anforderungen in Fich, keine dunklen Muster. (R)
Engineering/Architektur - Tokenisierung, Isolation tenant/region, API-Verträge. (R)
Data/Analytics - De-PII Pipelines, PETs, Aggregation. (R)
Legal - Rechtsgrundlagen, Texte und Orte. (C)
Marketing/CRM - Einwilligungen/Suppression, ehrliche Kommunikation. (R)
Internal Audit - Proben von Artefakten, CAPA. (C)
4) Klassifizierung und Taxonomie der Daten
PII Basic: Name, E-Mail, Telefon, Adresse, Geburtsdatum, IP/ID des Geräts.
Sensible PII: Biometrie (Selfie/Lebendigkeit), KYC-Dokumente, Zahlungsdetails, RG/SE-Status.
Operativ: Spielereignisse, Protokolle/Trails (PII-frei standardmäßig).
Marketing/Analytics: Cookie-IDs/SDKs (mit Zustimmung).
Regeln: Minimierung, getrennte Lagerung, ausdrücklicher Zweck und Aufbewahrungsfrist.
5) Datenlebenszyklus (Data Lifecycle)
1. Sammlung - nur die notwendigen Felder; GMR/Zustimmung; Altersüberprüfungen.
2. Getriebe ist TLS 1. 2 +/mTLS, Signatur von Webhooks, regionales Routing.
3. Speicherung - Verschlüsselung, Tokenisierung, Schlüsselrotation, Isolation über Märkte hinweg.
4. Verwendung - RBAC/ABAC, „need-to-know“, PETs für Analysen.
5. Austausch - DPA/SCC, Mindestsätze, auditierbare Kanäle.
6. Retention/Entfernung - Begriff nach Kategorie; Cascading delete jobs; Krypto-Löschung von Archiven.
7. Reporting/Audit - Zugriffs- und Exportprotokolle, DPIA/DSAR-Artefakte.
6) DPIA/TRA (wie man kurz macht)
Auslöser: neue PII-Kategorien, spezielle Kategorien, neue Anbieter, grenzüberschreitende Übertragungen, hohe RG/biometrische Risiken.
DPIA-Vorlage: Zweck → Datenkategorien → Rechtsgrundlage → Streams/Karte → Risiken → Maßnahmen (te/org) → Restrisiko → Lösung.
Artefakte: Flussdiagramm, Feldliste, Risikotabelle, Genehmigungsprotokoll.
7) Architektonische PbD-Muster
Tenant/Region Isolation: physische/logische Trennung von DB, Schlüssel und Geheimnisse.
Control vs Data Plane: Globale Kontrolle - ohne PII; PII nur lokal.
De-PII Pipeline: vor dem Export nach DWH - Hash/Salz, Trunkierung, k-Anonymität/Cochorting.
Tokenization Gateway: Token anstelle der primären IDs im Service-Bus.
Edge ohne PII: CDN/Edge-Cache - nur öffentliche Inhalte.
Fail-Closed: unbekannte' player _ region '→ Verbot von Operationen mit PII.
8) Technische Maßnahmen und Normen
Verschlüsselung: AES-256/GCM at rest TLS 1. 2+/1. 3; PFS.
Schlüssel: KMS, BYOK/HYOK, Rotation, Zugriff über HSM-Rollen, Key Operations Log.
Zugang: RBAC/ABAC, JIT-Zugänge, getrennte Admin- und Audit-Rollen.
Protokolle: unveränderlich (WORM), Hash-Ketten, Speicherung in der Region.
DevSecOps: Geheimnisse in Vault, SAST/DAST, PII-Feld-Linter, Privacy-Tests in CI.
Testdaten: Standardsynthetik; wenn Re-Daten - De-Identifizierung und kurze Retention.
9) PETs (Privacy-Enhancing Technologies)
Pseudonymisierung: Ersetzung der ID durch Token; Key-Map wird separat gespeichert.
Anonymisierung: Aggregate, K- anonimnost/ℓ -Diversität, Bining/Kohorten.
Differentielle Privatsphäre: Lärm um Berichte, „Datenschutzbudget“.
Federated Analytics: Lokale Modelle, nur Gewichte/Aggregate exportieren.
Maskierung/Revision: EXIF löschen, Felder in KYC-Dokumenten ausfärben.
10) UX ohne dunkle Muster
Gleiche Sichtbarkeit von „Alle ablehnen „/„ Alle akzeptieren „/„ Anpassen “.
Verständliche Zieltexte und Beispiele für die Datennutzung.
Die Ablehnung der Personalisierung beeinträchtigt das zugrunde liegende Erlebnis nicht.
Privatsphäre-Panel in 1-2 Klicks von überall; Verfügbarkeit von AA +.
11) Anbieter und Datenübermittlung
Vendor Registry: DC Jurisdiktionen, Sub-Prozessoren, Zertifizierung, Speicherregionen, DPA/SCC/IDTA.
„Minimum Set“ -Politik: Nur notwendige Felder, Verbot des freien Exports.
Benachrichtigung und Überprüfung bei Standort-/Unterprozessorwechsel.
12) Daten und Ereignisse (Minimalmodell)
data_asset{id, category{KYC PCI RG CRM LOG ANON}, region, owner, retention_days, lawful_basis, pii{yes/no}}
processing_event{id, actor, purpose, lawful_basis, started_at, ended_at, records_count, export{yes/no, basis_id}}
access_log{id, subject_id_hash, actor, action{read/write/export/delete}, ts_utc, reason, ticket_id}
erasure_job{id, subject_id_hash, scope, started_at, completed_at, evidence_id}
13) KPI/KRI und PbD Dashboard
PII-Minimierungsindex (durchschnittliche Anzahl der PII-Felder pro Abschnitt).
Residency Coverage (% der Einträge in der richtigen Region).
Export Justification Rate (wie viele Exporte mit Bezug auf die Basis).
DSAR SLA (Median der Ausführung/Genauigkeit).
Tag Firing Violations (Tags ohne Zustimmung).
Auditability Score (% der Fälle mit einem vollständigen Artefakt-Paket).
Incidents/Findings (wiederholte Bemerkungen des Audits/der Regulierungsbehörde).
14) Checklisten
A. Vor der Entwicklung von Fichi (Design)
- Zweck und Rechtsgrundlage der Verarbeitung sind festgelegt.
- Datenkarte und Feldliste mit PII-Kennzeichnung/sensibel.
- DPIA/TRA erfüllt; Restrisiken eingegangen werden.
- Ein „anonymer Modus“ oder ein Modus mit einem Minimum an Daten wurde durchdacht.
B. Vor der Veröffentlichung (Build/Release)
- Geheimnisse im Manager, Schlüssel/Verschlüsselung konfiguriert.
- Logs ohne PII; Ereignisse und Audits enthalten.
- Regional Routing und Retention Policy sind aktiv.
- Tests: consent-gates, deny-by-default für Tags, erasure-path.
C. In Operationen
- Vierteljährliche Revue der Zugänge und Exporte.
- Überwachung von Firing-Verstößen und grenzüberschreitenden Anfragen.
- DSAR/Löschungen werden fristgerecht durchgeführt; Artefakte bleiben erhalten.
15) Vorlagen (Schnelleinfügungen)
A) DPIA-Vorlage (kurz)
Datenkategorien: ____ (PII: ja/nein)
Basis: ____
Streams/Standorte: ____
Risiken/Auswirkungen: ____
Maßnahmen: te (Chiffre/Token/Isolation), org (RBAC/Training)
Restrisiko: ____ Entscheidung: Zulassung/Recycling
B) Feldminimierungsrichtlinie
C) Klause mit Verkäufer (PbD-Pflicht)
D) DSAR-Antwort (Auszug)
16) Häufige Fehler und wie man sie vermeidet
Sammlung „nur für den Fall“. → Minimierungsrichtlinie + Code-Reviewschemata.
Rohe Protokolle mit PII in APM. → Masking/Revision auf Agent, lokale Speicher.
Globale DWH mit PII. → Nur de-PII Aggregate/Pseudonyme.
Keine Artefakte DPIA/consent. → WORM-Repository, Auto-Snapshots von UI/Texte.
Nicht gemeldete Anbieter/SDK. → Vierteljährliches Register, Verbot von „grauen“ Verbindungen.
17) 30-tägiger Implementierungsplan
Woche 1
1. PbD-Richtlinien und DPIA/TRA-Vorlagen genehmigen.
2. Erstellen Sie eine Daten-/Flusskarte nach Schlüsselbereichen (KYC/PCI/RG/CRM/Logs).
3. Hervorhebung der regionalen Außengrenzen (EU/UK/...); Definieren Sie das Schlüsselmodell (BYOK/HYOK).
Woche 2
4) Aktivieren Sie Tokenisierung/de-PII Pipelines und Deny-by-default für Tags.
5) Konfigurieren Sie WORM-Protokolle (Zugriffe/Exporte/Consent/Löschungen).
6) Aktualisierung der Verträge mit den Anbietern (DPA/SCC, Standorte, Unterverarbeiter).
Woche 3
7) Implementierung von Privacy-Tests in CI (PII-Linter, CMP-Bildschirmfixierung, erasure-E2E).
8) Freigabe des Privacy Panels im Profil; Texte und Locales verbessern.
9) Durchführung von Teamschulungen (Product/Eng/Data/CS/Legal).
Woche 4
10) Halten Sie die DPIA-Revue top fest, schließen Sie die CAPA.
11) Führen Sie das KPI/KRI-Dashboard (Residency, Exports, DSAR SLA) aus.
12) Plan v1. 1: diff. Privatsphäre für Berichte, föderierte Pipelines.
18) Miteinander verbundene Abschnitte
DSGVO: Benutzerzustimmungsmanagement/Cookie und CMP-Richtlinie
Datenlokalisierung nach Jurisdiktion
Altersüberprüfung und Altersfilter
AML/KYC und Lagerung von Artefakten
Compliance Dashboards und Monitoring/Regulatorische Berichte
Interne/externe Prüfung und Prüflisten
BCP/DRP/Verschlüsselung bei Rest & In Transit