Backup-Richtlinie schreiben: Aufbau, Inhalt und Beispiel

Warum eine Backup-Richtlinie kein optionales Dokument ist

Backups sind so selbstverständlich wie Strom aus der Steckdose. Irgendjemand in der IT hat irgendwann ein Sicherungsskript eingerichtet, es läuft nachts durch, und solange keine Fehlermeldung kommt, geht jeder davon aus, dass alles in Ordnung ist. Bis es das nicht mehr ist.

Ransomware verschlüsselt die Produktivdaten und gleich die Backup-Shares mit. Ein fehlerhaftes Update zerschießt die Datenbank, und beim Restore stellt sich heraus, dass die Sicherung seit drei Wochen fehlschlägt, weil der Speicher vollgelaufen war. Oder der Geschäftsführer fragt nach einem gelöschten Vertrag von vor acht Monaten, und niemand weiß, ob die Aufbewahrungsfrist der Backups das überhaupt abdeckt.

All das passiert regelmäßig, und all das ließe sich mit einer sauber dokumentierten Backup-Richtlinie vermeiden oder zumindest beherrschbar machen. Eine Backup-Richtlinie ist das Dokument, das verbindlich regelt, welche Daten in welchem Rhythmus, auf welches Medium, an welchen Standort gesichert werden, wie lange die Sicherungen aufbewahrt werden, wer verantwortlich ist und wie die Wiederherstellung im Ernstfall abläuft.

Für ein ISMS nach ISO 27001 ist dieses Dokument nicht verhandelbar. Control A.8.13 (Information backup) fordert explizit, dass Sicherungskopien von Informationen, Software und Systemkonfigurationen erstellt, regelmäßig getestet und dokumentiert werden. NIS2 geht noch einen Schritt weiter: Artikel 21 Absatz 2 Nr. 3 verlangt Maßnahmen zur Aufrechterhaltung des Betriebs, und dazu gehört eine funktionierende Datensicherung als elementare Grundlage.

Was die Backup-Richtlinie von einem Backup-Konzept unterscheidet

Bevor du losschreibst, lohnt sich eine kurze Begriffsklärung, weil die Begriffe Backup-Richtlinie und Backup-Konzept häufig durcheinandergeworfen werden.

Die Backup-Richtlinie (Policy) ist das übergeordnete Dokument. Sie definiert Grundsätze, Verantwortlichkeiten, Mindestanforderungen und Rahmenbedingungen. Sie richtet sich an alle relevanten Stakeholder im Unternehmen und wird von der Geschäftsführung freigegeben.

Das Backup-Konzept ist das technische Umsetzungsdokument. Es beschreibt die konkreten Backup-Jobs, Zeitpläne, Speichersysteme, Netzwerkpfade und Konfigurationsdetails. Es richtet sich an die IT-Abteilung und wird vom IT-Leiter oder Administrator verantwortet.

In der Praxis kannst du beide in einem Dokument zusammenfassen, wenn dein Unternehmen nicht zu groß ist. Sauberer ist eine Trennung: Die Richtlinie gibt den Rahmen vor, das Konzept beschreibt die technische Umsetzung. Für das ISMS brauchst du mindestens die Richtlinie. Ein Auditor wird nach den Grundsätzen fragen, nicht nach den Details einzelner Backup-Jobs.

Geltungsbereich und Klassifizierung

Jede Backup-Richtlinie beginnt mit der Frage, was gesichert werden muss. Die Antwort lautet nicht pauschal „alles", sondern orientiert sich an der Klassifizierung und dem Schutzbedarf der Daten.

Dein Unternehmen hat im Rahmen des ISMS eine Schutzbedarfsfeststellung durchgeführt. Die Ergebnisse fließen direkt in die Backup-Richtlinie ein. Daten mit hohem Schutzbedarf bezüglich Verfügbarkeit brauchen kürzere Sicherungsintervalle und kürzere Recovery-Zeiten als Daten mit normalem Schutzbedarf.

Typischerweise definiert die Richtlinie drei bis vier Backup-Klassen:

Klasse A (Geschäftskritisch): ERP-System, Finanzbuchhaltung, Kundendatenbank, E-Mail-Server. Sicherung mehrmals täglich, Recovery Time Objective (RTO) unter vier Stunden, Recovery Point Objective (RPO) unter einer Stunde. Wie du RPO und RTO richtig definierst, hängt von der Business-Impact-Analyse ab.

Klasse B (Wichtig): Fileserver, Projektdaten, Intranet, Dokumentenmanagement. Tägliche Sicherung, RTO unter 24 Stunden, RPO unter 24 Stunden.

Klasse C (Standard): Entwicklungsumgebungen, Testdaten, Archivmaterial. Wöchentliche Sicherung, RTO unter 72 Stunden, RPO unter einer Woche.

Klasse D (Nicht sicherungsrelevant): Temporäre Dateien, lokale Caches, öffentlich verfügbare Informationen. Keine Sicherung erforderlich.

Die Zuordnung der Systeme zu den Klassen erfolgt gemeinsam durch die IT und die Fachabteilungen. Die Richtlinie muss festlegen, dass diese Zuordnung dokumentiert und mindestens jährlich überprüft wird. Neue Systeme müssen vor der Produktivnahme einer Backup-Klasse zugewiesen werden.

Sicherungsarten und ihre Einsatzbereiche

Die Richtlinie sollte die zugelassenen Sicherungsarten definieren und festlegen, wann welche zum Einsatz kommt.

Vollsicherung (Full Backup)

Bei einer Vollsicherung werden alle Daten vollständig kopiert. Sie bildet die Basis für jede Backup-Strategie, ist aber zeit- und speicherintensiv. Typischerweise wird eine Vollsicherung wöchentlich oder monatlich durchgeführt, je nach Datenvolumen und Backup-Fenster.

Vorteil: Die Wiederherstellung ist einfach und schnell, weil nur ein einziger Sicherungssatz benötigt wird. Nachteil: Hoher Speicherbedarf und lange Laufzeit.

Inkrementelle Sicherung (Incremental Backup)

Eine inkrementelle Sicherung sichert nur die Daten, die sich seit der letzten Sicherung (egal ob Voll- oder inkrementell) geändert haben. Das ist die effizienteste Methode bezüglich Speicherplatz und Laufzeit.

Vorteil: Schnell und speichersparend. Nachteil: Für die Wiederherstellung wird die letzte Vollsicherung plus alle nachfolgenden inkrementellen Sicherungen benötigt. Fällt ein Glied in der Kette aus, ist der Restore gefährdet.

Differentielle Sicherung (Differential Backup)

Eine differentielle Sicherung sichert alle Daten, die sich seit der letzten Vollsicherung geändert haben. Sie wächst mit jedem Tag, ist aber einfacher wiederherzustellen als eine Kette inkrementeller Sicherungen.

Vorteil: Für die Wiederherstellung werden nur die letzte Vollsicherung und die letzte differentielle Sicherung benötigt. Nachteil: Wachsender Speicherbedarf im Laufe der Woche.

Empfohlene Kombination

Für die meisten Unternehmen im Mittelstand hat sich folgende Kombination bewährt: Wöchentliche Vollsicherung am Wochenende, tägliche inkrementelle oder differentielle Sicherung an Werktagen. Bei geschäftskritischen Systemen der Klasse A kommt zusätzlich eine untertägige inkrementelle Sicherung oder eine Echtzeit-Replikation hinzu.

Die Richtlinie legt die Mindestanforderungen pro Backup-Klasse fest. Die technische Detailplanung erfolgt im Backup-Konzept.

Die 3-2-1-Regel als Fundament

Die 3-2-1-Regel ist der Goldstandard der Datensicherung und sollte in jeder Backup-Richtlinie als Grundsatz verankert sein:

3 Kopien: Neben den Originaldaten existieren mindestens zwei weitere Kopien. Damit übersteht dein Unternehmen den gleichzeitigen Ausfall eines Speichermediums.

2 verschiedene Medien: Die Kopien liegen auf mindestens zwei unterschiedlichen Speichertechnologien. Festplatte und Band, lokaler Storage und Cloud, SAN und NAS. Das schützt gegen technologiespezifische Ausfälle.

