NIS2 und BSIG: Backup-Management, das im Ernstfall trägt

Seit dem 6. Dezember 2025 sind Backup und Notfallwiederherstellung für viele Unternehmen in Deutschland gesetzliche Pflicht. Das NIS2-Umsetzungsgesetz (NIS2UmsuCG) hat dafür das BSI-Gesetz neu gefasst und die europäische NIS2-Richtlinie umgesetzt. Rund 30.000 Unternehmen müssen jetzt nachweisbar Risikomanagement betreiben, viele davon zum ersten Mal. Einen Überblick über alle technischen Anforderungen findest du auf unserer Seite NIS2 für Entwicklung und Betrieb.

Dieser Artikel konzentriert sich auf einen Teil davon, der in der Praxis oft unterschätzt wird: § 30 Abs. 2 Nr. 3 BSIG verlangt Maßnahmen zur „Aufrechterhaltung des Betriebs, wie Backup-Management und Wiederherstellung nach einem Notfall, und Krisenmanagement“. In der Richtlinie ist das Artikel 21 Abs. 2 Buchstabe c. Wir zeigen, was dahintersteckt, welche konkreten Vorgaben es gibt und wie ein Datensicherungskonzept aussieht, das auch einen Ransomware-Angriff übersteht.

Hinweis: Dieser Artikel ist eine technische Einordnung und ersetzt keine Rechtsberatung. Ob und wie dein Unternehmen betroffen ist, klärst du am besten mit deiner Rechtsabteilung oder Kanzlei.

Bist du betroffen?

Das BSIG unterscheidet in § 28 zwei Kategorien. Entscheidend sind der Sektor (Anlage 1 und 2 des Gesetzes) und die Größe:

Einige Einrichtungen sind unabhängig von ihrer Größe erfasst, etwa Betreiber kritischer Anlagen, DNS-Diensteanbieter, TLD-Registries und qualifizierte Vertrauensdiensteanbieter. Für Telekommunikationsanbieter gelten abgesenkte Schwellen. Betroffene Unternehmen müssen sich nach § 33 beim BSI registrieren. Für Einrichtungen, die schon zum Inkrafttreten betroffen waren, endete die Frist am 6. März 2026. Wer erst später betroffen wird, etwa durch Wachstum, hat ab dann drei Monate Zeit. Ob du dazugehörst, kannst du mit der Betroffenheitsprüfung des BSI prüfen.

Für Banken und Versicherungen gilt vorrangig der Digital Operational Resilience Act (DORA). Die Anforderungen an Backup und Wiederherstellung stehen dort in Artikel 12 und gehen in eine ähnliche Richtung.

Backups sind jetzt Chefsache

Neu ist, wer verantwortlich ist. Nach § 38 BSIG muss die Geschäftsleitung die Risikomanagementmaßnahmen umsetzen und ihre Umsetzung überwachen. Sie muss regelmäßig an Schulungen teilnehmen und haftet ihrer Einrichtung für schuldhaft verursachte Schäden.

Die Frage „Funktioniert unser Backup?“ landet damit nicht mehr nur bei der IT, sondern in der Geschäftsführung. Und die braucht eine Antwort, die sich belegen lässt.

Was in dein Datensicherungskonzept gehört

Der Gesetzestext selbst bleibt allgemein. Konkreter wird die Durchführungsverordnung (EU) 2024/2690. Sie gilt unmittelbar für digitale Anbieter wie Cloud-, Rechenzentrums- und DNS-Dienste sowie Managed Service Provider. Für alle anderen ist sie die beste verfügbare Orientierung, was Prüfer:innen unter „Stand der Technik“ verstehen werden.

Abschnitt 4.2 des Anhangs („Backup- und Redundanzmanagement“) fordert im Kern:

