Datenaufbewahrungsrichtlinie: Weniger Daten speichern, Risiko reduzieren

Warum weniger Daten speichern das Risiko senkt

Zusätzliche Daten zu behalten wirkt harmlos. Sie liegen ruhig in einer Datenbank, einer Tabelle oder einem Postfach. Aber jedes gespeicherte Datum ist etwas, das später durchsickern, verloren gehen oder missbraucht werden kann. Weniger zu speichern ist eine der einfachsten Möglichkeiten, Datenschutzrisiken und tägliche Sicherheitsarbeit zu reduzieren.

Mehr Daten erhöhen das Risiko, weil sie mehr Orte zum Schützen schaffen und mehr Möglichkeiten für Fehler bieten. Sie verursachen auch Kosten: mehr Speicher und Backups, mehr Zugriffskontrollen, mehr Aufwand bei Löschanfragen und mehr Zeit für Incident-Untersuchungen.

Teams behalten oft Informationen ohne klaren Grund, etwa alte Support-Tickets mit vollständigen Verläufen, dauerhaft gespeicherte Logs, Kopien von Ausweisen und Screenshots, exportierte CSVs auf Laptops oder geteilten Laufwerken und Testdatenbanken mit realen Kundendaten.

Eine praktische Denkweise ist: "wer es wissen muss" und "was man aufbewahren muss." "Wer es wissen muss" bedeutet, dass nur die Personen und Systeme, die für eine Aufgabe erforderlich sind, Zugriff haben. "Was man aufbewahren muss" bedeutet, dass Sie nur sammeln und speichern, was nötig ist, um den Service zu liefern, gesetzliche Pflichten zu erfüllen oder Betrug zu verhindern — der Rest wird gelöscht.

Genau hier verdient eine Datenaufbewahrungsrichtlinie ihren Platz. Sie erzwingt klare Antworten: Wofür ist diese Daten? Wer nutzt sie? Was passiert, wenn sie durchsickert? Und wann können wir sie sicher löschen?

„Für immer“ ist keine neutrale Wahl. Wenn etwas schiefgeht, kann „für immer“ Jahre der Exposition bedeuten. Ein einziger Vorfall kann alte Konten, verwaiste Features, veraltete Logs und vergessene Exporte umfassen. Zudem müssen Sie möglicherweise Jahre später erklären, warum Sie Daten aufbewahrt haben, die Sie nicht brauchten.

Ein typisches Beispiel ist Debug-Logging. Schnell gebaute Apps (einschließlich KI-generierter Prototypen) protokollieren oft versehentlich sensible Details: Tokens zum Zurücksetzen von Passwörtern, vollständige API-Antworten oder Secrets im Klartext. Wenn diese Logs unbegrenzt gespeichert werden, kann ein Fehler zu einem langwierigen, teuren Vorfall werden. Kürzere Aufbewahrungsfristen verringern den möglichen Schaden.

Ermitteln, was Sie sammeln und wo es landet

Bevor Sie weniger speichern können, brauchen Sie ein einfaches Inventar der heute vorhandenen Daten. Die meisten Teams überspringen diesen Schritt und schreiben gleich Regeln — nur um später Überraschungskopien in Exporten, E-Mail-Threads und alten Backups zu entdecken.

Beginnen Sie damit, die Datentypen aufzuzählen, mit realen Beispielen aus dem Tagesgeschäft:

• Kundendaten (Kontodaten, Zahlungsinfos, Support-Tickets)
• Mitarbeiterdaten (Lohnabrechnung, Leistungsbeurteilungen, Geräte-Records)
• Lieferantendaten (Verträge, Rechnungen, Kontaktlisten)
• Produktdaten (Nutzungsereignisse, Fehlerberichte, Feature-Flags)
• Sensible Inhalte (Passwörter, Ausweisdokumente, Gesundheits- oder Finanzdaten)

Schreiben Sie als Nächstes auf, wo jeder Typ herkommt: Anmelde- und Checkout-Formulare, Support-E-Mails, Server-Logs, Dateiuploads und Drittanbieter-Tools (Zahlungen, Analytics, E-Mail, CRM). Sammelstellen sind oft der Ort, an dem versehentlich zu viel gesammelt wird.