1 externer Standort: Mindestens eine Kopie befindet sich an einem geografisch getrennten Standort. Das schützt gegen lokale Katastrophen wie Brand, Hochwasser oder Einbruch.

In der Praxis wird die Regel zunehmend um eine Erweiterung ergänzt: 3-2-1-1-0. Die zusätzliche 1 steht für eine Offline-Kopie (Air-Gapped), die vor Ransomware geschützt ist, weil sie physisch nicht erreichbar ist. Die 0 steht für null Fehler bei der Überprüfung, also regelmäßige Restore-Tests ohne Beanstandungen.

Deine Backup-Richtlinie sollte die 3-2-1-Regel (oder die erweiterte Variante) als verbindlichen Grundsatz formulieren und Ausnahmen nur mit dokumentierter Risikoakzeptanz zulassen.

Aufbewahrungsfristen

Die Frage, wie lange Backups aufbewahrt werden, ist nicht rein technisch, sondern hat rechtliche und geschäftliche Dimensionen.

Gesetzliche Aufbewahrungspflichten: Handelsrechtliche Unterlagen müssen laut HGB zehn Jahre aufbewahrt werden, steuerlich relevante Unterlagen nach AO sechs bis zehn Jahre. Wenn diese Daten nur im Backup existieren (was nicht der Standard sein sollte, aber vorkommt), muss das Backup mindestens so lange verfügbar sein.

Datenschutzrechtliche Löschpflichten: Die DSGVO verlangt, dass personenbezogene Daten gelöscht werden, wenn der Verarbeitungszweck entfällt. Backups, die personenbezogene Daten enthalten, müssen in das Löschkonzept einbezogen werden. Das bedeutet nicht, dass du jede einzelne Person aus dem Backup löschen musst, aber du musst dokumentieren, wie du mit personenbezogenen Daten in Backups umgehst und wann die Sicherungen regulär gelöscht werden.

Geschäftliche Anforderungen: Fachabteilungen haben oft eigene Vorstellungen, wie weit sie in der Zeit zurückgehen können müssen. Ein Monat mag für die IT ausreichen, die Rechtsabteilung möchte vielleicht drei Jahre.

Typische Aufbewahrungsfristen in der Richtlinie:

Diese Fristen sind Richtwerte. Deine Richtlinie muss sie an die spezifischen Anforderungen deines Unternehmens anpassen.

Speicherorte und Zugriffsschutz

Die Richtlinie muss festlegen, wo Backups gespeichert werden und wie der Zugriff geschützt wird.

Lokale Sicherung

Backups auf lokale Speichersysteme (NAS, SAN, dedizierte Backup-Server) bieten schnelle Sicherung und schnellen Restore. Sie sind der erste Anlaufpunkt für den täglichen Betrieb. Die Richtlinie sollte vorgeben, dass lokale Backup-Speicher in einem separaten Netzwerksegment stehen und nicht über die gleichen Benutzerkonten erreichbar sind wie die Produktivdaten. Ransomware-Angriffe nutzen regelmäßig die Tatsache aus, dass Backup-Shares mit denselben Credentials erreichbar sind wie die Originaldaten.

Offsite-Sicherung

Die externe Sicherung erfolgt an einen geografisch getrennten Standort. Das kann ein zweiter Unternehmensstandort, ein Rechenzentrum eines Dienstleisters oder ein Cloud-Speicherdienst sein. Die Richtlinie muss definieren, welche Anforderungen an den externen Speicherort gestellt werden: Standort in der EU (DSGVO), Verschlüsselung der Daten vor der Übertragung und im Ruhezustand, vertragliche Regelungen mit dem Dienstleister (AVV, SLA).

Offline-Sicherung (Air-Gapped)

Mindestens für geschäftskritische Daten der Klasse A sollte die Richtlinie eine Offline-Kopie vorsehen – sogenannte Immutable Backups bieten hier besonderen Schutz. Das können Bandmedien sein, die nach der Sicherung physisch aus dem Laufwerk entnommen werden, oder ein dediziertes Speichersystem, das nur während der Sicherung mit dem Netzwerk verbunden wird. Diese Kopie ist die letzte Verteidigungslinie gegen Ransomware.

