Datenschutz by Design: Minimierung, Pseudonymisierung, Retention

Die nächtliche Warnung

Es ist 02:13 Uhr. Ein Alarm meldet einen möglichen Abfluss von Daten. Sie öffnen das Dashboard. Doch es gibt keinen Vorfall. Warum? Weil die App nur die nötigsten Felder speichert. Weil sensible IDs schon als Tokens vorliegen. Und weil alte Logs nach festen Zeiten weg sind. Das ist Datenschutz by Design in der Praxis. Weniger Daten. Weniger Risiko. Weniger Kosten bei Störungen.

Was wir meinen, wenn wir von «by Design» und «by Default» sprechen

«By Design» heißt: Datenschutz ist Teil des Produkts. Von Anfang an. In der Architektur. In den Abläufen. «By Default» heißt: sichere Voreinstellungen. Ohne Klicks. Ohne Extra‑Schritte. Beides ist Kern von Art. 25 DSGVO. Ein guter Startpunkt sind die EDPB Guidelines zu Art. 25 (Datenschutz durch Technikgestaltung).

Die Basis bilden auch die Grundsätze aus Art. 5 DSGVO: Zweckbindung, Datenminimierung, Speicherbegrenzung, Integrität, Rechenschaft. Den amtlichen Text finden Sie im EUR‑Lex zur DSGVO. Dieser Rahmen ist klar. Die Kunst liegt im Umsetzen.

Drei Hebel, ein Ziel: Minimierung, Pseudonymisierung, Retention

Viele Teams behandeln diese Themen getrennt. Das ist ein Fehler. Minimierung senkt die Menge der Daten. Pseudonymisierung senkt die Aussagekraft pro Datensatz. Retention senkt die Zeit im System. Zusammen formen sie einen starken Schutz. Die Grundprinzipien der Verarbeitung nennen das deutlich: so wenig wie nötig, so kurz wie möglich, so sicher wie nötig.

Kurzer Boxenstopp: typische Irrtümer

• «Pseudonymisierung ist gleich Anonymisierung.» Nein. Pseudonyme kann man unter Umständen zurückführen. Anonymisierte Daten nicht. Für klare Abgrenzung hilft der ICO‑Leitfaden zu Anonymisierung.
• «Retention gilt nicht für Backups.» Doch. Auch Sicherungen brauchen Regeln. Sonst bleiben Daten ewig im Offsite‑Tape.
• «Weniger Daten ruinieren das Reporting.» Selten. Meist braucht es klare Events, gute Labels und stabile IDs. Nicht mehr Rohdaten.

Branchensplitter: wo das Risiko hoch ist

Health, FinTech, iGaming. Hier sind Daten sensibel, Geschäftsmodelle schnell, und Prüfungen häufig. In Health geht es um Diagnosen, Befunde, Termin‑Logs. In FinTech um Kontobewegungen, Zahlungen, KYC. In iGaming um Spielverläufe, Zahlungswege, Geodaten, Altersnachweise. In all diesen Feldern zahlen sich klare Regeln aus: strikte Pflichtfelder, Token statt Klardaten, kurze Aufbewahrung, strenge Zugriffe.

Gerade im iGaming hilft Markt‑Einblick. Neutrale Reviews zeigen, was wirklich läuft und was nur auf Papier steht. Ein gutes Bild vom Stand der Branche geben Benchmarks wie Gambling Giant. Solche Übersichten lassen erkennen, welche Profilfelder Firmen streichen, wie lange Wett‑Logs bleiben, und wo Pseudonyme statt Kundennummern genutzt werden.

Technisch gibt es in Web‑Apps wiederkehrende Schwachstellen. Ein Blick auf die OWASP Top 10 Privacy Risks hilft, Priorität zu setzen: übermäßige Sammlung, fehlende Löschung, schwache Verschlüsselung, zu breite Zugriffe.

Entscheidungsbaum: Wann minimieren, wann pseudonymisieren, wann löschen?

Starten Sie immer mit dem Zweck. Fragen Sie: Brauche ich dieses Feld, um den Zweck zu erfüllen? Wenn nein, weglassen. Wenn ja, prüfen Sie: Geht es mit einem gröberen Wert? Dann aggregieren. Geht es ohne direkten Personenbezug? Dann Pseudonymisierung. Bleibt ein Rest‑Risiko, sichern Sie ab: Zugriff, Schlüssel, Protokolle.

Für die Zeitachse hilft eine einfache Regel: so kurz wie möglich, so lang wie nötig. Messen Sie in Tagen und in Events. Beispiel: 30 Tage für Fehlersuche in Logs. 180 Tage für Abrechnungen. 10 Jahre nur, wenn ein Gesetz es so will. Halten Sie das in einer Policy fest und legen Sie den Timer technisch an.

Ein guter Rahmen für den Daten‑Lebenszyklus ist das NIST Privacy Framework. Es führt durch Inventar, Schutz, Kontrolle, Kommunikation und Reaktion. Nutzen Sie es als Check.

