Löschkonzept DSGVO: Löschfristen, Backups & Betroffenenrechte rechtssicher umsetzen

Viele Unternehmen starten beim Datenschutz mit den „sichtbaren“ Themen: Datenschutzerklärung, Auftragsverarbeitungsverträge, vielleicht noch ein Verzeichnis von Verarbeitungstätigkeiten. Die Daten selbst wachsen derweil weiter. Neue Tools kommen hinzu, Abteilungen speichern „für alle Fälle“, E-Mail-Postfächer werden zu Archiven und aus einer überschaubaren IT-Landschaft wird ein Geflecht aus Fachanwendungen, Cloud-Diensten, Collaboration-Tools und Alt-Systemen. In dieser Praxislage passiert etwas Typisches: Irgendwann weiß niemand mehr zuverlässig, welche Daten wo liegen, wer sie wirklich braucht und wann sie eigentlich weg müssten. Genau hier setzt ein Löschkonzept an.

Ein Löschkonzept ist mehr als der Gedanke „Wir löschen halt irgendwann“. Es ist die Übersetzung der DSGVO-Anforderung, personenbezogene Daten nicht länger als erforderlich zu speichern, in eine funktionierende Routine. Ohne klare Regeln und Prozesse entstehen häufig Risiken, die sich vermeiden lassen. Dazu zählen etwa unnötig große Datenbestände, die bei Sicherheitsvorfällen oder Fehlversand gleich doppelt schaden, weil mehr betroffen ist als nötig. Dazu gehört auch die unangenehme Situation, in der Betroffenenanfragen zur Löschung eingehen, Sie aber erst mühsam recherchieren müssen, ob und wo die Daten überall gespeichert sind. Und nicht zuletzt steigt mit jeder Datenkopie in Export-Dateien, Mail-Threads oder Projektordnern das Risiko, dass interne Abläufe unkontrollierbar werden.

Ein belastbares Löschkonzept bringt Ordnung, ohne dass Sie jeden Tag „Datenschutz spielen“ müssen. Es sorgt dafür, dass Speicherdauern nicht aus dem Bauch heraus entschieden werden, sondern an Zweck, Rechtsgrundlage und tatsächlicher Erforderlichkeit ausgerichtet sind. Es schafft klare Verantwortlichkeiten, damit Löschung nicht „irgendwo zwischen IT und Fachbereich“ hängen bleibt. Und es macht Ergebnisse überprüfbar, damit Sie intern nachvollziehen können, ob Löschregeln in den Systemen tatsächlich greifen.

Was Sie nach der Lektüre konkret mitnehmen sollen: Sie werden verstehen, welche Bausteine ein praxistaugliches Löschkonzept typischerweise braucht, wie Löschfristen sinnvoll hergeleitet werden und welche Datenorte erfahrungsgemäß gerne übersehen werden. Sie erhalten außerdem eine klare Vorstellung davon, wie Sie Löschung, Einschränkung der Verarbeitung und Anonymisierung voneinander abgrenzen und wie Sie daraus Prozesse ableiten, die im Alltag funktionieren.

Übersicht:

Begriffsklärung: Was ein Löschkonzept in der DSGVO-Praxis bedeutet
Rechtlicher Rahmen: Wo die DSGVO das Löschkonzept indirekt und direkt verlangt
Der Kern in der Praxis: Wie Sie Löschfristen rechtssicher herleiten
Datenlandkarte als Voraussetzung: Welche Daten wo liegen
Bausteine eines belastbaren Löschkonzepts
Prozessdesign: Von der Regel zur verlässlichen Routine
Technische und organisatorische Umsetzung
Auftragsverarbeitung und gemeinsame Verantwortlichkeit: Löschung über Systemgrenzen
Betroffenenrechte in der Praxis: Löschanfragen sicher und effizient bearbeiten
Häufige Fehler, die in Unternehmen immer wieder auftreten
Best Practices: So wirkt ein Löschkonzept im Alltag
Kompakte Checkliste: Was Sie für ein tragfähiges Löschkonzept typischerweise benötigen

Begriffsklärung: Was ein Löschkonzept in der DSGVO-Praxis bedeutet

In der DSGVO-Praxis ist ein Löschkonzept kein „IT-Projekt“, das man einmal aufsetzt und dann abhakt. Ein Löschkonzept ist ein organisatorisch-technischer Rahmen, mit dem Sie steuern, welche personenbezogenen Daten zu welchem Zeitpunkt auf welche Weise aus welchen Systemen entfernt oder zumindest wirksam aus der Nutzung genommen werden. Der entscheidende Punkt: Es geht nicht nur darum, dass Daten „irgendwann“ verschwinden, sondern darum, dass Sie Speicherdauern begründet festlegen, Verantwortlichkeiten definieren und die Umsetzung im Alltag verlässlich funktioniert.

Löschkonzept als Bestandteil eines Datenschutz-Managements

Ein Löschkonzept gehört typischerweise in ein Datenschutz-Management, weil es mehrere Pflichten praktisch zusammenführt. Die Speicherbegrenzung wird damit in Prozesse übersetzt, die Rechenschaftspflicht wird durch Dokumentation und Kontrollen greifbar, und auch der Umgang mit Betroffenenrechten wird planbarer, weil Sie nicht bei jeder Anfrage von Null anfangen. Ohne Löschkonzept wirken viele Datenschutzdokumente in der Praxis wie eine statische Akte, während die Datenbestände dynamisch weiterwachsen. Mit einem guten Löschkonzept wird Datenschutz an einer Stelle konkret, an der Unternehmen ihn tatsächlich spüren: bei Systemen, Workflows und Verantwortlichkeiten.

Abgrenzung zu Archivierung, Aufbewahrung, „Retention“ und Berechtigungskonzept

In Unternehmen werden Begriffe rund um „Aufbewahren“ und „Löschen“ oft vermischt. Das führt regelmäßig zu Fehlentscheidungen. Archivierung meint im Kern die geordnete, nachvollziehbare Ablage, häufig mit dem Ziel, Informationen wiederauffindbar zu halten, etwa für interne Nachweise oder langfristige Dokumentation. Aufbewahrung ist stärker rechtlich geprägt: Daten oder Dokumente werden für bestimmte Mindestzeiträume vorgehalten, etwa wegen handels- oder steuerrechtlicher Pflichten oder zur Abwehr bzw. Durchsetzung von Ansprüchen. Retention wird oft als Sammelbegriff für Aufbewahrungs- und Löschregeln in IT-Systemen verwendet, häufig geprägt durch technische Einstellungen in Softwarelösungen. Ein Berechtigungskonzept wiederum regelt, wer auf Daten zugreifen darf, ersetzt aber kein Löschkonzept: Wenn Daten unnötig lange gespeichert werden, bleiben sie ein Risiko, selbst wenn nur wenige Personen darauf zugreifen können.

Löschen, Sperren/Einschränken, Anonymisieren: Unterschiede und typische Einsatzfälle

Löschen bedeutet, dass personenbezogene Daten im operativen System so entfernt oder unkenntlich gemacht werden, dass sie dort nicht mehr genutzt werden können. In der Praxis heißt das: keine produktive Nutzung mehr und keine Wiederherstellung im Regelbetrieb ohne unverhältnismäßigen Aufwand. Typische Kopien (z. B. Exporte, Anhänge, Nebenablagen) müssen in den realistisch beherrschbaren Datenorten mitgedacht und durch Regeln/Prozesse adressiert werden. Backups werden regelmäßig nicht selektiv „bereinigt“, sondern im vorgesehenen Zyklus überschrieben; bei einem Restore sind Lösch- und Sperrregeln erneut anzuwenden. Die Einschränkung der Verarbeitung (häufig technisch als „Sperrung“ umgesetzt) ist relevant, wenn Daten nicht mehr im Tagesgeschäft genutzt werden sollen, aber aus nachvollziehbaren Gründen noch aufzubewahren sind oder nicht gelöscht werden dürfen – etwa bei Streit über die Richtigkeit von Daten, bei laufenden Prüfungen, bei rechtlichen Aufbewahrungs-/Nachweisinteressen oder zur Abwehr/Durchsetzung von Ansprüchen. Zentral ist, dass die Daten dann nur noch für diese eng definierten Zwecke verarbeitet werden und eine „Nebenbei“-Weiterverwendung organisatorisch und technisch ausgeschlossen ist. Anonymisieren bedeutet, dass der Personenbezug dauerhaft und irreversibel entfernt wird, sodass eine Zuordnung zu einer Person auch unter Einsatz vernünftigerweise zu erwartender Mittel nicht mehr möglich ist. Das kann sinnvoll sein, wenn Auswertungen, Statistiken oder Qualitätskontrollen weiter benötigt werden, der Personenbezug aber nicht. Wichtig ist die saubere Abgrenzung: Pseudonyme Kennungen oder Hashwerte ersetzen häufig nur den Klarbezug (Pseudonymisierung) und sind regelmäßig weiterhin personenbezogene Daten, wenn eine Re-Identifizierung (direkt oder indirekt, z. B. über Zuordnungstabellen, Zusatzwissen oder Merkmalskombinationen) möglich bleibt.

Löschkonzept als „lebendes“ Dokument: wann Anpassungen naheliegen

Ein Löschkonzept bleibt nur dann nützlich, wenn es aktualisiert wird, sobald sich die Realität ändert. Anpassungen liegen typischerweise nahe, wenn neue Systeme oder Tools eingeführt werden, wenn Prozesse umgebaut werden, wenn neue Datenkategorien hinzukommen, wenn sich Aufbewahrungspflichten oder interne Compliance-Vorgaben ändern oder wenn Sie im Rahmen von Betroffenenanfragen und Audits feststellen, dass Löschroutinen in der Praxis nicht sauber greifen. Auch organisatorische Veränderungen spielen eine Rolle: Wechsel von Zuständigkeiten, Outsourcing, neue Dienstleister oder eine Migration in die Cloud sind klassische Auslöser. Ein praxistauglicher Ansatz ist, das Löschkonzept als Teil des Change-Managements zu verstehen: Wenn sich Datenflüsse verändern, sollte das Löschkonzept mitwandern.

nach oben

Rechtlicher Rahmen: Wo die DSGVO das Löschkonzept indirekt und direkt verlangt

Ein Löschkonzept steht in der DSGVO selten als „Pflichtdokument“ mit genau dieser Überschrift im Vordergrund. In der Praxis ergibt sich die Notwendigkeit jedoch aus mehreren Bausteinen, die zusammenlaufen: dem Grundsatz der Speicherbegrenzung, dem Recht auf Löschung, organisatorischen Anforderungen an Prozesse und der Pflicht, die eigene Compliance nachvollziehbar belegen zu können. Gerade weil die DSGVO eher Prinzipien und Ziele vorgibt, ist ein Löschkonzept häufig der praktikable Weg, diese Vorgaben in belastbare Abläufe zu übersetzen.

