DSGVO-Löschpflicht: Nutzer aus komplexen SaaS-Systemen wirklich löschen

Ein Berliner B2B-SaaS-Anbieter mit rund 80.000 Endnutzern erhielt Anfang 2026 einen Antrag auf Löschung nach der DSGVO von einem ehemaligen Kunden. Der Produktmanager klickte im Admin-Tool auf "Nutzer löschen", die Zeile verschwand aus der primären Datenbank, und eine Bestätigungsmail ging innerhalb einer Stunde raus. Dreizehn Tage später schickte dieselbe Person eine E-Mail mit Screenshots ihrer alten Support-Tickets - mit vollständigen, unveränderten personenbezogenen Daten, die aus einem Zendesk-Export stammten, den der SaaS-Anbieter zwei Jahre zuvor in sein Analytics-Warehouse importiert hatte. Die betroffene Person reichte eine Beschwerde bei der Berliner Beauftragten für Datenschutz und Informationsfreiheit ein. Das Bußgeld war moderat. Der Reputationsschaden war es nicht.

Das DSGVO-Recht auf Löschung ist die datenschutzrechtliche Pflicht, die Engineering-Teams am häufigsten unterschätzen. Auf dem Papier ist es nur ein Artikel - Artikel 17 - und einige bekannte Ausnahmen. In einem echten Produktionssystem ist es ein verteiltes Problem, das jede Datenbank, jede Queue, jeden Suchindex, jedes Analytics-Warehouse, jedes Backup-Band, jeden Drittanbieter-Processor und jedes Audit-Log berührt, das ein Team über ein Jahrzehnt des Entwickelns angesammelt hat. Halb implementierte Lösch-Flows sind die Norm, nicht die Ausnahme, und genau das suchen Regulatoren und Prüfer heute. Dieser Beitrag ist ein praktischer Engineering-Blueprint dafür, wie man die Pflicht in einem komplexen SaaS wirklich erfüllt.

Was Artikel 17 tatsächlich verlangt - und die Frist für das Recht auf Löschung

Artikel 17 DSGVO gibt betroffenen Personen das Recht auf Löschung ihrer personenbezogenen Daten, wenn einer von sechs Gründen vorliegt - am häufigsten, wenn die Daten für den ursprünglichen Zweck nicht mehr notwendig sind, die betroffene Person die Einwilligung widerruft und keine andere Rechtsgrundlage besteht, oder die Person nach Artikel 21 Widerspruch einlegt und kein überwiegendes berechtigtes Interesse vorliegt. Der Verantwortliche muss "unverzüglich" handeln, was der EDPB als maximal einen Kalendermonat interpretiert, verlängerbar um zwei Monate bei komplexen Fällen, sofern die betroffene Person über die Verlängerung und die Gründe informiert wird.

Drei Ausnahmen sind für Engineering-Teams relevant. Erstens kann der Verantwortliche Daten aufbewahren, die zur Erfüllung einer rechtlichen Verpflichtung erforderlich sind - Rechnungsmetadaten nach Steuerrecht (in Deutschland typischerweise zehn Jahre), KYC-Unterlagen nach Geldwäscherecht, Beschäftigungsunterlagen und ähnliches. Zweitens kann der Verantwortliche Daten aufbewahren, die für die Geltendmachung, Ausübung oder Verteidigung von Rechtsansprüchen erforderlich sind. Drittens kann der Verantwortliche Daten für Archivzwecke im öffentlichen Interesse, wissenschaftliche Forschung oder statistische Zwecke aufbewahren, sofern die Verarbeitung wirklich anonymisiert oder streng abgesichert ist. Außerhalb dieser Ausnahmen ist die Pflicht absolut: die Daten müssen weg.