Von Prinzip zu Praxis: eine kompakte Umsetzungstabelle

Die folgende Tabelle zeigt, wie Sie die drei Hebel aufsetzen. Mit rechtlicher Basis, einem klaren Technik‑Muster, passenden Tools und einer Metrik. Für Pseudonymisierung lohnt ein Blick auf die ENISA‑Übersicht zu Techniken und Best Practices.

Minimierung	Art. 5(1)(c) DSGVO	Pflicht‑/Kann‑Felder trennen; Events schlank halten	Consent‑aware Tracking; Data Contracts; Schema Linter	Anteil Pflichtfelder ≤ X%; Felder je Event ≤ N	Overcollection; höhere Folgen bei Vorfällen
Pseudonymisierung	Art. 32 DSGVO; Erwägungsgrund 28	Format‑preserving Tokenization; Hash mit Salt; Schlüsselrotation	Tokenization Service; KMS; Vault; HSM	Abdeckung Pipelines ≥ Y%; Re‑ID‑Risiko unter Schwelle	Re‑Identifizierbarkeit; Zweckentfremdung
Retention	Art. 5(1)(e) DSGVO	Zeit‑ und Event‑basierte Lösch‑Policies; TTL in Tabellen	Data Catalog; Scheduler; Lifecycle Policies (Objektspeicher)	Median‑Aufbewahrung sinkt; Erfolgsquote Löschjobs ≥ 99%	Endlose Speicherung; Sanktionsrisiko; unnötige Kosten
Transparenz	Art. 12–14 DSGVO	Kurze Datenschutzhinweise; Layered Notices	CMS; Consent‑Banner mit Zweck‑Texten	Lesedauer ≤ 60 Sek.; Absprungrate sinkt	Intransparenz; Beschwerden; Reputationsschäden
Löschung	Art. 17 DSGVO	Rechte‑Workflows; Hard/Soft Delete mit Audit	Ticketing; Identity & Access; Job‑Runner	Time‑to‑Delete P95 ≤ 30 Tage	Rechtsrisiken; Support‑Last; Vertrauensverlust
Backups	Art. 32 DSGVO	Backup‑Löschfenster; Key‑Separation	Backup‑Suite; KMS; Key Escrow	Max. Aufbewahrung im Backup ≤ Z Tage	«Zombie‑Daten»; lange Wiederherstellung

Architektur und Rollen: Retention by Default verdrahten

Skizzieren Sie den Fluss: Events kommen rein. Ein Katalog ordnet Felder. Policies legen Zweck und Zeit fest. Ein Service vergibt Tokens. Ein Scheduler löscht nach Plan. DLP und Logs wachen über Abweichungen. Ein Audit‑Trail hält Belege. Ohne klare Rollen klappt das nicht: Produkt priorisiert Felder, Legal prüft Zwecke, DPO prüft Risiken, Data Engineering baut die Pipelines, SecOps betreibt Schlüssel und Monitoring.

Als Rahmen für Rollen, Rechte und Maßnahmen eignet sich der BSI IT‑Grundschutz. Er hilft, Zuständigkeiten und Schutzbedarf sauber zu fassen.

Messgrößen, die zählen

• Anteil minimierter Felder pro Event.
• Abdeckung pseudonymisierter Pipelines in Prozent.
• Median der Aufbewahrungszeit je Datenklasse.
• Erfolgsquote geplanter Löschjobs pro Woche.
• Time‑to‑Delete bei Betroffenen‑Anfragen (P95).
• Quote der DLP‑Fehlalarme (soll sinken).
• Anteil Tabellen mit aktivem TTL.

Für die sichere Löschung auf Datenträgern lohnt der Blick in NIST SP 800‑88 Rev.1. Es erklärt, wann Löschen reicht, wann Überschreiben nötig ist, und wann physische Zerstörung.

Stolpersteine, die Projekte kippen

• Schatten‑Backups ohne Retention. Ergebnis: Löschpfade greifen nicht durch.
• Endlose Logs. Besonders bei Auth und Payment. Fix: Log‑Profile kürzen, TTL setzen.
• Data Lakes ohne Data Contracts. Viele Rohdaten, wenig Kontrolle. Fix: Felder labeln, Zugriffe drosseln.
• Masken in BI inkonsistent. Der gleiche Kunde hat drei IDs. Fix: zentrales Token‑Schema.
• Timer nur in App, nicht in Storage. Fix: Lebenszyklen im Speicher setzen (Objektspeicher, DB‑TTL).

Für ein sauberes Löschkonzept hilft die Norm DIN 66398. Sie gibt Struktur für Klassen, Fristen und Prozesse.

Mini‑Fallstudie: 34% weniger PII, gleiche Conversion

