Die erste Lösch-Anfrage kam an einem Donnerstagmittag als E-Mail mit dem Betreff „Bitte löscht alle meine Daten". Ich saß vor einem System, das ich nicht durchschaute — eine Web-Datenbank, Logs mit IP-Adressen, ein Analytics-System, E-Mail-Archiv, und irgendwo in einem Backup-Ordner von vor drei Jahren standen noch Exporte. Drei Stunden später hatte ich eine grobe Vorstellung davon, wo die Daten des Anfragenden überall lagen. Manuell hätte die Löschung Tage gedauert. Heute, mit einer fünfstufigen Pipeline aus Skripten, arbeite ich so eine Anfrage in unter 30 Minuten ab — und das ohne Panik.

Dieser Artikel zeigt die technische Seite der DSGVO-Betroffenenrechte (Art. 15 bis 21), wie sie im Admin-Alltag aussieht: welche Daten du finden musst, wie der maschinenlesbare Export aussieht, wie Löschung und Anonymisierung konkret laufen, und wie du die Frist im Blick behältst. Das ist keine Rechtsberatung — das ist die Mechanik dahinter.

Die Rechte im Überblick: Art. 15 bis 21

Bevor du automatisierst, musst du wissen, was du automatisierst. Die sieben Betroffenenrechte der DSGVO in der Reihenfolge, in der sie im Alltag auftauchen:

Rechte-Checkliste: Art. 15 Auskunft, 16 Berichtigung, 17 Löschung, 18 Einschränkung, 19 Mitteilung, 20 Übertragbarkeit, 21 Widerspruch — mit technischer Umsetzung

Zwei Rechte dominieren die Praxis: Art. 15 (Auskunft) und Art. 17 (Löschung). Beide laufen auf dieselbe Frage hinaus: Wo liegen die Daten dieser Person überhaupt? Wer diese Frage nicht schnell beantworten kann, hat ein Problem — denn die Frist läuft ab dem Eingang der Anfrage, nicht ab dem Moment, in dem du das Daten-Inventar verstanden hast.

Die Fristen: ein Monat, keine Ausreden

Die DSGVO gibt in Art. 12 Abs. 3 eine Frist von einem Monat ab Anfrage-Eingang. Bei Komplexität oder vielen Anfragen darfst du um zwei weitere Monate verlängern — aber nur mit Begründung gegenüber dem Anfragenden innerhalb des ersten Monats. Und: Die Bearbeitung ist kostenlos. Gebühren sind nur bei offensichtlich unbegründeten oder exzessiven Anfragen erlaubt (Art. 12 Abs. 5) — und selbst dann musst du die Entscheidung begründen.

Praktisch heißt das: Die Uhr tickt ab der E-Mail, nicht ab deinem ersten Kaffee. Ein einfaches Frist-Tracking in einer Tabelle — eingegangen am, Frist am, Status — verhindert die teuerste Fehlerquelle überhaupt: das stille Verstreichen der Frist. Bei einer mittelständischen Website sind das ein paar Zeilen pro Monat; bei einem größeren Betrieb gehört das in ein Ticketsystem mit automatischer Erinnerung.

Die Daten, die du finden musst: das Inventar

Der schwierigste Teil ist nicht das Löschen, sondern das Finden. Personendaten liegen typischerweise an diesen Orten:

  • Datenbank: User-Tabelle, Bestellungen, Kommentare, Tickets. Alles, was über eine E-Mail-Adresse oder User-ID verknüpft ist.
  • Logs: Jede Anfrage an deinen Webserver enthält die IP-Adresse des Besuchers — das ist ein personenbezogenes Datum. Zugriffs-Logs, Error-Logs, Auth-Logs.
  • Analytics: Matomo oder ähnliche Tools speichern Besuche, Geräte, Herkunft — oft ohne klare User-ID, aber trotzdem personenbeziehbar.
  • E-Mail und Tickets: Der Klassiker, den alle vergessen. Eine Support-Konversation von vor zwei Jahren enthält Namen, Adressen, manchmal Passwörter (die dann sofort rotiert werden müssen).
  • Backups: Die gefürchtete Ecke. Daten in Backups sind nicht „weg", nur weil du sie in der Live-DB löschst.
  • Third-Party-Dienste: Newsletter-Dienste, Zahlungsanbieter, CRM — alles, was du extern betreibst, musst du separat anfassen.

