Retention- und Löschkonzept für IT-Dokumentation: Compliance-konforme Aufbewahrungsfristen umsetzen

Ein Retention- und Löschkonzept für IT-Dokumentation wirkt auf den ersten Blick wie „Papierkram“. In Audits, bei Sicherheitsvorfällen oder bei personellen Wechseln zeigt sich aber schnell: Ohne definierte Aufbewahrungsfristen, ohne nachvollziehbare Löschregeln und ohne saubere Zuständigkeiten wird Dokumentation selbst zum Risiko. Zu lange Aufbewahrung erhöht Angriffsfläche, Datenvolumen und eDiscovery-Aufwand; zu frühe Löschung gefährdet Nachweisfähigkeit, Betriebskontinuität und rechtliche Pflichten.

Dieser Beitrag beschreibt, wie IT-Leitung, Compliance, Datenschutz und Security ein Retention- und Löschkonzept für IT-Dokumentation so aufsetzen, dass es im Alltag umsetzbar bleibt: mit klarer Entscheidungslogik, Governance, Audit-Perspektive, Vorlagen-Elementen, technischen Umsetzungsbausteinen und Kontrollmechanismen. Der Fokus liegt auf Dokumentationsarten, die in Unternehmen real vorkommen: System- und Architekturunterlagen, Betriebshandbücher, Change- und Freigabe-Nachweise, Berechtigungskonzepte, Protokolle, Runbooks, Lieferantennachweise sowie Ticket- und Wissensdatenbank-Inhalte.

Warum IT-Dokumentation eigene Retention-Regeln braucht

IT-Dokumentation ist kein homogener Datenbestand. Sie enthält häufig Mischinhalte: technische Informationen (Konfigurationen, IPs, Topologien), Sicherheitsrelevantes (Schlüsselmaterial, Notfallzugänge), personenbezogene Daten (Namen in Tickets, Ansprechpartner, E-Mail-Verläufe) und manchmal auch Vertrags- oder Finanzbezug (Abnahmen, Leistungsnachweise). Genau diese Mischung macht Retention schwierig: Die „eine“ Aufbewahrungsfrist gibt es nicht.

Typische Konflikte, die in der Praxis ohne Konzept auftreten:

• Audit vs. Minimierung: Revision und ISMS (Informationssicherheits-Managementsystem) benötigen Nachweise; Datenschutz fordert Datenminimierung und zweckgebundene Aufbewahrung.
• Wissensbasis vs. Security: Betrieb will vollständige Runbooks; Security will keine dauerhaften Passwörter, Notfall-Token oder verwertbaren Angriffspläne im Klartext.
• Change-Historie vs. Pflegeaufwand: Nachvollziehbarkeit verlangt Historie; Teams verlieren Zeit, wenn Altdokumente nicht sauber gekennzeichnet oder automatisch ausgesondert werden.

Ein Retention- und Löschkonzept löst diese Konflikte nicht durch „mehr Regeln“, sondern durch entscheidbare Kategorien und automatisierbare Lebenszyklen – mit definierten Ausnahmen (z. B. Legal Hold) und überprüfbaren Kontrollen.

Regulatorische und normative Einordnung: was wirklich treibt

Für IT-Dokumentation greifen mehrere Anforderungstypen. Wichtig: In der Regel geben sie Pflichten zur Nachvollziehbarkeit und Schutzziele vor, aber selten eine konkrete Zahl „X Jahre“ für alle Dokumente. Sie müssen daher in ein internes Regelwerk übersetzt werden.

Datenschutz (DSGVO): Speicherbegrenzung und Löschpflichten

Die DSGVO fordert u. a. Speicherbegrenzung (Daten nicht länger als nötig) und Integrität/Vertraulichkeit. Für IT-Dokumentation ist das relevant, sobald personenbezogene Daten enthalten sind (z. B. Incident-Tickets, Protokolle mit User-IDs, Ansprechpartnerlisten). Praktische Konsequenz: Sie brauchen eine Datenklassifizierung, eine Zweckbindung und Lösch- bzw. Anonymisierungsregeln, die sich technisch durchsetzen lassen.

