Wie man Aufbewahrung und Loeschung operativ umsetzt, ohne Produktlieferung zu bremsen

Aufbewahrung und Loeschung funktionieren, wenn SaaS-Teams rechtliche Absicht in normale Delivery-Gewohnheiten uebersetzen. Das Ziel ist nicht, bei jeder Account-Loeschung, jedem Support-Ticket, jedem Log oder jedem Erasure Request neu zu diskutieren. Das Ziel ist zu wissen, welche Daten existieren, warum sie noch gebraucht werden, welches Ereignis die Frist startet, wer Ausnahmen entscheidet, wie die Aktion passiert und welcher Nachweis die Umsetzung belegt.

Unter der DSGVO sollen personenbezogene Daten nicht laenger identifizierbar gespeichert werden, als es fuer die Verarbeitungszwecke notwendig ist. Die Europaeische Kommission erklaert ausserdem, dass Daten so kurz wie moeglich gespeichert werden sollen und dass Organisationen Fristen fuer Loeschung oder Review festlegen sollten.

In SaaS-Produkten wird das schnell operativ: Daten liegen in Produktdatenbanken, Billing, Support-Anhaengen, Analytics Events, Security Logs, Backups, Warehouses, Exporten und Processor-Systemen. Operationalisierung bedeutet, einen Workflow zu bauen, der Produktlieferung erlaubt und trotzdem Retention-Entscheidungen sichtbar, begruendet, ausfuehrbar und pruefbar macht.

Mit Delivery-Momenten starten

Retention sollte nicht erst als spaeter Legal Check auftauchen. Definieren Sie die Momente, in denen Retention- oder Loeschentscheidungen entstehen: ein Feature sammelt neue Daten, Daten wandern in Warehouse oder Vendor Tool, ein Kunde kuendigt, ein User verlangt Loeschung, ein Ticket schliesst, ein Security Incident endet oder ein Vertrag aendert sich.

Diese Ereignisse sind fuer Product, Engineering, Support, Finance, Security und Legal erkennbar. Wenn eine Roadmap einen neuen Export enthaelt, fragt das Team, wie lange der Export bleibt. Wenn Support Screenshots speichert, fragt es, wann Anhaenge geloescht werden. So bleibt Retention nahe an Privacy Impact Reviews in der Produktplanung.

Einen kurzen Intake verwenden

Der Intake sollte genug Fakten liefern, um die Entscheidung richtig zu routen. Fragen Sie, welche personenbezogenen Daten erstellt, kopiert, gespeichert, geloggt, exportiert oder offengelegt werden; welche Personen betroffen sind; welche Systeme und Vendoren die Daten halten; welches Ereignis die Frist startet; welcher Zweck weitere Aufbewahrung rechtfertigt; ob Gesetz, Vertrag, Audit, Security oder Legal Claim weitere Retention verlangt; welches Ergebnis erwartet wird; und wer Regel, Ausfuehrung und Ausnahmen besitzt.

Dieser Intake gehoert in Product Requirements, Vendor Intake, Architekturreview, Support Operations, Customer Offboarding und Warehouse Changes. Er soll keine Privacy-Anwaelte aus allen Teams machen, sondern versteckte Retention-Entscheidungen sichtbar machen.

Routine-Retention und Erasure Requests trennen

Routine-Retention laeuft aus geplanten Ereignissen: Vertrag beendet, Ticket geschlossen, Log gealtert, Lead inaktiv, Backup rotiert. Die Organisation definiert die Regel vorher und fuehrt sie konsistent aus.

Ein Erasure Request beginnt, weil eine Person Loeschung verlangt. DSGVO Artikel 17 gibt dieses Recht in bestimmten Situationen, etwa wenn Daten fuer den Zweck nicht mehr notwendig sind, Consent zurueckgezogen wurde und keine andere Grundlage greift oder Verarbeitung rechtswidrig ist. Das Recht ist nicht absolut. Ausnahmen koennen rechtliche Pflichten, oeffentliches Interesse oder Rechtsansprueche betreffen.

SaaS-Teams brauchen daher einen eigenen Pfad: Request und Frist loggen, Requester verifizieren, Account-, Workspace-, System-, Vendor- und Backup-Scope klaeren, ueber Loeschung, Aufbewahrung, Restriction oder Ausschluss entscheiden, Teilablehnungen dokumentieren, Aktionen ausfuehren und Nachweise speichern. Dieser Pfad sollte mit DSAR Operations verbunden sein.

Regeln in Systemaktionen uebersetzen

