Aus der Datenbank gelöscht – aber in den Backups noch lebendig

Jedes Unternehmen hat eine Aufbewahrungsrichtlinie. Sie existiert irgendwo in einem Dokument, wahrscheinlich zuletzt aktualisiert, als jemand merkte, dass die Prüfung bevorstand, und sie besagt selbstbewusst etwas wie „personenbezogene Daten werden nach 90 Tagen gelöscht“ – eine Zahl, die gewählt wurde, um beeindruckend kurz zu klingen, anstatt aus einer dokumentierten Analyse der Zweckbindung abgeleitet zu sein. Das Management nickt. Die Rechtsabteilung stimmt zu. Das Dokument wird abgelegt.

Die Daten sind in der Zwischenzeit unsterblich. Besonders in den Backups, die niemand während des Richtlinien-Meetings erwähnt hat und die seit drei Jahren leise alles aufbewahren.

Das ist die Lücke, über die niemand spricht: der Unterschied zwischen der Existenz einer Aufbewahrungsrichtlinie und deren tatsächlicher Durchsetzung. Das Verfassen der Richtlinie dauert einen Nachmittag. Die Durchsetzung in einem echten Produktionssystem (Datenbanken, Backups, Protokolle, Drittanbieter-Prozessoren, archivierte Exporte, Data Warehouses, Schattenkopien) dauert erheblich länger und deckt architektonische Entscheidungen auf, die Sie wahrscheinlich nicht mit Blick auf die Löschung getroffen haben.

Warum die meisten Löschungsdurchsetzungen scheitern, bevor sie beginnen

Das Kernproblem ist, dass Daten an mehr Orten angesammelt werden, als die Personen, die die Richtlinie verfasst haben, wussten. Sie dachten an die Hauptdatenbank. Sie dachten nicht an die Logging-Pipeline, die Request Bodies mit Benutzerdaten erfasst und auf unbestimmte Zeit aufbewahrt, weil niemand eine Log-Rotation-Richtlinie eingerichtet hat, die tatsächlich ausgeführt wird. Oder an das Analyse-Warehouse, in das vor achtzehn Monaten Rohdaten für ein nie gestartetes Projekt geleert wurden und das immer noch vollständige Benutzerkennungen enthält, weil die Pseudonymisierung „auf der Roadmap“ war. Oder an das nächtliche Datenbank-Backup, das neunzig Tage lang aufbewahrt wird, was bedeutet, dass Daten, die Sie am ersten Tag aus Ihrer Live-Datenbank gelöscht haben, bis zum einundneunzigsten Tag intakt in einem Backup liegen, möglicherweise länger, wenn jemand vor einem großen Release manuell eine Kopie archiviert hat, „nur für den Fall“.

Ihre Aufbewahrungspflicht erstreckt sich auch auf jede Drittanbieter-Integration, die Sie im vorherigen Beitrag abgebildet haben. Wenn Sie einen Benutzer aus Ihrem System löschen, Ihr CRM aber immer noch dessen Datensatz hat, Ihr Fehlerüberwachungstool immer noch dessen Stack-Traces enthält und Ihre KI-Modell-API immer noch dessen Gesprächsverlauf in einem Fine-Tuning-Datensatz hat, haben Sie nichts wirklich gelöscht. Sie haben nur die Kopie gelöscht, die Sie kontrollieren.

Und dann ist da noch die CSV-Datei, die jemand für eine einmalige Analyse exportiert und auf seinem Laptop gespeichert hat. Dagegen können Sie sich nicht technisch absichern, aber Sie können es zu einer disziplinarischen Angelegenheit machen, anstatt zu einem technischen Nachgedanken.

Löschung, Anonymisierung, Pseudonymisierung: Warum der Unterschied zählt

Bevor Sie auch nur eine Zeile Löschcode schreiben, entscheiden Sie, welchen Ansatz Sie tatsächlich verfolgen, denn sie sind wirklich unterschiedlich und die DSGVO behandelt sie unterschiedlich.

Löschung bedeutet, dass die Daten weg sind. Wenn jemand nach der Löschung eine Auskunftsanfrage stellt, ist die richtige Antwort: „Wir speichern keine Daten über Sie.“ Sauber, einfach und am schwierigsten sauber in großem Maßstab zu implementieren.

Anonymisierung bedeutet, dass die Daten weiterhin existieren, aber nicht mehr auf eine Einzelperson zurückgeführt werden können. Nicht von Ihnen, nicht von jemandem, nicht einmal mit zusätzlichen Datensätzen oder zumutbarem Aufwand. Wenn Sie dies richtig machen, gilt die DSGVO nicht mehr für die anonymisierten Daten. Sie können sie unbegrenzt aufbewahren. Verwenden Sie sie für Analysen, QA-Datensätze, Modelltraining, Lasttests, was auch immer Sie benötigen. Das ist keine Lücke. Es ist die beabsichtigte Lösung. Die DSGVO ermutigt die Anonymisierung ausdrücklich, damit Organisationen Daten für legitime sekundäre Zwecke aufbewahren können, ohne dass die Aufbewahrungsfrist abläuft. Die Verordnung möchte, dass Sie dies tun. Sie möchte nur, dass Sie es richtig tun.