Verfolgen Sie dann, wo diese Daten heute liegen — nicht, wo Sie glauben, dass sie liegen. Nehmen Sie offensichtliche Systeme auf (App-DB, Data Warehouse, Ticketing-Tool) und informelle Orte (geteilte Tabellen, Chatnachrichten, persönliche Postfächer).

Markieren Sie schließlich die „versteckten“ Speicher, die die Aufbewahrungsdauer still verlängern:

• Backups und Snapshots
• Analytics-Exporte oder rohe Event-Dumps
• Logging-Tools, die Request-Payloads speichern
• E-Mail-Anhänge, die im Team weitergeleitet werden
• Staging-/Dev-Datenbanken, die von der Produktion kopiert wurden

Ein kurzes Beispiel: Ein kleines SaaS fragt bei der Anmeldung nach „Unternehmensgröße“, aber der Support bittet um Screenshots, die Namen enthalten, und Error-Logs erfassen vollständige Requests mit Tokens. Das Team denkt, es speichere nur Basisprofile — tatsächlich liegen Kundendaten in Logs, Postfächern und Backup-Archiven.

Wenn Sie eine KI-generierte App übernommen haben, ist dieser Mapping-Schritt noch wichtiger. Häufig finden sich Auth-Tokens, Secrets oder komplette Benutzerobjekte versehentlich in Logs oder Analytics. Eine einfache Karte gibt Ihnen eine Ziel-Liste: was Sie nicht mehr sammeln sollten, wo Aufbewahrungsfristen verkürzt werden müssen und was sicher gelöscht werden muss.

Entscheiden, was Sie wirklich sammeln müssen

Eine gute Datenaufbewahrungsrichtlinie beginnt früher als bei der Aufbewahrung — sie beginnt bei der Erhebung. Wenn Sie ein Datum nie sammeln, müssen Sie es weder sichern noch löschen noch erklären, warum Sie es hatten.

Nutzen Sie einen einfachen Test: Hilft diese Information, den Service zu liefern, eine rechtliche Pflicht zu erfüllen oder Betrug zu verhindern? Wenn die ehrliche Antwort „könnte irgendwann nützlich sein“ lautet, behandeln Sie sie als optional, bis Sie das Gegenteil belegen können.

„Erforderlich“ von „nice to have“ trennen

Die meisten Teams sammeln zusätzliche Felder, weil ein Formular Platz hatte, eine Vorlage es vorschlug oder jemand es einmal angefragt hat. So füllen sich Datenbanken stillschweigend mit sensiblen Details.

Stellen Sie für jedes Feld die Frage: Was geht kaputt, wenn wir es entfernen? Wenn nichts passiert, ist es „nice to have“. Wenn das Produkt ohne das Feld nicht funktionieren kann (z. B. kann kein Konto ohne E-Mail erstellt werden), ist es „erforderlich“.

Praktisches Vorgehen:

• Kennzeichnen Sie jedes Feld als Erforderlich, Optional oder Nicht mehr sammeln
• Setzen Sie neue Felder standardmäßig auf Optional und machen sie nur bei echtem Mehrwert verpflichtend
• Vermeiden Sie das Sammeln von Hochrisikodaten „für den Fall der Fälle"
• Benennen Sie für jedes Feld einen Verantwortlichen (eine Person oder ein Team)

Verbinden Sie jeden Datentyp mit einem klaren Zweck

Schreiben Sie für jeden Datentyp eine Zweckbeschreibung, die eine nicht-technische Person versteht:

• E-Mail: „Login-Codes und wichtige Konto-Mitteilungen senden.“
• Rechnungsadresse: „Steuern berechnen und Rechnungen erstellen.“
• Support-Chats: „Kundenprobleme lösen und Hilfeartikel verbessern.“

Wenn Sie keinen einzigen klaren Zweck formulieren können, ist das ein Zeichen dafür, dass Sie die Daten ohne echten Bedarf sammeln.

Entscheiden Sie, wer tatsächlich Zugriff braucht

