„Konto löschen“ reicht nicht: Der technische Erasure-Test für Websites und SaaS

Ein Nutzer klickt auf „Konto löschen“. Das Profil verschwindet, der Login funktioniert nicht mehr und die Anwendung zeigt eine Bestätigung.

Im Hintergrund existieren jedoch weiterhin ein Support-Ticket mit der E-Mail-Adresse, eine exportierte CSV im Team-Ordner, hochgeladene Dateien im Object Storage, Events im Analytics-System, Datensätze beim Newsletter-Anbieter und ein Benutzerobjekt im Auth-Dienst. Beim nächsten Restore aus einem alten Backup könnte ein Teil davon sogar wieder auftauchen.

Dann wurde nicht unbedingt gelöscht. Es wurde zunächst nur die sichtbare Oberfläche entfernt.

Genau diese Lücke ist 2026 besonders aktuell: Der Europäische Datenschutzausschuss veröffentlichte am 18. Februar 2026 die Ergebnisse seiner koordinierten Aktion zum Recht auf Löschung. 32 Datenschutzaufsichtsbehörden waren beteiligt, 764 Verantwortliche antworteten. Zu den wiederkehrenden Herausforderungen gehörten fehlende interne Verfahren, unzureichende Informationen für betroffene Personen und ungeeignete Anonymisierung als Ersatz für echte Löschung.

Die technische Kernfrage lautet deshalb:

Kann Ihr System personenbezogene Daten über die gesamte Datenkette nachvollziehbar entfernen – oder löscht es nur den offensichtlichsten Datensatz?

Löschung ist kein einzelnes SQL-Statement

Bei einer einfachen Anwendung scheint der Vorgang klar: DELETE FROM users WHERE id = ....

In realen Website-, Shop- und SaaS-Systemen verteilt sich eine Identität jedoch über viele Dienste:

• Benutzer- und Profiltabellen
• Authentifizierungsanbieter und aktive Sessions
• Bestellungen, Buchungen oder Vertragsdaten
• Formulareinsendungen und CRM
• Support- und Ticketsysteme
• Newsletter- und Marketingplattformen
• Uploads, Avatare, Dokumente und Audio
• Analyse- und Produkt-Events
• Suchindizes, Caches und Data Warehouses
• E-Mail-Provider und Zustellprotokolle
• Anwendungs-, Sicherheits- und Infrastruktur-Logs
• Exporte, Reports und lokale Arbeitskopien
• Backups
• externe Auftragsverarbeiter

Ein Löschprozess muss nicht zwangsläufig alles sofort und unterschiedslos vernichten. Das Recht auf Löschung ist nicht absolut; für bestimmte Daten können Aufbewahrungspflichten oder andere Ausnahmen gelten. Technisch braucht es deshalb pro Datenkategorie eine bewusste Entscheidung: löschen, wirksam anonymisieren, gesperrt aufbewahren oder aus einem anderen nachvollziehbaren Grund weiterhin verarbeiten.

Was nicht belastbar ist: Daten einfach dort liegen zu lassen, weil niemand weiß, wo sie sind.

Der gefährliche Unterschied zwischen Konto und Person

Viele Systeme modellieren ein „Konto“, aber nicht alle Daten, die zu einer Person gehören.

Ein Beispiel:

• Der Account nutzt die interne ID usr_2841.
• Das CRM kennt nur jenny@example.de.
• Ein Support-Tool speichert die Person unter einer eigenen Kontakt-ID.
• Dateinamen enthalten die alte E-Mail-Adresse.
• Analytics verwendet eine pseudonyme Geräte- oder Nutzer-ID.
• Rechnungen referenzieren eine Kunden-ID des Zahlungsanbieters.
• Logs enthalten Request-Pfade, IP-Adressen oder Formularfelder.

Wird nur usr_2841 gelöscht, bleiben diese Beziehungen bestehen. Für eine vollständige Bearbeitung braucht das System deshalb eine Identitätsauflösung: Welche stabilen, erlaubten Schlüssel verbinden Datensätze über Systeme hinweg, und wie werden sie gefunden, ohne dabei noch mehr personenbezogene Daten unnötig zu vervielfältigen?

Das ist weniger glamourös als ein neuer Button. Es ist aber der Unterschied zwischen einer UI-Funktion und einem belastbaren Prozess.

Neun Red Flags in bestehenden Löschabläufen

1. Der Button deaktiviert nur den Login

Das Konto erhält deleted_at, aber Profil, Dateien, Events und Drittanbieter-Daten bleiben unverändert bestehen. Soft Delete kann für Wiederherstellung oder Prüfung sinnvoll sein, ist allein aber keine Löschstrategie.

2. E-Mail-Adressen werden durch Platzhalter ersetzt

Aus max@example.de wird deleted-user-123@example.invalid, während Name, Freitext, IP-Adressen, Bestellhistorie und Uploads erhalten bleiben. Das ist keine wirksame Anonymisierung, wenn die Person weiterhin identifizierbar ist.