Revisions- und Nachweispflichten: Nachvollziehbarkeit, Unveränderbarkeit, Auffindbarkeit

Unabhängig von der Branche erwarten interne/externe Prüfer für wesentliche IT-Prozesse Nachweise: Freigaben, Change-Dokumentation, Berechtigungskonzepte, Notfalltests, Lieferantennachweise, Risiko- und Maßnahmenverfolgung. „Revisionssicher“ bedeutet im Kern: Dokumente sind auffindbar, vollständig, zeitlich einordenbar und gegen unerkannte Manipulation geschützt (z. B. über Versionierung, Signaturen/Hashes oder WORM-Speicher, also „write once, read many“).

ISMS/Informationssicherheit: Schutzbedarf und kontrollierte Löschung

Ein ISMS (z. B. nach ISO 27001-Logik) verlangt dokumentierte Prozesse, Rollen, Risikobehandlung und Nachweise, aber vor allem: Schutzbedarfsgerechten Umgang mit Informationen. Für Dokumentation heißt das: Klassifizieren, Zugriff steuern, Protokollierung (Audit-Log) und sichere Entsorgung (Löschung, ggf. kryptografische Löschung). Löschung muss dabei nicht nur „weg“ bedeuten, sondern nachweisbar und wiederholbar sein.

Scope klären: Welche Artefakte zählen zur IT-Dokumentation?

Bevor Fristen diskutiert werden, muss der Umfang definiert werden. In Projekten ist das einer der häufigsten Stolpersteine: Teams denken an Wiki-Seiten, Prüfer denken an alles, was eine Entscheidung oder einen Betriebsvorgang belegt.

Ein praxistauglicher Scope für ein Retention- und Löschkonzept umfasst typischerweise:

• System- und Architekturunterlagen: Ziel-/Ist-Architektur, Schnittstellenbeschreibungen (API), Datenflüsse, Netzpläne.
• Betriebsdokumentation: Runbooks, Notfallhandbücher, Backup/Restore-Anleitungen, Monitoring- und Alarmierungsregeln.
• Change- und Release-Nachweise: Requests, Risikoabwägungen, Freigaben, Abnahmen, Rollback-Entscheidungen.
• Security- und Berechtigungsdokumente: Rollen- und Rechtekonzepte, Rezertifizierungen, Härtungsstandards, Ausnahmegenehmigungen.
• Ticketing- und Wissensdatenbank: Incidents, Problems, Service Requests, bekannte Fehler, Root-Cause-Analysen.
• Lieferanten- und Betriebsnachweise: SLAs, Wartungsfenster, Sicherheitsnachweise, Kommunikationsprotokolle.

Nicht alles wird gleich behandelt: Gerade Tickets enthalten oft personenbezogene Daten und sollten anders befristet werden als Architekturentscheidungen oder Notfallkonzepte.

Entscheidungslogik: Von der Dokumentart zur Aufbewahrungsfrist

Statt einzelne Dokumente zu verhandeln, funktioniert eine Retention-Matrix: Dokumentkategorie → Schutzbedarf → Zweck/Nachweis → Aufbewahrungsdauer → Lösch-/Archivmodus → Verantwortliche Rolle → Legal-Hold-Regel.

Vier Fragen, die jede Kategorie entscheiden

1. Welche Pflicht oder welcher Zweck verlangt die Aufbewahrung? (z. B. Nachweis von Änderungen, Betriebssicherheit, Vertrags-/Haftungsfragen)
2. Wie hoch ist der Schutzbedarf? (Vertraulichkeit/Integrität/Verfügbarkeit; besonders kritisch bei Admin-Zugängen, Schlüsselmaterial, Schwachstelleninfos)
3. Wie schnell veraltet der Inhalt? (Runbooks können nach einer Plattformmigration falsch und gefährlich werden)
4. Wie wird „End of Life“ erkannt? (System außer Betrieb, Vertrag beendet, Ticket geschlossen + X Monate, Change superseded)