• Backups und Redundanz mit ausreichend Ressourcen: Standorte, Systeme und Personal.
• Einen Backup-Plan, abgeleitet aus Risikobewertung und Notfallplan, mit Wiederherstellungszeiten, Zugriffskontrollen und Aufbewahrungsfristen. Die Kopien müssen vollständig sein, ausdrücklich auch mit Konfigurationsdaten und Daten in Cloud-Diensten, und an einem Ort liegen, der nicht im selben Netz wie das System ist und weit genug entfernt, um einen Schaden am Hauptstandort zu überstehen.
• Regelmäßige Integritätsprüfungen der Sicherungskopien.
• Redundanz bei Systemen, Einrichtungen, Personal und Kommunikationswegen, wo nötig.
• Regelmäßige, dokumentierte Tests der Wiederherstellung, mit Korrekturmaßnahmen, wenn etwas nicht funktioniert.

Die ENISA hat dazu eine ausführliche Implementierungshilfe veröffentlicht, mit Beispielen dafür, welche Nachweise als ausreichend gelten.

Zuerst die Frage: Wie viel Ausfall verträgst du?

Jede Backup-Strategie beginnt mit zwei Zahlen pro System:

• RPO (Recovery Point Objective): Wie viele Daten darfst du verlieren? Ein RPO von 24 Stunden heißt: Ein nächtliches Backup reicht. Bei 5 Minuten brauchst du kontinuierliche Replikation oder Point-in-Time-Recovery.
• RTO (Recovery Time Objective): Wie lange darf das System ausfallen, bis es wieder läuft?

Diese Zahlen legt nicht die IT fest, sondern das Business, idealerweise in einer Business-Impact-Analyse nach BSI-Standard 200-4. Ein pragmatischer Einstieg sind drei Klassen:

Erst daraus ergeben sich Backup-Frequenz, Speicherort und der Aufwand, den du in Tests steckst.

Ransomware-sichere Backups

Ransomware-Gruppen suchen gezielt nach Backups und löschen oder verschlüsseln sie, bevor sie die Produktivsysteme angreifen. Ein Backup, auf das ein kompromittierter Admin-Account zugreifen kann, schützt dich also nicht. Bewährt hat sich die 3-2-1-1-0-Regel:

• 3 Kopien deiner Daten,
• auf 2 unterschiedlichen Medien oder Systemen,
• 1 davon an einem anderen Standort,
• 1 davon unveränderbar (Immutable Backup, etwa mit S3 Object Lock, MinIO Object Lock oder WORM-Medien) oder offline,
• 0 Fehler bei der Prüfung der Wiederherstellung.

Achte bei Object Lock auf den Modus. Nur im Compliance-Modus kann niemand die Sperre vorzeitig aufheben, auch kein Root-Account. Im Governance-Modus darf jeder löschen, der die Berechtigung s3:BypassGovernanceRetention hat, und genau diese Rechte sucht ein Angreifer zuerst.

Dazu kommen Punkte, die in Projekten regelmäßig fehlen:

• Eigene Identitäten für das Backup-System. Backups gehören nicht in dieselbe Active-Directory-Domäne wie die Produktion. Getrennte Zugänge, Multi-Faktor-Authentifizierung und möglichst wenige Personen mit Löschrechten.
• Schlüsselmanagement. Verschlüsselte Backups sind wertlos, wenn der Schlüssel mit dem kompromittierten System verloren geht. Bewahre die Schlüssel getrennt auf und teste, ob du ohne die Produktivumgebung an sie herankommst.
• Aufbewahrung länger als die Verweildauer. Angreifer sind oft Tage bis Wochen im Netz, bevor sie verschlüsseln. Hältst du Backups nur sieben Tage vor, kann jede Kopie bereits kompromittiert sein. Die Aufbewahrungsfrist muss deshalb länger sein als eine realistische Verweildauer.
• Das Backup-System selbst. Katalog und Konfiguration deiner Backup-Software, etwa bei Veeam oder Bareos, gehören selbst gesichert. Fehlen sie, sind die Daten zwar da, aber du kommst nicht mehr an sie heran.
• Aufbewahrung und Datenschutz. Unveränderbare Backups und Löschpflichten nach DSGVO widersprechen sich auf den ersten Blick. Kurze, dokumentierte Aufbewahrungsfristen und ein Prozess für Wiederherstellungen, der gelöschte Datensätze erneut entfernt, lösen den Konflikt.

