Wenn die Datenkopie Leichen im Keller findet

Es gibt Anfragen, die harmlos aussehen und teuer werden. Eine davon ist ein Satz in einer Kunden-E-Mail: „Bitte stellen Sie mir eine Kopie aller Daten zur Verfügung, die Sie über mich gespeichert haben."

Für ein hochdigitalisiertes Unternehmen ist das kein Knopfdruck. Es ist ein Projekt. Und manchmal ist es ein Röntgenbild der eigenen IT — mit Befund.

Ich schildere hier einen Fall aus unserer Beratungspraxis. Er ist anonymisiert und in Details verändert, aber die Mechanik ist typisch. Und die Lehre daraus gilt für jedes Unternehmen mit gewachsener Systemlandschaft: Banken, Versicherer, Energieversorger, Handel, Plattformen, Mittelstand.

Der Fall: ein Auskunftsersuchen, ein Beispieldokument, ein Problem

Unsere Mandantin ist ein Kreditinstitut. Ein Kunde verlangt eine Datenkopie nach Art. 15 DSGVO. Bis hierhin: Alltag. Aufwendig, aber beherrschbar — Kernbanksystem, CRM, Archiv, Telefonie, Postkorb, Ticketsystem, Marketing-Tools. Zehn, fünfzehn, manchmal dreißig Quellen, aus denen etwas zusammenlaufen muss.

Im Zuge der Abstimmung schickt uns die Mandantin ein Beispiel, wie sie Drittdaten in den Dokumenten unkenntlich macht. Gute Praxis, völlig richtig gedacht. Nur: Aus dem Originaldokument, das dem geschwärzten Beispiel beilag, ergab sich etwas anderes.

Dort waren Gesprächsnotizen zu sehen, die 2015 und 2017 aus einem abgelösten Beratungs-Tool in die aktuelle Umgebung migriert worden waren. Also lange vor Geltung der DSGVO. Und die migrierten Einträge reichten inhaltlich bis 2009 zurück.

Sechzehn Jahre alte Gesprächsnotizen. Freitext. Subjektive Einschätzungen von Beratern. Familienverhältnisse, Gesundheitshinweise, Bonitätseinschätzungen, private Lebenslagen — alles, was in Beratungsnotizen landet, wenn niemand über Datenminimierung nachdenkt.

Diese Daten hätten längst gelöscht sein müssen. Sie waren es nicht. Und jetzt liegen sie in einem Auskunftsverfahren auf dem Tisch.

Das Dilemma in einem Satz

Wir können sie nicht einfach löschen, und wir können sie nicht einfach verschweigen.

Das ist der Punkt, an dem viele Verantwortliche instinktiv falsch reagieren. Der erste Reflex lautet: „Dann räumen wir das jetzt schnell auf, dann ist es weg, und dann beauskunften wir den sauberen Bestand."

Genau das ist der gefährlichste Weg.

Warum „schnell löschen" der Fehler ist

Das VG Düsseldorf hat mit Gerichtsbescheid vom 21. Januar 2026 (Az. 29 K 7470/24) einen Fall entschieden, in dem ein Unternehmen die Daten eines Beschwerdeführers löschte, nachdem dieser Auskunft verlangt hatte — ohne dass er die Löschung verlangt hätte. Die Aufsichtsbehörde verwarnte das Unternehmen, das Gericht bestätigte dieses Vorgehen.

Die entscheidenden Aussagen, in Klartext übersetzt:

• Löschen ist selbst eine Verarbeitung. Es braucht eine Rechtsgrundlage nach Art. 6 Abs. 1 DSGVO. „Wir wollten aufräumen" ist keine.
• Ab dem Eingang des Auskunftsersuchens ist die Weiterspeicherung erforderlich, weil die Auskunftspflicht erfüllt werden muss. Der Verarbeitungszweck entfällt frühestens, wenn die Auskunft vollständig und fristgerecht erteilt ist.
• Wer vorher löscht, verstößt gegen die DSGVO — und zwar unabhängig davon, ob die später erteilte Auskunft inhaltlich vollständig war.

Das Gericht formuliert sogar, es spreche viel dafür, dass die Daten so lange gespeichert bleiben müssen, bis die betroffene Person die Gelegenheit hatte, die Rechtmäßigkeit der Verarbeitung zu prüfen. Wie lange das im Einzelfall ist, hat es offengelassen.

Damit ist der Ausweg versperrt. Das Auskunftsersuchen friert den Bestand ein. Auch den Teil, der peinlich ist.

Und verschweigen geht auch nicht

Der Bundesgerichtshof legt den Auskunftsanspruch weit aus. Es gibt keine Reduktion auf „wichtige" oder „biografisch signifikante" Daten; auch interne Vermerke und Kommunikation sind erfasst (BGH, Urteil vom 15. Juni 2021, VI ZR 576/19). Auskunft und Datenkopie sind ein einheitlicher Anspruch; Art. 15 Abs. 3 DSGVO regelt nur die Modalitäten der Umsetzung (BGH, Urteil vom 5. März 2024, VI ZR 330/21).