Speicherbegrenzung als Leitprinzip: Daten nicht länger als erforderlich

Der Ausgangspunkt ist die einfache, aber im Alltag anspruchsvolle Leitidee: Personenbezogene Daten sollen typischerweise nur so lange gespeichert werden, wie sie für den jeweiligen Zweck noch benötigt werden. Das klingt klar, ist aber ohne System schwer umzusetzen, weil „erforderlich“ selten auf ein einzelnes Datum hinausläuft. Häufig hängt die Speicherdauer von mehreren Faktoren ab, etwa vom Vertragsverlauf, von Gewährleistungs- und Verjährungsüberlegungen, von gesetzlichen Aufbewahrungspflichten oder von internen Dokumentationsinteressen, die sich sachlich begründen lassen müssen.

Ein Löschkonzept sorgt an dieser Stelle für Struktur: Es zwingt dazu, Zwecke zu trennen, Speicherdauern zu begründen und festzulegen, was nach Zweckerreichung passiert. Ohne diese Systematik entsteht leicht eine „Aufbewahrung aus Gewohnheit“, die in Prüfungen oder bei Betroffenenanfragen schwer zu verteidigen sein kann.

Löschung als Betroffenenrecht und als Organisationspflicht

In der DSGVO ist Löschung nicht nur ein abstrakter Grundsatz, sondern auch ein konkretes Betroffenenrecht. Das führt zu einem praktischen Druckpunkt: Wenn eine Person die Löschung verlangt, müssen Sie strukturiert prüfen, ob ein Löschgrund vorliegt – und zugleich, ob Ausnahmen greifen, denn das Löschrecht ist nicht absolut (z. B. bei gesetzlichen Aufbewahrungspflichten oder wenn Daten zur Geltendmachung, Ausübung oder Verteidigung von Rechtsansprüchen benötigt werden). Entscheidend ist außerdem die Fristlogik: Sie müssen die betroffene Person grundsätzlich ohne unangemessene Verzögerung und spätestens innerhalb eines Monats über die ergriffenen Maßnahmen informieren; eine Verlängerung um bis zu zwei Monate ist nur bei Komplexität/Anzahl möglich und muss innerhalb eines Monats begründet mitgeteilt werden. Wenn Sie nicht löschen (oder nicht vollständig löschen), müssen Sie dies ebenfalls binnen eines Monats mit Gründen sowie Hinweis auf Beschwerde- und Rechtsbehelfe kommunizieren. Wenn Daten zuvor an Empfänger offengelegt wurden, gehört außerdem eine Empfängerkommunikation in den Prozess (Mitteilung der Löschung/Einschränkung an Empfänger, soweit nicht unmöglich oder unverhältnismäßig).

Parallel dazu wirkt Löschung als Organisationspflicht: Auch ohne Anfrage sollten Unternehmen typischerweise dafür sorgen, dass Datenbestände nicht unkontrolliert anwachsen. Ein Löschkonzept ist hier weniger „Reaktion“ als vielmehr „Vorsorge“, damit Löschung nicht erst dann beginnt, wenn ein Problem entsteht. In der Praxis zeigt sich oft: Wer Löschroutinen sauber etabliert, kann Betroffenenrechte meist schneller und konsistenter bedienen, weil die Datenorte bekannt sind und die Logik der Speicherdauer dokumentiert ist.

Rechenschaftspflicht: warum Sie Löschentscheidungen nachvollziehbar machen sollten

Die DSGVO arbeitet nicht nur mit materiellen Anforderungen, sondern auch mit dem Prinzip: Sie sollen in der Lage sein zu erklären, warum Sie etwas so machen. Das betrifft Löschung in besonderem Maß, weil Speicherdauern häufig im Zusammenspiel von Recht, Prozess und Technik entstehen. Es reicht in der Praxis oft nicht, „wir löschen irgendwann“ zu behaupten. Hilfreich ist vielmehr, wenn Sie nachvollziehbar darlegen können, welche Datenkategorien betroffen sind, welche Löschereignisse auslösen, welche Fristen angewendet werden und wie die Umsetzung technisch und organisatorisch abgesichert ist.

Diese Nachvollziehbarkeit hat mehrere Vorteile. Sie erleichtert interne Abstimmungen zwischen Fachbereichen und IT. Sie reduziert Reibung in Audits oder bei Rückfragen von Geschäftspartnern. Und sie hilft, wenn es zu Streitigkeiten kommt, in denen Speicherentscheidungen kritisch hinterfragt werden. Ein gutes Löschkonzept funktioniert daher nicht nur als „Datenschutzpapier“, sondern auch als internes Steuerungsinstrument.

Schnittstellen zu Transparenzpflichten und Informationspflichten

Löschung ist eng mit Transparenz verbunden. Wenn Sie Personen darüber informieren, welche Daten Sie verarbeiten und wie lange Sie diese voraussichtlich speichern, braucht es im Hintergrund eine belastbare Logik. In vielen Fällen ist es realistischer, mit Fristenkategorien und Kriterien zu arbeiten als mit einem starren Kalenderdatum. Entscheidend ist, dass Ihre Aussagen nach außen mit Ihren internen Regeln zusammenpassen.

Hier zeigt sich eine typische Schwachstelle: Unternehmen formulieren nach außen sehr allgemeine Angaben zur Speicherdauer, während intern keine klare Regel existiert, wann wirklich gelöscht wird. Das kann zu Widersprüchen führen, die bei Beschwerden oder Anfragen unangenehm werden können. Ein Löschkonzept schafft die Brücke zwischen „Was sagen wir?“ und „Was tun wir?“ Es hilft, Informationspflichten konsistent zu erfüllen, ohne sich durch zu enge Formulierungen selbst unnötig zu binden, und unterstützt gleichzeitig eine Umsetzung, die im Alltag tragfähig bleibt.

nach oben

Der Kern in der Praxis: Wie Sie Löschfristen rechtssicher herleiten

Die größte Fehlerquelle bei Löschkonzepten ist selten die Technik. Meist scheitert es früher: an der Herleitung der Löschfristen. In vielen Unternehmen entstehen Fristen nach dem Muster „Das machen wir schon immer so“ oder „Die IT kann nur 3, 5 oder 10 Jahre“. Beides ist aus DSGVO-Sicht riskant, weil Speicherdauern typischerweise begründet werden müssen. Gleichzeitig ist es kaum praktikabel, für jeden Einzelfall eine juristische Einzelfallprüfung zu organisieren. Ziel ist daher ein Ansatz, der rechtlich vertretbar und operativ handhabbar ist.

Zweckbindung als Ausgangspunkt: Welche Zwecke gibt es wirklich?

Der sinnvollste Startpunkt ist nicht die Frage „Wie lange dürfen wir speichern?“, sondern: Wozu speichern wir überhaupt? In der Praxis lohnt sich ein kritischer Blick, weil Unternehmen Zwecke oft zu grob formulieren. „Kundenverwaltung“ ist selten ein einzelner Zweck, sondern eher eine Sammelkategorie. Häufig verbergen sich dahinter unterschiedliche Zwecke mit unterschiedlichen Speicherdauern, etwa Vertragsdurchführung, Abrechnung, Support, Dokumentation von Einwilligungen, Betrugsprävention oder Marketing.

Wenn Zwecke zu grob bleiben, werden Löschfristen fast automatisch zu lang, weil man sich am „schlimmsten Fall“ orientiert. Ein praxistauglicher Weg ist deshalb, Zwecke so zu schneiden, dass sie einerseits realistisch zu Ihren Prozessen passen, andererseits unterschiedliche Lebenszyklen abbilden. Das schafft die Grundlage, Löschereignisse und Fristen später sauber zu definieren.

Rechtsgrundlagen und deren Einfluss auf die Speicherdauer

Die Rechtsgrundlage beeinflusst häufig, wie lange Daten typischerweise benötigt werden. Das bedeutet nicht, dass eine bestimmte Rechtsgrundlage automatisch eine feste Frist vorgibt. Sie gibt aber einen Rahmen dafür, wann der Zweck typischerweise entfällt.

Bei vertraglicher Verarbeitung liegt der Schwerpunkt oft auf der Laufzeit des Vertrags und der Phase danach, in der noch Abwicklung, Gewährleistung oder Rückfragen möglich sind. Bei rechtlichen Pflichten spielen Aufbewahrungs- und Nachweispflichten eine Rolle, die Speicherdauern verlängern können. Bei berechtigten Interessen kommt es besonders darauf an, dass Sie das Interesse konkret fassen und regelmäßig prüfen, ob es noch trägt. Und bei Einwilligungen ist die Frage zentral, wie Sie den Widerruf praktisch abbilden und welche Daten Sie nach Widerruf noch aus anderen Gründen weiter speichern dürfen oder müssen. Eine saubere Trennung von Zweck und Rechtsgrundlage verhindert, dass „Marketing“ und „Vertrag“ in der Praxis vermischt werden.

Gesetzliche Aufbewahrungspflichten: warum sie Löschung oft verschieben, aber nicht „aufheben“

Aufbewahrungspflichten werden in Unternehmen gerne als Allzweckargument genutzt: „Wir müssen das alles 10 Jahre behalten.“ Das ist in dieser Pauschalität häufig nicht belastbar – schon weil die Fristen je nach Unterlagenart unterschiedlich ausfallen (in der Praxis häufig 6, 8 oder 10 Jahre; seit 2025 sind bestimmte Buchungsbelege/Rechnungen auf 8 Jahre verkürzt). Aufbewahrungspflichten betreffen typischerweise bestimmte Dokumente und Inhalte, nicht zwangsläufig jede Datenkopie in jedem System. Außerdem folgt daraus nicht automatisch, dass die Daten während der gesamten Zeit im gleichen System, in der gleichen Detailtiefe und für alle Zwecke nutzbar bleiben dürfen.

Praktisch bedeutet das: Aufbewahrungspflichten verschieben Löschung häufig, sie machen Löschung aber nicht überflüssig. Ein gutes Löschkonzept trennt daher zwischen „Weiter im operativen System erforderlich“ und „nur noch aufzubewahren“. Oft ist es sinnvoll, Daten nach Abschluss der operativen Phase in eine gezieltere, restriktiver zugängliche Aufbewahrung zu überführen, statt sie in produktiven Oberflächen weiter „mitschleppen“ zu lassen. Dadurch reduzieren Sie Risiken, ohne Aufbewahrungspflichten zu ignorieren.

„Erforderlichkeit“ im Alltag: Kriterien, die sich in Unternehmen bewähren