Ein Retention Schedule ist erst operativ, wenn er beschreibt, was in Systemen passiert. Priorisieren Sie Produktdatenbanken, Auth-Tools, Support-Plattformen, Billing, Analytics, Security Logs, Warehouses, CRM, HR-Systeme und Processor.

"Account-Daten loeschen" kann bedeuten: Login sofort deaktivieren, Workspace-Inhalte nach Wartezeit entfernen, Product Events anonymisieren, Anhaenge abtrennen, Suchindizes purgen, Rechnungen wegen gesetzlicher Pflichten behalten und verschluesselte Backups im normalen Zyklus auslaufen lassen.

Dieselben Daten brauchen in verschiedenen Systemen verschiedene Aktionen. Billing Records bleiben vielleicht wegen Steuern. Telemetrie wird anonymisiert. Support-Tickets bleiben fuer Disputes, aber Anhaenge werden frueher geloescht. Security Logs haben eine definierte Frist fuer Monitoring und Investigations.

Proportionale Reviews nutzen

Nicht jede Aenderung braucht dieselbe Prueftiefe. Low-risk Aenderungen mit begrenzten Business-Kontaktdaten oder kurzlebigen Logs brauchen oft nur Standardregel, Owner und Evidence Location. Medium-risk Aenderungen mit Customer Account Data, Support-Inhalten, Analytics oder Vendor-Daten brauchen Mapping, Trigger, Actions, Exceptions und Vendor-Bestaetigung. High-risk Aenderungen mit Customer Content, sensiblen Daten, AI Processing, grossen Exporten, ungewoehnlichen Fristen oder vertraglichen Loeschversprechen brauchen cross-funktionale Review vor Launch.

Ausnahmen vorab definieren

Loeschung darf legitime Gruende nicht ignorieren, aber "just in case" darf keine Daueraufbewahrung werden. Typische Ausnahmen sind Steuern, Accounting, Payroll, Vertragserfuellung, Fraud Prevention, Security Monitoring, Incident Response, Legal Holds, Disputes, Versicherungen, Audit Evidence und regulatorische Reports.

Jede Ausnahme braucht Datenumfang, Grund, Approver, Startdatum, Review-Datum, Restriction und Endprozess. Ohne diesen Record behalten Teams zu viel fuer immer oder loeschen Daten, die eine dokumentierte Funktion noch braucht.

Vendoren einbeziehen

Retention und Loeschung muessen Processor einschliessen. Fragen Sie, welche Daten der Vendor erhaelt, ob er speichert, transformiert, loggt oder an Subprocessor weitergibt, wie Fristen konfiguriert werden, wie Loeschung ausgeloest wird, wie Backups behandelt werden und welche Evidence der Vendor liefern kann.

Das gehoert zu Processor Management. Ein Vendor ist nicht wirklich freigegeben, wenn niemand erklaeren kann, wie Daten die Vendor-Umgebung verlassen, wenn der Zweck endet oder ein gueltiger Erasure Request greift.

Evidence beim Ablauf erfassen

Nachweise sollten waehrend der Ausfuehrung entstehen: Retention-Regel, Data Inventory, Review Ticket, Loesch- oder Anonymisierungslog, Offboarding Record, Vendor Confirmation, Backup Policy, Legal Hold Release, Exception Approval und periodische Rule Review.

Die Evidence muss vier Fragen beantworten: welche Regel galt, welche Aktion passierte, wer genehmigte sie und wann war sie erledigt. So wird compliant delivery einfacher, weil Teams das Thema nicht erst bei Launch, Renewal, Audit oder Customer Review neu zusammensuchen.

FAQ

Was ist der praktische Zweck von Aufbewahrung und Loeschung?

Der Zweck ist sicherzustellen, dass personenbezogene Daten nur mit berechtigtem Zweck oder Pflicht gehalten werden und danach nach dokumentiertem Workflow geloescht, anonymisiert, eingeschraenkt oder auslaufen gelassen werden.

Wann gilt das fuer SaaS-Teams?

Immer wenn personenbezogene Daten in Produkten, operativen Systemen, internen Tools, Vendor-Plattformen, Logs, Archiven, Exporten, Warehouses oder Backups liegen.

Was sollten Teams zuerst dokumentieren?

Starten Sie mit Customer Offboarding, Account-Loeschung, Support-Tickets, Billing Records, Product Analytics, Security Logs, Backups und Vendor-Daten. Definieren Sie Trigger, Owner, Aktion, Ausnahmeprozess und Evidence.

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.