Nirgends steht: „Daten, die eigentlich gelöscht sein müssten, sind von der Auskunft ausgenommen." Das Gegenteil ist der Sinn der Vorschrift. Der Anspruch existiert gerade, damit Betroffene eine rechtswidrige Verarbeitung erkennen können.

Was Sie dürfen — und was in unserem Fall richtig gemacht wurde — ist die Schwärzung von Informationen, die nicht die anfragende Person betreffen. Das VG Düsseldorf hat am 28. Januar 2026 (Az. 29 K 9469/23) ausdrücklich festgehalten: Da sich das Recht auf Datenkopie auf die Daten der betroffenen Person beschränkt, darf der Verantwortliche Daten ohne Bezug zu dieser Person im selben Dokument unkenntlich machen, bevor er die Kopie herausgibt. Das ist eine echte Erleichterung für den operativen Prozess — aber es rettet Sie nicht vor Altdatenbeständen.

Der eigentliche Fehler liegt nicht 2026, sondern 2015

Hier wird es für Geschäftsführung und CISO interessant. Der Auskunftsantrag hat kein Problem verursacht. Er hat eines sichtbar gemacht.

Das Problem entstand bei zwei Systemmigrationen. Und es entstand auf eine Weise, die ich in fast jedem Projekt wiederfinde:

1. Ein Altsystem wird abgelöst. Der Projektauftrag lautet „Datenverluste vermeiden".
2. Also wird alles übernommen. Vollständigkeit ist messbar, Datenminimierung nicht.
3. Die Herkunftsinformation geht verloren. Das Erstellungsdatum des Eintrags aus 2009 wird zum Migrationsdatum 2015 — oder verschwindet ganz.
4. Damit ist der Datensatz für jede Löschregel unsichtbar. Eine Frist „10 Jahre nach Vertragsende" greift nicht, wenn das System nicht weiß, wann etwas entstanden ist und zu welchem Vorgang es gehört.
5. Niemand merkt es, weil Löschen kein Prozess mit Fehlermeldung ist. Wenn Löschen nicht passiert, passiert einfach — nichts.

Das ist der Kern: Nicht gelöschte Daten erzeugen keinen Alarm. Ein ausgefallener Server erzeugt einen Alarm. Ein nicht gelöschter Datensatz liegt zehn Jahre still da und wartet auf ein Auskunftsersuchen, eine Beschwerde, eine Prüfung oder einen Datenabfluss.

Warum das Löschkonzept im Ordner nicht hilft

Unsere Mandantin hatte ein Löschkonzept. Ordentlich gemacht, Datenkategorien, Fristen, Rechtsgrundlagen, Verantwortlichkeiten. Es hätte jede Dokumentenprüfung überstanden.

Nur war es eine Beschreibung dessen, was passieren soll. Nicht ein Mechanismus, der es passieren lässt.

Das ist der verbreitetste Compliance-Irrtum, den ich kenne. Ein Löschkonzept setzt die Löschpflichten aus Art. 17 DSGVO, den Grundsatz der Speicherbegrenzung aus Art. 5 Abs. 1 lit. e DSGVO und die Rechenschaftspflicht aus Art. 5 Abs. 2 DSGVO um. Die Rechenschaftspflicht verlangt einen Nachweis der Einhaltung — nicht den Nachweis einer Absicht.

Die praktische Frage lautet deshalb nicht: „Haben wir ein Löschkonzept?"

Löschkonzept auf Systemebene: die Umsetzungsebene, die meistens fehlt

Zwischen Papier und Wirklichkeit liegen sieben Bausteine. Das ist die Checkliste, mit der ich in Mandaten arbeite.

1. Löschklassen statt Einzelfristen

Nicht jede Datenkategorie bekommt eine eigene Frist, sondern es werden wenige Löschklassen definiert — etwa „3 Jahre nach Vorgangsende", „10 Jahre nach Geschäftsjahresende", „unverzüglich nach Zweckerreichung". Die ISO/IEC 27555 liefert dafür ein tragfähiges Rahmenwerk. Jede Datenkategorie wird einer Klasse zugeordnet; sonst wird das Konzept technisch nicht abbildbar.

2. Startpunkt-Logik ist Pflichtfeld

Eine Löschregel braucht ein Ereignis, an dem die Frist beginnt: Vertragsende, letzter Kontakt, Ablehnung, Kündigung. Jedes System muss dieses Ereignis technisch führen. Wenn es das nicht kann, ist die Frist nicht implementierbar — und das gehört als Feststellung ins Konzept, nicht ins Nirwana.

3. Löschfähigkeit als Anforderung in Beschaffung und Migration

Vor jedem Tool-Kauf und jeder Migration: Kann das System zeitgesteuert löschen? Auf Datensatzebene? Nachvollziehbar? Gehen Erstellungsdaten und Vorgangsbezug bei der Übernahme verloren? Das ist eine Frage an die Fachabteilung und den Einkauf, nicht an den Datenschutzbeauftragten am Ende des Projekts. Löschfähigkeit ist ein Abnahmekriterium.

