Löschkonzept nach DSGVO und ISO/IEC 27001: Datenschutz und Informationssicherheit sinnvoll verbinden

Personenbezogene Daten dürfen nicht unbegrenzt gespeichert werden. Gleichzeitig müssen Unternehmen sicherstellen, dass Informationen nach Ablauf ihrer zulässigen oder erforderlichen Aufbewahrungsdauer kontrolliert, nachvollziehbar und technisch angemessen entfernt werden.
Ein belastbares Löschkonzept ist deshalb weit mehr als eine Datenschutzrichtlinie. Es verbindet rechtliche Aufbewahrungs- und Löschanforderungen mit technischen Verfahren, Verantwortlichkeiten und Kontrollmechanismen innerhalb der IT.
Besonders sinnvoll ist eine abgestimmte Zusammenarbeit zwischen Datenschutz, Informationssicherheit, IT und den jeweiligen Fach- und Systemverantwortlichen. Die DSGVO und ISO/IEC 27001:2022 verfolgen dabei unterschiedliche Perspektiven, lassen sich in der betrieblichen Praxis jedoch gut miteinander verzahnen.

Der Inhalt im Überblick

• Warum Löschung Datenschutz und Informationssicherheit gleichermaßen betrifft
• Welche Anforderungen sich aus der DSGVO ergeben
• Welche Bedeutung ISO/IEC 27001 und ISO/IEC 27002 haben
• Wie DSB, ISB, IT und Fachbereiche zusammenarbeiten sollten
• Welche Speicherorte bei einem Löschkonzept häufig vergessen werden
• Wie Backups, Logs und Cloud-Systeme berücksichtigt werden können
• Wie sich Löschprozesse nachvollziehbar dokumentieren lassen
• Warum ein Löschkonzept dauerhaft gepflegt werden muss

Warum Unternehmen überhaupt ein Löschkonzept benötigen
Die datenschutzrechtliche Grundlage ergibt sich zunächst aus dem Grundsatz der Speicherbegrenzung.
Nach Art. 5 Abs. 1 Buchst. e DSGVO dürfen personenbezogene Daten grundsätzlich nur so lange in einer Form gespeichert werden, die eine Identifizierung betroffener Personen ermöglicht, wie dies für die jeweiligen Verarbeitungszwecke erforderlich ist.
Hinzu kommt Art. 17 DSGVO. Danach besteht unter den dort genannten Voraussetzungen ein Recht auf Löschung personenbezogener Daten. Ein Löschgrund kann beispielsweise vorliegen, wenn Daten für die ursprünglichen Zwecke nicht mehr erforderlich sind, eine maßgebliche Einwilligung wirksam widerrufen wurde, ein erfolgreicher Widerspruch erfolgt oder eine Verarbeitung rechtswidrig ist.
Die Löschpflicht ist allerdings nicht absolut. Art. 17 Abs. 3 DSGVO enthält Ausnahmen, unter anderem für bestimmte gesetzliche Verpflichtungen sowie für die Geltendmachung, Ausübung oder Verteidigung von Rechtsansprüchen.
Ein funktionierendes Löschkonzept muss daher nicht lediglich beantworten, wann Daten gelöscht werden, sondern ebenso, warum sie gegebenenfalls weiterhin gespeichert werden dürfen oder müssen.
Die Rechenschaftspflicht nach Art. 5 Abs. 2 DSGVO verlangt zudem, dass Verantwortliche die Einhaltung der Datenschutzgrundsätze nachweisen können.

Welche Rolle spielt ISO/IEC 27001?
ISO/IEC 27001:2022 verfolgt einen anderen Ausgangspunkt. Die Norm definiert Anforderungen an ein Informationssicherheitsmanagementsystem und verlangt eine risikoorientierte Steuerung der Informationssicherheit. ISO beschreibt den Standard als Rahmen für die Einrichtung, Umsetzung, Aufrechterhaltung und fortlaufende Verbesserung eines ISMS.
Für die Löschung von Informationen ist insbesondere Control A.8.10 „Information deletion“ relevant.
Dabei sollte eine wichtige Differenzierung berücksichtigt werden: Die Controls des Annex A werden innerhalb eines ISO/IEC-27001-ISMS nicht schematisch und losgelöst vom Risikomanagement umgesetzt. Ihre Anwendbarkeit ist im Rahmen der Risikobehandlung und der Statement of Applicability zu beurteilen.
ISO/IEC 27002:2022 ergänzt ISO/IEC 27001 um Umsetzungshinweise und bewährte Vorgehensweisen für Informationssicherheitsmaßnahmen. ISO stellt ausdrücklich klar, dass ISO/IEC 27002 selbst keine Zertifizierungsnorm ist, sondern Empfehlungen für Informationssicherheitskontrollen enthält.
Damit ergibt sich eine sinnvolle Arbeitsteilung:

Die DSGVO beantwortet insbesondere, unter welchen rechtlichen Voraussetzungen personenbezogene Daten gespeichert oder gelöscht werden müssen. Das ISMS organisiert, wie solche Anforderungen kontrolliert, technisch umgesetzt, überprüft und dauerhaft betrieben werden können.
Eine vollständige Gleichsetzung nach dem Muster „DSGVO = Was, ISO = Wie“ wäre allerdings zu pauschal. Auch die DSGVO enthält technische und organisatorische Anforderungen, während ein ISMS wiederum gesetzliche und vertragliche Vorgaben berücksichtigen muss.

Wer ist für das Löschkonzept verantwortlich?
In der Praxis werden die Rollen von Datenschutzbeauftragtem und Informationssicherheitsbeauftragtem häufig zu stark mit der operativen Durchführung vermischt.
Für die Einhaltung der DSGVO bleibt der Verantwortliche im Sinne von Art. 4 Nr. 7 DSGVO verantwortlich.
Der Datenschutzbeauftragte übernimmt nach Art. 39 DSGVO insbesondere Beratungs-, Informations- und Überwachungsaufgaben. Er sollte deshalb beispielsweise bei der Definition datenschutzrechtlicher Anforderungen, Löschfristen, Betroffenenrechte und Kontrollmechanismen beteiligt werden.
Er sollte jedoch nicht ohne Weiteres selbst zum operativ Verantwortlichen für sämtliche Löschvorgänge gemacht werden. Dies kann nicht nur organisatorisch unzweckmäßig sein, sondern muss auch mit seiner gesetzlich vorgesehenen unabhängigen Kontrollfunktion vereinbar bleiben.
Der Informationssicherheitsbeauftragte betrachtet dagegen insbesondere die technische und organisatorische Einbettung in das ISMS, beispielsweise:

• sichere Löschverfahren,
• Systemabhängigkeiten,
• Berechtigungen,
• technische Automatisierung,
• Nachweis- und Kontrollmechanismen,
• Risiken durch verbleibende Kopien,
• Cloud- und Dienstleisterstrukturen sowie
• die Einbindung in bestehende IT-Prozesse.

Die operative Umsetzung sollte regelmäßig bei denjenigen Stellen liegen, die tatsächlich über Anwendungen, Systeme und Geschäftsprozesse verfügen: beispielsweise System Owner, Application Owner, IT-Betrieb und verantwortliche Fachbereiche.

Der erste Schritt: Daten und Systeme vollständig erfassen
Ein Löschkonzept kann nur funktionieren, wenn bekannt ist, wo die betreffenden Informationen gespeichert werden.
Das Verzeichnis von Verarbeitungstätigkeiten liefert hierfür im Datenschutz einen wichtigen Ausgangspunkt. Für die technische Umsetzung reicht es allein jedoch häufig nicht aus.
Zusätzlich sollte eine systembezogene Betrachtung erfolgen.
Typische Speicherorte sind beispielsweise:

• produktive Datenbanken,
• Fachanwendungen,
• CRM- und ERP-Systeme,
• Dokumentenmanagementsysteme,
• Netzlaufwerke,
• lokale Benutzerverzeichnisse,
• E-Mail-Systeme,
• Kollaborationsplattformen,
• Cloud-Speicher,
• mobile Geräte,
• Protokoll- und Logsysteme,
• Exportdateien,
• temporäre Dateien,
• Test- und Entwicklungsumgebungen,
• Archive,
• Sicherungsmedien und Backups sowie
• Datenbestände stillgelegter Systeme.

Gerade Kopien, Exporte und Schattenbestände werden in der Praxis leicht übersehen.
Ein gutes Löschkonzept betrachtet deshalb nicht nur eine Verarbeitung abstrakt, sondern verbindet Datenkategorien, Zweck, Rechtsgrundlage, Aufbewahrungsanforderungen und konkrete technische Speicherorte miteinander.