Datenminimierung betrifft nicht nur die Sammlung, sondern auch, wer sie täglich sehen kann. Viele Datenschutzpannen entstehen, weil zu viele Personen zu viel Zugriff haben.

Halten Sie den Zugriff eng: Gewähren Sie Vollzugriff nur an Rollen, die die Daten für ihre Arbeit wirklich benötigen. Für alle anderen bieten Sie weniger Details (z. B. die letzten 4 Ziffern statt vollständiger Kennungen) oder entziehen den Zugriff ganz.

Gehen Sie bei schwer zu schützenden oder schwer zu rechtfertigenden Feldern (z. B. Sozialversicherungsnummern) besonders strikt vor. Wenn keine rechtliche Pflicht besteht, sammeln Sie diese Daten nicht. Muss Hochrisikodaten trotzdem erhoben werden, behandeln Sie sie als Sonderfall mit zusätzlichen Kontrollen und kurzer Aufbewahrungsfrist.

Wie lange sollte man Daten behalten? Einfache Regeln, die funktionieren

Eine Aufbewahrungsrichtlinie ist am einfachsten, wenn Sie mit einer Idee beginnen: Jede Information braucht ein Enddatum. Wenn Sie nicht erklären können, warum Sie sie noch brauchen, sollten Sie sie wahrscheinlich nicht behalten.

Beginnen Sie mit einer Standardfrist und machen Sie Ausnahmen

Wählen Sie für jeden Datentyp eine Standard-Aufbewahrungsfrist basierend auf dem Zweck (Support, Abrechnung, Sicherheit, Recht). Defaults verhindern, dass „für immer behalten“ zur stillen Regel wird.

Ein praktischer Ansatz ist die Aufbewahrung nach Kategorien:

• Kontodaten (Name, E-Mail): Aufbewahrung während das Konto aktiv ist, danach löschen oder anonymisieren nach einer Schonfrist.
• Zahlungen und Rechnungen: So lange aufbewahren, wie es für Buchhaltung und Streitfälle nötig ist.
• Support-Nachrichten: Nur so lange behalten, wie sie zur Problemlösung und Schulung des Teams dienen.
• Sicherheitsereignisse: So lange aufbewahren, wie nötig, um Vorfälle zu untersuchen, danach nur noch Summenwerte behalten.
• Produkt-Analytics: Aggregierte Daten länger aufbewahren als rohe Event-Traces.

Sensible Daten sollten in der Regel die kürzeste Aufbewahrungsdauer haben. Gleiches gilt für ausführliche Logs. Logs enthalten oft IP-Adressen, Tokens oder versehentliche Secrets, besonders in schnell gebauten Produkten. Bewahren Sie detaillierte Logs kurz (Tage oder Wochen) auf und speichern Sie danach nur das Nötigste (Zählungen, Fehlertypen).

Unterschiedliche Zeitlinien für aktive vs. inaktive Nutzer

Behandeln Sie Inaktivität als Auslöser. Zum Beispiel: Vollständige Profile und Aktivitätsdaten für aktive Nutzer aufbewahren, aber nach 90 Tagen Inaktivität bestimmte Events nicht mehr sammeln und nach 12 Monaten Historie löschen oder anonymisieren.

Das zwingt zur Klarheit bei „für den Fall der Fälle“-Daten. Wenn ein Nutzer das Produkt nicht nutzt, sinkt in der Regel schnell der Bedarf, seine detaillierten Daten aufzubewahren.

Legen Sie fest, was bei einer Löschanfrage passiert

Eine Löschanfrage sollte kein hektisches Einzelereignis sein. Definieren Sie es vorher:

• Was gelöscht wird (und was aus rechtlichen/buchhalterischen Gründen aufbewahrt werden muss)
• Wie lange die Erledigung dauert (z. B. innerhalb von 30 Tagen)
• Wie Backups gehandhabt werden (automatisch auslaufen lassen oder bei Wiederherstellungen ausschließen)
• Welchen Nachweis Sie aufbewahren (z. B. ein kleines Record, dass die Anfrage erfüllt wurde)

Wenn Sie diese Regeln einfach formulieren können, lassen sie sich meist ohne Drama umsetzen — und ohne Daten länger zu behalten, als nötig.