Typische Retention-Profile für IT-Dokumentation (als Vorlage)

Die folgenden Profile sind bewusst als Entscheidungshilfe formuliert. Konkrete Fristen müssen Sie an Ihr Regelwerk, Ihre Branche und Verträge anpassen. Wichtig ist die Logik dahinter: Nachweisrelevanz und Risiko bestimmen die Aufbewahrung, nicht Bequemlichkeit.

• Architekturentscheidungen und Systemgrundlagen: Aufbewahrung mindestens über den Lebenszyklus des Systems plus definierte Übergangszeit, weil sie Migrationen, Incident-Analyse und Haftungsfragen stützen. Archivierung mit Versionshistorie, klare Kennzeichnung „gültig bis“ und „ersetzt durch“.
• Betriebsrunbooks und Notfallprozesse: Aufbewahrung solange sie gültig sind; Altversionen nur, wenn als Nachweis benötigt (z. B. für Audit von Notfallübungen). Sonst kontrolliert entfernen, weil veraltete Anleitungen im Ernstfall echten Schaden verursachen.
• Change- und Freigabenachweise: Aufbewahrung nach internen Kontrollsystemen und Prüfzyklen; häufig werden mehrere Jahre benötigt, damit Prüfer die Wirksamkeit von Kontrollen beurteilen können. Hier zählt Unveränderbarkeit/Integrität besonders.
• Tickets (Incident/Service): Differenzieren: rein technische Incidents ohne Personenbezug vs. Tickets mit personenbezogenen Daten. Für letztere klare Lösch-/Anonymisierungsregeln nach Zweckerfüllung und Ablauf von Gewährleistungs-/Nachweisbedarfen. Anhänge (Logs, Screenshots) separat betrachten.
• Security-Ausnahmen und temporäre Berechtigungen: Kurze Retention für operative Inhalte, aber Nachweis der Genehmigung länger. Inhalte wie Notfallpasswörter gehören nicht in Dauer-Dokumentation, sondern in dafür vorgesehene, kontrollierte Systeme (z. B. Passwort-Tresor) mit eigener Retention.

Governance: Rollen, Verantwortlichkeiten und Freigaben

Ohne Governance bleibt ein Löschkonzept Theorie. Entscheidend ist, dass Retention nicht „die IT“ alleine beschließt, sondern als gemeinsame Kontrolle von IT, Compliance/Revision, Datenschutz und Informationssicherheit betrieben wird.

Rollenmodell (RACI-tauglich)

• Owner der Dokumentkategorie (Business/IT): definiert Zweck, inhaltliche Mindestanforderungen, „End of Life“-Kriterien.
• Informationssicherheitsverantwortliche: legt Klassifizierung, Zugriffsmodell, Schutzmaßnahmen, sichere Löschmethoden fest.
• Datenschutz (falls personenbezogen): prüft Zweckbindung, Speicherbegrenzung, Anonymisierung/Pseudonymisierung.
• Compliance/Revision: definiert Nachweisanforderungen, Mindestaufbewahrung, Audit-Trails, Stichprobenlogik.
• IT-Betrieb/Plattformteams: setzen technische Policies um (Archivspeicher, Aufbewahrungslabels, Backups, Protokollierung).
• Legal (bei Legal Hold): steuert Ausnahmen, Sperrfristen und Freigabe zur Wiederaufnahme der Löschung.

Change-Management für Retention-Regeln

Retention-Policies sind kontrollrelevant. Änderungen daran sollten wie Konfigurationsänderungen behandelt werden: dokumentierter Antrag, Begründung, Risikoabschätzung, Freigabe und Versionshistorie. Das reduziert Audit-Findings wie „Retention wurde ad hoc geändert“.

Technische Umsetzung: von Labels bis zu sicherer Löschung