3. Hintergrundjobs können teilweise scheitern

Der Auth-Account wird entfernt, die CRM-Löschung schlägt jedoch fehl. Trotzdem markiert das System den gesamten Vorgang als erledigt. Ohne Einzelstatus, Retry und Eskalation entsteht ein stiller Teilerfolg.

4. Auftragsverarbeiter werden manuell vergessen

Newsletter, CRM, Support, Hosting, Analyse oder Dateiverarbeitung enthalten weiterhin Daten, weil es weder API-Aufruf noch betreute manuelle Aufgabe gibt. Die CNIL empfiehlt für die technische Umsetzung ausdrücklich, auch die Benachrichtigung von Auftragsverarbeitern vorzusehen.

5. Backups können gelöschte Daten zurückbringen

Ein Restore stellt einen alten Datenstand wieder her, danach laufen keine Lösch-Tombstones oder Nachverarbeitungen. Der zuvor bearbeitete Datensatz wird erneut aktiv.

6. Logs kopieren den gesamten Löschantrag

Um den Vorgang zu beweisen, schreibt das System Name, E-Mail, Request Body und Datenkopien in ein dauerhaftes Audit-Log. Damit erzeugt die Löschung ein neues, besonders langlebiges personenbezogenes Archiv.

7. Exporte sind außerhalb des Systems unsichtbar

Eine CSV wurde für Vertrieb, Support oder Buchhaltung erzeugt. Der Hauptprozess kennt sie nicht mehr. Ohne Exportinventar und Ablaufregeln kann niemand verlässlich sagen, wo Kopien liegen.

8. Ein gelöschter Nutzer wird beim nächsten Login neu angelegt

Social Login oder ein externes Identity-System erzeugt automatisch wieder ein lokales Konto. Alte Zuordnungen, Marketingstatus oder Events verbinden sich erneut.

9. Niemand testet den vollständigen Ablauf

Der Happy Path löscht einen Testnutzer aus der Hauptdatenbank. Nie geprüft werden Drittanbieter-Ausfall, große Dateimengen, laufende Jobs, parallele Sessions, Restore oder erneut eintreffende Webhooks.

Ein belastbarer technischer Löschprozess

1. Datenlandkarte vor Automatisierung

Erstellen Sie zunächst eine Tabelle für jede relevante Datenkategorie:

• System und Verantwortlicher
• Identifikatoren
• Zweck
• Speicherort
• Aufbewahrungsregel
• mögliche Ausnahme
• technische Aktion
• Nachweis
• Fehler- und Eskalationsweg

Ohne diese Übersicht automatisiert ein Team nur die Systeme, an die es gerade denkt.

2. Anfrage sicher verifizieren

Ein Lösch-Endpunkt ist eine hochkritische Funktion. Eine fremde Person darf nicht durch Kenntnis einer E-Mail-Adresse ein Konto zerstören.

Je nach Risiko gehören dazu:

• aktuelle Authentifizierung
• erneute Passwort- oder MFA-Bestätigung
• Schutz vor CSRF und Session-Hijacking
• klare Behandlung kompromittierter oder verlorener Konten
• Rate Limits und Missbrauchserkennung
• sichere manuelle Prüfung bei Sonderfällen

Die Verifikation sollte verhältnismäßig sein. Sie darf nicht künstlich so schwer werden, dass das Recht praktisch nicht ausgeübt werden kann.

3. Einen orchestrierten Vorgang statt einer langen Anfrage verwenden

Löschung über mehrere Systeme dauert und einzelne Dienste können ausfallen. Ein robuster Prozess erzeugt deshalb einen Vorgang mit eigener ID und klaren Zuständen, beispielsweise:

• angefordert
• Identität geprüft
• in Bearbeitung
• teilweise fehlgeschlagen
• ausstehende manuelle Prüfung
• abgeschlossen
• wegen dokumentierter Ausnahme teilweise aufbewahrt

Jede Aktion sollte idempotent sein: Ein Retry darf nicht zu doppelten Nebenwirkungen oder einem unklaren Zustand führen.

4. Daten pro System gezielt behandeln

Nicht jedes System unterstützt denselben Vorgang. Typische Aktionen sind:

• Datensatz löschen
• Datei inklusive Derivate entfernen
• Suchindex aktualisieren
• Cache invalidieren
• Token, Sessions und API-Schlüssel widerrufen
• Marketingprofil löschen oder sperren
• Drittanbieter-API aufrufen
• Daten wirksam anonymisieren
• rechtlich aufzubewahrende Daten isolieren und Zugriffe begrenzen

„Wir anonymisieren alles“ ist keine ausreichende Spezifikation. Es muss geprüft werden, ob direkte und indirekte Identifikatoren tatsächlich keine Re-Identifikation mehr erlauben.