Der Haken ist, dass eine ordnungsgemäße Anonymisierung schwieriger ist, als es scheint. Das Entfernen eines Namens und einer E-Mail-Adresse aus einem Datensatz ist keine Anonymisierung, wenn die verbleibenden Felder (Altersgruppe, Postleitzahl, Berufsbezeichnung, Datum der Kontoerstellung) spezifisch genug sind, dass eine entschlossene Person die Person trotzdem identifizieren könnte. Dies wird als Re-Identifizierungsrisiko bezeichnet, und die Unterschätzung dieses Risikos führt dazu, dass Anonymisierungsprojekte leise zu Pseudonymisierungsprojekten werden, die niemanden täuschen, am allerwenigsten einen Regulierungsbehörden.

Pseudonymisierung (Ersetzen direkter Identifikatoren durch Token, wobei eine Zuordnungstabelle irgendwo aufbewahrt wird) ist betrieblich nützlich und die DSGVO erkennt dies an, aber sie erfüllt allein keine Löschungspflicht. Die Person ist über die Zuordnungstabelle immer noch identifizierbar. Das Löschen der Zuordnungstabelle hilft, ist aber auch nicht garantiert ausreichend, da die pseudonymisierten Datensätze möglicherweise immer noch durch andere Attribute im Datensatz re-identifizierbar sind. Wenn Sie beabsichtigen, sich zur Erfüllung von Aufbewahrungspflichten auf die Pseudonymisierung zu verlassen, holen Sie sich eine ordnungsgemäße Stellungnahme ein, bevor Sie die Aufgabe abschließen, und nicht danach.

Die praktische Aufteilung für die meisten Entwickler: Löschen Sie personenbezogene Daten, die Sie für den ursprünglichen Zweck nicht mehr benötigen, anonymisieren Sie Daten, für die Sie einen echten legitimen Grund zur Aufbewahrung für sekundäre Zwecke wie QA, Tests und Modellverbesserung haben. Führen Sie die Anonymisierung ordnungsgemäß durch: Entfernen Sie direkte Identifikatoren, bewerten Sie das Re-Identifizierungsrisiko anhand der verbleibenden Felder, dokumentieren Sie Ihre Bewertung. Wenn Sie dies nicht selbstbewusst tun können, löschen Sie stattdessen. Eine fehlerhafte Anonymisierung und die Behauptung, sie sei abgeschlossen, ist schlimmer, als es gar nicht erst zu versuchen.

Wie man die Löschung tatsächlich implementiert

Beginnen Sie damit, jeden Ort zu kartieren, an dem die Daten eines Benutzers gespeichert sind. Nicht die Orte, an denen Sie denken, dass sie gespeichert sind. Die Orte, an denen sie tatsächlich gespeichert sind. Führen Sie die Übung auf die gleiche Weise durch wie die Integrationsprüfung im vorherigen Beitrag: Beginnen Sie mit dem, was beobachtbar ist (Datenbanktabellen, Protokollziele, Drittanbieter-Integrationen), nicht mit dem, was das Architekturdiagramm besagt.

Beantworten Sie für jeden Ort drei Fragen. Können Sie bedarfsgesteuert löschen oder anonymisieren? Können Sie diese Löschung automatisiert planen? Können Sie überprüfen, ob die Löschung stattgefunden hat?

Die dritte Frage ist diejenige, die die meisten Teams überspringen. Ein Löschauftrag, der stillschweigend fehlschlägt und Erfolg meldet, ist schlimmer als gar kein Löschauftrag, da Sie nun einen Compliance-Nachweis haben, der besagt, dass Daten gelöscht wurden, obwohl dies nicht der Fall war. Bauen Sie die Überprüfung von Anfang an ein. Protokollieren Sie die Löschung, protokollieren Sie die Anzahl der betroffenen Datensätze, lösen Sie Alarme aus, wenn für Benutzer, die Daten hätten haben sollen, keine Löschungen erfolgen.

Für Ihre Hauptdatenbank ist die Löschung normalerweise unkompliziert: ein geplanter Auftrag, der auf `created_at` oder `last_active` basiert, mit einer Soft-Delete-Periode, falls Ihr Support-Team ein Wiederherstellungsfenster benötigt. Die Soft-Delete-Periode ist ebenfalls eine Aufbewahrungsfrist. Definieren Sie sie explizit und setzen Sie sie durch.

Für Protokolle legen Sie Aufbewahrungsrichtlinien auf Pipeline-Ebene fest, nicht als manuellen Bereinigungsauftrag. Wenn Ihre Logging-Infrastruktur dies unterstützt, filtern Sie PII-Daten bereits bei der Aufnahme aus den Protokolleinträgen heraus, anstatt zu versuchen, sie später zu löschen. Das nachträgliche Löschen bestimmter Datensätze aus einem Protokollstrom ist mühsam. Sie gar nicht erst zu schreiben, ist viel einfacher.