Wer das Inventar einmal aufgebaut hat — im Grunde eine Liste aller Systeme und ihrer Datenquellen —, kann jede Anfrage in derselben Reihenfolge abarbeiten. Wer kein Inventar hat, beginnt jede Anfrage bei null. Deshalb ist das Inventar der eigentliche Return on Investment der Automatisierung.

Die Pipeline: fünf Schritte, unter 30 Minuten

Meine Abarbeitung folgt fünf Schritten, die ich einmal als Skripte und Vorlagen aufgebaut habe und seitdem nur noch ausführe:

Fristen-Pipeline: Eingang mit Identitätsprüfung, Inventar-Suche, JSON-Export, Löschung mit Anonymisierung, Nachweis mit Frist-Check

Schritt 1 — Eingang und Identität. Bevor irgendetwas passiert: Wer stellt die Anfrage? Bei Fernkommunikation (E-Mail) kannst du den Anfragenden nicht sehen — und du darfst Daten nicht einfach an jeden herausgeben, der eine E-Mail-Adresse nennt. Bei begründeten Zweifeln fragst du nach, obwohl die Frist läuft. Wir haben dafür eine Standard-Antwort: „Bitte bestätigen Sie mit einer Kopie Ihres Ausweises (geschwärzt) oder beantworten Sie die Sicherheitsfragen." Das ist kein Bürokratismus, sondern der Schutz vor Datendiebstahl per Social Engineering.

Schritt 2 — Inventar durchsuchen. Ein Skript sammelt alle Fundstellen: DB-Queries über die E-Mail-Adresse, grep über die Logs, Analytics-Suche. Die Ausgabe ist eine Liste „wo etwas gefunden wurde" — die Grundlage für Export und Löschung.