Verschlüsselung

Alle Backups, die das Unternehmensnetzwerk verlassen (Offsite, Cloud, Bandtransport), müssen verschlüsselt werden. Die Richtlinie sollte AES-256 als Mindeststandard vorgeben und festlegen, wie die Verschlüsselungsschlüssel verwaltet werden. Ein Backup, dessen Entschlüsselungsschlüssel verloren geht, ist wertlos. Schlüsselmanagement für Backup-Verschlüsselung muss separat und sicher dokumentiert sein.

Zugriffsschutz

Zugriff auf Backup-Systeme und -Daten muss nach dem Least-Privilege-Prinzip geregelt sein. Die Richtlinie sollte festlegen, dass nur namentlich benannte Administratoren Zugriff auf Backup-Systeme haben, dass alle Zugriffe protokolliert werden und dass für den Restore kritischer Daten ein Vier-Augen-Prinzip gilt.

Restore-Tests: Das Herzstück der Richtlinie

Ein Backup, das nie getestet wurde, ist kein Backup, sondern eine Hypothese. Restore-Tests sind der Teil der Richtlinie, der am häufigsten vernachlässigt wird, und gleichzeitig der wichtigste.

Warum Restore-Tests unverzichtbar sind

Die Gründe, warum Backups im Ernstfall versagen, sind vielfältig: korrupte Sicherungsdateien, inkompatible Backup-Software-Versionen, fehlende Treiber oder Lizenzen für die Restore-Umgebung, zu langsame Wiederherstellung, unvollständige Daten, fehlerhafte Konfiguration des Backup-Jobs. All das fällt erst auf, wenn du den Restore tatsächlich testest.

Wie die Richtlinie Restore-Tests regeln sollte

Die Richtlinie sollte folgende Punkte definieren:

Häufigkeit: Mindestens vierteljährlich für geschäftskritische Systeme (Klasse A), halbjährlich für wichtige Systeme (Klasse B). Jährlich für Systeme der Klasse C.

Umfang: Nicht nur einzelne Dateien wiederherstellen, sondern regelmäßig auch vollständige Systemwiederherstellungen testen. Kann der Datenbankserver komplett aus dem Backup wiederhergestellt werden? Funktioniert das ERP-System nach dem Restore?

Dokumentation: Jeder Restore-Test wird protokolliert: Datum, getestetes System, Backup-Datum der wiederhergestellten Daten, benötigte Zeit, Ergebnis (erfolgreich/fehlgeschlagen), identifizierte Probleme und eingeleitete Maßnahmen.

Verantwortlichkeit: Wer führt die Tests durch, wer prüft die Ergebnisse, wer eskaliert bei Problemen?

RTO-Validierung: Die gemessene Wiederherstellungszeit wird mit dem definierten RTO verglichen. Wenn der Restore vier Stunden dauert, das RTO aber zwei Stunden beträgt, muss die Backup-Strategie angepasst werden.

Ein Auditor wird fast immer nach den letzten Restore-Tests fragen. Wer Protokolle vorlegen kann, die regelmäßige, erfolgreiche Tests belegen, hat bei diesem Punkt gewonnen. Wer keine hat, hat ein Finding.

Verantwortlichkeiten klar zuweisen

Eine Richtlinie ohne klare Zuständigkeiten bleibt wirkungslos. Folgende Rollen sollten definiert sein:

Geschäftsführung: Gibt die Richtlinie frei, stellt Ressourcen bereit, trägt die Gesamtverantwortung.

Informationssicherheitsbeauftragter (ISB): Erstellt und pflegt die Richtlinie, überwacht die Einhaltung, berichtet an die Geschäftsführung.

IT-Leitung: Verantwortet die technische Umsetzung, erstellt das Backup-Konzept auf Basis der Richtlinie, überwacht den Betrieb der Backup-Infrastruktur.

Backup-Administrator: Führt die tägliche Überwachung durch, reagiert auf Fehlermeldungen, führt Restore-Tests durch, dokumentiert die Ergebnisse.

