Haeufige Aufbewahrungs- und Loeschfehler, die SaaS-Teams noch machen

Aufbewahrungs- und Loeschfehler entstehen meistens, wenn ein SaaS-Unternehmen das Thema nur als Policy-Frage behandelt. Unter der DSGVO duerfen personenbezogene Daten nicht laenger gespeichert werden, als der Zweck es rechtfertigt. Unternehmen sollten Fristen fuer Loeschung oder Review festlegen, und das Recht auf Loeschung kann eine konkrete Aktion ausloesen. Operativ schwer ist nicht der Satz in der Policy, sondern der Nachweis in Systemen, Tickets, Vendor-Workflows, Backups und Reviews.

Die wiederkehrenden Fehler sind klar: unklare Trigger, Regeln ohne Systemkarte, informelle Ausnahmen, unrealistische Backup-Versprechen und schwache Nachweise. Teams vermeiden viel Risiko, wenn sie einen kleinen, wiederholbaren Workflow mit Ownern, Entscheidungspunkten und Evidenz bauen.

Warum das in guten Teams trotzdem scheitert

Auf Papier klingt Aufbewahrung einfach. Kundendaten bleiben fuer eine definierte Zeit. Support Records werden nach einer Frist geloescht. Bewerberdaten laufen nach dem Hiring-Prozess ab. Backups rotieren separat.

In der Praxis liegen dieselben Daten oft in Produktdatenbank, Warehouse, Support Desk, CRM, Logs, Analytics, Billing, Exports, Shared Drives und Backup-Umgebungen. Wenn diese Realitaet nicht abgebildet ist, wird Loeschung nur teilweise umgesetzt. Ein Account verschwindet aus der App, aber Events, Anhaenge oder Exporte bleiben bestehen.

Fehler 1: Policy ohne Systemkarte

Eine Retention Schedule reicht nicht. Sie muss an reale Systeme gebunden sein: wo Daten entstehen, wohin sie kopiert werden, welcher Vendor sie verarbeitet, welche Aktion technisch moeglich ist und welcher Nachweis bleibt. Beginnen Sie mit Customer Closure, Erasure Requests, Support Tickets, Employee Records, Vendor Offboarding sowie Analytics und Logs.

Fehler 2: Dauer ohne Trigger

Viele Teams wissen, wie lange Daten bleiben sollen, aber nicht, wann die Frist startet. Beginnt sie bei Kuendigung, finaler Rechnung, Account-Deaktivierung oder Ende aller Vertragspflichten? Ohne Trigger berechnen Teams unterschiedliche Daten. Schreiben Sie Trigger als Ereignis: "Vertrag beendet und Billing Disputes geschlossen" ist besser als "nach Churn".

Fehler 3: Loeschung nur Engineering zuordnen

Engineering fuehrt oft die technische Aktion aus, aber Legal, Privacy, Security, Support, Finance, Product und Procurement haben ebenfalls Rollen. Wenn alles als "Engineering loescht das" formuliert ist, fehlen Ausnahmepruefung, Eskalation und Nachweis. Definieren Sie, wer Regel, Trigger, Ausnahme, Ausfuehrung, Evidenz und Review besitzt.

Fehler 4: Datenminimierung zu spaet pruefen

Loeschung wird schwerer, wenn vorher zu viel gesammelt wurde. Onboarding Forms, Product Analytics, Support Attachments, Integrationen und Freitextfelder verbreiten personenbezogene Daten schnell. Jede neue Funktion sollte fragen, ob die Daten noetig sind, ob aggregierte oder anonyme Daten reichen, wohin Kopien gehen und welche Retention Rule ab Launch gilt.

Fehler 5: Backups unrealistisch versprechen

Live-Systeme koennen oft schneller geloescht werden als Backups. Manche Backups laufen ueber Rotation, sind immutable oder koennen nicht pro Datensatz bereinigt werden. Das ist kein Freibrief, aber die Aussagen muessen stimmen: Live-Loeschung, Anonymisierung, Backup-Ablauf, Restore Controls und Legal Holds sollten getrennt beschrieben werden. Der EDPB hat 2026 gerade Backup-Loeschung und Retention Periods als praktische Herausforderungen benannt.

Fehler 6: jede Loeschanfrage gleich behandeln

Das Recht auf Loeschung ist wichtig, aber nicht absolut. Gesetzliche Pflichten, Public Interest und Legal Claims koennen Ausnahmen rechtfertigen. Teams sollten deshalb einen Entscheidungsbaum nutzen: Identitaet und Scope bestaetigen, Systeme und Vendors finden, Loeschgrund pruefen, Ausnahme pruefen, Aktion ausfuehren und Abschluss oder rechtliche Grenze dokumentieren.

Fehler 7: Evidenz verlieren

Viele Teams erledigen die Arbeit, koennen sie aber spaeter nicht belegen. Ein Script laeuft, ein Vendor antwortet, ein Ticket wird geschlossen. Der Nachweis liegt verteilt in Slack, Logs und E-Mails. Audit-ready ist das erst, wenn Regel, Trigger, Entscheidung, Owner, Aktion und Datum zusammenhaengen.

Fehler 8: Produktveraenderungen nicht einbeziehen

Neue Integrationen, Analytics Tables, AI Debug Logs, Support Screenshots oder Billing-Migrationen koennen Retention veraendern. High-risk Launches sollten deshalb vor Go-live klaeren, welche personenbezogenen Daten entstehen, wo sie landen, wer sie loescht und welcher Nachweis bleibt.

Praktische Kontrollfragen

• Ist jede Regel mit Systemen und Vendors verbunden?
• Ist der Trigger ein klares Ereignis?
• Gibt es Owner fuer Entscheidung, Ausfuehrung und Evidenz?
• Sind Backups, Archive und Exporte separat behandelt?
• Sind Ausnahmen und Legal Holds dokumentiert?
• Stimmen Kundenversprechen mit technischer Realitaet ueberein?

Wenn mehrere Antworten nein sind, starten Sie mit einem Workflow wie Customer Account Closure, Erasure Request oder Support Ticket Retention. Ein kleiner funktionierender Prozess ist besser als eine grosse Policy, die niemand ausfuehren kann.