„Erforderlich“ ist kein Gefühl, sondern eine Abwägung, die sich strukturieren lässt. In der Praxis bewähren sich Kriterien, die Sie für Datenkategorien wiederkehrend anwenden können, statt ad hoc zu entscheiden. Typische Leitfragen sind:

Brauchen wir diese Daten noch für einen aktiven Prozess?
Wenn der Prozess abgeschlossen ist, spricht vieles dafür, Daten zu reduzieren oder in einen anderen Status zu überführen.

Gibt es realistische Folgeereignisse, die die Daten noch nötig machen?
Dazu zählen etwa Rückfragen, Reklamationen, Gewährleistung oder Support. Hier hilft es, nicht vom Ausnahmefall auszugehen, sondern von plausiblen Standardabläufen.

Bestehen nachvollziehbare Nachweis- oder Verteidigungsinteressen?
Gerade bei Verträgen, Haftungsthemen oder Compliance kann eine begrenzte Nachhaltung sinnvoll sein. Entscheidend ist, dass das Interesse konkret bleibt und nicht zum „Dauergrund“ wird.

Können wir mit weniger arbeiten?
Oft reicht eine reduzierte Datentiefe, etwa die Aufbewahrung von Rechnungsdaten ohne komplette Kommunikationshistorie oder die Speicherung eines Nachweises ohne alle Rohdaten. Datensparsamkeit ist häufig der einfachste Hebel für Löschfähigkeit.

Aus diesen Kriterien lassen sich Löschlogiken ableiten: Ereignis (z. B. Vertragsende), Frist (z. B. X Monate/Jahre), Maßnahme (Löschen, Einschränken, Archivieren, Anonymisieren) und Verantwortlichkeit.

Umgang mit Sonderfällen: Rechtsstreit, Gewährleistung, Verjährung, Compliance-Fälle

Sonderfälle sind der Punkt, an dem Löschkonzepte entweder professionell wirken oder als Theorie entlarvt werden. In der Praxis sollten Sie deshalb klar definieren, wie Sie mit „Hold“-Situationen umgehen, in denen Löschung vorübergehend nicht sachgerecht wäre.

Bei Rechtsstreitigkeiten oder absehbaren Auseinandersetzungen ist es naheliegend, Daten, die für die Rechtsverteidigung benötigt werden könnten, gezielt zu sichern und gleichzeitig die Nutzung einzuschränken. Wichtig ist, dass solche „Holds“ nicht unbegrenzt laufen, sondern überprüfbar sind und ein Ende haben können, etwa nach Abschluss des Verfahrens oder nach Klärung der Rechtslage.

Bei Gewährleistung und Verjährung ist der typische Fehler, pauschal alles lange zu speichern. Sinnvoller ist häufig eine differenzierte Betrachtung: Welche Daten sind wirklich relevant, um Ansprüche zu prüfen oder abzuwehren? Welche Daten können vorher reduziert oder anonymisiert werden? Gerade Kommunikationsdaten und interne Notizen sind oft überproportional risikobehaftet, wenn sie ohne klaren Zweck über Jahre vorgehalten werden.

Bei Compliance-Fällen kommt es besonders darauf an, Zuständigkeiten und Zugriff zu regeln. Nicht jeder Compliance-Hinweis rechtfertigt eine vollständige Datensammlung auf Dauer. Häufig ist ein abgestuftes Vorgehen praktikabler: temporäre Sicherung, restriktiver Zugriff, klare Prüffristen, dokumentierte Entscheidung, und anschließend entweder Löschung oder Überführung in eine rechtlich begründete Aufbewahrung.

Wenn Sie diese Sonderfälle im Löschkonzept sauber abbilden, vermeiden Sie zwei Extreme: unkontrollierte „Daueraufbewahrung“ und vorschnelles Löschen, das in Konfliktsituationen problematisch werden könnte.

nach oben

Datenlandkarte als Voraussetzung: Welche Daten wo liegen

Ein Löschkonzept funktioniert nur so gut wie Ihr Überblick über die Datenrealität. Wenn Sie nicht wissen, welche personenbezogenen Daten in welchen Systemen und Ablagen landen, bleibt Löschung Zufall oder hängt vom Engagement einzelner Mitarbeiter ab. Genau deshalb ist eine Datenlandkarte in der Praxis oft der entscheidende Schritt: Sie schafft Transparenz darüber, welche Datenkategorien existieren, wo sie gespeichert werden und wie sie sich durch Ihr Unternehmen bewegen. Ohne diese Grundlage werden Löschfristen zwar auf Papier definiert, in der Umsetzung aber regelmäßig verfehlt.

Datenkategorien: Kunden, Interessenten, Beschäftigte, Lieferanten, Bewerber

• Kunden
• Stammdaten, Vertrags- und Abrechnungsdaten, Kommunikationshistorien
• Supporttickets, Reklamationen, Dokumentation von Vereinbarungen
• Zahlungs- und Mahndaten, ggf. Bonitäts- oder Identitätsprüfungen
• Interessenten
• Kontaktanfragen, Lead-Daten, Angebotsdokumente
• Newsletter-Anmeldungen und Einwilligungsnachweise
• Gesprächsnotizen und Kalender-/Terminbezüge
• Beschäftigte
• Personalakte, Lohn- und Gehaltsdaten, Arbeitszeit- und Urlaubsverwaltung
• Kommunikationsdaten, Leistungs- und Qualifikationsnachweise
• Berechtigungen, Zutritts- und IT-Logdaten (je nach Systemlandschaft)
• Lieferanten und Dienstleister
• Ansprechpartnerdaten, Vertrags- und Leistungsdokumentation
• Abrechnungsunterlagen, Korrespondenz, Projektunterlagen
• Zugriffs- und Berechtigungsdaten in Portalen oder Ticketsystemen
• Bewerber
• Bewerbungsunterlagen, Gesprächsnotizen, Bewertungen
• Korrespondenz, Terminabsprachen, ggf. Nachweise/Referenzen
• Daten aus Recruiting-Tools und E-Mail-Postfächern

Systeme und Speicherorte: ERP/CRM, E-Mail, Fileserver, Cloud, Papierakten, Messenger

• ERP/CRM
• Zentrale Datenquelle für Stammdaten, Vertragsstatus, Rechnungen, Historien
• Häufige Herausforderung: Dubletten, Alt-Datensätze, unklare Felder und Freitext
• E-Mail
• In der Praxis oft „Neben-CRM“ und „Langzeitarchiv“
• Risiken: Anhänge, Weiterleitungen, CC-Ketten, personenbezogene Daten im Fließtext
• Fileserver und Netzlaufwerke
• Projektordner, Kundenordner, Exporte, Zwischenstände
• Typisches Problem: Kopien an mehreren Orten, unklare Versionen, fehlende Zuständigkeit
• Cloud-Speicher und Kollaboration
• Teams/SharePoint/OneDrive, Google Workspace, Projekttools
• Stolperstelle: geteilte Links, externe Gäste, parallele Ablagen zur „Hauptakte“
• Papierakten
• Verträge, unterschriebene Dokumente, Notizen, Posteingänge
• Praktisches Problem: Medienbruch, dezentrale Ablage, schwer automatisierbare Löschung
• Messenger und mobile Kommunikation
• Kurznachrichten, Sprachnachrichten, Fotos, Screenshots
• Hoher Kontrollverlust, wenn keine klaren Regeln und Unternehmenslösungen existieren

Schatten-IT und Tool-Wildwuchs: typische Stolperstellen

• Private oder nicht freigegebene Tools
• Dateiablagen, Umfrage-Tools, Notiz-Apps, Übersetzungs- oder KI-Tools
• Problem: fehlende Übersicht, fehlende Verträge, fehlende Löschmechanismen
• Inoffizielle Datenkopien
• Excel-Listen, lokale Downloads, Exportdateien aus CRM/ERP
• Gefahr: Daten werden „aus dem System herausgetragen“ und entziehen sich Löschläufen
• Abteilungsinseln
• Vertrieb, HR, Support und Buchhaltung führen getrennte Datentöpfe
• Folge: Fristen werden uneinheitlich angewendet, Daten bleiben liegen, weil sich niemand zuständig fühlt
• Schnell eingeführte Tools
• Pilotprojekte werden zum Dauerbetrieb
• Nachträgliche Löschkonzepte werden schwierig, weil Datenmodelle und Prozesse nicht sauber definiert sind

Backups und Protokolle: warum sie im Löschkonzept gesondert behandelt werden sollten

• Backups sind kein normales Archiv
• Sie dienen der Wiederherstellung nach Störungen, nicht der operativen Nutzung
• Häufig ist selektive Löschung einzelner Datensätze technisch nur eingeschränkt möglich
• Relevanz für das Löschkonzept
• Sie sollten definieren, wie lange Backups vorgehalten werden, wer Zugriff hat und in welchen Fällen eine Wiederherstellung erfolgt
• Wichtig ist auch, wie Sie verhindern, dass gelöschte Daten durch Restore-Prozesse unbemerkt wieder „aufleben“
• Protokolle und Logdaten
• Enthalten oft personenbezogene Daten (z. B. Nutzerkennungen, IP-Bezüge, Zeitstempel)
• Werden aus Sicherheits- oder Nachweisgründen benötigt, sollten aber mit eigenen, plausiblen Fristen geführt werden
• Praktischer Ansatz
• Backups und Logs als eigene Datenkategorien behandeln
• Speicherdauer, Zugriff, Zweck und Lösch-/Überschreiblogik getrennt festlegen
• Dokumentieren, wann eine Einschränkung statt vollständiger Löschung naheliegen kann

nach oben

Bausteine eines belastbaren Löschkonzepts

Ein Löschkonzept wird in der Praxis dann belastbar, wenn es nicht nur erklärt, was „eigentlich“ passieren soll, sondern wenn es Verantwortlichkeiten, Regeln und technische Umsetzung so miteinander verbindet, dass Löschung wiederholbar und prüfbar wird. Sie brauchen dafür keine Papierlawine. Sie brauchen eine Struktur, die für Ihre Systemlandschaft und Ihre Prozesse funktioniert und auch dann trägt, wenn Mitarbeiter wechseln oder neue Tools hinzukommen.

Rollen und Verantwortlichkeiten: Fachbereich, IT, Datenschutzkoordination, Dienstleister