Was oft nicht gesichert wird

Die meisten Lücken entstehen nicht bei der klassischen Datenbank im Rechenzentrum, sondern hier:

• SaaS-Dienste: Microsoft 365, GitHub, Jira oder dein CRM. Die Anbieter sichern ihre Infrastruktur, aber nicht zwingend deine Daten gegen versehentliches Löschen oder einen kompromittierten Account. Lies das Shared-Responsibility-Modell deines Anbieters genau.
• Kubernetes: Neben den Persistent Volumes brauchst du den Cluster-Zustand. Bei selbst betriebenen Clustern sicherst du etcd per Snapshot. Bei Managed Kubernetes (EKS, AKS, GKE) hast du darauf keinen Zugriff. Dort sicherst du API-Objekte und Volumes mit Velero, oder du baust den Cluster-Zustand per GitOps neu auf und sicherst nur die Daten. Denk an die Schlüssel: Wer Secrets mit Sealed Secrets oder einem KMS verschlüsselt, braucht nach dem Restore genau diese Schlüssel. Mehr dazu in unserem Artikel zu Kubernetes für Software-Produkte.
• Datenbanken: Eine im laufenden Betrieb kopierte Datenbankdatei ist kein verlässliches Backup. Nutze die Werkzeuge der Datenbank: bei PostgreSQL Base-Backups plus WAL-Archivierung mit pgBackRest oder WAL-G, die auch Point-in-Time-Recovery ermöglichen.
• Infrastruktur und Konfiguration: Wenn deine Plattform als Code in Git liegt, ist das Repository Teil deines Disaster-Recovery-Plans. Mit GitOps und Argo CD baust du eine Umgebung aus Git wieder auf, statt sie aus Backups zusammenzusuchen.
• Manuelle Änderungen an IaC-Infrastruktur: Wurde eine Cloud-Ressource, ein Switch oder eine Appliance ursprünglich per Terraform oder Ansible provisioniert und danach von Hand angepasst, stellt dein Code nur noch den alten Stand her. Diese Abweichung (Drift) fällt meist erst bei der Wiederherstellung auf. Erkenne Drift regelmäßig, etwa mit terraform plan in der Pipeline, und überführe manuelle Änderungen zurück in den Code.
• Konfiguration nach der Installation: Viele Anwendungen werden automatisiert installiert, aber danach über ihre Oberfläche konfiguriert: Benutzer, Gruppen, Runner, Integrationen, Webhooks. Bei GitLab zum Beispiel stecken solche Einstellungen in der Datenbank und in Konfigurationsdateien, die das Installationsskript nicht kennt. Sichere sie mit, oder verwalte sie ebenfalls als Code.

Was wir in Projekten immer wieder sehen

Wenn wir bei Kund:innen auf das Backup-Management schauen, finden wir fast immer eine oder mehrere dieser Schwachstellen:

• Backups in derselben Umgebung wie die Anwendung. Liegen Backup und Anwendung im selben Cloud-Account, im selben Cluster oder auf demselben Storage, nimmt ein Angriff oder eine Fehlbedienung beides auf einmal mit.
• Backup-Jobs werden kaum oder gar nicht überwacht. Ein Job, der seit Wochen fehlschlägt oder nur noch leere Dateien schreibt, fällt erst auf, wenn jemand ein Backup braucht.
• Restore-Tests nur einmal nach der Einführung. Danach ändern sich Datenmengen, Versionen und Abhängigkeiten, aber niemand prüft mehr, ob die Wiederherstellung noch funktioniert und wie lange sie dauert.
• Kein WORM. Ohne unveränderbaren Speicher kann jeder, der Schreibrechte auf das Backup-Ziel hat, Backups löschen oder verschlüsseln, auch ein kompromittierter Account.
• Backups unvollständig. Ein typisches Beispiel ist GitLab: Repositories und Datenbank werden gesichert, aber die Datei mit den Schlüsseln, mit denen GitLab sensible Daten in der Datenbank verschlüsselt (gitlab-secrets.json), ist nicht Teil des Standard-Backups. Ohne sie lassen sich CI/CD-Variablen, Zwei-Faktor-Einstellungen und Runner-Tokens nach dem Restore nicht mehr entschlüsseln. Das merkt man nur, wenn man die Wiederherstellung wirklich testet.