Bei Backups akzeptieren Sie, dass es eine Verzögerung geben wird. Wenn Ihre Backups dreißig Tage lang aufbewahrt werden, bleiben Daten, die aus Ihrem Live-System gelöscht wurden, bis zu dreißig Tage in den Backups erhalten. Dokumentieren Sie dies. Dies ist unter der DSGVO im Allgemeinen akzeptabel, vorausgesetzt, Ihre Aufbewahrungsrichtlinie berücksichtigt dies und Sie verwenden Backups nicht als Mittel zur Umgehung von Löschungspflichten. Was nicht akzeptabel ist, ist die unbegrenzte Aufbewahrung von Backups, weil niemand jemals die Aufbewahrungseinstellung für den Backup-Auftrag überprüft hat.

Für Drittanbieter-Prozessoren müssen Löschungsanforderungen nach unten weitergeleitet werden. Dies bedeutet entweder automatisierte API-Aufrufe, um die Löschung bei jedem Prozessor auszulösen, oder einen dokumentierten manuellen Prozess mit einem Abschlussnachweis. Die meisten großen Anbieter unterstützen Löschungs-APIs. Nutzen Sie diese. Für Anbieter, die dies nicht tun, ist dies eine Unterhaltung, die Sie führen müssen, bevor Sie sich auf sie verlassen, wenn es um personenbezogene Daten geht.

Das Backup-Problem in einfachen Worten

Backups verdienen einen eigenen Absatz, da sie der Ort sind, an dem die meisten Aufbewahrungsprogramme leise scheitern.

Ein Backup ist ein Point-in-Time-Snapshot. Wenn Sie Daten aus Ihrem Live-System löschen, breitet sich diese Löschung nicht auf bestehende Backups aus. Die gelöschten Daten existieren weiterhin in jedem Backup, das vor der Löschung erstellt wurde. Das ist in Ordnung und erwartet. Die Frage ist, wie lange diese Backups aufbewahrt werden.

Die Antwort in den meisten Unternehmen lautet: „Länger als irgendjemand ahnte.“ Backup-Aufbewahrungseinstellungen werden einmal konfiguriert und vergessen. Speicher ist billig. Niemand prüft die Backup-Aufbewahrungsrichtlinie gegen die Datenaufbewahrungsrichtlinie. Das Ergebnis ist ein Friedhof von Point-in-Time-Snapshots, die personenbezogene Daten von Benutzern enthalten, die ihre Konten vor Jahren gelöscht haben.

Überprüfen Sie jetzt Ihre Backup-Aufbewahrungseinstellungen. Richten Sie sie an Ihrer Datenaufbewahrungsrichtlinie aus. Wenn Ihre Richtlinie besagt, dass Daten nach neunzig Tagen gelöscht werden, sollten Ihre Backups nicht ein Jahr lang aufbewahrt werden. Und wenn Sie eine Löschungsanforderung für eine bestimmte Person erhalten, vermerken Sie in Ihren Aufzeichnungen, dass die Löschung abgeschlossen ist, sobald das relevante Backup-Fenster abgelaufen ist. Das ist die ehrliche Antwort, und sie ist vertretbar.

Was gut aussieht

Ein Aufbewahrungsprogramm, das tatsächlich funktioniert, hat vier Eigenschaften.

Es ist automatisiert. Manuelle Löschprozesse scheitern, weil Menschen vergessen, krank werden, das Unternehmen verlassen und den Löschungsrückstand von jemandem erben, der vor ihnen gegangen ist. Wenn es nicht automatisiert ist, ist es kein Aufbewahrungsprogramm. Es ist eine gute Absicht.

Es ist verifiziert. Jeder Löschauftrag erzeugt einen Nachweis darüber, was wann gelöscht wurde und wie viele Datensätze betroffen waren. Anomalien lösen Alarme aus. Der Verifizierungsnachweis wird aufbewahrt. Ja, es gibt eine gewisse Ironie darin, Aufzeichnungen über Ihre Löschungsaufzeichnungen aufzubewahren, aber so sehen Prüfungsnachweise aus.

Es deckt den gesamten Datenbestand ab. Hauptdatenbank, Protokolle, Backups, Drittanbieter-Prozessoren, Data Warehouses, exportierte Dateien, wo immer möglich. Eine Löschungsdurchsetzung, die nur die Hauptdatenbank betrifft, ist keine Löschungsdurchsetzung. Es ist das Aufräumen eines Regals, während der Rest des Hauses sich ansammelt.

Es wird getestet. Führen Sie einen Löschauftrag gegen einen Testdatensatz aus, bevor Sie ihn in der Produktion ausführen. Überprüfen Sie das Ergebnis. Tun Sie dies jedes Mal, wenn sich der Auftrag ändert. „Der Löschauftrag läuft“ und „Der Löschauftrag funktioniert korrekt“ sind unterschiedliche Aussagen, und Sie möchten Beweise für beides haben.