• Fachbereich
• definiert, welche Zwecke für Datenkategorien tatsächlich bestehen und wann diese typischerweise enden
• bewertet, welche Daten nach Prozessende noch sachlich erforderlich sein könnten
• liefert Trigger-Ereignisse (z. B. „Vertragsende“, „Ticket geschlossen“, „Bewerbungsverfahren beendet“)
• entscheidet in Sonderfällen (z. B. Streit, Compliance), ob ein Hold gesetzt werden soll
• IT
• prüft, wo die Daten technisch liegen und welche Löschmechanismen das System bietet
• setzt Löschläufe, Retention-Settings, Workflows oder Skripte um
• stellt sicher, dass Löschungen keine Systemintegrität zerstören (z. B. Referenzen, Protokollierung, Reporting)
• dokumentiert technische Randbedingungen, etwa wenn nur logische Löschung möglich ist
• Datenschutzkoordination
• sorgt für Konsistenz: Zweck, Rechtsgrundlage, Fristlogik und Maßnahmen müssen zueinander passen
• moderiert Zielkonflikte zwischen Fachbereich („lieber behalten“) und IT („nicht machbar“)
• achtet darauf, dass Betroffenenrechte und Informationspflichten zur Speicherdauer inhaltlich anschlussfähig bleiben
• organisiert Reviews und Aktualisierungen, damit das Löschkonzept nicht veraltet
• Dienstleister
• müssen Löschanforderungen in ihren Systemen umsetzen können oder Alternativen anbieten
• benötigen klare Vorgaben zu Fristen, Rückgabe, Löschbestätigungen und Offboarding-Prozessen
• sollten in der Praxis so eingebunden werden, dass Löschung nicht erst beim Providerwechsel auffällt

Löschregeln je Datenkategorie: Ereignis + Frist + Maßnahme

• Ereignis (Trigger)
• typische Trigger sind z. B. Vertragsende, Zweckwegfall, Widerruf, Widerspruch, Ticketabschluss, Projektende, Austritt eines Beschäftigten, Abschluss eines Bewerbungsverfahrens
• Trigger sollten so gewählt sein, dass sie im System erkennbar und auswertbar sind
• Frist
• Fristen sind häufig gestaffelt (z. B. operative Phase, danach Aufbewahrung, danach Löschung)
• sinnvoll ist eine Logik, die Ausnahmen abbildet (z. B. Hold bei Streit) und nicht nur „Einheitsfristen“ kennt
• Maßnahme
• klare Festlegung, was am Fristende passiert: Löschen, Einschränken, Archivieren, Anonymisieren
• Zuordnung zu konkreten Systemen: Was passiert im CRM, was im Ticketsystem, was in der E-Mail-Ablage?
• Praktischer Mindeststandard
• pro Datenkategorie zumindest festlegen:
• Datenart (z. B. Vertragsdaten, Kommunikationsdaten, Nachweise)
• System/Speicherort
• Trigger
• Frist
• Maßnahme
• Verantwortlicher
• Sonderfallregel (Hold/Einzelfallprüfung)

Löschmethoden: physische Löschung, logische Löschung, Zugriffsbeschränkung, Anonymisierung

• Physische Löschung
• Daten werden so entfernt, dass sie im operativen System nicht mehr verfügbar sind
• eignet sich häufig für Daten, deren Zweck eindeutig entfallen ist und für die kein plausibles Aufbewahrungsinteresse mehr besteht
• Stolperstelle: Kopien in Exporten, Anhängen, Fileablagen müssen mitgedacht werden
• Logische Löschung
• Datensatz bleibt technisch vorhanden, wird aber im System „deaktiviert“ oder ausgeblendet
• sinnvoll, wenn Systeme Referenzen benötigen oder Löschung sonst Folgefehler erzeugen könnte
• wichtig ist, dass logische Löschung nicht zu „Weiterverarbeitung durch die Hintertür“ führt, sondern wirksam ist
• Zugriffsbeschränkung beziehungsweise Einschränkung der Verarbeitung
• Daten bleiben für eng definierte Zwecke verfügbar, z. B. Nachweis, Rechtsverteidigung, Aufbewahrung
• Zugriff wird auf wenige Rollen begrenzt, Nutzung im Tagesgeschäft wird unterbunden
• eignet sich besonders für Aufbewahrungsphasen oder Sonderfälle
• Anonymisierung
• Personenbezug wird entfernt, wenn Daten für Auswertungen oder Qualitätssicherung sinnvoll bleiben
• funktioniert in der Praxis vor allem dann gut, wenn Prozesse von Anfang an darauf ausgelegt sind (z. B. Trennung von Identifikationsdaten und Sachinformationen)
• wichtig ist eine realistische Prüfung, ob Re-Identifikation durch Kombination von Merkmalen naheliegen könnte

Dokumentation: was sinnvoll festgehalten wird (ohne unnötige Bürokratie)

• Warum dokumentieren?
• damit Entscheidungen nachvollziehbar bleiben, auch wenn Personen wechseln
• damit Prozesse wiederholbar sind und bei Betroffenenanfragen nicht improvisiert werden muss
• Was typischerweise genügt
• Übersicht über Datenkategorien und Systeme (Datenlandkarte)
• Löschmatrix oder Löschplan: Trigger, Frist, Maßnahme, Verantwortlicher je Kategorie/System
• Beschreibung der Umsetzung: automatisierte Löschläufe, manuelle Prozesse, Kontrollmechanismen
• Sonderfallregeln: Hold-Prozess, Freigaben, Eskalation, Prüffristen
• Schnittstellen zu Dienstleistern: Verantwortlichkeit, Offboarding, Nachweise
• Was häufig unnötig belastet
• überdetaillierte Einzelfalllisten, die niemand pflegt
• Dokumente ohne Bezug zur Systemrealität, die bei jeder Tool-Änderung sofort veralten

Nachweisbarkeit: wie Sie intern prüfen können, ob Regeln funktionieren

• Stichproben und Plausibilitätschecks
• zufällige Datensätze prüfen: Sind sie nach Fristablauf wirklich gelöscht oder eingeschränkt?
• Prüfung an typischen Datenorten: CRM, Tickets, E-Mail-Ordner, Projektablagen
• Technische Kontrollen
• Löschläufe mit Protokollausgaben oder Reportings, die erkennen lassen, dass der Lauf stattgefunden hat
• Monitoring von Fehlern (z. B. Datensätze, die wegen Referenzen nicht gelöscht wurden)
• Organisatorische Kontrollen
• regelmäßige Reviews, etwa nach Systemwechseln oder Prozessänderungen
• definierte Verantwortliche, die Abweichungen aufnehmen und Maßnahmen planen
• Typische Warnsignale
• Fristen existieren nur als Text, aber nicht als umgesetzte Regel im System
• Löschung funktioniert in einem System, aber nicht in Exporten und Nebenablagen
• Sonderfall-Holds werden gesetzt, aber selten wieder aufgehoben
• Praktisches Zielbild
• Sie können intern mit vertretbarem Aufwand zeigen, dass Löschung nicht Zufall ist, sondern ein kontrollierter Prozess.

nach oben

Prozessdesign: Von der Regel zur verlässlichen Routine

Ein Löschkonzept wirkt erst dann, wenn es in Prozesse übersetzt wird, die wiederholbar laufen und nicht davon abhängen, ob einzelne Personen „daran denken“. In der Praxis ist das Prozessdesign deshalb der entscheidende Schritt: Sie machen aus Regeln eine Routine, die in den Systemen, in Verantwortlichkeiten und in Kontrollmechanismen verankert ist. Ziel ist ein Ablauf, der planbar ist, Sonderfälle abbildet und intern nachvollziehbar bleibt, ohne den Betrieb zu lähmen.

Trigger-Ereignisse: Vertragsende, Zweckwegfall, Widerruf, Widerspruch, Löschantrag

• Vertragsende
• Trigger sollte systemseitig eindeutig sein (Status, Enddatum, Kündigungsbestätigung)
• Abgrenzung der Phasen hilft: Abwicklung, Nachlauf (Rückfragen/Support), Aufbewahrung, Löschung
• Zweckwegfall
• Trigger kann prozessual sein (Ticket geschlossen, Projekt beendet, Angebot abgelehnt)
• wichtig ist, dass „Zweckwegfall“ nicht nur eine abstrakte Formel bleibt, sondern an konkrete Prozessereignisse gekoppelt wird
• Widerruf
• betrifft typischerweise Daten, die auf Einwilligung beruhen (z. B. Newsletter, Tracking, Werbeansprache)
• Prozess sollte klar trennen: Was fällt weg (Marketing), was bleibt ggf. aus anderen Gründen (z. B. Vertragsdokumentation)
• Widerspruch
• häufig relevant bei Verarbeitung auf Basis berechtigter Interessen (z. B. Direktwerbung, bestimmte Auswertungen)
• in der Praxis ist entscheidend, dass der Widerspruch systemseitig markiert und in nachgelagerten Prozessen berücksichtigt wird
• Löschantrag
• löst einen Einzelfallprozess aus, der Identität, Umfang, Anspruch, Ausnahmen und Umsetzung abdeckt
• gute Praxis: der Löschantrag ist kein „Sonderfall ohne Regeln“, sondern folgt einem Standardablauf mit Checkpunkten

Regelmäßige Löschläufe vs. Einzelfallbearbeitung

• Regelmäßige Löschläufe
• eignen sich für Standardfälle mit klaren Kriterien (Frist ab Trigger, eindeutige Datenfelder, systemgestützte Identifikation)
• Vorteile:
• gleichmäßige Datenreduktion statt „Löschaktionismus“
• geringeres Risiko, dass Datenbestände unkontrolliert wachsen
• bessere Planbarkeit für IT und Fachbereiche
• typische Umsetzung:
• automatisierte Jobs im System
• regelmäßige Reports über betroffene Datensätze
• Fehlerlisten, wenn Datensätze nicht verarbeitet werden konnten
• Einzelfallbearbeitung
• ist oft notwendig bei:
• Betroffenenanfragen, die mehrere Systeme betreffen
• Sonderfällen (Hold, Streit, Compliance)
• unklarer Datenlage (Dubletten, Freitext, Mischakten)
• Risiko in der Praxis: Einzelfälle werden zur Regel, wenn Standardlöschungen nicht gut umgesetzt sind
• Pragmatisches Zielbild
• Standarddaten laufen über Löschläufe
• Einzelfallprozesse sind für Abweichungen, Konflikte und Betroffenenrechte reserviert
• beide Wege greifen auf dieselbe Löschlogik zurück, damit keine Widersprüche entstehen

Freigabe- und Eskalationswege bei Unsicherheiten

• Typische Unsicherheiten
• unklare Aufbewahrungspflichten oder Überschneidungen verschiedener Zwecke
• laufende oder drohende Streitigkeiten
• Daten, die in mehreren Systemen widersprüchlich klassifiziert sind
• technische Einschränkungen, die „echte“ Löschung erschweren
• Freigabemodell in der Praxis
• Fachbereich bestätigt Zweckwegfall und Sonderfallfreiheit (kein Hold)
• IT bestätigt technische Umsetzung und dokumentiert Einschränkungen
• Datenschutzkoordination prüft Plausibilität, insbesondere bei neuen Kategorien oder geänderten Prozessen
• Eskalationsweg
• klar definieren, wer entscheidet, wenn Interessen kollidieren (z. B. Fachbereich will behalten, Datenschutz will löschen)
• hilfreich ist ein Standard: „Behalten nur bei dokumentierter Begründung, sonst Löschlauf“
• Sonderfälle zeitlich begrenzen und mit Review-Datum versehen, damit Eskalationen nicht zu Dauerzuständen werden