Die Wiederherstellung planen, nicht nur das Backup

Die Notfallwiederherstellung (Disaster Recovery) scheitert selten am Backup selbst, sondern an der Reihenfolge. Bevor deine Fachanwendung wieder läuft, brauchst du Netzwerk, DNS, Identity Provider, Secrets und Datenbanken. Ein Disaster-Recovery-Plan legt deshalb fest:

1. Wer entscheidet und wer wiederherstellt, inklusive Vertretung.
2. In welcher Reihenfolge Systeme zurückkommen, abgeleitet aus den Abhängigkeiten.
3. Wo die Anleitung liegt. Ein Runbook im Wiki, das mit dem Wiki ausfällt, hilft nicht. Halte eine Offline-Kopie bereit.
4. Wie ihr kommuniziert, wenn E-Mail und Chat nicht funktionieren.

Ob der Plan trägt, zeigen nur Wiederherstellungstests, und zwar auf mehreren Stufen: einzelne Dateien, ganze Systeme und einmal im Jahr eine vollständige Notfallwiederherstellung als Übung. Am meisten Sicherheit geben automatisierte Restore-Tests, etwa eine Pipeline, die jede Nacht die Produktionsdatenbank in eine Staging-Umgebung zurückspielt und prüft. So misst du dein tatsächliches RTO, statt es zu schätzen, und das Protokoll ist gleich dein Nachweis.

Plane dabei die Meldepflichten mit ein. Nach § 32 BSIG musst du einen erheblichen Sicherheitsvorfall ab Kenntnis spätestens nach 24 Stunden mit einer frühen Erstmeldung, nach 72 Stunden mit einer Meldung und nach einem Monat mit einer Abschlussmeldung beim BSI melden. Diese Fristen laufen parallel zur Wiederherstellung. Lege vorher fest, wer meldet.

Ein Szenario: Freitag, 22 Uhr

Ein Monitoring-Alert meldet ungewöhnlich viele Dateiänderungen auf dem Fileserver. Kurz darauf sind die ersten Systeme verschlüsselt. Was jetzt zählt:

• Stunde 0–2: Krisenstab zusammenrufen, betroffene Systeme isolieren, Backups vom Netz trennen, falls nicht ohnehin schon getrennt. Geschäftsleitung informieren.
• Bis Stunde 24: Frühe Erstmeldung an das BSI. Prüfen, welche Backups sauber sind, also aus der Zeit vor dem ersten Zugriff der Angreifer stammen.
• Ab Stunde 24: Wiederherstellung in der geplanten Reihenfolge, zuerst in eine saubere, isolierte Umgebung (Clean Room). Dort prüfst du die Daten auf Schadsoftware, bevor sie zurück in die Produktion gehen, damit der Angreifer nicht mit dem Backup zurückkommt. Kritische Systeme gemäß RTO zuerst.
• Bis Stunde 72: Meldung mit erster Bewertung an das BSI.
• Danach: Ursachenanalyse, Abschlussmeldung, Lessons Learned in den Plan zurückspielen.

Wer diesen Ablauf vorher einmal als Tabletop-Übung durchgespielt hat, ist im Ernstfall deutlich schneller.

Was du im Audit vorzeigen solltest

NIS2 verlangt nicht nur Maßnahmen, sondern Nachweise. Halte mindestens diese Unterlagen aktuell:

• Backup-Richtlinie mit RPO und RTO je Systemklasse
• Übersicht, welche Systeme und Daten gesichert werden und wo
• Protokolle der Wiederherstellungstests mit gemessener Dauer
• Monitoring-Historie der Backups und Reaktion auf Alerts
• Disaster-Recovery-Plan mit Datum der letzten Übung
• Nachweis, dass die Geschäftsleitung die Maßnahmen kennt und überwacht

Am einfachsten wird das, wenn die Nachweise automatisch entstehen: Pipelines, die Tests protokollieren, Monitoring mit Historie und dokumentierte Architekturentscheidungen.

Einordnung in bekannte Standards

Wenn du bereits nach einem Standard arbeitest, kannst du vieles wiederverwenden:

Checkliste für die Praxis

Mit diesen Fragen findest du schnell heraus, wo du stehst:

• Sind RPO und RTO für deine wichtigsten Systeme festgelegt? Und hat das Business sie freigegeben?
• Weißt du, welche Daten gesichert werden und welche nicht? Gerade SaaS-Dienste und neue Systeme fallen oft durchs Raster.
• Gibt es eine unveränderbare oder Offline-Kopie? Und kann ein kompromittierter Admin-Account sie löschen?
• Sind die Zugänge zum Backup-System von der Produktion getrennt? Mit eigener Multi-Faktor-Authentifizierung?
• Kommst du an die Schlüssel, wenn Prod weg ist?
• Merkst du es, wenn ein Backup fehlt oder auffällig klein ist? Ein Job, der „erfolgreich“ meldet, heißt noch nicht, dass die Datei vollständig da ist.
• Wann hast du zuletzt eine Wiederherstellung getestet? Wie lange hat sie gedauert, und passt das zum RTO?
• Kennt jede:r im Team den Notfallplan? Und ist er verfügbar, wenn die Systeme ausfallen?
• Weißt du, wer innerhalb von 24 Stunden an das BSI meldet?
• Kannst du all das im Audit belegen?

Backups aktiv überwachen

Für die Überwachung haben wir backmon entwickelt. backmon prüft Vorhandensein, Größe und Alter deiner Backup-Dateien im Dateisystem oder in S3-kompatiblem Object Storage und liefert die Metriken an Prometheus und Grafana. Dort baust du Dashboards und Alerts, wenn ein Backup fehlt, zu alt ist oder aus der Reihe fällt. Die Historie dient dir gleichzeitig als Nachweis im Audit. backmon ist Open Source und kostenlos.

Damit beantwortest du die Frage „Ist das Backup da?“. Ob es sich auch wiederherstellen lässt, zeigen nur Wiederherstellungstests. Beides zusammen ergibt ein Backup-Management, das du vor Prüfer:innen und deiner Geschäftsleitung vertreten kannst.

Du willst wissen, was NIS2 konkret für deine Architektur und Infrastruktur bedeutet? Auf unserer Seite NIS2 für Entwicklung und Betrieb findest du alle technischen Baustellen im Überblick. Oder sprich uns direkt an: Im Advisory beantworten wir genau solche Fragen.

Quellen

• Richtlinie (EU) 2022/2555 (NIS2-Richtlinie), Art. 21: EUR-Lex
• BSI-Gesetz (BSIG) in der Fassung des NIS2UmsuCG: § 28, § 30, § 32, § 33, § 38
• Durchführungsverordnung (EU) 2024/2690, Anhang Abschnitt 4: EUR-Lex
• ENISA: NIS2 Technical Implementation Guidance (Juni 2025): enisa.europa.eu
• BSI: NIS-2-regulierte Unternehmen und Betroffenheitsprüfung: bsi.bund.de
• BSI: IT-Grundschutz-Kompendium, Baustein CON.3: bsi.bund.de
• BSI-Standard 200-4 Business Continuity Management: bsi.bund.de
• Verordnung (EU) 2022/2554 (DORA), Art. 12: EUR-Lex
• ISO/IEC 27001:2022: iso.org
• GitLab-Dokumentation: Backup von Konfigurations- und Secrets-Dateien: docs.gitlab.com

Ursprünglich veröffentlicht am 9. Juli 2024.