5. Externe Dienste mit eigenem Status führen

Für jeden Auftragsverarbeiter braucht der Löschvorgang einen sichtbaren Ausgang:

• bestätigt
• API fehlgeschlagen
• manuelle Aufgabe erstellt
• nicht betroffen
• Aufbewahrung begründet
• erneute Prüfung erforderlich

Ein erfolgreicher API-Request ist noch kein Beweis, dass der Anbieter die gewünschte Aktion abgeschlossen hat. Wo verfügbar, sollten Webhook, Statusabfrage oder dokumentierte Bestätigung ausgewertet werden.

6. Den Vorgang protokollieren, ohne neue Datenhalde

OWASP empfiehlt, Lösch- und Benutzerverwaltungsaktionen zu protokollieren, warnt aber zugleich davor, sensible personenbezogene Daten unnötig direkt in Logs zu schreiben.

Ein sinnvoller Nachweis kann enthalten:

• interne Vorgangs-ID
• Zeitpunkt
• authentifizierter Auslöser oder Rolle
• betroffene Systemklasse
• Aktion
• Ergebnis
• Fehlercode
• Release-Version
• Abschlussstatus

Name, vollständige E-Mail, Inhalte und Tokens gehören nicht automatisch in jeden Logeintrag. Der Nachweis soll zeigen, dass etwas bearbeitet wurde, nicht die gelöschten Daten konservieren.

7. Backups als eigenen Lebenszyklus behandeln

Die CNIL nennt zwei technische Wege: Daten auch in Backups löschen oder sicherstellen, dass gelöschte Daten bei einer Wiederherstellung nicht wiederhergestellt werden.

In vielen Backup-Systemen ist eine nachträgliche Änderung unveränderlicher Archive weder sinnvoll noch sicher. Dann braucht es mindestens:

• dokumentierte Aufbewahrungsdauer
• stark begrenzten Zugriff
• keine normale operative Nutzung
• automatische Überschreibung oder Ablauf
• Lösch-Tombstones oder eine Wiederanwendungs-Liste
• einen Restore-Runbook-Schritt, der gelöschte Identitäten vor Freigabe erneut entfernt
• einen Test, der genau dieses Verhalten beweist

Ein Backup darf nicht zur Zeitmaschine werden, die abgeschlossene Löschungen unbemerkt rückgängig macht.

8. Den Workflow als reale Nutzerreise testen

Ein aussagekräftiger Test erzeugt einen synthetischen Nutzer mit eindeutigen Markern und verteilt bewusst Daten über alle vorgesehenen Systeme:

1. Konto und Profil anlegen.
2. Formular senden, Datei hochladen und Supportfall erzeugen.
3. Newsletter- oder CRM-Integration auslösen.
4. Events und Logs entstehen lassen.
5. Löschung anfordern.
6. jeden Systemstatus prüfen.
7. nach Suchindex, Cache, Storage und Drittanbieter-Daten suchen.
8. einen Teilausfall simulieren und Retry prüfen.
9. einen isolierten Backup-Restore testen.
10. kontrollieren, ob keine gelöschte Identität reaktiviert wird.

„Die Benutzerzeile ist weg“ wäre hier nur eine von vielen Assertions.

Was Website-Pflichtencheck prüfen würde

Ein technischer Lösch- und Datenlebenszyklus-Check kann untersuchen:

• sichtbare Lösch- und Anfragewege
• sichere Identitätsprüfung
• Dateninventar und Identifikatoren
• Hauptdatenbank, Auth, Dateien und Suchindizes
• CRM-, Newsletter-, Support- und Analytics-Integrationen
• Sessions, Tokens und Webhooks
• Orchestrierung, Retries und Teilerfolge
• Logs und Datenminimierung
• Backups und Restore-Verhalten
• Exporte und manuelle Arbeitskopien
• Nutzerkommunikation und Statusmeldungen
• automatisierte Regressionstests

Das Ergebnis sollte nicht pauschal versprechen, dass „alles gelöscht“ wird. Es sollte pro System zeigen, was entfernt wurde, was aus welchem dokumentierten Grund verbleibt, wer dafür verantwortlich ist und wie Fehler sichtbar werden.

Ein Löschbutton ist schnell gebaut. Ein Löschprozess, der Daten über Jahre gewachsener Integrationen zuverlässig findet, behandelt und nicht wiederauferstehen lässt, ist echte Produkt- und Betriebsqualität.

Wenn Sie heute nicht nachvollziehen können, in welchen Systemen ein Nutzer nach der Kontolöschung noch existiert, haben Sie kein abgeschlossenes Löschverfahren – sondern eine Hoffnung mit Button.

Hinweis: Dieser Beitrag ist eine technische Übersicht und keine Rechtsberatung. Ob und in welchem Umfang Daten gelöscht oder aufbewahrt werden müssen, sollte für den konkreten Fall rechtlich geprüft werden.