Löschprotokolle: was sie leisten sollen und wo sie selbst Datenschutzfragen auslösen können

• Was Löschprotokolle leisten sollen
• Nachweis, dass Löschläufe stattgefunden haben
• Transparenz über Umfang: welche Kategorien/Systeme, welcher Zeitraum, welche Anzahl Datensätze
• Fehler- und Ausnahmebehandlung: was konnte nicht gelöscht werden und warum?
• Grundlage für interne Kontrollen und Verbesserungen
• Wo Löschprotokolle selbst datenschutzrelevant werden
• wenn Protokolle mehr personenbezogene Daten enthalten als nötig
• wenn Protokolle zu lange gespeichert werden und selbst zum „Datenfriedhof“ werden
• wenn Protokolle breiten Zugriff haben und damit neue Risiken schaffen
• Gute Praxis
• Protokolle auf das erforderliche Maß begrenzen, z. B. über interne Vorgangs-/Datensatz-IDs oder aggregierte Auswertungen. Wenn pseudonyme Kennungen oder Hashwerte eingesetzt werden, sind sie regelmäßig weiterhin personenbezogene Daten (Pseudonymisierung) und müssen entsprechend geschützt, zugriffsbegrenzt und mit passenden Löschfristen versehen werden
• Zugriffe beschränken (Need-to-know)
• eigene Löschfristen für Protokolle definieren, die zu ihrem Zweck passen
• klar regeln, wann Detailprotokolle notwendig sind und wann Summenberichte genügen

Qualitätssicherung: Stichproben, Kontrollen, Verbesserungszyklen

• Stichproben
• regelmäßig Datensätze prüfen, die eigentlich hätten gelöscht oder eingeschränkt sein müssen
• nicht nur im „Hauptsystem“ prüfen, sondern auch in typischen Nebenablagen (E-Mail, Exporte, Projektordner)
• Kontrollen
• technische Kontrolle: Laufprotokolle, Fehlerraten, Ausnahmelisten, Monitoring
• organisatorische Kontrolle: Reviews bei Systemwechseln, Prozessänderungen, neuen Tools
• Dienstleisterkontrolle: Offboarding-Checks, Löschbestätigungen, Plausibilitätsprüfungen
• Verbesserungszyklen
• Fehlerquellen systematisch aufnehmen: Warum blieb etwas liegen? Fehlender Trigger? Technisches Limit? Unklare Zuständigkeit?
• Maßnahmen ableiten: Felder ergänzen, Prozesse ändern, Automatismen verbessern, Schulung nachschärfen
• feste Review-Termine einplanen, damit das Löschkonzept mit der Realität mitwächst
• Praktisches Ergebnis
• Löschung wird zu einem verlässlichen Ablauf mit Rückkopplung, statt zu einer einmaligen „Aufräumaktion“.

nach oben

Technische und organisatorische Umsetzung

Ein Löschkonzept steht und fällt mit der Umsetzung. In der Praxis entsteht die größte Wirkung nicht dadurch, dass Sie Löschfristen noch genauer formulieren, sondern dadurch, dass Sie Datenhaltung, Berechtigungen und Tool-Nutzung so gestalten, dass Löschung überhaupt möglich bleibt. Technisch-organisatorisch geht es daher um zwei Leitfragen: Wie verhindern Sie unnötiges Datenwachstum von vornherein? Und wie stellen Sie sicher, dass vorhandene Daten über Systemgrenzen hinweg tatsächlich in den vorgesehenen Status wechseln?

Minimalprinzip: Datenhaltung von vornherein reduzierter gestalten

• Datensparsame Prozesse
• nur Felder erfassen, die für den Zweck plausibel erforderlich sind
• Pflichtfelder kritisch prüfen: „nice to have“ wird schnell zum Dauerbestand
• Datenlebenszyklen schon bei der Systemkonfiguration mitdenken
• Statusmodelle einführen (z. B. aktiv, abgeschlossen, aufbewahrungspflichtig, gesperrt)
• Trigger-Felder so gestalten, dass Löschläufe zuverlässig arbeiten können
• Freitext reduzieren, wo es realistisch ist
• Freitextfelder sind praktisch, aber sie erschweren Klassifizierung, Suche und Löschung
• Alternativen: strukturierte Kategorien, kurze Notizen mit klarer Zweckbindung, separate „Aktennotiz“-Felder mit Regeln
• Dubletten und Parallelablagen vermeiden
• konsequente „Single Source of Truth“ festlegen (z. B. CRM statt Excel-Leadlisten)
• Exportregeln definieren: wer darf exportieren, wohin, wie lange, mit welchen Schutzmaßnahmen
• Anonymisierung als Option früh einplanen
• insbesondere bei Reporting und Analytics: Identifikationsdaten und Sachinformationen trennen
• so können Sie später eher anonymisieren, statt lange personenbezogen zu speichern

Berechtigungskonzept und Löschkonzept als Team: warum beides zusammengehört

• Berechtigungen reduzieren das Risiko, Löschung reduziert die Datenlast
• Zugriffsbeschränkung allein behebt nicht, dass Daten unnötig lange existieren
• Löschung allein hilft nicht, wenn Daten bis dahin zu breit zugänglich sind
• Gemeinsame Steuerlogik
• Datenstatus sollte Berechtigungen steuern: „aufbewahrungspflichtig“ bedeutet typischerweise reduzierte Rollenrechte
• „gesperrt/eingeschränkt“ sollte systemseitig verhindern, dass Daten in Workflows, Marketinglisten oder Auswertungen landen
• Trennung von operativer Nutzung und Aufbewahrung
• operativ: viele Funktionen, breitere Rollen
• Aufbewahrung: Zugriff auf wenige Rollen, keine Bearbeitung, möglichst keine Weiterverarbeitung
• Sonderfälle sauber abbilden
• Hold-Fälle: Zugriff streng begrenzen, Nutzung klar zweckgebunden, Review-Datum setzen
• Protokollierung: wer hat wann warum Zugriff gehabt, ohne unnötige Detaildaten zu sammeln

E-Mail- und Kollaborationstools: Aufbewahrung, Export, Automatisierung, Löschregeln

• E-Mail als Risikozone
• häufigster Datenfriedhof: Anhänge, Vertragskopien, Ausweiskopien, Korrespondenzketten
• typische Schwäche: fehlende einheitliche Ordnerlogik und fehlende Löschroutinen
• Pragmatische organisatorische Regeln
• geschäftsrelevante Dokumente gehören in definierte Systeme (DMS, CRM, ERP), nicht dauerhaft ins Postfach
• klare Regeln für Anhänge: Ablage im System, danach E-Mail-Version löschen oder Postfach aufräumen (ggf. aber gesetzliche Aufbewahrungsfristen beachten)
• Weiterleitungs- und CC-Kultur begrenzen, wenn sensible Daten betroffen sind
• Kollaborationstools und Cloudspeicher
• Risiken: parallele Ablagen, geteilte Links, externe Gäste, Versionsverläufe
• gute Praxis:
• Projekt- und Kundenteams mit definierten Lebenszyklen (Anlage, Abschluss, Archivstatus, Löschung)
• Export- und Downloadrechte einschränken, wo sinnvoll
• automatisierte Aufbewahrungsregeln für Projektordner, Kanaldateien und Chatverläufe, soweit technisch möglich
• Automatisierung
• wo Tools Retention-Regeln bieten, sollten diese nicht isoliert eingestellt werden, sondern an die Löschlogik des Löschkonzepts gekoppelt sein
• Fehlerquelle: Retention-Regeln werden „global“ gesetzt und kollidieren mit differenzierten Fristen einzelner Datenkategorien
• Löschregeln für Chats und Nachrichten
• klare Trennung: „Kommunikationsbequemlichkeit“ ist selten ein langfristiger Speicherzweck
• kurze, realistische Fristen für Chatverläufe können sinnvoll sein, insbesondere wenn Inhalte regelmäßig in Systeme übertragen werden sollen

Mobile Geräte und Remote Work: Risiken und pragmatische Schutzmaßnahmen

• Typische Risiken
• lokale Downloads auf Laptops, private Synchronisation, Screenshots, gespeicherte Anhänge
• Nutzung von Messenger-Apps außerhalb kontrollierter Unternehmenslösungen
• vermischte Nutzung privat/geschäftlich (insbesondere bei BYOD-Konstellationen)
• Pragmatische Schutzmaßnahmen
• klare Regeln, welche Daten mobil verarbeitet werden dürfen und welche nicht
• technische Grundabsicherung: Geräteschutz, Verschlüsselung, Remote-Wipe, MDM wo angemessen
• Vorgaben für lokale Speicherung: zeitlich begrenzen, automatische Bereinigung, Nutzung zentraler Ablagen bevorzugen
• Sensibilisierung: typische Fehlerbilder (Weiterleitung, Foto von Dokumenten, Dateiablage in privaten Clouds) konkret ansprechen
• Löschfähigkeit verbessern
• Arbeiten mit Links statt mit Anhängen fördern, wenn Systeme das zuverlässig können
• zentrale Ablage als Standard, mobile Kopien als Ausnahme mit klarer Rückführung oder Löschung

Backups: realistische Strategien zwischen Wiederherstellbarkeit und Löschpflichten

• Realismus statt Theorie
• Backups sind für Wiederherstellung gedacht, nicht für operative Nutzung
• selektive Löschung einzelner Datensätze in Backups ist technisch oft nur begrenzt möglich
• Was ein Löschkonzept hier leisten sollte
• klare Backup-Strategie definieren: Zweck, Aufbewahrungsdauer, Zugriff, Wiederherstellungsprozesse
• festlegen, wie lange Backups typischerweise vorgehalten werden und wann Überschreibung erfolgt
• Vermeidung des „Wiederauflebens“ gelöschter Daten
• Restore-Prozesse so gestalten, dass nach Wiederherstellung Löschregeln erneut angewendet werden
• dokumentierte Abläufe für Notfälle, damit nicht „aus Versehen“ alte Datenstände dauerhaft wieder produktiv werden
• Zugriff und Kontrolle
• Backup-Zugriffe strikt beschränken und protokollieren
• definieren, wann eine Wiederherstellung zulässig ist und wer sie freigibt
• Praktischer Ausgleich
• Sie müssen Wiederherstellbarkeit und Löschpflichten zusammenbringen, ohne beides zu überziehen:
• Backups nicht zu lange halten, wenn kein plausibles Wiederherstellungsinteresse besteht
• gleichzeitig nicht so kurz, dass Betriebsrisiken steigen
• entscheidend ist, dass Ihr Vorgehen konsistent dokumentiert und in der Praxis umsetzbar ist