Ein mittleres B2C‑Portal hatte zu viele Felder im Profil. Geburtstag, Geschlecht, Telefon, Straße, alles Pflicht. Logs hielten IPs, User‑Agent, Cookies, IDs, bis zu 400 Tage. Das Team startete mit einer Karte der Daten. Es stufte Felder in Pflicht und Kann. Es strich Geburtstag und Telefon als Pflicht. Adresse nur bei Versand. Es führte Tokenization für Kundennummern ein. Es kürzte Log‑Profile. Es setzte TTL auf 30 und 90 Tage.

Ergebnis nach 8 Wochen: 34% weniger PII. 61% mehr Tabellen mit TTL. 0 PII in drei Analytics‑Dashboards. Conversion blieb gleich. Support meldete weniger Auskunftsanfragen mit Rückfragen. Audit zeigte klare Belege. Bußgeld‑Risiko sank. Kosten für Storage sanken messbar.

90‑Tage‑Plan: schnell starten, sauber verstetigen

Tag 0–30

• Datenkarte: Systeme, Tabellen, Felder, Zwecke, Rechtsgrundlagen.
• Entwurf Retention‑Policy je Datenklasse.
• Risikoliste: High‑Risk‑Felder, High‑Risk‑Pipelines.

Tag 31–60

• Pilot 1: Token für Kunden‑IDs in einer Kern‑Pipeline.
• Pilot 2: TTL in zwei großen Log‑Themen (Auth, Zahlungen).
• Auto‑Labeling von PII in Katalog und BI.

Tag 61–90

• Rollout Tokens auf weitere Streams.
• Löschjobs mit Erfolgskontrolle und Alarm bei Fehlern.
• Schulung: Produkt, Data, Support. Kurze, klare Playbooks.

Planen Sie auch Prüfungen mit Blick auf Folgenabschätzungen. Die Leitlinien zur DSFA finden Sie bei der Aufsicht als EDPB DPIA Guidelines.

FAQ aus Reviews

Wie lange darf ich IP‑Adressen speichern?
So kurz wie es für Sicherheit und Abwehr nötig ist. Oft reichen 7–30 Tage. Prüfen Sie Rechtsgrundlage und Logs je Zweck.

Brauche ich Pseudonymisierung, wenn ich schon minimal sammle?
Meist ja, zumindest für Schlüssel‑IDs. Minimierung senkt Menge. Pseudonymisierung senkt Rückführbarkeit.

Zählen Backups zur Aufbewahrung?
Ja. Definieren Sie auch hier Fristen und Wege zur Entfernung. Sonst bleiben Daten trotz Löschung in der App erhalten.

Hilft Hash immer?
Nicht immer. Ohne Salt oder bei kleinen Werte‑Mengen ist ein Hash schwach. Nutzen Sie Salt, Pepper oder Tokenization.

Praxisnahe Hinweise zur Pseudonymisierung finden Sie auch bei der CNIL.

Checkliste zum Mitnehmen

• Zweck pro Feld klar? Wenn nein: streichen.
• Pflicht‑/Kann‑Felder getrennt? UX geprüft?
• Statt Klar‑IDs: Tokens mit Rotation und KMS.
• Retention je Klasse: 30/90/180 Tage, 10 Jahre nur wenn Pflicht.
• Löschjobs geplant, getestet, geloggt, mit Alarm.
• Backups mit eigenem Löschfenster und Schlüssel‑Trennung.
• Logs schlank. Keine PII, wenn nicht zwingend nötig.
• Metriken aktiv. Monatlicher Bericht an Produkt + DPO.
• Kurze, klare Datenschutzhinweise. Kein Fachjargon für Nutzer.

Transparenz‑Box (EEAT)

Erstellt von: Redaktion Datenschutz & Data Governance, Praxis seit 10+ Jahren in Produkt‑ und Daten‑Teams (u. a. Commerce, FinTech, iGaming).
Fachlich geprüft durch: Datenschutzbeauftragte/r (DPO), Legal Counsel.
Stand: 23.03.2026. Version: 1.0.
Hinweis: Keine Rechtsberatung. Prüfen Sie immer nationale Vorgaben und Hinweise Ihrer Aufsichtsbehörde.

Weiterführende Quellen im Text

• Art. 25 DSGVO, «Datenschutz durch Technikgestaltung»: EDPB Guidelines
• Amtlicher Text der DSGVO: EUR‑Lex
• Grundsätze der Verarbeitung und Datenminimierung: BfDI
• Anonymisierung vs. Pseudonymisierung: ICO
• Privacy‑Risiken in Web‑Anwendungen: OWASP
• Privacy Framework und Lifecycle: NIST
• Pseudonymisierung: ENISA Best Practices
• Rollen, Rechte, Maßnahmen: BSI IT‑Grundschutz
• Sichere Datenlöschung: NIST SP 800‑88
• Löschkonzept: DIN 66398
• DSFA/DPIA: EDPB Guidelines
• Pseudonymisierung in der Praxis: CNIL