Aufbewahrung und Loeschung: Praxisleitfaden fuer SaaS-Teams

Aufbewahrung und Loeschung funktionieren am besten, wenn SaaS-Teams Policy-Sprache in operative Regeln fuer echte Systeme uebersetzen. Das praktische Ziel ist zu wissen, welche personenbezogenen Daten existieren, warum sie noch gebraucht werden, welches Ereignis die Aufbewahrungsfrist startet, wer die Aktion besitzt, wie Loeschung oder Anonymisierung geschieht, welche Ausnahmen gelten und welcher Nachweis die Umsetzung belegt.

Unter der DSGVO sollten personenbezogene Daten nicht laenger identifizierbar gespeichert werden, als es fuer die Zwecke der Verarbeitung notwendig ist. Fuer SaaS bedeutet das: Produktionsdatenbanken, Support-Tools, Billing, Analytics, Logs, Backups, Data Warehouses, Exporte und Vendoren muessen in denselben operativen Plan passen.

Warum das praktisch wichtig ist

Eine Policy, die "Kundendaten nach Vertragsende loeschen" sagt, beantwortet nicht, welche Systeme betroffen sind, ob ein Account nur deaktiviert wurde, ob Analytics Events identifizierbar bleiben, ob Support-Tickets Anhaenge enthalten oder ob ein Vendor noch Kopien haelt.

Zu lange Aufbewahrung erhoeht das Risiko bei Breaches, vergroessert den Suchumfang bei Auskunftsersuchen, erschwert Migrationen und Vendor Exits und schwacht Data Minimisation. Unkontrollierte Loeschung kann umgekehrt Daten entfernen, die fuer Steuern, Betrugsvermeidung, Vertragserfuellung, Security Investigations oder Legal Claims benoetigt werden.

Wann Aufbewahrung und Loeschung gilt

Das Thema gilt, sobald ein SaaS-Team personenbezogene Daten in Produkt, operativem System, internem Tool, Vendor-Plattform, Archiv, Log, File Store oder Backup speichert. Es betrifft Kundendaten, Nutzerkonten, Supportinhalte, Billing Records, Telemetrie, Security Logs, Marketing Leads, Bewerber, Mitarbeitende, Contractor, Vendor-Kontakte und Compliance-Nachweise.

Die Europaeische Kommission erklaert, dass Daten so kurz wie moeglich gespeichert werden sollten, unter Beruecksichtigung der Verarbeitungsgruende und gesetzlicher Aufbewahrungspflichten. Organisationen sollten Fristen fuer Loeschung oder Review festlegen.

Regeln um Ereignisse bauen

Aufbewahrungsplaene scheitern, wenn sie nur Datentypen und Zeitraeume nennen. SaaS-Systeme brauchen Trigger.

Definieren Sie fuer jede Datenkategorie den betroffenen Record, die Systeme und Vendoren, das Ereignis, das die Frist startet, die Standardfrist, die Loesch-, Anonymisierungs-, Archivierungs- oder Restriktionsaktion, den Owner, den Ausnahmeprozess, den erforderlichen Nachweis und das Review-Intervall.

Trigger sind oft der schwierigste Teil. Startet die Frist bei Account-Loeschung, Vertragsende, finaler Zahlung, Ticket-Schluss, Bewerberabsage, Lead-Unsubscribe oder Abschluss eines Security Incidents? Verschiedene Antworten koennen berechtigt sein, muessen aber explizit sein.

Regeln auf Systeme mappen

Die meisten Retention-Probleme sind Mapping-Probleme. Dieselben Daten koennen in App-Datenbank, Auth Provider, CRM, Billing, Support Tool, Analytics, Data Warehouse, Cloud Storage, Exporten, Spreadsheets, Logs, Backups und Vendor-Umgebungen liegen.

Beginnen Sie mit Kundendaten, Nutzerprofilen, Support-Tickets, Billing, Product Analytics, Security Logs, Marketingdaten, HR-Daten und Vendor- oder Compliance-Nachweisen. Die Regel ist erst operativ, wenn das Team weiss, wo die Daten liegen.