nach oben

Auftragsverarbeitung und gemeinsame Verantwortlichkeit: Löschung über Systemgrenzen

Sobald personenbezogene Daten bei Dienstleistern verarbeitet werden, endet Ihr Löschkonzept nicht am eigenen Serverraum. In der Praxis wirkt jeder externe Anbieter wie eine „Datenverlängerung“: Daten werden gespiegelt, synchronisiert, in Ticketsysteme übertragen, in Cloud-Speichern abgelegt oder in Supportfällen repliziert. Wenn Sie Löschung intern sauber steuern, aber extern keine belastbaren Regeln haben, bleibt ein wesentlicher Teil des Risikos bestehen. Gleichzeitig sollten Sie realistisch bleiben: Nicht jeder Anbieter kann jede Löschanforderung in jeder technischen Tiefe abbilden. Das entbindet Sie jedoch nicht von der Verantwortlichkeit – Sie müssen Dienstleister so auswählen und vertraglich binden, dass Rückgabe/Löschung nach Ende der Leistung sowie der Umgang mit Kopien (inkl. gesetzlicher Aufbewahrungsausnahmen) geregelt und praktisch umsetzbar sind. Technische Grenzen müssen daher vorab identifiziert, vertraglich transparent abgebildet und prozessual kompensiert werden (z. B. „beyond use“, definierte Überschreibzyklen, Restore-Kontrollen). Ein guter Ansatz schafft deshalb klare vertragliche Pflichten, praktikable organisatorische Abläufe und nachvollziehbare Nachweise, ohne sich auf unerfüllbare Zusagen zu verlassen.

Dienstleister als „Datenverlängerung“: was Sie vertraglich und organisatorisch regeln sollten

• Vertragliche Regelung des Löschregimes
• klare Festlegung, wann Daten zu löschen sind (z. B. auf Weisung, nach Projektende, nach Vertragsende, nach Ablauf definierter Fristen)
• klare Festlegung, wie zu löschen ist (Löschung, Rückgabe, Anonymisierung, Einschränkung) und welche Datenarten betroffen sind
• Regelungen zu Unterauftragnehmern: Weitergabe nur unter Bedingungen, die Löschpflichten praktisch fortsetzen
• Weisungs- und Umsetzungsprozess
• definieren, wie Löschweisungen erteilt werden (Kontaktstelle, Ticketweg, Form, notwendige Angaben)
• Reaktions- und Umsetzungslogik festlegen, damit Löschung nicht im „Support-Pingpong“ hängen bleibt
• klare Verantwortlichkeit, wer intern Weisungen auslöst und wer die Erledigung prüft
• Abgrenzung der Rollen
• sauber prüfen, ob es wirklich Auftragsverarbeitung ist oder eher gemeinsame Verantwortlichkeit oder eigenständige Verantwortlichkeit des Dienstleisters
• diese Einordnung ist praktisch relevant, weil sie beeinflusst, wer welche Pflichten bei Löschanfragen übernimmt und wie Transparenz nach außen gestaltet wird
• Technische Randbedingungen offen adressieren
• wenn ein Dienstleister nur logische Löschung bietet oder Backups erst mit Verzögerung überschrieben werden, sollte das transparent geregelt sein
• wichtig ist, dass daraus keine „Freifahrtscheine“ entstehen, sondern definierte, nachvollziehbare Prozesse
• Schnittstellen und Datenflüsse
• dokumentieren, welche Daten in welche Systeme des Dienstleisters gelangen (z. B. Support-Tickets, Logs, Spiegelungen)
• besonderes Augenmerk auf „Nebenprodukte“: Exporte, Debug-Logs, Anhänge, Chatverläufe, temporäre Caches

Lösch- und Rückgabekonzepte bei Providerwechsel und Projektende

• Projektende als Löschtrigger
• Projektabschluss ist häufig der Moment, in dem Daten besonders unkontrolliert bleiben, weil niemand mehr „Owner“ ist
• gute Praxis: bereits bei Projektstart definieren, welche Daten am Ende
• zurückgegeben werden sollen
• in welcher Form (strukturierte Exporte, DMS-Import)
• und welche Daten beim Dienstleister zu löschen sind
• Providerwechsel
• Wechsel erzeugt typischerweise mehrere Datenstände:
• Daten im alten System
• Migrationskopien
• Testumgebungen
• Zwischenspeicher beim Migrationsdienstleister
• ein belastbares Konzept regelt daher:
• welche Daten migriert werden (nicht „alles, weil einfach“)
• wie lange Migrationskopien existieren dürfen
• wann das Altsystem endgültig stillgelegt wird
• wie Löschung nach Abschluss der Migration verifiziert wird
• Rückgabe und Löschung in Stufen
• in der Praxis ist eine stufenweise Abwicklung häufig realistischer:
• Erst Rückgabe/Export und Abnahme
• dann Sperrung/Deaktivierung der Umgebung
• anschließend Löschung produktiver Daten
• danach Löschung temporärer Daten, Testdaten und Migrationsartefakte
• Zugriffs- und Berechtigungs-Offboarding
• nicht nur Daten löschen, sondern auch Zugänge beenden:
• Admin-Zugänge, API-Tokens, Gastaccounts, Supportzugriffe
• klare Checkliste, weil „vergessene Zugänge“ oft ein größerer Risikotreiber sind als einzelne Altdaten

Kontroll- und Nachweispraxis: welche Nachweise in der Praxis typischerweise genügen

• Realistische Erwartungshaltung
• Sie werden selten „Beweise“ im mathematischen Sinn bekommen
• Ziel ist eine Nachweiskette, die plausibel zeigt, dass Löschung organisiert und umgesetzt wird
• Typische Nachweise, die in der Praxis häufig genügen
• Löschbestätigung des Dienstleisters mit
• Datum, Umfang (System/Umgebung), Datenkategorien
• Hinweis auf ggf. verzögerte Löschung in Backups und die dafür geltende Logik
• Tickets oder Protokolle aus dem Supportsystem als Nachweis des Vorgangs (ohne unnötige personenbezogene Details)
• Offboarding-Protokolle: Deaktivierung von Umgebungen, Konten, Zugängen, API-Schlüsseln
• Audit- oder Compliance-Reports des Anbieters, soweit vorhanden und relevant (als Plausibilitätsbaustein, nicht als Allheilmittel)
• Was Sie kritisch sehen sollten
• rein pauschale Formulierungen („Daten werden gelöscht“) ohne Bezug zu Systemen, Umgebungen oder Zeitpunkten
• Nachweise, die selbst umfangreiche personenbezogene Daten enthalten und dadurch neue Risiken schaffen
• fehlende Regelung, was bei technischen Einschränkungen passiert (z. B. Backup-Überschreibung), weil genau dort häufig Streit entsteht
• Pragmatische Kontrolllogik
• riskobasiert kontrollieren: je sensibler und je größer der Datenumfang, desto enger sollten Prozess und Nachweise sein
• bei kritischen Systemen zusätzlich interne Plausibilitätschecks einplanen (z. B. Testnutzer, Stichproben über Exporte, Abgleich mit Migrationslisten)
• klare Zuständigkeit für die „Abnahme“ von Löschung, damit Nachweise nicht ungelesen abgelegt werden

nach oben

Betroffenenrechte in der Praxis: Löschanfragen sicher und effizient bearbeiten

Löschanfragen wirken in vielen Unternehmen zunächst wie eine Ausnahmesituation. In der Praxis sind sie jedoch häufig ein Stresstest für Organisation und Datenhaltung: Wenn Sie nicht genau wissen, wo Daten liegen und warum Sie sie noch speichern, geraten Fristen, Kommunikation und Umsetzung schnell unter Druck. Ein gutes Löschkonzept hilft, weil es die Logik für Speicherzwecke und Datenorte bereits strukturiert. Trotzdem bleibt jede Löschanfrage ein Einzelfall mit klaren Mindestschritten, die Sie sauber abarbeiten sollten.

Prüfungsschritte: Identität, Umfang, Anspruch, Ausnahmen, Dokumentation

• Identität prüfen
• Ziel: sicherstellen, dass Sie Daten nicht an die falsche Person löschen oder Informationen an Unbefugte geben
• praxisnah ist eine risikobasierte Prüfung:
• bei unkritischen Daten kann die Kontrolle über den Kommunikationskanal (z. B. Anfrage von der bekannten E-Mail-Adresse) ausreichen, solange keine begründeten Zweifel an der Identität bestehen; bei Zweifeln ist eine zusätzliche Verifikation erforderlich, die risikoadäquat und möglichst schlank bleibt
• bei sensibleren Daten oder Kontenbezug kann eine zusätzliche Verifikation sinnvoll sein (z. B. Rückfrage, Token, Nachweis, Konto-Login)
• wichtig ist, dass die Identitätsprüfung nicht zur Verzögerungstaktik wird, sondern zielgerichtet bleibt
• Umfang klären
• konkretisieren, welche Verarbeitung betroffen ist:
• alle Daten oder bestimmte Bereiche (z. B. Newsletter, Kundenkonto, Bewerbungsunterlagen)
• welche Zeiträume oder Interaktionen
• intern: welche Systeme sind typischerweise betroffen (CRM, ERP, Tickets, E-Mail, Files, Kollaboration)
• Anspruch prüfen
• prüfen, ob Gründe für Löschung vorliegen, etwa:
• Zweck entfallen
• Widerruf einer Einwilligung bei darauf basierender Verarbeitung
• Widerspruch mit durchgreifender Wirkung (z. B. bei Direktwerbung typischerweise relevant)
• unrechtmäßige Verarbeitung oder sonstige Konstellationen, die eine Bereinigung nahelegen
• gleichzeitig prüfen, ob statt vollständiger Löschung eine Einschränkung oder Anonymisierung der passende Weg ist
• Ausnahmen prüfen
• typische Gegenrechte/Gründe für weitere Speicherung:
• rechtliche Aufbewahrungspflichten für bestimmte Unterlagen
• Erforderlichkeit zur Geltendmachung, Ausübung oder Verteidigung von Rechtsansprüchen
• laufende Streitigkeiten oder absehbare Auseinandersetzungen
• wichtig ist die Differenzierung: Ausnahmen betreffen oft Teilbestände, nicht zwingend „alles“
• Dokumentation
• dokumentieren sollten Sie typischerweise:
• Eingang, Identitätsprüfung, betroffene Systeme, Entscheidung, umgesetzte Maßnahmen
• etwaige Ausnahmen und deren Begründung
• Datum der Umsetzung und Verantwortlichkeiten
• in der Praxis genügt häufig eine schlanke Akte oder ein Ticket, wenn es nachvollziehbar ist und keine unnötigen personenbezogenen Detailkopien erzeugt