Erstellen Sie einen Aufbewahrungsplan, dem Sie tatsächlich folgen können

Ein Aufbewahrungsplan ist der Teil Ihrer Richtlinie, den Menschen ohne Rätselraten nutzen können. Liest er sich wie ein juristisches Dokument, wird er ignoriert. Halten Sie ihn kurz, konkret und verknüpfen Sie jede Zeile mit einem klaren Zweck.

Beginnen Sie mit einer einfachen Tabelle, die fünf Fragen beantwortet: Welche Daten sind es, warum haben Sie sie, wer ist verantwortlich, wie lange behalten Sie sie und wie löschen Sie sie. Das Ziel ist nicht, am ersten Tag alles perfekt zu katalogisieren. Ziel ist, dass nichts „für den Fall der Fälle“ liegen bleibt.

„Verantwortlicher“ ist der Unterschied zwischen Plan und Wunsch. Benennen Sie eine echte Person oder Rolle für jede Zeile. Sie müssen nicht selbst löschen, aber sie müssen bemerken, wenn sich Dinge einschleichen (z. B. Logs, die stillschweigend ein Jahr lang behalten werden).

Formulieren Sie Aufbewahrungsregeln in klaren Worten und vermeiden Sie vage Formulierungen wie „nach Bedarf“. Gute Regeln klingen wie: „30 Tage nach Kontoschließung löschen“ oder „14 Tage aufbewahren, es sei denn, ein Incident ist offen.“ Wenn Sie es nicht in einem Satz sagen können, ist es wahrscheinlich nicht klar genug.

Ausnahmen werden passieren — dokumentieren Sie sie vorab:

• Legal Hold: Löschung für bestimmte Konten oder Datensätze pausieren
• Betrugs- oder Sicherheitsuntersuchung: Relevante Logs und Events behalten, bis der Fall abgeschlossen ist
• Regulatorische Anfrage: Nur das aufbewahren, was vorgeschrieben ist, nicht alles

Für jede Ausnahme nennen Sie, wer sie genehmigen kann und wie sie dokumentiert wird (auch ein einfaches Ticket oder eine schriftliche Notiz reicht). So wird aus „vorübergehend“ nicht „für immer“.

Schritt für Schritt: Datenminimierung und Aufbewahrung umsetzen

Eine Aufbewahrungsrichtlinie wirkt nur, wenn sie das Sammeln, die Ablage und das Verschwinden von Daten tatsächlich ändert. Hier eine Abfolge, die den Aufwand klein hält und Überraschungen reduziert.

1) An der Quelle weniger sammeln

Beginnen Sie bei Formularen, Anmeldeabläufen, Checkout, Support-Tickets und „nice-to-have“-Analytics. Entfernen Sie Felder, die Sie nicht brauchen, um den Service zu liefern, Betrug zu verhindern oder klare rechtliche Anforderungen zu erfüllen.

Wenn Sie den Bericht, das Feature oder den rechtlichen Grund nicht benennen können, hören Sie auf, das Feld zu sammeln.

2) Kopien reduzieren und Zugriff einschränken

Risiko wächst, wenn dieselben Daten an fünf Orten liegen. Streben Sie ein primäres System of Record an, und lassen Sie andere Tools nur das abrufen, was sie brauchen. Begrenzen Sie Zugriffe nach Rollen und vermeiden Sie geteilte Accounts.

Wenn ein Drittanbieter Daten braucht, senden Sie nur den kleinstmöglichen Ausschnitt (z. B. Nutzer-ID und Tarif, nicht das vollständige Profil).

3) Löschen automatisieren, nicht Erinnerungen

Manuelle Bereinigung wird übersprungen. Legen Sie zeitbasierte Regeln fest, um inaktive Profile ablaufen zu lassen, Support-Anhänge nach Ticketabschluss zu löschen, Logs zu rotieren, temporäre Exporte zu löschen und Testdaten zu bereinigen.

Halten Sie Regeln so einfach, dass ein Entwickler sie schnell implementieren kann.

4) Sicherstellen, dass Löschung echt ist (inkl. Backups)