Ein Retention- und Löschkonzept scheitert selten an fehlenden Tools, sondern an fehlenden Metadaten und durchgängigen Systemgrenzen. Die Umsetzung muss daher pragmatisch sein: wenige, robuste Mechanismen, die in allen relevanten Ablagen funktionieren.

Metadaten als Schlüsselfaktor: ohne Klassifizierung keine Automatisierung

Mindestens erforderlich sind:

• Dokumentkategorie (z. B. „Change-Nachweis“, „Runbook“, „Architektur“)
• Owner (Rolle/Team, nicht nur Person)
• Schutzklasse (z. B. intern, vertraulich, streng vertraulich)
• Gültigkeitsstatus (entwurf, gültig, ersetzt, außer Betrieb)
• Retention-Label (Policy-ID) und Startdatum (z. B. „Ticket geschlossen am …“)

Wenn Ihre Dokumentation in mehreren Systemen lebt (Wiki, DMS, Ticketing, Git, Fileshares), müssen diese Metadaten entweder systemübergreifend abbildbar sein oder Sie definieren bewusst, welche Systeme „System of Record“ für welche Kategorie sind.

Archiv vs. Backup vs. Live-Ablage: häufige Fehlannahmen

In Audits ist „wir haben Backups“ kein Ersatz für Archivierung. Ein Backup dient der Wiederherstellung, nicht der langfristigen, gezielten Aufbewahrung. Umgekehrt ist ein Archiv kein Disaster-Recovery-Konzept. Praktische Leitlinie:

• Live-Ablage: aktuelle, operative Dokumentation; Zugriff schnell, Änderungen erlaubt.
• Archiv: für Nachweise; eher unveränderbar, versioniert, mit Audit-Log; gezielte Suche und Export möglich.
• Backup: zeitpunktbezogene Sicherung; enthält auch gelöschte Daten bis zum Ablauf der Backup-Retention.

Für Löschkonzepte ist besonders wichtig, wie Backups behandelt werden: Löschung in der Live-Ablage bedeutet nicht sofortige Löschung aus Backups. Das muss im Konzept transparent beschrieben werden („Löschung wirksam in Produktion sofort, vollständiges Auslaufen aus Backups nach X Tagen/Monaten“).

Sichere Löschung und „kryptografische Löschung“

Bei Cloud- und Storage-Systemen ist physisches Überschreiben oft nicht sinnvoll oder nicht möglich. Stattdessen wird häufig kryptografische Löschung genutzt: Daten werden so verschlüsselt gespeichert, dass das Löschen des Schlüssels die Daten praktisch unlesbar macht. Das ist nur belastbar, wenn Schlüsselmanagement, Zugriffskontrolle und Nachweisführung stimmen (z. B. getrennte Rollen, dokumentierter Key-Lifecycle, Protokollierung).

Beispiel: Policy-Logik als kopierbarer Entwurf (ohne Tool-Bindung)

Wenn Sie Retention als „Policy as Text“ dokumentieren, vermeiden Sie Tool-Silos. Der folgende Entwurf kann als Ausgangspunkt für ein internes Richtliniendokument dienen.

POLICY-ID: DOC-RET-CHG-001
Kategorie: Change- und Freigabenachweise
Zweck: Nachvollziehbarkeit von Änderungen, Prüfbarkeit interner Kontrollen
Schutzklasse: Vertraulich
Aufbewahrung: 6 Jahre ab Abschluss des Changes (Status: geschlossen)
Ablage: Archivspeicher (unveränderbar), Referenzlink aus Ticketing/Wiki
Löschmodus: automatisiert nach Ablauf, außer bei Legal Hold
Legal Hold: Sperre durch Legal/Compliance, dokumentierter Start/Ende
Nachweis: Audit-Log der Archivierung und Löschung, monatlicher Report
Owner: IT Service Management
Freigabe Retention-Regel: Compliance + Informationssicherheit

Beispiel: Lösch- und Anonymisierungsregeln für Tickets (kopierbarer Entwurf)