Nicht jede Aufbewahrungsfrist ist eine Löschfrist
Ein häufiges Problem besteht darin, rechtliche Aufbewahrungsfristen und tatsächliche Löschzeitpunkte gleichzusetzen.
Die Aussage „zehn Jahre Aufbewahrung“ beantwortet beispielsweise noch nicht vollständig, wann ein Datensatz konkret gelöscht werden muss.
Ein Löschkonzept sollte daher je Datenkategorie zumindest bestimmen:

• welchen Zweck die Speicherung verfolgt,
• welche Rechtsgrundlage besteht,
• ob gesetzliche oder vertragliche Aufbewahrungspflichten bestehen,
• wann der operative Zweck endet,
• ab welchem Zeitpunkt eine Sperrung oder Einschränkung erforderlich sein kann,
• wann die endgültige Löschung erfolgen soll und
• welches Ereignis die jeweilige Frist auslöst.

Gerade der Fristbeginn ist praktisch entscheidend.
Eine Löschregel „nach sechs Jahren löschen“ ist unzureichend, wenn nicht feststeht, ob diese Frist beispielsweise mit Vertragsschluss, Vertragsende, Rechnungsstellung, Jahresende oder Abschluss eines Vorgangs beginnt.

Backups benötigen eine eigene Löschlogik
Besondere Aufmerksamkeit verdienen Sicherungssysteme.
Bei produktiven Datenbanken kann ein einzelner Datensatz häufig gezielt entfernt werden. Bei technisch geschlossenen Backup-Sätzen ist dies dagegen oftmals nur eingeschränkt oder nur mit unverhältnismäßigem Aufwand möglich.
Daraus darf jedoch nicht gefolgert werden, dass Backups von Löschkonzepten ausgenommen werden könnten.
Stattdessen sollte nachvollziehbar festgelegt werden:

• welche Backup-Zyklen bestehen,
• wie lange Sicherungen aufbewahrt werden,
• wann sie automatisiert überschrieben oder vernichtet werden,
• wer Zugriff darauf hat,
• für welche Zwecke sie wiederhergestellt werden dürfen und
• wie verhindert wird, dass zuvor gelöschte Daten nach einem Restore dauerhaft wieder produktiv verarbeitet werden.

Hier empfiehlt sich beispielsweise ein Verfahren, bei dem Löschinformationen nach einer Wiederherstellung erneut auf den zurückgespielten Datenbestand angewendet werden.
Damit wird nicht verlangt, jeden einzelnen Datensatz aus jedem historischen Backup sofort technisch herauszulösen. Entscheidend ist vielmehr ein nachvollziehbares Gesamtkonzept, das verhindert, dass eigentlich gelöschte Daten durch Sicherungssysteme dauerhaft weiterverarbeitet oder unbegrenzt gespeichert werden.

Testsysteme und Echtdaten: ein unterschätztes Risiko
Auch Test-, Entwicklungs- und Qualitätssicherungssysteme sollten ausdrücklich in das Löschkonzept aufgenommen werden.
Werden Produktivdaten in eine Testumgebung kopiert, entsteht regelmäßig ein zusätzlicher Datenbestand.
Dieser kann sogar problematischer sein als das Produktionssystem, wenn beispielsweise:

• Berechtigungen großzügiger vergeben sind,
• Testdatenbanken seltener gepflegt werden,
• Löschautomatismen des Produktionssystems fehlen oder
• alte Kopien über Jahre bestehen bleiben.

Wo möglich, sollten deshalb synthetische, anonymisierte oder anderweitig datenschutzgerecht aufbereitete Testdaten verwendet werden.
Sind Echtdaten erforderlich und rechtlich zulässig, müssen auch diese Kopien Bestandteil der definierten Löschprozesse sein.

Logs sind keine Ausnahme von der Speicherbegrenzung
Protokolldaten werden häufig mit Informationssicherheit begründet. Tatsächlich können Logs für Angriffserkennung, Fehleranalyse, Nachweisführung und Incident Response erforderlich sein.
Das rechtfertigt jedoch keine unbegrenzte Speicherung.
Auch Protokolldaten können personenbezogene Daten enthalten, beispielsweise:

• Benutzerkennungen,
• IP-Adressen,
• Gerätekennungen,
• Zeitstempel,
• Zugriffsaktivitäten oder
• Kommunikationsinformationen.

Deshalb sollten auch Logdaten konkrete Aufbewahrungsregeln erhalten.
Dabei ist zwischen Sicherheitsanforderungen und Datenschutz abzuwägen. Eine sinnvolle Lösung kann darin bestehen, unterschiedliche Logtypen mit unterschiedlichen Aufbewahrungsfristen zu versehen, statt sämtliche Protokolle pauschal gleich lange vorzuhalten.