Ein Datensatz in der App zu löschen heißt nicht, ihn überall zu entfernen. Prüfen Sie, wie lange Backups, Replikate und Data-Warehouse-Tabellen Daten behalten. Müssen Backups existieren, setzen Sie ein kurzes Backup-Fenster und dokumentieren Sie, was „gelöscht“ praktisch bedeutet (z. B.: sofort aus Produktion entfernen, dann innerhalb von 30 Tagen aus Backups verschwinden).

5) Vierteljährlich prüfen und Drift beheben

Produkte ändern sich, und das Sammeln schleicht sich zurück. Quartalsweise nehmen Sie sich einen Flow vor und prüfen: Was sammeln wir, wo landet es, wer kann es sehen und wann wird es gelöscht?

Häufige Fehler, die das Risiko hochhalten

Die meisten Datenprobleme entstehen nicht durch eine einzelne große Entscheidung, sondern durch kleine Gewohnheiten, die sich aufsummieren, bis Sie nicht mehr erklären können, was Sie speichern oder warum.

Eine Falle ist, Logs für immer zu behalten, weil sie „später nützlich“ sein könnten. Logs helfen beim Debugging, aber sie enthalten oft E-Mails, IP-Adressen, Reset-Tokens und andere sensible Informationen. Ohne Zeitlimit wird die Fehlerbehebung von gestern zur Lecksquelle von morgen.

Ein weiterer häufiger Fehler ist das „Löschen“ in der App, während Kopien woanders verbleiben. Menschen entfernen einen Datensatz aus der Datenbank, vergessen aber die CSV im geteilten Laufwerk, den Anhang in E-Mails oder den Snapshot in Backups. Wenn ein Kunde Löschung verlangt, reicht eine partielle Löschung nicht aus und schadet dem Vertrauen.

Warnzeichen, die die Exposition still erhöhen

Achten Sie auf diese Muster:

• „Für den Fall“-Speicherung ohne Ablauf- oder Überprüfungsdatum
• Löschungen, die nur an einem Ort passieren, nicht in Exporten, Tickets und Backups
• Secrets im Klartext oder eingebettet im Client-Code
• Tools, die Kundendaten standardmäßig kopieren, ohne klaren Bedarf
• Kein klarer Verantwortlicher, sodass niemand Ausnahmen nachverfolgt

Ein praktisches Beispiel: Ein Gründer stellt einen KI-generierten Prototypen live, der in Demos funktioniert. Später stellt er fest, dass die App vollständige Auth-Responses loggt und ein API-Schlüssel im Frontend hardcodiert ist. Der Schlüssel wird aus einer Datei entfernt, aber ein alter Build, ein eingefügter Ausschnitt in einer Support-E-Mail und ein Backup enthalten ihn noch. Das Risiko bleibt bestehen.

Kurze Checks, die Sie diese Woche durchführen können

Sie brauchen keinen großen Projektplan, um das Risiko zu reduzieren. Ein paar schnelle Prüfungen zeigen, wo Sie zu viel sammeln, zu lange speichern oder nicht wirklich löschen können.

Beginnen Sie mit dem, was Sie sammeln. Wählen Sie einen wichtigen Flow (Anmeldung, Checkout, Kontaktformular) und prüfen Sie jedes Feld. Wenn Sie nicht in einem Satz erklären können, warum Sie ein Feld brauchen, entfernen Sie es oder machen Sie es optional.

Prüfen Sie dann die Bereiche, die leicht vergessen werden: Logs, Datei-Uploads und Support-Systeme. Dort liegen oft E-Mails, IP-Adressen, Screenshots und manchmal Secrets, die in Nachrichten kopiert wurden.

Fünf Checks, die Sie in einer Woche schaffen können:

• Für jedes Feld eine Ein-Satz-Begründung und das kleinstmögliche Format notieren (z. B. Geburtsjahr statt volles Datum).
• Aufbewahrungsfristen für Logs, Uploads und Support-Tickets aufschreiben, auch grob (z. B. 30, 90, 365 Tage).
• Einen End-to-End-Löschtest für einen Nutzer durchführen: App-DB, Analytics-Exporte, Dateien und Support-Threads.
• Auflisten, wo Backups liegen und wie lange sie bestehen, inklusive alter Snapshots und Entwickler-Rechner.
• Bestätigen, dass sensible Daten verschlüsselt sind und der Zugriff auf eine kleine Gruppe beschränkt ist.