Umgang mit Konflikten: Aufbewahrungspflichten, Beweisinteressen, laufende Streitigkeiten

• Aufbewahrungspflichten sauber abgrenzen
• prüfen, welche konkreten Dokumente/Inhalte betroffen sind
• häufig ist es möglich, nur den aufbewahrungspflichtigen Teil zu behalten und den Rest zu löschen
• wenn möglich: Aufbewahrung in einem Status mit eingeschränktem Zugriff statt „weiter voll nutzbar im Tagesgeschäft“
• Beweisinteressen konkretisieren
• nicht „vorsichtshalber alles behalten“, sondern fragen:
• welche Daten sind realistisch beweisrelevant?
• wie lange ist der Bedarf plausibel?
• reicht eine eingeschränkte Verarbeitung (Hold) statt Weiterverarbeitung?
• besonders sensibel: interne Notizen, Freitextfelder, Kommunikationshistorien, die ohne klaren Zweck lange gespeichert werden
• Laufende Streitigkeiten
• wenn ein Streit bereits besteht oder absehbar ist, ist häufig ein Hold-Prozess naheliegend:
• Daten sichern
• Zugriff und Nutzung eng begrenzen
• Review-Datum und Ende des Holds definieren
• wichtig ist, dass der Hold nicht zum Dauerzustand wird, sondern regelmäßig überprüft wird

Kommunikation: wie Sie transparent bleiben, ohne sich festzulegen, wo es unklar ist

• Transparenz über Vorgehen
• erklären, dass Sie die Anfrage prüfen, in welchen Systembereichen typischerweise gesucht wird und welche Kategorien betroffen sein können
• ankündigen, dass bestimmte Daten aus rechtlichen Gründen ggf. weiter gespeichert werden müssen, dann aber nur zweckgebunden
• Präzise, aber vorsichtig formulieren
• statt absolute Zusagen („alles ist gelöscht“) besser:
• „Wir haben die Daten in den folgenden Bereichen gelöscht bzw. die Verarbeitung eingeschränkt.“
• „Soweit rechtliche Aufbewahrungspflichten bestehen, werden diese Daten nur noch für diesen Zweck gespeichert.“
• bei unklaren Datenlagen (z. B. Altarchive, Backup-Logik) offen bleiben, ohne Unsicherheit zu demonstrieren:
• „Backups werden in einem festgelegten Zyklus überschrieben; eine Nutzung erfolgt nicht im operativen Betrieb.“
• Erwartungsmanagement
• klare Zeitlinien und nächste Schritte kommunizieren
• falls Nachfragen erforderlich sind: gezielte Fragen stellen, nicht „Bitte präzisieren Sie alles“
• Konfliktkommunikation
• wenn Sie nicht vollständig löschen, begründen Sie den Umfang und die Gründe
• zugleich anbieten, welche Maßnahmen stattdessen erfolgen (Einschränkung, Sperrung, Abmeldung von Marketing)

Praxis-Tipp: Standardtexte und interne Checkfragen, die die Bearbeitung beschleunigen

• Standardtexte (Baukastenprinzip)
• Eingangsbestätigung mit Hinweis auf Identitätsprüfung und Prüfung der betroffenen Systeme
• Rückfragevorlage zur Eingrenzung des Umfangs (z. B. „betrifft das Ihr Kundenkonto oder nur den Newsletter?“)
• Abschlussmitteilung mit:
• umgesetzten Maßnahmen (Löschung/Einschränkung/Abmeldung)
• verbleibenden Daten aufgrund rechtlicher Pflichten (mit Zweck)
• Hinweis auf eingeschränkten Zugriff und Zweckbindung
• Interne Checkfragen
• Wer ist die Person im System? Kunde, Interessent, Bewerber, Beschäftigter, Lieferant?
• Welche Systeme sind standardmäßig betroffen? CRM/ERP, Tickets, E-Mail, Files, Kollaboration, Marketingtools
• Gibt es aktive Vorgänge? Offene Rechnungen, offene Tickets, laufende Verfahren, Gewährleistungsfälle
• Welche Unterlagen könnten aufbewahrungspflichtig sein? Rechnung/Beleg, Vertrag, steuerrelevante Dokumente
• Gibt es einen Hold-Grund? Rechtsstreit, drohende Auseinandersetzung, Compliance-Fall
• Welche Maßnahme passt wirklich? Löschen, Einschränken, Anonymisieren, Abmelden/Opt-out
• Organisatorischer Beschleuniger
• ein zentrales Ticket- oder Formularsystem, das Löschanfragen strukturiert erfasst und automatisch
• Systeme zuordnet
• Zuständigkeiten verteilt
• Fristen überwacht
• Abschlussdokumentation erzeugt

nach oben

Häufige Fehler, die in Unternehmen immer wieder auftreten

Viele Löschkonzepte scheitern nicht an der DSGVO, sondern an typischen Mustern im Unternehmensalltag: Zeitdruck, Tool-Wildwuchs, unklare Zuständigkeiten und die Neigung, „zur Sicherheit“ zu viel zu speichern. Die folgenden Fehler tauchen in der Praxis regelmäßig auf und sind häufig der Grund, warum Löschroutinen bei Prüfungen, Betroffenenanfragen oder Sicherheitsvorfällen kritisch werden.

„Einheitsfristen“ ohne Zweckbezug

• Pauschale Fristenlogik
• ein Wert für alles („wir löschen nach 10 Jahren“) ohne Trennung nach Datenkategorien und Zwecken
• Folge: Löschung wird entweder zu spät umgesetzt oder kollidiert mit tatsächlichen Aufbewahrungspflichten
• Zwecke werden zu grob formuliert
• „Kundenverwaltung“ oder „Personal“ als Sammelbecken, obwohl unterschiedliche Prozesse dahinterstehen
• Ergebnis: Fristen orientieren sich am längsten möglichen Bedarf statt am typischen Zweckende
• Fehlende Trigger-Definition
• ohne klare Ereignisse (z. B. Vertragsende, Ticketabschluss) lässt sich eine Frist im System nicht sauber automatisieren
• häufig bleibt die Frist dann ein Text im Dokument statt eine umsetzbare Regel
• Praktische Gegenmaßnahme
• Zweck- und Datenkategorien trennen, Trigger festlegen, Fristen als Regelkette (operativ, Aufbewahrung, Löschung) definieren

Löschkonzept nur auf dem Papier: fehlende Implementierung in Systemen

• Kein technischer Anschluss
• Löschregeln sind dokumentiert, aber in CRM/ERP/Ticketsystem nie als Retention-Regel, Workflow oder Löschlauf umgesetzt
• Löschung passiert dann nur „bei Gelegenheit“ und ist nicht verlässlich
• Manuelle Prozesse ohne Ressourcen
• wenn Löschung allein auf manuelle Tätigkeiten setzt, wird sie bei Auslastung regelmäßig verdrängt
• typische Folge: Datenbestände wachsen, während das Löschkonzept formal „existiert“
• Technische Einschränkungen werden ignoriert
• Systeme erlauben nur logische Löschung oder benötigen Referenzen
• wenn das nicht berücksichtigt wird, entsteht ein Konzept, das in der Realität nicht ausführbar ist
• Praktische Gegenmaßnahme
• für jedes System konkret festlegen, wie die Maßnahme umgesetzt wird (Job, Setting, Workflow, Ticketprozess) und wie Fehler behandelt werden

Ignorierte Datenorte: E-Mail-Postfächer, Teams/Slack, lokale Laufwerke, Export-Dateien

• E-Mail-Postfächer als Schattenarchiv
• Anhänge, Vertragskopien, Ausweise, lange Korrespondenzen bleiben dauerhaft liegen
• Löschläufe in Fachsystemen greifen nicht, weil Datenkopien im Postfach weiterexistieren
• Kollaborationstools als Parallelwelt
• Teams/Slack-Chats, Kanaldateien, geteilte Links, Projektspaces wachsen unbemerkt
• besonders kritisch: externe Gäste, private Chats, Datei-Duplikate
• Lokale Laufwerke und Downloads
• Dateien werden lokal gespeichert, weitergegeben, in privaten Ordnern behalten
• zentrale Löschroutinen erreichen diese Datenorte oft nicht
• Export-Dateien und Excel-Listen
• häufigster „Löschkiller“: Daten werden aus dem System exportiert und entziehen sich jeder Retention-Logik
• Export-Dateien werden dann in Projektordnern, E-Mail-Anhängen oder Desktop-Ordnern dauerhaft konserviert
• Praktische Gegenmaßnahme
• Datenlandkarte konsequent erweitern um „Nebenablagen“, Exportregeln definieren, Kollaborationstools mit Lebenszyklen und Retention-Settings betreiben

Backups als Blindspot

• Unrealistische Erwartung an selektive Löschung
• Backups werden behandelt, als müsse man jeden Einzeldatensatz sofort herauslöschen können
• Ergebnis: entweder wird das Thema verdrängt oder es entstehen unrealistische Zusagen
• Keine Regel gegen Wiederaufleben
• Daten werden im Produktivsystem gelöscht, tauchen nach Restore-Prozessen aber wieder auf
• ohne definierte Nachlöschläufe wird Löschung dadurch faktisch unterlaufen
• Backups werden zu lange vorgehalten
• häufig ohne klare Begründung, ohne Zugriffsbeschränkung und ohne eigene Retention-Logik
• Backups entwickeln sich dann selbst zu einem umfangreichen Datenbestand
• Praktische Gegenmaßnahme
• Backups als eigene Kategorie mit Zweck, Zugriff, Aufbewahrungsdauer und Restore-Prozess definieren, plus Regel: nach Restore Löschlogik erneut anwenden

Unklare Verantwortlichkeiten und fehlende Eskalationswege

• „Zwischen IT und Fachbereich“ bleibt es liegen
• Fachbereich erwartet, dass IT löscht; IT erwartet, dass Fachbereich Trigger und Freigaben liefert
• Ergebnis: Löschung passiert nicht oder nur unkoordiniert
• Keine Entscheidung bei Zielkonflikten
• z. B. Vertrieb will Daten lange behalten, Datenschutz will reduzieren, IT sieht technische Grenzen
• ohne Eskalationsweg wird der Konflikt vertagt und Daten bleiben dauerhaft
• Sonderfälle ohne Owner
• Holds werden gesetzt, aber nicht überprüft
• Ausnahmen werden zum Standard, weil niemand den Abschluss organisiert
• Praktische Gegenmaßnahme
• Verantwortlichkeiten pro Datenkategorie/System festlegen, Eskalationsrolle definieren, Hold-Prozesse mit Review-Datum und Zuständigkeit ausstatten