Ticketing-Systeme sind auditrelevant, aber auch personenbezogen. Häufig ist eine Kombination sinnvoll: technische Fakten behalten, personenbezogene Inhalte minimieren.

POLICY-ID: DOC-RET-TCK-002
Kategorie: Incident- und Service-Tickets
Unterkategorie A: Tickets ohne personenbezogene Daten
  Aufbewahrung: 3 Jahre ab Schließung
  Löschmodus: automatisiert
Unterkategorie B: Tickets mit personenbezogenen Daten (z. B. Nutzeranfragen)
  Aufbewahrung: 12 Monate ab Schließung
  Maßnahme: Anonymisierung von Namen/E-Mail, Entfernen personenbezogener Anhänge
  Technische Kerndaten bleiben: Kategorie, System, Zeitstempel, Maßnahmen, RCA-Referenz
Unterkategorie C: sicherheitsrelevante Incidents (IR/Forensik)
  Aufbewahrung: nach IR- und Rechtsvorgaben; standardmäßig länger, strenge Zugriffskontrolle
Legal Hold: möglich in allen Unterkategorien
Owner: Service Desk / Incident Management
Freigabe: Datenschutz + Informationssicherheit + Compliance

Audit-Perspektive: Welche Evidence Prüfer erwarten

In Prüfungen geht es selten darum, ob Ihre Fristen „schön“ sind, sondern ob sie begründet, umgesetzt und kontrolliert sind. Typische Erwartungshaltungen:

• Dokumentierte Retention-Matrix mit Kategorien, Fristen, Verantwortlichen, Ausnahmen.
• Nachweis der technischen Durchsetzung: Systemkonfiguration, Labels, Workflows, Berechtigungen.
• Audit-Logs: wer hat was erstellt/geändert/gelöscht; bei sensiblen Bereichen unveränderbar.
• Stichproben: einzelne Dokumente/Tickets werden rückwärts geprüft (Existenz, Integrität, Löschstatus nach Frist).
• Legal-Hold-Prozess: klarer Trigger, Freigaben, Ende der Sperre, dokumentierte Kommunikation.

Ein hilfreicher interner Kontrollpunkt ist ein quartalsweises „Retention Review“: nicht als Gremiumstermin, sondern als Report-basiertes Verfahren (Top-Kategorien, Ausnahmen, Löschrückstände, fehlende Labels, Systeme ohne Durchsetzung).

Kosten- und Betriebsfolgen: Wo Retention wirklich Geld und Risiko bewegt

Retention wird oft nur mit Speicherplatz assoziiert. Der größere Hebel liegt jedoch in Betrieb, Security und Audit-Aufwand.

Direkte Kosten

• Speicher und Backup-Fenster: mehr Daten verlängern Backup-Zeiten, erhöhen RTO/RPO-Risiken (Wiederanlaufzeit und maximaler Datenverlust).
• Lizenz-/SaaS-Kosten: viele Systeme bepreisen nach Volumen oder Nutzer; historische Anhänge und Duplikate treiben Kosten.
• eDiscovery/Recherche: je größer der Datenberg, desto teurer jede Suche im Streit- oder Prüfungsfall.

Indirekte Risiken

• Angriffsfläche: alte Netzpläne, Zugangsdaten, Schwachstellenanalysen oder „Quick Fix“-Anleitungen sind für Angreifer wertvoll.
• Fehlbedienung im Betrieb: veraltete Runbooks und „tote“ Confluence-Seiten führen zu falschen Handgriffen unter Stress.
• Audit-Findings: fehlende Löschkonzepte und unklare Zuständigkeiten sind wiederkehrende Beanstandungen.

Pragmatischer Implementierungsplan in 6 Schritten

Die Umsetzung gelingt am besten iterativ. Ziel ist nicht „perfekt“, sondern kontrollierbar und ausbaufähig.