Cloud-Dienste und Auftragsverarbeiter einbeziehen
Ein Löschkonzept endet nicht an der eigenen Firewall.
Werden personenbezogene Daten durch Auftragsverarbeiter oder Cloud-Anbieter verarbeitet, muss geprüft werden, wie Löschanforderungen technisch und organisatorisch umgesetzt werden können.
Relevant sind unter anderem:

• Löschfunktionen der Anwendung,
• Datenreplikationen,
• Backup-Aufbewahrung,
• Mandantentrennung,
• Unterauftragsverarbeiter,
• Exportmöglichkeiten,
• Vertragsbeendigung,
• Rückgabe und Löschung von Daten sowie
• vorhandene Löschbestätigungen.

Die bloße Aussage eines Dienstleisters, Daten würden „gelöscht“, reicht für eine belastbare interne Prozessbeschreibung häufig nicht aus.
Das Unternehmen sollte verstehen, was unter Löschung technisch tatsächlich verstanden wird und innerhalb welcher Zeiträume Daten aus den verschiedenen Systemebenen verschwinden.

Kryptographisches Löschen: sinnvoll, aber nicht automatisch ausreichend
Bei verschlüsselten Speichersystemen kann die kontrollierte Vernichtung des verwendeten Schlüsselmaterials ein technisch sehr wirksamer Mechanismus sein.
Dadurch können die verbleibenden verschlüsselten Daten praktisch unlesbar werden.
Ein solches Verfahren sollte jedoch nicht lediglich deshalb eingesetzt werden, weil ein Datenträger verschlüsselt ist. Das Löschkonzept sollte vielmehr festlegen,

• für welche Systeme kryptographisches Löschen zulässig ist,
• welche Schlüssel vernichtet werden,
• ob Kopien dieser Schlüssel existieren,
• wie die Vernichtung nachgewiesen wird und
• ob eine Wiederherstellung des Schlüssels tatsächlich ausgeschlossen ist.

Nur dann entsteht aus Verschlüsselung ein definierter Löschmechanismus.

Wie kann die Durchführung nachgewiesen werden?
Sowohl ein ISMS als auch die Rechenschaftspflicht der DSGVO machen nachvollziehbare Prozesse erforderlich.
Dabei sollte jedoch vermieden werden, eine neue Schatten-Datenbank über sämtliche jemals gelöschten personenbezogenen Daten aufzubauen.
Ein guter Löschungsnachweis dokumentiert deshalb möglichst den Prozess und nicht den gelöschten Inhalt.
Geeignet können beispielsweise sein:

• dokumentierte automatisierte Löschläufe,
• Systemberichte über erfolgreiche Jobs,
• Ticket- oder Workflow-Nachweise,
• Zeitpunkt und Ergebnis eines Löschprozesses,
• betroffene Anwendung oder Datenkategorie,
• verantwortliche Organisationseinheit,
• Fehlermeldungen und Nachbearbeitung,
• Stichprobenkontrollen,
• interne Kontrollen und ISMS-Audits sowie
• versionierte Löschregeln und Richtlinien.

Für personenbezogene Einzelanfragen kann darüber hinaus eine fallbezogene Dokumentation erforderlich sein.
Entscheidend ist die Verhältnismäßigkeit: Ein Löschungsnachweis soll die Umsetzung belegen und nicht seinerseits unnötig neue personenbezogene Daten dauerhaft speichern.

Automatisierung ist meist besser als manuelle Löschung
Je größer ein Unternehmen und je vielfältiger seine Systemlandschaft ist, desto schwieriger wird eine ausschließlich manuelle Löschung.
Daher sollten Löschregeln möglichst bereits technisch in Anwendungen integriert werden.
Beispielsweise kann ein System anhand definierter Kriterien feststellen:
1. Der Geschäftsprozess ist abgeschlossen.
2. Eine festgelegte Aufbewahrungsfrist beginnt.
3. Die Frist ist abgelaufen.
4. Es besteht kein Sperrgrund.
5. Der Datensatz wird einem Löschlauf zugeordnet.
6. Der erfolgreiche Lauf wird technisch dokumentiert.
Eine solche Automatisierung reduziert nicht nur den manuellen Aufwand, sondern auch das Risiko uneinheitlicher Entscheidungen.