Die Pflicht, die Engineers am häufigsten übersehen, ergibt sich aus Artikel 19. Wenn ein Verantwortlicher personenbezogene Daten an Empfänger weitergegeben hat - Drittanbieter-Processor, Sub-Processor, Integrationspartner - muss er jedem davon die Löschung mitteilen, es sei denn, das erweist sich als unmöglich oder wäre mit einem unverhältnismäßigen Aufwand verbunden. In einem typischen SaaS bedeutet das: E-Mail-Dienst, Analytics-Processor, Support-Tool, Abrechnungssystem, Data Warehouse und alle vom Nutzer autorisierten Kunden-Integrationen. "Wir haben sie in unserer Datenbank gelöscht" ist keine vollständige Antwort.

Das Architekturproblem: Wo Nutzer-PII tatsächlich liegt

Ein modernes SaaS verteilt Nutzerdaten über weitaus mehr Stellen, als die Architekturdiagramme zugeben. In einem Symfony-plus-Next.js-Stack umfasst ein ehrliches Inventar zehn oder mehr Stellen: die primäre PostgreSQL-Datenbank, Read-Replicas und Reporting-Kopien, den Redis-Cache, die Message-Queue (die serialisierte Nutzer-Payloads in Retry-Queues stundenlang hält), Elasticsearch- oder OpenSearch-Indizes, S3 oder Objektspeicher für Uploads und Exporte, Anwendungslogs und den Event-Stream, ein Analytics-Warehouse wie BigQuery oder Snowflake, den Data Lake, der es speist, Drittanbieter-Processor (E-Mail, CRM, Support, A/B-Tests) und die Backups aller persistenten Stores.

Jede dieser Stellen hat einen anderen Löschmechanismus. Eine PostgreSQL-Zeile ist einfach; ein Suchindex ist eventually-consistent und braucht einen Refresh; eine Message-Queue lässt sich nicht selektiv bearbeiten; ein Analytics-Warehouse ist typischerweise append-only mit partitionierten Tabellen, die Point-Deletes teuer machen; ein Drittanbieter-Processor ist nur über seine DSR-API erreichbar. Backups sind eine eigene Welt, dazu weiter unten mehr.

Eine Löschstrategie muss daher als Dateninventar-Übung beginnen. Erfasse jedes System, das irgendetwas enthält, das mit einem Nutzeridentifier verknüpft ist, und markiere, welche Bestände direkte PII sind, welche pseudonymisierte Ereignisse, welche abgeleiteten Aggregate ohne PII sobald die Nutzer-ID entfernt ist, und welche einer gesetzlichen Aufbewahrungspflicht unterliegen. Ein fokussiertes Code-Quality-Audit legt oft die stillen Bestände offen - alte Microservices, die in einen vergessenen S3-Bucket schreiben, Ad-hoc-CSV-Exporte auf einem Netzlaufwerk, Integrationstestdaten in einem öffentlichen Reporting-Tool - die niemand auf der Liste hatte.

Das Backup-Problem: Legitime Aufbewahrung vs. operative Realität

Backups sind die Stelle, an der die meisten "Wir unterstützen DSGVO-Löschung"-Behauptungen stillschweigend auseinanderfallen. Der Europäische Datenschutzausschuss hat relativ pragmatische Leitlinien veröffentlicht: Ein Verantwortlicher muss keinen Datensatz zum Zeitpunkt eines Antrags chirurgisch aus jedem Backup-Band löschen. Aber der Verantwortliche braucht eine vertretbare Antwort darauf, was mit der Löschung passiert, wenn das Backup wiederhergestellt wird.

Das in 2026 akzeptierte Muster ist ausstehende Löschung bei Wiederherstellung, manchmal auch als "Delete on Resurrection"-Muster bezeichnet. Der Verantwortliche führt eine dauerhafte Liste der gelöschten Betroffenen-Identifier - getrennt von der operativen Datenbank, in einem Append-only-Store mit eigener Backup-Disziplin. Wenn ein Backup wiederhergestellt wird, konsultiert der Restore-Prozess diese Liste und wendet jede Löschung erneut an, bevor die wiederhergestellten Daten einem Produktionssystem oder einer Person zugänglich gemacht werden. In Kombination mit einer vertretbaren Backup-Aufbewahrungsrichtlinie - typischerweise 30 bis 60 Tage für vollständige operative Backups - erfüllt dies die Pflicht nach den veröffentlichten Leitlinien fast jeder Aufsichtsbehörde.

