In den meisten gewachsenen Systemen gibt es eine Funktion zum Anlegen, eine zum Ändern und eine zum Suchen. Eine Funktion zum Löschen gibt es formal auch — sie setzt in der Regel ein Flag. Der Datensatz bleibt, er wird nur nicht mehr angezeigt. Nach fünf Jahren Betrieb enthält die Datenbank damit alles, was jemals eingegeben wurde, verteilt über Haupttabellen, Protokolle, Suchindizes, Caches, Exportdateien und Backups.
Das ist aus drei Richtungen ein Problem: rechtlich, weil personenbezogene Daten nicht unbegrenzt vorgehalten werden dürfen; wirtschaftlich, weil Speicher, Indexgrößen und Backup-Fenster mitwachsen; und im Schadensfall, weil bei einem Sicherheitsvorfall Daten abfließen, die längst nicht mehr da sein müssten.
Aufbewahren und Löschen sind kein Widerspruch
Der häufigste Einwand lautet, man müsse ohnehin zehn Jahre aufbewahren. Das stimmt für bestimmte Belege und Geschäftsvorfälle, nicht für alles. Eine Rechnung ist aufbewahrungspflichtig — der Verlauf der Warenkorb-Klicks, die zu ihr geführt haben, ist es nicht. Ein Arbeitsvertrag ist es, das Bewerbungsprofil eines abgelehnten Kandidaten nicht.
Der Ausweg ist eine Trennung auf Feldebene statt auf Datensatzebene. Die aufbewahrungspflichtigen Angaben werden in einen unveränderlichen Beleg überführt, der Rest bleibt im operativen System und unterliegt dort einer eigenen Frist. Wer das nicht trennt, hält am Ende alles zehn Jahre — nicht aus Pflicht, sondern aus Bequemlichkeit.
Ein Löschkonzept ist eine Tabelle, kein Aufsatz
Praktisch besteht ein brauchbares Löschkonzept aus einer Zeile je Datenart mit fünf Spalten: Welche Daten, in welchem System, ab welchem Ereignis läuft die Frist, wie lang ist sie, und was passiert am Ende — löschen, anonymisieren oder archivieren.
- Startereignis benennen: Fristen beginnen nicht am Anlagedatum, sondern an einem fachlichen Ereignis — Vertragsende, letzte Bestellung, Abschluss des Vorgangs.
- Endzustand festlegen: Löschen entfernt, Anonymisieren entfernt den Personenbezug und erhält die Auswertbarkeit, Archivieren verlagert in ein System mit engerem Zugriff.
- Alle Kopien erfassen: Suchindex, Cache, Data Warehouse, Protokolltabellen, Exportverzeichnisse und Anhänge im Dateispeicher gehören dazu.
- Verantwortlichkeit setzen: Je Zeile eine Person, die bestätigt, dass der Job läuft — sonst läuft er irgendwann nicht mehr und niemand merkt es.
Anonymisierung ist schwerer, als sie klingt. Ein Datensatz ohne Namen, aber mit Postleitzahl, Geburtsdatum und Kaufhistorie ist häufig wieder eindeutig zuordenbar. Wer anonymisiert, muss aggregieren oder vergröbern — sonst hat er nur den Namen entfernt und den Personenbezug behalten.
Technische Umsetzung: der Teil, der schiefgeht
Ein Löschlauf, der nachts über die Produktivdatenbank geht und Millionen Zeilen entfernt, ist ein Betriebsrisiko. Bewährt hat sich stattdessen ein schrittweises Vorgehen: kleine Stapel mit Obergrenze pro Durchlauf, außerhalb der Lastspitzen, mit Protokoll über die Anzahl betroffener Zeilen je Tabelle und einem Trockenlauf-Modus, der nur zählt.
Zweiter kritischer Punkt sind Fremdschlüssel und fachliche Abhängigkeiten. Wird ein Kunde gelöscht, dessen Rechnungen bleiben müssen, bricht die Referenz. Sauber gelöst wird das, indem der Beleg die benötigten Angaben zum Zeitpunkt der Erstellung als Kopie enthält — Rechnungen sind ohnehin Momentaufnahmen und dürfen sich nicht rückwirkend ändern.
Backups: die ehrliche Antwort
Ein gelöschter Datensatz existiert im Backup von gestern weiter. Diese Kopien nachträglich zu bereinigen ist bei den meisten Verfahren technisch nicht sinnvoll umsetzbar und erhöht das Risiko, die Wiederherstellbarkeit zu beschädigen. Der übliche und vertretbare Weg besteht aus zwei Festlegungen: eine klar begrenzte Aufbewahrungsdauer der Sicherungen und ein dokumentierter Nachlauf, der nach einer Rücksicherung die zwischenzeitlich fälligen Löschungen erneut ausführt.
Genau dieser Nachlauf fehlt fast überall. Ohne ihn holt jede Wiederherstellung Daten zurück, die bereits entfernt waren — und niemand bemerkt es, weil die Löschung als erledigt protokolliert ist.
Wo das Thema hingehört
Ein Löschkonzept, das erst nach dem Livegang entsteht, wird nie vollständig, weil die Datenflüsse dann bereits verzweigt sind. Es gehört an dieselbe Stelle wie Zugriffsrechte und Verschlüsselung — in den Entwurf. Wie das systematisch aussieht, steht im Beitrag Datenschutz by Design.
Der pragmatische Einstieg für ein bestehendes System ist trotzdem klein: eine Liste aller Tabellen mit personenbezogenen Feldern, sortiert nach Zeilenzahl. Die drei größten Positionen decken erfahrungsgemäß den überwiegenden Teil des Volumens ab — und lassen sich einzeln abarbeiten, ohne dass ein Gesamtprojekt daraus wird.