nach oben

Best Practices: So wirkt ein Löschkonzept im Alltag

Ein gutes Löschkonzept erkennt man weniger an der Länge des Dokuments als an der Wirkung im Tagesgeschäft. Es sorgt dafür, dass Datenbestände kontrollierbar bleiben, Betroffenenanfragen nicht zur Krisenübung werden und Teams wissen, was sie tun sollen, ohne ständig Rückfragen zu stellen. Die folgenden Best Practices sind in der Praxis besonders wirksam, weil sie an den typischen Engpässen ansetzen: zu viele Daten, zu wenig Automatisierung, zu wenig Klarheit in den Fachbereichen und ein Konzept, das nach Systemwechseln nicht mehr zur Realität passt.

„Weniger Daten“ als Grundstrategie

• Datensparsamkeit als operative Leitlinie
• nur Daten erheben, die für den konkreten Zweck nachvollziehbar erforderlich sind
• Pflichtfelder und „Freitext aus Gewohnheit“ regelmäßig hinterfragen
• Datenlebenszyklus schon beim Prozessdesign
• bei neuen Prozessen gleich mitdenken: Was ist der Trigger für Abschluss? Was wird danach noch gebraucht?
• Statusmodelle nutzen: aktiv, abgeschlossen, aufbewahrungspflichtig, gesperrt, löschreif
• Reduktion statt Daueraufbewahrung
• nach Abschluss der operativen Phase Datenmenge verringern:
• Anhänge und Dubletten entfernen
• Kommunikationskopien reduzieren, wenn ein Nachweis genügt
• Identifikationsdaten von Auswertungsdaten trennen, um später eher anonymisieren zu können
• Single Source of Truth
• klar definieren, welches System führend ist (z. B. CRM statt Excel-Listen)
• Exporte begrenzen und für unvermeidbare Exporte klare Regeln festlegen (Speicherort, Zugriff, Frist)

Automatisierung dort, wo sie belastbar ist

• Automatisieren, was standardisiert ist
• wiederkehrende Fälle mit klaren Triggern und Fristen eignen sich für Retention-Regeln und Löschläufe
• typische Kandidaten:
• abgelehnte Angebote nach definierter Zeit
• erledigte Tickets nach Nachlaufphase
• Bewerbungen nach Abschluss des Verfahrens (mit sauber geregelten Ausnahmen)
• Technisch saubere Trigger-Felder
• ohne eindeutige Status- und Datumsfelder bleibt Automatisierung fragil
• gute Praxis: Trigger-Events werden als Systemstatus gepflegt, nicht in Freitext versteckt
• Fehlerhandling als Bestandteil der Automatisierung
• Löschläufe sollten nicht nur „laufen“, sondern auch
• Fehlerlisten erzeugen (z. B. wegen Referenzen)
• Verantwortliche informieren
• Nachbearbeitung ermöglichen
• Automatisierung nicht blind einsetzen
• bei komplexen Mischakten, Freitextlast oder Sonderfällen ist ein kontrollierter Einzelfallprozess oft stabiler
• gute Praxis ist ein zweistufiges Modell: automatisierter Standard plus Einzelfall-Queue für Ausnahmen

Schulung und Verantwortungsbewusstsein in Fachbereichen

• Fachbereiche sind Datenproduzenten
• viele Löschprobleme entstehen nicht in der IT, sondern durch Ablagegewohnheiten, Exporte und Kommunikationskultur
• deshalb wirkt Schulung dann gut, wenn sie konkrete Alltagsfälle adressiert, nicht abstrakte DSGVO-Sätze
• Praxisnahe Inhalte
• wie man Kundenunterlagen richtig ablegt (System statt Postfach)
• wann Exporte zulässig sind und wie sie zeitlich begrenzt werden
• wie „Holds“ funktionieren und wer sie freigibt bzw. beendet
• wie man sensible Daten in Chats, Tickets und Projekträumen behandelt
• Klare Rollen statt „Jeder irgendwie“
• Verantwortliche pro Prozess benennen (Owner), die Trigger-Qualität und Datenhygiene im Blick haben
• Eskalationsweg kommunizieren: Wohin bei Unsicherheiten? Wer entscheidet bei Konflikten?
• Nudges im Alltag
• kurze Checklisten, Standardtexte, Tool-Hinweise und Vorlagen
• Ziel: richtige Entscheidungen erleichtern, statt nur Regeln aufzustellen

Regelmäßige Aktualisierung bei Prozess- und Systemänderungen

• Löschkonzept als Change-Management-Thema
• jedes neue Tool, jede Migration, jede Prozessänderung kann Löschlogiken brechen
• gute Praxis: „Privacy-Löschcheck“ als Bestandteil von
• Tool-Einführung
• Prozess-Redesign
• Providerwechsel
• Einführung neuer Datenkategorien
• Review-Rhythmus
• regelmäßige, schlanke Reviews sind oft wirksamer als seltene Großprojekte
• besonders sinnvoll nach:
• organisatorischen Veränderungen
• neuen Schnittstellen und Integrationen
• auffälligen Befunden aus Stichproben oder Betroffenenanfragen
• Kontrollpunkte, die sich bewähren
• stimmen Trigger-Felder und Statusmodelle noch?
• sind Retention-Einstellungen im Tool noch passend oder wurden sie „nebenbei“ verändert?
• sind neue Datenorte entstanden (neue Teams, neue Projektspaces, neue Exporte)?
• Verbesserungslogik statt Schuldlogik
• wenn Löschung nicht funktioniert, ist die Kernfrage: Was muss im Prozess oder Tool angepasst werden?
• Ziel ist ein System, das Fehler sichtbar macht und Korrekturen ermöglicht

nach oben

Kompakte Checkliste: Was Sie für ein tragfähiges Löschkonzept typischerweise benötigen

Diese Checkliste ist so aufgebaut, dass Sie damit relativ schnell erkennen können, ob Ihr Löschkonzept eher „gut gemeint“ ist oder ob es als steuerbares System funktioniert. Entscheidend ist weniger, dass jeder Punkt maximal ausformuliert ist. Entscheidend ist, dass Sie für die wichtigsten Datenkategorien und Systeme klare Regeln, klare Zuständigkeiten und eine umsetzbare Routine haben.

Inventar der Daten und Systeme

• Datenkategorien definiert
• Kunden, Interessenten, Beschäftigte, Lieferanten, Bewerber
• je Kategorie: typische Datenarten (Stammdaten, Vertragsdaten, Kommunikation, Nachweise, Logs)
• System- und Speicherortliste vollständig
• ERP/CRM, Ticketsystem, E-Mail, Fileserver, Cloudspeicher/Kollaboration, Papierakten, Messenger
• inklusive „Nebenablagen“: Exporte, lokale Laufwerke, Projektordner, Testumgebungen
• Datenflüsse und Schnittstellen erfasst
• welche Systeme synchronisieren Daten?
• wo entstehen Kopien (Export, Reporting, Supportfälle)?
• Verantwortliche pro System benannt
• System-Owner (fachlich) und technischer Owner (IT) mit klarer Zuständigkeit

Fristenlogik und Trigger-Ereignisse

• Zwecke getrennt und praxistauglich formuliert
• nicht zu grob („Kundenverwaltung“), sondern lebenszyklusorientiert (Vertrag, Support, Marketing etc.)
• Trigger-Ereignisse pro Datenkategorie definiert
• Vertragsende, Ticketabschluss, Projektende, Widerruf, Widerspruch, Abschluss Bewerbungsverfahren
• Trigger sind systemseitig erkennbar (Status/Feld/Datum), nicht nur „in Köpfen“
• Fristen je Kategorie festgelegt
• operative Phase, ggf. Aufbewahrungsphase, danach Löschung oder Anonymisierung
• Sonderfälle (Hold) mit Review-Datum und Zuständigkeit
• Maßnahmen klar zugeordnet
• für jede Frist: Löschen, Einschränken, Archivieren, Anonymisieren
• je System konkret beschrieben, wie die Maßnahme umgesetzt wird

Dokumentations- und Prüfkonzept

• Löschmatrix vorhanden
• Datenkategorie → System → Trigger → Frist → Maßnahme → Verantwortlicher
• Prozessbeschreibung für Standard und Sonderfälle
• regelmäßige Löschläufe vs. Einzelfallbearbeitung (Betroffenenanfragen, Holds)
• Freigabe- und Eskalationswege bei Konflikten
• Löschprotokoll-Logik definiert
• was wird protokolliert (möglichst datensparsam)?
• wer hat Zugriff?
• wie lange werden Protokolle aufbewahrt?
• Qualitätssicherung geplant
• Stichproben, Kontrollen, Fehlerlisten, Verbesserungszyklen
• definierte Review-Termine, insbesondere bei Tool- und Prozessänderungen

Dienstleister-Regelungen

• Rollenmodell geklärt
• Auftragsverarbeitung vs. gemeinsame Verantwortlichkeit vs. eigenständige Verantwortlichkeit
• intern festgelegt, wer welche Teile bei Betroffenenanfragen übernimmt
• Lösch- und Rückgabepflichten vertraglich geregelt
• Löschung auf Weisung, bei Projektende, bei Vertragsende
• Umgang mit Unterauftragnehmern
• Offboarding- und Providerwechselprozesse
• Nachweise praktikabel definiert
• Löschbestätigungen, Ticketnachweise, Offboarding-Protokolle
• Umgang mit technischen Randbedingungen (z. B. Backup-Überschreibung) nachvollziehbar geregelt
• Kontrollumfang risikobasiert
• kritischere Systeme erhalten engere Kontrollen und Nachweisketten

Maßnahmenplan für die technische Umsetzung

• Priorisierung
  • zuerst die Systeme mit hohem Datenvolumen, hoher Sensibilität oder hohem Export-/Kopier-Risiko
• Technische Umsetzung je System geplant
  • Retention-Settings, Workflows, Löschjobs, Sperr-/Archivstatus, Berechtigungskopplung
  • Fehlerhandling und Monitoring (was passiert bei Löschhindernissen?)
• Nebenablagen adressiert
  • Regeln und technische Hilfen für E-Mail, Kollaborationstools, Exporte, lokale Speicher
  • klare Vorgaben zur Ablage in führenden Systemen statt in Postfächern
• Backup- und Restore-Prozess abgestimmt
  • Aufbewahrungsdauer, Zugriff, Restore-Freigabe, Nachlöschläufe nach Wiederherstellung
• Schulung und Kommunikation vorgesehen
  • fachbereichsspezifische Kurzanleitungen, Standardprozesse, Eskalationskontakte

nach oben