4. Migration bedeutet Selektion, nicht Übernahme

Die Regel für jedes Altsystem: Es wird nur migriert, was aktuell und rechtlich haltbar erforderlich ist. Alles andere wird vor der Migration gelöscht — nicht mitgeschleppt, nicht „vorsichtshalber" in ein Archiv gelegt. Das Projektziel „keine Datenverluste" muss ersetzt werden durch „keine unzulässigen Datenübernahmen".

5. Freitextfelder sind das Hochrisiko-Asset

Gesprächsnotizen, Beratungsvermerke, Kommentarfelder, Ticketverläufe. Dort steht das, was keine Löschregel erwischt und was in der Datenkopie am meisten weh tut — auch weil dort regelmäßig Gesundheits- und andere Daten nach Art. 9 DSGVO landen. Hier brauchen Sie Vorgaben, Schulung und harte Fristen.

6. Löschen muss messbar und protokolliert sein

Jeder Löschlauf produziert einen Report: welches System, welche Klasse, wie viele Datensätze, Fehlerquote, Abbrüche. Kein Report bedeutet keinen Nachweis. Nehmen Sie diese Kennzahl ins Monatsreporting an die Geschäftsführung auf — so, wie Sie Patch-Level oder Verfügbarkeit reporten.

7. Backups, Archive, Testumgebungen und Auftragsverarbeiter mitdenken

Der Anspruch richtet sich gegen den Verantwortlichen, nicht gegen ein einzelnes System. Ein Löschkonzept, das an der Produktionsdatenbank endet, ist unvollständig. Für Backups brauchen Sie eine dokumentierte Regel — etwa Löschung beim nächsten Restore-Vorgang und begrenzte Aufbewahrungszyklen. Sie muss vorhanden und begründet sein.

Wenn Sie jetzt gerade Altdaten gefunden haben: die richtige Reihenfolge

Der Fund von Daten, die längst gelöscht sein müssten, ist unangenehm, aber beherrschbar — wenn Sie nicht improvisieren.

1. Bestand einfrieren, nicht löschen. Sobald ein Auskunftsersuchen vorliegt, gilt für die betroffenen Daten ein Löschstopp.
2. Vollständig beauskunften. Auch die Altdaten. Mit Verarbeitungszweck, Herkunft, Kategorien, Empfängern und Speicherdauer.
3. Drittdaten schwärzen. Das ist zulässig und ändert nichts an der Vollständigkeit der Auskunft.
4. Den Befund intern dokumentieren. Welches System, welche Migration, welcher Zeitraum, welche Kategorien, wie viele Betroffene voraussichtlich. Diese Dokumentation ist Ihr Aktivposten, nicht Ihr Risiko: Sie zeigt, dass Sie den Mangel erkannt und gesteuert haben.
5. Prüfen, ob eine Meldepflicht besteht — und ob die Konstellation gegenüber der Aufsicht proaktiv adressiert werden sollte. Das ist eine Einzelfallentscheidung, aber sie sollte bewusst getroffen und protokolliert werden.
6. Nach Erfüllung der Auskunft die Löschung durchführen — für den gesamten Bestand, nicht nur für die eine anfragende Person. Wer nur den Anfragenden bereinigt, hat die Rechtswidrigkeit bestätigt und den Rest behalten.
7. Die Ursache abstellen. Also die sieben Bausteine der Systemebene. Sonst wiederholt sich der Fall beim nächsten Antrag.

Vier Sätze, die ich nicht mehr hören möchte

• „Wir haben ein Löschkonzept." Entscheidend ist der Nachweis durchgeführter Löschungen, nicht das Dokument.
• „Wir löschen das schnell, dann ist das Thema durch." Löschen nach Eingang des Auskunftsersuchens ist selbst ein Verstoß.
• „Interne Notizen sind nicht auskunftspflichtig." Auch interne Vermerke und Kommunikation sind erfasst.
• „Die Daten sind ja anonymisiert." Anonym ist nur, was nicht mit vertretbarem Aufwand re-identifizierbar ist — die Hürde liegt hoch.

Fazit

Der Auskunftsanspruch ist zum wirksamsten Audit-Instrument des Datenschutzrechts geworden. Er kostet die betroffene Person eine E-Mail und Ihr Unternehmen einen vollständigen Blick in die eigene Datenhaltung — inklusive der Teile, die man selbst nicht mehr kannte.

Zwei Fragen für Ihre nächste Managementrunde:

• Wie viele Löschläufe haben unsere Systeme in den letzten zwölf Monaten ausgeführt — und wo liegt der Nachweis?
• Welche unserer Systeme enthalten Daten aus abgelösten Vorgängersystemen, bei denen wir das ursprüngliche Erstellungsdatum nicht mehr kennen?

Wenn die Antwort auf die zweite Frage „das wissen wir nicht" lautet, haben Sie Ihr nächstes Projekt gefunden. Am besten, bevor es ein Kunde für Sie startet.