Die Implementierung ist unspektakulär. Das Lösch-Ledger muss vor dem Ausführen der operativen Löschung geschrieben werden, damit ein Absturz mitten im Flow den Antrag nicht verliert. Restore-Runbooks müssen den Ledger-Replay-Schritt als verbindliche Checkliste enthalten. Und das Team muss mindestens vierteljährlich einen echten Restore üben.

Tombstones, Pseudonymisierung und das Audit-Log-Problem

Die schwierigste Entscheidung ist, was mit Datensätzen zu tun ist, die den Nutzer referenzieren, aber nicht einfach verschwinden können. Ein Fremdschlüssel in einer Bestelltabelle, ein Audit-Log, das zeigt, dass Nutzer X Transaktion Y genehmigt hat, ein unveränderlicher Event-Store - keiner davon kann hard-gelöscht werden, ohne die Systemkonsistenz zu brechen oder eine andere gesetzliche Anforderung zu verletzen.

Das richtige Muster ist Löschung personenbezogener Daten, Beibehaltung des strukturellen Datensatzes. Die Bestellzeile bleibt, aber der Kunden-ID-Fremdschlüssel wird durch einen Tombstone-Marker ersetzt und jede PII-Spalte überschrieben. Der Audit-Log-Eintrag bleibt, aber der Akteur-Identifier wird durch ein stabiles Pseudonym ersetzt, das ohne einen zerstörten Schlüssel nicht auf den ursprünglichen Nutzer zurückzuführen ist. Der Event-Store bleibt, aber eine Ersatz-Projektion wird aufgebaut, die gelöschte Betroffene ausschließt.

Eine typische Symfony-Implementierung sieht in etwa so aus:

// src/Service/UserErasure/Eraser.php
public function erase(User $user, ErasureRequest $request): void
{
    $this->em->wrapInTransaction(function () use ($user, $request) {
        $pseudonym = $this->pseudonymiser->createFor($user);

        $this->ledger->record($user->getId(), $request);

        $this->scrubProfile($user);
        $this->repointReferences($user, $pseudonym);
        $this->scrubFreeTextColumns($user, $pseudonym);

        $this->em->persist($user);
    });

    $this->bus->dispatch(new SubjectErasedEvent($user->getId(), $pseudonym));
}

Das SubjectErasedEvent breitet die Löschung asynchron auf jedes andere System aus: Der Suchindex löscht das Dokument, der Analytics-Consumer schreibt die Ereignisse des Betroffenen um oder anonymisiert sie, die Drittanbieter-Processor erhalten DSR-API-Aufrufe, der Objektspeicher-Purge-Job entfernt hochgeladene Dateien, und ein abschließender Verifizierungsjob bestätigt, dass jedes nachgelagerte System Erfolg gemeldet hat. Der synchrone Teil der Löschung dauert Millisekunden; der Rest ist beobachtbar, wiederholbar und über den Event-Bus nachverfolgbar.

Löschung über Microservices und Drittanbieter orchestrieren

Die Orchestrierung ist der Punkt, an dem Teams es entweder richtig machen oder Audits nicht bestehen. Das funktionierende Muster ist eine DSR-Pipeline - ein dedizierter, beobachtbarer, testbarer Workflow-Dienst statt ad-hoc-Löschcode verteilt über Module. Die Pipeline besitzt eine einzige State-Machine pro Antrag: empfangen, bestätigt, primär gelöscht, nachgelagert dispatched, nachgelagert bestätigt, verifiziert, abgeschlossen.