Fachabteilungen: Definieren die geschäftlichen Anforderungen an Verfügbarkeit und Aufbewahrung, melden neue Systeme und Datenbestände an, nehmen an Restore-Tests teil (Validierung der wiederhergestellten Daten).

Die Richtlinie muss festlegen, dass bei Personalwechsel in einer dieser Rollen eine ordentliche Übergabe der Backup-Verantwortlichkeiten stattfindet und dokumentiert wird.

Monitoring und Eskalation

Backup-Jobs können aus vielen Gründen fehlschlagen: Speicher voll, Netzwerkverbindung unterbrochen, Quellsystem nicht erreichbar, Zeitfenster überschritten. Die Richtlinie muss definieren, wie mit Fehlern umgegangen wird.

Automatisiertes Monitoring: Alle Backup-Jobs werden automatisiert überwacht. Erfolgreiche und fehlgeschlagene Jobs erzeugen Meldungen an das zuständige Team.

Tägliche Prüfung: Der Backup-Administrator prüft jeden Werktag die Ergebnisse der nächtlichen Sicherung und bestätigt die Prüfung.

Eskalationsverfahren: Fehlgeschlagene Backups werden sofort (nicht am nächsten Tag) eskaliert. Die Richtlinie definiert Eskalationsstufen: einmaliger Fehler wird behoben und nachgeholt, wiederholte Fehler werden an die IT-Leitung eskaliert, anhaltende Ausfälle werden an den ISB und die Geschäftsführung gemeldet.

Reporting: Monatliche oder vierteljährliche Berichte über den Backup-Status fließen in das Management-Review des ISMS ein. Der Bericht enthält Erfolgsquoten, aufgetretene Probleme, durchgeführte Restore-Tests und den aktuellen Stand der Compliance mit der Richtlinie.

Sonderfälle und häufige Fallstricke

Cloud-Dienste und SaaS

Viele Unternehmen gehen davon aus, dass Cloud-Anbieter wie Microsoft 365, Google Workspace oder Salesforce die Datensicherung übernehmen. Das ist ein gefährlicher Irrtum. Die meisten SaaS-Anbieter sichern ihre Infrastruktur, nicht deine Daten. Gelöschte E-Mails, SharePoint-Dokumente oder CRM-Datensätze sind nach einer kurzen Aufbewahrungsfrist (oft 30 bis 93 Tage) unwiederbringlich verloren.

Die Richtlinie muss festlegen, dass auch SaaS-Daten in die Backup-Strategie einbezogen werden. Ein eigener Artikel beschreibt, warum ein separates Cloud-Backup für Microsoft 365 unverzichtbar ist. Dafür gibt es spezialisierte Backup-Lösungen (z.B. Veeam Backup for Microsoft 365, Acronis, Spanning).

Datenbanken

Datenbankbackups erfordern besondere Sorgfalt. Ein dateibasiertes Backup einer laufenden Datenbank liefert unter Umständen inkonsistente Daten. Die Richtlinie muss vorgeben, dass Datenbanken mit datenbankspezifischen Methoden gesichert werden (Dump, Snapshot, Log-Shipping) und dass die Konsistenz der Sicherung Teil des Restore-Tests ist.

Verschlüsselte Systeme

Wenn die Produktivdaten verschlüsselt sind (Festplattenverschlüsselung, Datenbankverschlüsselung), muss sichergestellt sein, dass die Backup-Daten ebenfalls verschlüsselt sind und dass die Entschlüsselungsschlüssel für den Restore verfügbar sind. Die Richtlinie sollte explizit darauf hinweisen, dass Schlüsselmaterial separat und sicher aufbewahrt wird.

Virtuelle Maschinen und Container

Moderne Infrastrukturen basieren auf Virtualisierung und Containerisierung. Die Richtlinie muss klarstellen, ob VM-Level-Backups (Snapshot der gesamten VM) oder Application-Level-Backups (Sicherung der Daten innerhalb der VM) gefordert sind. In der Praxis ist oft eine Kombination sinnvoll: VM-Snapshots für schnelle Wiederherstellung und applikationsspezifische Backups für granulare Restores.

Beispielgliederung für eine Backup-Richtlinie