1. Inventar & Systeme festlegen: Wo liegt IT-Dokumentation (Wiki, DMS, Ticketing, Fileshare, Git, CMDB)? Welche Kategorien sind kritisch?
2. Klassifizierung und Kategorien definieren: 8–15 Kategorien reichen oft für den Start. Zu viele Kategorien verhindern Automatisierung.
3. Retention-Matrix beschließen: Fristen, Trigger, Owner, Legal Hold, Archiv-/Löschmodus.
4. Technische Durchsetzung priorisieren: Beginnen Sie dort, wo Volumen und Risiko hoch sind (Ticketing-Anhänge, alte Runbooks, Sicherheitsausnahmen).
5. Kontrollen und Reports etablieren: monatliche/vierteljährliche Reports, Stichproben, KPIs (Label-Abdeckung, Löschrückstand, Legal-Hold-Fälle).
6. Schulung und Betriebsübergabe: kurze Handlungsanweisungen für Autoren und Betreiber („welches Label wann?“), plus klare Eskalation.

Checkliste: Retention- und Löschkonzept für IT-Dokumentation (auditfähig)

• Scope definiert: Dokumentarten, Systeme, „System of Record“ je Kategorie
• Kategorienmodell und Schutzklassen beschlossen
• Retention-Matrix: Frist, Trigger, Archiv/Löschung, Owner, Freigaben, Legal Hold
• Metadaten-Standard: Pflichtfelder und Validierung
• Technische Durchsetzung in den Kernsystemen umgesetzt (Labels/Policies/Workflows)
• Backup-Retention und Löschwirkung transparent dokumentiert
• Audit-Logs und Integritätsmechanismen (Versionierung, Hash/Signatur oder WORM) geregelt
• Prozess für Ausnahmen und Legal Hold etabliert
• Kontrollplan: Reports, Stichproben, Review-Takt, Verantwortlichkeiten
• Onboarding-/Autorenguides für neue Dokumente und Ticket-Anhänge

Häufige Fehlerbilder und wie Sie sie vermeiden

„Alles aufbewahren, dann sind wir sicher“

Das Gegenteil ist oft der Fall: Sie erhöhen Angriffsfläche und Audit-Aufwand. Sicherheit entsteht durch klare Nachweisketten und kontrollierte Reduktion, nicht durch unbegrenztes Sammeln.

„Löschung ist Sache des Tools“

Tools können nur umsetzen, was Sie als Kategorien, Metadaten und Trigger definieren. Ohne saubere Startpunkte („ab wann läuft die Frist?“) bleibt Löschung zufällig.

„Backups lösen Retention“

Backups sind zeitpunktbezogen und schwer selektiv zu löschen. Ein gutes Konzept beschreibt deshalb explizit, wie Löschung und Backup-Retention zusammenwirken.

„Keine Zuständigkeit, weil es ‚nur Dokumentation‘ ist“

Gerade IT-Dokumentation enthält Betriebs- und Sicherheitswissen. Ohne Owner gibt es keine belastbare Entscheidung, wann etwas weg darf oder bleiben muss.

Fazit: Retention ist ein Steuerungsinstrument, kein Archivprojekt

Ein Retention- und Löschkonzept für IT-Dokumentation ist dann erfolgreich, wenn es drei Dinge gleichzeitig erreicht: Es hält Nachweise für Audit und Betrieb verfügbar, reduziert unnötige Datenbestände und senkt Sicherheitsrisiken durch kontrollierte Löschung. Der Schlüssel liegt in wenigen, klaren Kategorien, belastbaren Triggern, einer governancefähigen Retention-Matrix und technischer Durchsetzung inklusive Reporting.

Wenn Sie das Thema angehen, starten Sie nicht mit „Jahre festlegen“, sondern mit Scope, Kategorien und Verantwortlichkeiten. Fristen ergeben sich dann aus Zweck, Nachweisbedarf und Schutzbedarf – und lassen sich im Betrieb tatsächlich einhalten.

Für dieses Thema sind auch Aufbewahrungsfristen It-Dokumentation und Löschkonzept Dokumentation wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.