Das Drittanbieter-Leg ist das unordentlichste. Jeder Processor stellt eine andere DSR-API zur Verfügung, mit unterschiedlicher Authentifizierung, Status-Codes und SLAs; manche erfordern noch immer ein Webformular oder E-Mail. Die realistische Engineering-Antwort ist ein Adapter pro Processor mit einer einheitlichen internen Schnittstelle, Integrationstests und Circuit-Breakern. Zehn bis fünfzehn Adapter sind typisch; Teams mit reichem Integrationsökosystem brauchen manchmal dreißig.

Eine Symfony-Messenger-basierte Implementierung verwendet eine Queue pro Processor mit Retry-Middleware, exponentiellem Backoff und einer Dead-Letter-Queue. Ein nächtlicher Reconciliation-Job versucht es entweder erneut mit frischen Credentials, eskaliert an einen Menschen oder protokolliert eine dokumentierte "unverhältnismäßiger Aufwand"-Ausnahme nach Artikel 19.

Für Teams, die ältere PHP-Codebases modernisieren, ist diese Orchestrierung oft der Auslöser für Legacy-Code-Optimierungsarbeit - die Lösch-Pipeline kann nicht auf einem Monolithen ohne Event-Bus und ohne klare Domain-Grenzen nachgerüstet werden, ohne zuerst den Datenfluss zu entwirren.

Löschung verifizieren: Das Audit-Artefakt, das die Schleife schließt

Das letzte Stück ist die Verifikation. Ein in der Pipeline als "abgeschlossen" markierter Antrag ist nichts wert, wenn das Team bei einer Anfrage keine Löschung nachweisen kann. Der richtige Ansatz ist, zum Abschlusszeitpunkt ein Löschzertifikat zu erstellen - ein strukturiertes Dokument, das die Antrags-ID, das Betroffenen-Pseudonym, den Zeitstempel in jedem Stadium, die Liste der abgefragten Systeme, die bestätigten Drittanbieter und alle Einträge im Ausnahmeregister aufzeichnet. Das Zertifikat wird kryptografisch signiert und in einem Append-only-Audit-Store aufbewahrt.

Was dies von Theater zu Beweis macht, ist ein automatisierter Sweep, der 24 Stunden nach Abschluss jedes System im Inventar erneut nach Datensätzen abfragt, die den Betroffenen-Identifier oder nicht maskierte PII aus dem Antrag enthalten. Jeder Treffer ist ein Befund: Er geht in eine Incident-Queue, das Zertifikat wird als provisorisch markiert, die Lücke wird geschlossen, und die Post-mortem-Analyse aktualisiert das Inventar.

Für Teams, die in regulierten Branchen verkaufen, ist das Löschzertifikat auch ein Verkaufsartefakt. Enterprise-Procurement fragt zunehmend danach, den Löschflow zu demonstrieren, nicht nur zu beschreiben.

Fazit

Das DSGVO-Recht auf Löschung ist kein Häkchen; es ist eine architektonische Eigenschaft eines SaaS. Teams, die es richtig machen, haben ein dokumentiertes PII-Inventar, ein Lösch-Ledger, das Backup-Restores überlebt, ein Pseudonymisierungsmuster, das ihren Audit-Trail nicht bricht, eine DSR-Pipeline mit Pro-Processor-Adaptern und einen automatisierten Verifizierungs-Sweep, der ein signiertes Zertifikat pro Antrag erstellt. Teams, die es falsch machen, erfüllen die Hauptpflicht in der primären Datenbank und tragen still Jahre residualer PII in ihrem Warehouse, ihrem Suchindex und ihren Support-Tools - bis eine Folge-E-Mail oder ein Beschaffungsfragebogen das Problem ans Licht bringt.

Wolf-Tech hilft Berliner und EU-SaaS-Teams dabei, Löschflows zu entwerfen, zu implementieren und zu validieren, die sowohl der Regulatoren-Prüfung als auch dem Enterprise-Procurement-Review standhalten. Kontaktiere uns unter hello@wolf-tech.io oder besuche wolf-tech.io für eine kostenlose Beratung.