Speicherbegrenzung ist 2026 die neue Front der Durchsetzung für Analytics
Die Aufsichtsbehörden fragen nicht mehr, ob du Daten rechtmäßig erhoben hast, sondern wann du sie gelöscht hast. Nach dem 42-Mio.-€-Bescheid der CNIL gegen Free und der Lösch-Prüfaktion des EDSA ist die Aufbewahrung in Analytics das Audit-Ziel.
Die teure DSGVO-Frage lautete früher gibt es eine Rechtsgrundlage zur Erhebung. 2026 wurde daraus warum liegt das noch in deiner Datenbank. Zwei Durchsetzungsereignisse holten die Aufbewahrung aus der Fußnote der Dokumentation an die Front, und Analytics-Systeme liegen genau im Wirkungsbereich.
Zwei Bescheide, die das Ziel verschoben haben
Am 13. Januar 2026 verhängte die CNIL gegen Free Mobile 27 Millionen Euro und gegen Free 15 Millionen Euro. Die meiste Berichterstattung drehte sich um die Datenpanne von 2024, bei der 24 Millionen Kundenverträge offengelegt wurden, doch der Bescheid nannte auch Artikel 5(1)(e) — die Speicherbegrenzung — ausdrücklich. Free Mobile hatte Daten zu 2,8 Millionen seit über zehn Jahren gekündigten Verträgen ohne Rechtfertigung aufbewahrt. Die Daten wurden nicht unrechtmäßig erhoben. Sie wurden unrechtmäßig behalten.
Einen Monat später veröffentlichte der EDSA die Ergebnisse seiner koordinierten Prüfaktion von 2025. Zweiunddreißig Datenschutzbehörden prüften 764 Verantwortliche zu Löschpraktiken und fanden zwei systemische Mängel: keine interne Datenklassifizierung und keine automatisierte Löschung in den IT-Systemen selbst. Eine dokumentierte Aufbewahrungsrichtlinie, die technisch nichts durchsetzt, wurde als erschwerender, nicht als mildernder Faktor gewertet.
Das Signal ist eindeutig. Die Behörden setzen die Erhebung inzwischen voraus; sie prüfen die Löschung.
Warum Analytics der naheliegende Ort ist
Die Speicherbegrenzung nach Artikel 5(1)(e) besagt, dass personenbezogene Daten nicht länger in identifizierbarer Form aufbewahrt werden dürfen, als der Zweck es erfordert. Die meisten Analytics-Stacks verstoßen dagegen stillschweigend.
Eine typische Ereignistabelle speichert pro Interaktion eine Zeile, verknüpft mit einer stabilen Kennung — einer Cookie-ID, einer Geräte-ID, einer gehashten E-Mail — mit Zeitstempel und ohne Verfallsdatum. Das Schema ist darauf ausgelegt, alles für immer aufzubewahren, damit "vielleicht wollen wir das später abfragen" möglich bleibt. Genau das ist die Vorratsspeicherung auf Verdacht, die die CNIL bestrafte.
Das Problem verschärft sich, weil erst die Kennung eine Zeile zu personenbezogenen Daten macht. Solange user_id = a91f... über Monate von Ereignissen einer Person zugeordnet werden kann, fällt jede dieser Zeilen in den Anwendungsbereich, unterliegt Auskunfts- und Löschanfragen und ist bei einer Panne eine Haftung. Aufbewahrung ist keine Speicherkosten. Sie ist in Zeit gemessenes Risiko.
Minimierung beim Schreiben schlägt Löschung beim Lesen
Die dauerhafte Lösung ist kein besserer Cronjob, der alte Zeilen entfernt. Es ist ein Datenmodell, in dem die identifizierbare Form gar nicht erst dauerhaft besteht.
Das Identitätsmodell von Monoid ist darauf aufgebaut. Ein Besucher wird nur durch einen Tages-Hash repräsentiert:
SHA-256(IP | UA | SALT_SECRET | YYYY-MM-DD)
Die rohe IP und der User-Agent existieren nur im Worker-Speicher, lange genug, um diesen Hash zu berechnen; D1 speichert den Hash, niemals die Rohwerte. Da das Datum ein Eingabewert ist, ändert sich der Hash desselben Besuchers jede Mitternacht. Es gibt keine stabile tagesübergreifende Kennung zum Aufbewahren, daher kann sich das sitzungsübergreifende Profil, auf das die Speicherbegrenzung zielt, nicht ansammeln — nicht per Richtlinie, sondern per Konstruktion.
Das ist Datenminimierung beim Schreiben. Du löschst die Verknüpfung nicht später, weil du sie nie geschrieben hast. Eine Löschanfrage wird trivial, wenn es keinen dauerhaften Schlüssel gibt, gegen den gelöscht werden müsste.
Aufbewahrung, die du tatsächlich nachweisen kannst
Die Speicherbegrenzung braucht trotzdem eine Obergrenze, und eine verteidigbare ist kurz und durchgesetzt, nicht lang und ambitioniert. Monoid bewahrt Seitenaufruf-Daten höchstens 730 Tage auf. Zwei Jahre sind eine bewusste Obergrenze für Trendanalysen, und die Löschung ist eine echte Operation auf der Tabelle, keine Zeile in einer Richtlinien-PDF. Der Befund des EDSA war, dass Richtlinien ohne Durchsetzung die Lücke sind, die Untersuchungen ausnutzen; eine Aufbewahrung, die tatsächlich ausgeführt wird, schließt sie.
Die Kombination zählt mehr als jede Hälfte für sich. Täglich rotierende Hashes bedeuten, dass die Daten schon aggregiert geformt sind, bevor die Aufbewahrung überhaupt greift. Die 730-Tage-Löschung bedeutet, dass selbst dieses aggregierte Signal ein hartes, nachweisbares Ende hat.
Wie du jede Analytics beurteilst, auf die du dich verlässt
Welche Analytics auch immer hinter deiner Website steht, drei Prüfungen lassen sich direkt auf das abbilden, was die Behörden geprüft haben:
- Finde jedes Feld, das einen Datensatz über die Zeit mit einer Person verknüpft. Eine stabile User-ID, ein persistenter Cookie-Wert, eine rohe IP, ein Fingerprint. Jedes verwandelt ein Ereignisprotokoll in ein aufbewahrtes Profil — frag also, ob die von dir genutzte Analytics überhaupt eines davon speichert.
- Frag, wann die Aufbewahrung angewendet wird — bei der Erfassung oder in einer Quartalsprüfung. Minimierung, die beim Schreiben der Daten geschieht, schlägt einen Löschjob, an dessen Auslösen sich jemand erinnern muss. Die stärkste Antwort ist ein Modell, in dem die identifizierbare Form gar nicht erst gespeichert wurde.
- Frag, ob die Löschung nachweisbar ist. Wenn ein Anbieter keine harte Aufbewahrungsgrenze nennen kann, die tatsächlich ausgeführt wird, hat er eine Richtlinie, keine Kontrolle — und die EDSA-Prüfaktion hat dir gerade gesagt, welche von beiden Bußgelder bringt.
Die in einem Audit am günstigsten zu verteidigenden Daten sind die, die du nie in identifizierbarer Form behalten hast. Die Speicherbegrenzung ist nicht mehr eine Klausel zum Paraphrasieren in einer Datenschutzerklärung; sie ist das, was die nächste Untersuchung messen wird, und die Architektur, die darauf antwortet, ist die, die nie ein Profil zum Löschen hatte.
Comments
Loading comments…