Data Lifecycle Management: Compliance, Kosten und Kontrolle

© Yaroslav Astakhov

Was ist Data Lifecycle Management?

Data Lifecycle Management (DLM) ist der richtliniengesteuerte Prozess, der Unternehmensdaten von ihrer Entstehung bis zur revisionssicheren Vernichtung begleitet. DLM legt für jede Datenkategorie verbindliche Regeln fest – Speicherort, Zugriffsberechtigung, Aufbewahrungsdauer und Löschzeitpunkt – und setzt diese Regeln automatisiert durch, nicht manuell überwacht.

DLM ist keine einzelne Software, sondern eine unternehmensweite Disziplin, die Architektur, Prozesse und Governance miteinander verbindet.

Laut IBM Cost of a Data Breach Report 2024 verursacht ein Datenleck in Deutschland im Durchschnitt Schäden von 4,9 Millionen Euro. Häufig ausgelöst durch unkontrolliert gespeicherte Daten ohne klare Zugriffskontrolle. Das vollständige Rahmenwerk, in dem das Data Lifecycle Management als eine von sechs Teildisziplinen eingebettet ist, beschreibt die IT Lifecycle Management-Übersicht.

Was ist der Unterschied zwischen Data Lifecycle Management und Data Governance?

Data Governance definiert Regeln, Qualitätsstandards und Verantwortlichkeiten – Data Lifecycle Management setzt diese Regeln operativ durch. Governance ohne DLM bleibt ein Regelwerk auf Papier. DLM ohne Governance-Rahmen ist wie ein Fahrplan ohne Ziel: er steuert, aber wohin? Der häufigste Fehler beim Start eines DLM-Projekts: Dateneigentümer und Klassifizierungsregeln sind noch nicht definiert.

Die wichtigsten begrifflichen Abgrenzungen im Überblick:

• Data Governance: Regeln, Qualitätsstandards, Dateneigentümer und Verantwortlichkeiten für alle Datenbereiche
• Information Lifecycle Management (ILM): steuert einzelne Inhalte und Dokumente; DLM agiert auf Datei- und Datenbankebene
• DSGVO-konforme Datenspeicherung: technische Umsetzung von Phase 2 des DLM – nicht der Gesamtprozess
• Backup und Archivierung: Teilaspekt von DLM-Phase 5, kein vollwertiger Lifecycle-Ansatz
• Data Quality Management: prüft Inhalt und Konsistenz; DLM steuert Speicherort, Zugang und Aufbewahrungsfrist

Welche 6 Phasen hat der Datenlebenszyklus?

Das 6-Phasen-Modell ist der gemeinsame Nenner professionellen Data Lifecycle Managements. Jede Phase stellt eigene Anforderungen an Zugriffskontrolle und Compliance-Nachweise. Eine automatisierte Policy-Steuerung wird erst möglich, wenn alle sechs Phasen im System abgebildet sind – nicht als Excel-Tabelle, sondern als durchsetzbare Lifecycle-Regel.

Phase 1–3: Der data lifecycle beginnt bei der Entstehung

In Phase 1 entstehen Daten durch Transaktionen, Benutzereingaben, Sensordaten oder API-Abrufe. Das Prinzip der Datensparsamkeit nach DSGVO Art. 5 Abs. 1 lit. c greift hier zuerst: Nur zu erfassen, was tatsächlich gebraucht wird, reduziert alle späteren Compliance-Aufwände erheblich. Phase 2 ist das Labeling: Datenkategorie, Vertraulichkeitsstufe, Erstellungsdatum – ohne diese Metadaten bleibt ein Datensatz lifecycle-blind. Ein Service Level Agreement kann die Qualität dieser Datenhaltung vertraglich absichern und Zuständigkeiten klar benennen.

Zugriffssteuerung in Phase 3

In Phase 3 greifen Systeme und Mitarbeitende aktiv auf die Daten zu. Zugriffsrechte müssen mit Vertraulichkeitsstufen exakt übereinstimmen, und alle Aktivitäten werden revisionssicher protokolliert – ein zentrales Nachweiserfordernis unter NIS-2 und ISO 27001. Der Wartungs- und Support-Service für Softwareanwendungen trägt diesen Anspruch in den laufenden Applikationsbetrieb. Auch Phase 4 – die Weitergabe – gehört dazu: DLM regelt, welche Datenkategorien an welchen Empfängerkreis gelangen dürfen.

Phase 4–6: Archivierung und data lifecycle-Abschluss

Phase 5 ist der wichtigste Kostenhebel im gesamten data lifecycle: Aufbewahrungspflichtige, aber inaktiv gewordene Daten wandern aus teuren Primärspeichern in günstigere Archivstufen. Konsequentes Tiering reduziert Speicherkosten für Archivdaten um bis zu 70 Prozent. Die formale Grundlage für diesen Wechsel schafft ein sauber aufgesetztes DSGVO-Löschkonzept, das Aufbewahrungsfristen und Löschpflichten klar trennt.

Die vier Speicherebenen im Vergleich:

• Hot Tier:
  hochverfügbar, niedrige Latenz, höchste Kosten – für aktiv genutzte Betriebsdaten
• Warm Tier:
  gelegentlicher Zugriff, moderater Preis – Daten der letzten 12 bis 24 Monate
• Cold Tier:
  seltener Zugriff, günstig – aufbewahrungspflichtige Archivdaten
• Archive Tier:
  minimale Kosten, längere Retrieval-Zeit – Long-Term-Retention nach gesetzlichen Fristen

Revisionssichere Vernichtung in Phase 6