Ein Test, der Teams oft überrascht: Bitten Sie jemanden, einen Nutzer zu finden und zu löschen, der vor einem Jahr Support schrieb. Wenn die Antwort lautet „Wir können in der App löschen, aber nicht im Ticketing-Tool oder in Backups“, haben Sie eine klare Lücke zu schließen.

Beispiel: Datensammlung in einem kleinen Produkt kürzen

Ein kleines SaaS verkaufte ein einfaches Monatsabo. Beim Signup fragte es nach Telefonnummer, Wohnadresse und Geburtsdatum. Keines davon war nötig, um das Produkt bereitzustellen — es war aus einer „Vollprofil“-Vorlage übernommen.

Monate später bat der Support Kunden um Screenshots, wenn etwas nicht funktionierte. Diese Screenshots enthielten oft Namen, E-Mails und manchmal Zahlungsdaten. Gleichzeitig exportierte das Team Analytics in eine Tabelle „für spätere Analyse“ und ließ sie jahrelang mit Nutzer-E-Mails im Klartext liegen.

Sie betrachteten es als Risiko und machten drei Änderungen:

• Telefonnummer, Adresse und Geburtsdatum aus dem Onboarding entfernen und nur das behalten, was für Konto und Abrechnung nötig war.
• Einen Hinweis im Support einführen, persönliche Daten zu verpixeln, und die interne Regel, Anhänge nach Ticketabschluss zu löschen.
• Rohdaten-Exporte mit Nutzer-Level standardmäßig stoppen. Wenn ein Export nötig war, nutzten sie anonymisierte Nutzer-IDs und setzten ein 30-Tage-Verfallsdatum.

Technische Log-Aufbewahrung kürzten sie ebenfalls: Anwendungslogs gingen von „für immer“ auf 14 Tage, Fehler-Traces mit Nutzerkennungen wurden maskiert. Backups wurden angepasst: tägliche Backups 14 Tage aufbewahrt, monatliche Backups 3 Monate, ältere Kopien sicher gelöscht.

Das Ergebnis war einfach: Weniger sensible Daten in Formularen, Postfächern, Tabellen, Logs und Backups. Wenn etwas schiefging, gab es weniger zu leaken, weniger zu durchsuchen und weniger zu erklären.

Nächste Schritte: Weniger speichern und es dauerhaft machen

Eine gute Aufbewahrungsrichtlinie ist kein dickes Dokument. Es sind ein paar klare Entscheidungen, denen Ihr Team jede Woche folgen kann.

Beginnen Sie damit, die zehn wichtigsten Datenpunkte aufzuschreiben, die Ihr Produkt berührt (nicht alles, nur die großen). Neben jedem Punkt wählen Sie eine Aufbewahrungsfrist, die Sie verteidigen können. Dann suchen Sie sich einen Hochrisikobereich aus, den Sie zuerst beheben: Auth-Logs, Datei-Uploads oder ein geteiltes Support-Postfach sind häufige Kandidaten.

Fügen Sie leichte Automatisierung hinzu, damit es nicht vom Gedächtnis abhängt: Lösch-Jobs für abgelaufene Tokens, Log-Rotation mit fixer Maximaldauer und klare Ablaufregeln für Uploads und Exporte.

Wenn Sie eine KI-generierte Codebasis übernommen haben und unsicher sind, was geloggt oder behalten wird, kann eine fokussierte Code- und Konfigurationsprüfung die großen Risiken schnell aufdecken (zu ausführliche Logs, exponierte Secrets und Daten, die in falsche Tools kopiert wurden). Teams wie FixMyMess (fixmymess.ai) führen solche Diagnosen und Reparaturen durch, wenn ein KI-erstellter Prototyp produktionsreif gemacht werden muss — inklusive sicherer Protokollierung, Härtung der Sicherheit und tatsächlich laufenden Löschroutinen.