Wenn du eine Backup-Richtlinie für dein Unternehmen erstellen willst, kannst du dich an folgender Gliederung orientieren:

1. Zweck und Geltungsbereich - Warum existiert die Richtlinie, für wen gilt sie?
2. Begriffe und Definitionen - RTO, RPO, Vollsicherung, inkrementell, differentiell
3. Normative Grundlagen - ISO 27001 A.8.13, NIS2 Art. 21 Nr. 3, BSI IT-Grundschutz
4. Grundsätze - 3-2-1-Regel, Verschlüsselungspflicht, Restore-Test-Pflicht
5. Klassifizierung und Sicherungsanforderungen - Backup-Klassen A bis D mit RTO, RPO, Intervall
6. Sicherungsverfahren - Zugelassene Sicherungsarten und Kombinationen
7. Speicherorte und Medien - Lokal, Offsite, Offline/Air-Gapped
8. Aufbewahrungsfristen - Tabelle mit Fristen pro Sicherungsart
9. Verschlüsselung und Schlüsselmanagement - Algorithmen, Schlüsselverwaltung
10. Zugriffsschutz - Berechtigungen, Protokollierung, Vier-Augen-Prinzip
11. Monitoring und Eskalation - Überwachung, Fehlerbehandlung, Eskalationsstufen
12. Restore-Tests - Häufigkeit, Umfang, Dokumentation
13. Verantwortlichkeiten - Rollen und Aufgaben
14. Sonderfälle - SaaS, Datenbanken, Verschlüsselung, VMs
15. Ausnahmen und Risikoakzeptanz - Prozess für begründete Abweichungen
16. Überprüfung und Aktualisierung - Jährlicher Review-Zyklus
17. Inkrafttreten und Freigabe - Datum, Unterschrift der Geschäftsführung

Diese Gliederung ist kein starres Korsett. Passe sie an dein Unternehmen an. Kleine Unternehmen können Abschnitte zusammenfassen, größere Organisationen werden einzelne Kapitel detaillierter ausarbeiten.

Von der Richtlinie zum gelebten Prozess

Die beste Backup-Richtlinie nützt nichts, wenn sie einmal geschrieben und dann vergessen wird. Damit sie wirkt, muss sie in den Unternehmensalltag eingebettet werden.

Kommunikation: Die Richtlinie wird allen relevanten Mitarbeitenden (IT, Fachabteilungen mit Verantwortung für Daten) bekannt gemacht. Idealerweise bestätigt jeder Beteiligte die Kenntnisnahme schriftlich.

Schulung: Backup-Administratoren werden auf die Richtlinie geschult und kennen ihre Pflichten. Fachabteilungen verstehen, welche Daten in welcher Klasse gesichert werden und was die Aufbewahrungsfristen bedeuten.

Review: Die Richtlinie wird mindestens jährlich überprüft, bei wesentlichen Änderungen an der IT-Infrastruktur auch anlassbezogen. Neue Systeme, neue Cloud-Dienste, geänderte gesetzliche Anforderungen oder ein Sicherheitsvorfall können einen außerplanmäßigen Review auslösen.

Versionierung: Jede Änderung wird dokumentiert, die alte Version archiviert, die neue Version freigegeben und kommuniziert.

ISMS Lite bildet genau diesen Lifecycle ab: Du erstellst die Richtlinie (bei Bedarf mit KI-Unterstützung), versionierst Änderungen automatisch, holst die digitale Kenntnisnahme der Mitarbeitenden ein und lässt die Geschäftsführung per Unterschrift freigeben. So wird die Backup-Richtlinie nicht zum Papiertiger, sondern zum lebendigen Dokument, das dein Unternehmen tatsächlich schützt.

Weiterführende Artikel

• Datensicherung nach BSI: Das 3-2-1-Prinzip und warum es allein nicht reicht
• Backup-Strategie und Restore-Tests: So sicherst du Daten richtig
• Business-Impact-Analyse (BIA): Kritische Prozesse identifizieren
• Wiederanlaufplan erstellen: Nach dem Vorfall schnell zurück in den Betrieb
• Richtlinien-Lifecycle: Von der Erstellung bis zur Außerkraftsetzung