Daten ohne aktive Aufbewahrungspflicht werden unwiederbringlich, protokolliert und DSGVO-konform gelöscht. Das überschneidet sich nicht mit DSGVO-konformer Datenspeicherung – Phase 6 ist deren logisches Ende, nicht deren Wiederholung. Automatisierte Löschroutinen ersetzen den manuellen Prüfprozess – und damit auch die stille Gefahr, dass Löschpflichten einfach übergangen werden.

Data Lifecycle Management: Aufbewahrung und Löschpflicht im Einklang

Das häufigste Compliance-Missverständnis rund um das Data Lifecycle Management: DSGVO verlangt keine schnellstmögliche Löschung aller Daten. Art. 17 Abs. 3 lit. b DSGVO schafft eine explizite Ausnahme: Gesetzliche Aufbewahrungspflichten gehen der Löschpflicht vor. Ohne automatisierte Lifecycle-Steuerung landen aufbewahrungspflichtige Buchungsbelege versehentlich in der Lösch-Queue – oder personenbezogene Daten ohne Rechtsgrundlage bleiben jahrelang ungeklärt im Bestand.

Welche Aufbewahrungsfristen gelten für Unternehmensdaten nach HGB und GoBD?

Die Fristen sind stabil, aber nicht unveränderlich. 8 Jahre statt 10 Jahren für Buchungsbelege – diese Verkürzung gilt seit dem 1. Januar 2025 durch das Bürokratieentlastungsgesetz IV (BEG IV). Wer Lifecycle-Policies nicht regelmäßig aktualisiert, speichert rechtlich unnötig und zahlt Kosten für Bestände, die bereits hätten gelöscht werden dürfen. Gerade bei Datenmigrationsprojekten tauchen veraltete Fristen zuverlässig als blinde Flecken auf.

Zentrale Aufbewahrungsfristen im Überblick:

• Buchungsbelege und Rechnungen (GoBD/BEG IV): 8 Jahre ab 1. Januar 2025 (vorher 10 Jahre)
• Handelsbriefe und Vertragsunterlagen (HGB § 257): 6 Jahre
• Handelsbücher, Bilanzen und Jahresabschlüsse (HGB § 257): 10 Jahre
• Lohnunterlagen (AO § 147): 6 bis 10 Jahre je nach Dokumenttyp
• Personenbezogene Kundendaten ohne laufende Rechtsgrundlage: unverzüglich nach Zweckentfall

Automatisierte Policy-Steuerung als DLM-Antwort

Data Lifecycle Management ist genau der Mechanismus, der beide Anforderungen gleichzeitig abbildet: Aufbewahrungspflichtige Daten wandern in sichere Archivstufen – nicht in die Lösch-Queue. Abgelaufene Daten ohne Rechtsgrundlage werden pünktlich und protokolliert vernichtet. Diese Steuerung lässt sich nicht durch manuelle Prozesse ersetzen, sobald Datenvolumina und Datenkategorien eine bestimmte Größe überschreiten. Die GoBD-Verkürzung auf 8 Jahre ist dabei kein Einzelfall – solche Anpassungsbedarfe sind ein reales, wiederkehrendes Ereignis.

Information Lifecycle Management: Ergänzung, nicht Ersatz

Information Lifecycle Management (ILM) und das Data Lifecycle Management werden oft gleichgesetzt – zu Unrecht. ILM steuert einzelne Dokumente und Inhalte auf Objektebene, DLM hingegen agiert auf Datei- und Datenbankebene und steuert ganze Datenkategorien nach Policy. Erst zusammen decken ILM und DLM den gesamten Datenbestand ab – keines der beiden greift allein weit genug.

DLM by Design: Lifecycle-Logik im Datenbankschema verankern

Die meisten Beiträge zu Data Lifecycle Management behandeln es als nachgelagerte Admindisziplin – ein Thema für das Rechenzentrum oder den Datenschutzbeauftragten. Aus der Softwareentwickler-Perspektive greift diese Sicht zu kurz. Wer individuelle Software entwickeln lässt, hat die einmalige Chance, das Data Lifecycle Management strukturell im Datenbankschema zu verankern. Spalten wie expires_at, anonymized_at oder delete_after machen Lifecycle-Regeln zur nativen Datenbankfunktion – nachvollziehbar, abfragbar und automatisierbar.

Konkrete Architekturentscheidungen für DLM by Design:

• Retention-Felder im Schema: expires_at, anonymized_at, delete_after als native Datenbankfunktion statt externer Konfiguration
• Soft-Delete-Muster: revisionssichere Nachverfolgbarkeit mit DSGVO-konformer Anonymisierungslogik von Anfang an
• Testdaten-Lifecycle: Entwicklungsumgebungen enthalten häufig produktionsnahe Daten – eine unterschätzte DSGVO-Falle
• API-Datenflüsse als Knotenpunkte: Wann verfallen diese Daten und wer ist Data Owner – diese Fragen gehören ins API-Design
• Database Lifecycle Management: Lifecycle-Policies direkt auf Datenbankebene implementieren, nicht in nachgelagerten Tools

Information Lifecycle Management in der Softwarearchitektur

Information Lifecycle Management setzt dort an, wo Dokumente und unstrukturierte Inhalte eine eigene Steuerungsebene brauchen – und DLM allein nicht ausreicht. Beide Disziplinen greifen erst ineinander, wenn sie in der Systemarchitektur gemeinsam geplant werden. Datenmigrationsprojekte legen die Lifecycle-Logik beider Ebenen schonungslos offen – und bieten die seltene Chance, Data Lifecycle Management von Grund auf strukturell neu aufzusetzen, statt vererbte Schwächen zu übernehmen.