Löschsperren müssen ebenfalls geregelt sein
Zu einem vollständigen Löschkonzept gehört auch die Frage, wann eine vorgesehene Löschung nicht durchgeführt werden darf.
Denkbare Gründe sind beispielsweise:

• gesetzliche Aufbewahrungspflichten,
• laufende Rechtsstreitigkeiten,
• behördliche Verfahren,
• interne Untersuchungen oder
• andere rechtlich zulässige Aufbewahrungsgründe.

Solche Fälle sollten nicht durch informelle Zurufe gelöst werden.
Sinnvoll ist ein definierter „Legal Hold“- oder Sperrprozess mit:

• dokumentiertem Grund,
• verantwortlicher Freigabe,
• betroffenem Datenbestand,
• Beginn der Sperre,
• regelmäßiger Überprüfung und
• definiertem Ende.

Damit wird verhindert, dass aus einer ursprünglich gerechtfertigten Aufbewahrung eine unbegrenzte Speicherung wird.

Datenschutz und Informationssicherheit gemeinsam organisieren
Ein belastbares Löschkonzept lässt sich daher nicht allein durch eine Löschfristentabelle herstellen.
Es benötigt mehrere Ebenen:
Datenschutzrechtliche Ebene:
Welche personenbezogenen Daten dürfen wie lange und aus welchem Grund verarbeitet werden?
Informationssicherheits-Ebene:
Welche technischen und organisatorischen Verfahren gewährleisten eine kontrollierte und sichere Löschung?
IT-Ebene:
Wo befinden sich die Daten tatsächlich und wie können sie technisch entfernt werden?
Fachliche Ebene:
Wann endet der jeweilige Geschäftsprozess und welche Aufbewahrungsanforderungen bestehen?
Governance-Ebene:
Wer entscheidet, wer führt aus und wer kontrolliert?
Erst das Zusammenspiel dieser Ebenen führt zu einem praktisch nutzbaren Löschmanagement.

Das Löschkonzept gehört in den Regelbetrieb
Ein Löschkonzept ist kein Dokument, das einmal erstellt und anschließend abgelegt werden kann.
Systemlandschaften verändern sich laufend. Neue Cloud-Dienste werden eingeführt, Anwendungen ersetzt, Datenbanken migriert und neue gesetzliche Anforderungen kommen hinzu.
Deshalb sollte das Löschkonzept regelmäßig überprüft und insbesondere bei wesentlichen Änderungen aktualisiert werden.
Typische Anlässe sind:

• Einführung neuer Software,
• Änderungen von Geschäftsprozessen,
• Wechsel eines Cloud-Anbieters,
• neue gesetzliche Aufbewahrungspflichten,
• Änderungen bei Datenkategorien,
• Übernahmen oder Migrationen,
• Änderungen von Backup-Konzepten und
• Feststellungen aus Datenschutz- oder ISMS-Audits.

Damit wird das Löschkonzept Bestandteil eines kontinuierlichen Managementprozesses.

Fazit: Ein Löschkonzept ist mehr als eine Fristentabelle

Ein wirksames Löschkonzept verbindet Datenschutz, Informationssicherheit und IT-Betrieb.
Die DSGVO gibt insbesondere den rechtlichen Rahmen für Speicherbegrenzung und Löschung personenbezogener Daten vor. ISO/IEC 27001:2022 integriert die sichere Informationsverarbeitung in ein risikobasiertes Managementsystem; Control A.8.10 adressiert dabei die Löschung von Informationen. ISO/IEC 27002:2022 bietet ergänzende Umsetzungshinweise für Informationssicherheitskontrollen.
Entscheidend ist jedoch nicht allein die Dokumentation.
Ein Löschkonzept funktioniert erst dann, wenn für alle relevanten Datenbestände klar geregelt ist:

Was muss gelöscht werden? Wann muss gelöscht werden? Was darf noch aufbewahrt werden? Wer entscheidet darüber? Welches technische Verfahren wird eingesetzt? Und wie lässt sich die ordnungsgemäße Durchführung angemessen nachweisen?
Unternehmen, die diese Fragen systematisch beantworten und Löschprozesse möglichst in ihre IT-, Datenschutz- und ISMS-Prozesse integrieren, reduzieren nicht nur Datenschutzrisiken. Sie verringern zugleich unnötige Datenbestände, verbessern die Beherrschbarkeit ihrer IT-Systeme und schaffen eine belastbare Grundlage für Datenschutzprüfungen und ISO/IEC-27001-Audits.