Wenn personenbezogene Daten über verschiedene Systeme, Anwendungen und Dienste hinweg verarbeitet werden, wird eine scheinbar einfache Aufgabe zur komplexen Herausforderung: die vollständige, nachvollziehbare und regelkonforme Löschung dieser Daten. Besonders in integrierten IT-Landschaften mit ERP, DMS, OT-Systemen, Cloud-Diensten und Low Code-Anwendungen muss Löschung technisch orchestriert, dokumentiert und durchsetzbar sein.
Warum ist Löschung in verteilten Systemen so komplex?
In klassischen Monolithen lässt sich ein Datensatz oft zentral löschen. In verteilten Systemarchitekturen dagegen:
- liegen Datenkopien in mehreren Applikationen
- erfolgen Datenübertragungen über REST, pub/sub, Time-Trigger oder Low Code-Prozesse
- existieren historische Versionen in DMS, Logdateien oder Archivsystemen
- kann die Löschung rechtlich erforderlich, technisch aber nicht trivial sein
Das Problem: Ohne klar strukturierte Löscharchitektur bleiben Daten an unerwarteten Stellen erhalten – ein Compliance-Risiko.
Was sind technische Anforderungen an eine durchsetzbare Löschung?
1. Identifizierbarkeit der Daten
– Einheitliche Schlüssel (z. B. User-ID, Referenznummern) müssen in allen Systemen verfügbar sein.
– Woher stammen die Daten? Wohin wurden sie verteilt? Welche Kopien existieren?
3. Lösch-Trigger
– Manuell über eine Benutzeroberfläche, automatisch via REST-API oder zeitgesteuert (Time-Triggering)
4. Verteilte Steuerung
– Eine zentrale Komponente koordiniert Löschaufträge an alle betroffenen Zielsysteme.
5. Bestätigungsmechanismus
– Jedes System meldet den Löschstatus zurück (erfolgreich, nicht gefunden, Fehler).
6. Protokollierung
– Jeder Schritt wird auditfähig dokumentiert (z. B. im Monitoring oder Log).
Welche Strategien zur Umsetzung?
|
Methode
|
Nutzen
|
|
Lösch-API in jedem System
|
Einheitlicher Zugriff zur Entfernung personenbezogener Daten
|
|
Zentrale Lösch-Engine
|
Steuerung aller Löschprozesse über ein zentrales Dashboard
|
|
Mapping-Tabellen mit Löschregeln
|
Definieren, welche Felder wohin übertragen und wann gelöscht werden
|
|
Anonymisierung statt Löschung
|
Bei technischen oder regulatorischen Einschränkungen
|
|
Low Code-Workflows
|
Automatisierte Steuerung durch Fachbereiche
|
|
Time-Triggering
|
Regelmäßige, geplante Löschdurchläufe
|
Gibt es technische Herausforderungen und Lösungen?
- Fehlende Löschschnittstellen bei Legacy-Systemen
→ Einsatz von Adaptern oder Aufruf über Datenbank-Skripte (mit Vorsicht)
- Verknüpfte Daten mit anderen Entitäten (z. B. Aufträge, Rechnungen)
→ Trennung von Pflichtaufbewahrung und personenbezogenen Elementen
- Unvollständige Rückmeldungen aus Zielsystemen
→ Retry-Logik, Eskalation an Systemverantwortliche
- Intransparente Datenverarbeitung (z. B. Shadow-Copies)
→ Dokumentationspflicht, regelmäßige Audits
Welche Best Practices haben sich bewährt?
- Aufbau einer zentralen Lösch-Architektur mit orchestrierten Abläufen
- Verwendung von standardisierten Feldkennzeichnungen für personenbezogene Daten
- Monitoring mit Fehlermeldungen, Löschhistorie und Statusübersicht
- Einbindung der Datenschutzverantwortlichen in Test und Review
- Automatisierung kombinieren mit Freigabemechanismen (Four-Eyes-Prinzip)
- Abbildung aller Löschprozesse in der Data Flow-Dokumentation und DSFA
Fazit
Verteilte IT-Systeme brauchen klare Regeln, strukturierte Schnittstellen und automatisierbare Prozesse, um Löschanforderungen zuverlässig umzusetzen. Technische Lösungen müssen mit organisatorischen Maßnahmen zusammenspielen – nur dann lassen sich gesetzliche Anforderungen und Vertrauen in Datenverarbeitung langfristig sicherstellen.
Können Sie heute garantieren, dass personenbezogene Daten vollständig gelöscht werden – auch in komplexen Prozessketten?
Lassen Sie uns gemeinsam prüfen, wie sich Löschprozesse in Ihrer Architektur technisch zuverlässig, transparent und revisionssicher gestalten lassen.