# Inventar: alle Treffer für eine E-Mail-Adresse
mysql -e "SELECT id, email, created_at FROM users WHERE email='x@example.com'"
grep -l "x@example.com" /var/log/nginx/*.log
grep -l "x@example.com" /srv/backups/*.sql.gz 2>/dev/null

Schritt 3 — Export (Art. 15/20). Für die Auskunft stellst du alle Daten als strukturierte Datei zusammen. Ich exportiere als JSON — maschinenlesbar, wie es Art. 20 für die Datenübertragbarkeit verlangt — und prüfe die Datei mit dem bitcalc JSON-Formatter: formatieren, validieren, Baumansicht. So sehe ich auf einen Blick, ob der Export vollständig und syntaktisch sauber ist, bevor er den Weg zum Anfragenden findet. Der Export wird nicht per E-Mail verschickt, sondern über ein passwortgeschütztes Portal mit Ablaufdatum bereitgestellt.

Schritt 4 — Löschung und Anonymisierung (Art. 17). Jetzt wird gelöscht — aber nicht blind:

# User-Daten löschen
mysql -e "DELETE FROM orders WHERE user_id=(SELECT id FROM users WHERE email='x@example.com')"
mysql -e "DELETE FROM users WHERE email='x@example.com'"

# Logs: IP anonymisieren statt löschen (Aufbewahrungspflichten!)
mysql -e "UPDATE access_log SET ip='0.0.0.0' WHERE email='x@example.com'"

Der wichtige Unterschied: In Logs wird nicht gelöscht, sondern anonymisiert — die IP wird durch eine neutrale Adresse ersetzt, damit Log-Statistiken nicht kippen und gesetzliche Aufbewahrungsfristen nicht verletzt werden. Das Prinzip habe ich im Datenschutz-Artikel schon für die IP-Anonymisierung im Webserver beschrieben; hier gilt es auch für bestehende Logs. Für Pseudonymisierung statt Anonymisierung (wenn du Zuordnungen später noch brauchst) eignet sich ein Hash mit Salt — das Prinzip zeigt der bitcalc Hash-Generator.

Schritt 5 — Nachweis und Frist. Am Ende dokumentierst du, was du wann gelöscht hast, und trägst die Anfrage im Tracking ein. Das klingt bürokratisch, ist aber dein Schutz: Wenn eine Aufsichtsbehörde fragt, belegst du die Bearbeitung — und wenn der Anfragende später behauptet, nichts bekommen zu haben, hast du den Nachweis. Für die Übergabe des Exports über das Portal generierst du ein einmaliges, starkes Passwort mit dem bitcalc Passwort-Generator — 20 Zeichen reichen für ein Ablauf-Portal, alle Klassen, und nach Ablauf ist der Zugang tot.

Backups: die ehrliche Antwort

Die Frage, die jeder stellt: „Was ist mit den Backups?" Die ehrliche Antwort: Daten in Backups sind Teil deines Verarbeitungsbestands, aber eine sofortige Löschung in allen historischen Backups ist technisch kaum sauber machbar — du müsstest jeden Snapshot neu bauen. Die übliche Praxis: Du dokumentierst, dass die Daten bis zur nächsten regulären Backup-Rotation in alten Sicherungen verbleiben und danach automatisch verschwinden, und dass Restores von alten Backups die Löschung beachten (beim Wiederherstellen wird die Löschliste angewendet). Diese Dokumentation ist der Unterschied zwischen „vergessen" und „bewusst und begründet". Wer seine Backups mit Versionierung betreibt (wie im Restic-Artikel beschrieben), kann die Retention pro Snapshot steuern — ein Grund mehr, Backups nicht als undurchsichtigen Klumpen zu behandeln.

Was die Automatisierung gebracht hat

Die erste Anfrage hat mich drei Stunden plus zwei Tage Grübeln gekostet. Die letzte, die ich bearbeitet habe, war in 26 Minuten durch: Eingang prüfen, Inventar-Skript laufen lassen (11 Sekunden), Export bauen und validieren (4 Minuten), DELETE + Anonymisierung (30 Sekunden), Nachweis und Tracking (5 Minuten). Die Frist von einem Monat war nie in Gefahr — und das Beruhigendste: Die Pipeline ist jetzt dieselbe für Auskunft, Löschung und Widerspruch, nur mit anderen Skript-Zeilen in der Mitte.

Der Kunde mit dem undurchsichtigen System von damals hat übrigens inzwischen ein Daten-Inventar — eine einzige Markdown-Datei mit allen Systemen, Datenquellen und dem jeweiligen Lösch-Skript. Sie liegt im Git-Repo des Projekts, und jede neue Datenquelle wird dort eingetragen, bevor sie produktiv geht. Das ist der eigentliche Kulturwandel: DSGVO nicht als Event, sondern als Betriebszustand.

Fazit

Betroffenenrechte sind kein Papierkram, sondern ein Datenbank-Problem. Wer das Daten-Inventar einmal aufgebaut hat, beantwortet Auskunfts- und Lösch-Anfragen mit Skripten in unter 30 Minuten statt in Tagen. Die fünf Schritte — Identität prüfen, Inventar durchsuchen, JSON-Export bauen, löschen und anonymisieren, nachweisen — decken alle sieben Rechte ab. Und wer den JSON-Export mit dem bitcalc JSON-Formatter validiert und die Übergabe mit einem frischen Passwort-Generator-Passwort absichert, hat die zwei häufigsten Fehlerquellen (kaputte Exporte und offene Übergaben) gleich mit eliminiert. Die Frist von einem Monat ist dann kein Wettlauf gegen die Uhr mehr — sondern ein Tag im Kalender, an dem längst alles erledigt ist.