Entscheiden, was Loeschung bedeutet

Loeschung ist nicht immer eine einzelne technische Aktion. Je nach System kann das Ergebnis Hard Delete, Soft Delete plus Purge, Anonymisierung, Pseudonymisierung, Archivbeschraenkung, Suppression oder Backup Expiry sein.

Backups brauchen besondere Klarheit. Wenn ein gueltiges Loeschersuchen gilt, muessen Schritte auch fuer Backups definiert sein. Gleichzeitig kann es technisch sein, dass Daten bis zum Ueberschreiben im Backup verbleiben, sofern sie ausser Nutzung gesetzt und nicht fuer andere Zwecke wiederhergestellt werden.

Versprechen Sie daher nicht sofortige Loeschung aus jedem Backup, wenn Backups einem Rotationsplan folgen. Beschreiben Sie, was in Live-Systemen passiert, was mit Backups geschieht und wie lange Backup Expiry typischerweise dauert.

Erasure Requests getrennt behandeln

Routine-Aufbewahrung und das Recht auf Loeschung ueberschneiden sich, sind aber nicht derselbe Workflow. Routine laeuft ueber Fristen und Business Events. Ein Loeschersuchen startet durch eine Person. Artikel 17 DSGVO greift in bestimmten Situationen, etwa wenn Daten nicht mehr noetig sind, Einwilligung widerrufen wird, Verarbeitung unrechtmaessig ist oder Loeschung gesetzlich vorgeschrieben ist. Das Recht ist nicht absolut.

Ein SaaS-Team braucht einen Triage-Prozess: Request erkennen, Frist erfassen, Identitaet pruefen, Systeme und Vendoren finden, Daten loeschen, aufbewahren oder einschraenken, Gruende fuer teilweise Ablehnung dokumentieren, Ausfuehrung nachweisen und bei Bedarf Empfaenger informieren.

Ausnahmen vor der Deadline definieren

Typische Ausnahmen sind Steuer- und Buchhaltungspflichten, Vertragsabwicklung, Fraud Prevention, Security Monitoring, Incident Response, Legal Holds, Disputes, Audit Evidence und gesetzliche Reportingpflichten. Wichtig ist, wer die Ausnahme genehmigt, welche Daten sie umfasst, warum sie gilt, wann sie ueberprueft wird und was nach ihrem Ende passiert.

Vendoren einbeziehen

SaaS-Daten leben selten nur im Produkt. Vendoren und Processor koennen Supportinhalte, Billing, Analytics Events, Kundennachrichten, Logs, Backups und Compliance Records halten. Retention und Loeschung sollten deshalb Teil von Vendor Onboarding und Processor Management sein.

Fragen Sie vor Freigabe eines Vendors, wie Retention funktioniert, wie Loeschung angefragt wird, ob Backups separat laufen, ob Exporte entstehen, welche Subprocessor speichern koennen und welche Nachweise der Vendor liefern kann.

FAQ

Was sollten Teams verstehen?

Aufbewahrung und Loeschung ist ein Live-Workflow. Er verbindet Dateninventar, System Ownership, Trigger, rechtliche Ausnahmen, Backup-Verhalten, Vendor-Loeschung, Erasure Requests und Nachweise.

Warum ist es praktisch wichtig?

SaaS-Unternehmen speichern personenbezogene Daten ueber viele Systeme. Ohne Arbeitsmodell werden Daten zu lange gehalten, inkonsistent geloescht oder in Einzelfallentscheidungen behandelt, die spaeter schwer beweisbar sind.

Was sollte zuerst dokumentiert werden?

Starten Sie mit Kundendaten, Supportdaten, Billing Records, Analytics Events, Security Logs und Vendor-Daten. Definieren Sie Trigger, Owner, Systemorte, Aktion, Ausnahmeprozess und Nachweis.

Sources

• European Union, General Data Protection Regulation.
• European Commission, For how long can data be kept and is it necessary to update it?
• European Commission, Do we always have to delete personal data if a person asks?
• Information Commissioner's Office, Principle (e): Storage limitation.
• Information Commissioner's Office, Right to erasure.