NIS2 Backup-Strategie: Die 3-2-1-Regel für Compliance

NIS2 Backup-Pflicht: Die 3-2-1-Regel als Standard

Letzte Aktualisierung: 23. März 2026

NIS2 verpflichtet Unternehmen gemäß Art. 21 Abs. 2 Buchst. c der Richtlinie (EU) 2022/2555 zu belastbaren Maßnahmen für Business Continuity, Backup-Management, Disaster Recovery und Krisenmanagement. Für die Praxis heißt das: Ein NIS2-konformes Backup ist nicht nur eine tägliche Sicherung, sondern ein getestetes Wiederherstellungssystem mit klaren Zielen für Datenverlust und Wiederanlauf.

Die operative Kernaussage lautet deshalb: Wer NIS2 Backup sauber umsetzen will, braucht mindestens die 3-2-1-Regel, dokumentierte RTO- und RPO-Werte, regelmäßige Restore-Tests und eine Trennung zwischen Produktivsystem, Backup-Infrastruktur und Offsite-Kopie. Genau diese Kombination reduziert das Risiko, dass Ransomware, Fehlkonfigurationen oder Hardware-Schäden gleichzeitig Produktion und Sicherung zerstören.

Für die Einordnung in das größere NIS2-Programm lohnt der Blick auf die NIS2 Online-Schulung, auf den Beitrag zu NIS2 Schwachstellenmanagement und auf die Analyse zu NIS2 Verschlüsselung nach BSI. Wenn Sie Grundlagen zu Begriffen suchen, können Sie außerdem den Eintrag Backup im Glossar ergänzend heranziehen.

Was Art. 21 NIS2 und § 30 BSIG zu Backups und Business Continuity fordern

Art. 21 Abs. 2 Buchst. c NIS2 verlangt ausdrücklich Maßnahmen zur Aufrechterhaltung des Betriebs, insbesondere Backup-Management, Disaster Recovery und Krisenmanagement. Diese Formulierung ist wichtig, weil sie Backups nicht als rein technische Nebenaufgabe behandelt, sondern als Teil eines übergreifenden Cyberrisikomanagements mit direktem Bezug zur Betriebsfortführung.

§ 30 Abs. 2 Nr. 3 BSIG übernimmt diese Vorgabe für besonders wichtige und wichtige Einrichtungen nahezu wörtlich und nennt „Aufrechterhaltung des Betriebs, wie Backup-Management und Wiederherstellung nach einem Notfall, und Krisenmanagement“. Für Unternehmen in Deutschland ist das die zentrale Brücke zwischen der europäischen Pflicht aus NIS2 und der nationalen Aufsichtspraxis. Ein Backup ist damit nicht nur sinnvoll, sondern ausdrücklich Gegenstand einer dokumentationspflichtigen Risikomanagementmaßnahme.

Die Rechtslogik ist klar: Der Gesetzgeber erwartet keine starre bestimmte Software oder ein einzelnes Tool, sondern geeignete, verhältnismäßige und wirksame Maßnahmen. Deshalb kommt es in der Praxis auf vier Fragen an:

1. Sind die geschäftskritischen Systeme und Daten überhaupt im Backup-Scope enthalten?
2. Ist das Backup gegen dieselben Risiken geschützt wie die Produktion, insbesondere gegen Ransomware und Administrationsmissbrauch?
3. Ist die Wiederherstellung innerhalb der geforderten Geschäftszeiten realistisch erreichbar?
4. Können Sie diese Wirksamkeit im Audit oder bei einer Aufsichtsprüfung mit Dokumentation und Tests belegen?

Wer nur Jobs erfolgreich durchlaufen lässt, beantwortet keine dieser Fragen. Ein grüner Haken im Backup-Tool ist kein Compliance-Nachweis, wenn Restore-Proben fehlen, Administratorrechte unklar verteilt sind oder das Offsite-Backup im selben kompromittierten Mandanten liegt. Genau deshalb gehören Backup-Strategie, Berechtigungskonzept, Notfallkommunikation und Wiederanlaufplanung zusammen.

Das BSI ordnet Backup und Wiederherstellung ebenfalls in einen größeren Sicherheitsrahmen ein. Im IT-Grundschutz werden Datensicherung, Notfallvorsorge, Zugriffsschutz und organisatorische Verantwortlichkeiten als zusammenhängende Bausteine verstanden. Für den Mittelstand ist das praktisch hilfreich, weil es den Blick weg von der Einzelfrage „Wurde gesichert?“ hin zur belastbaren Frage „Können wir nach einem Sicherheitsvorfall geordnet wieder anlaufen?“ verschiebt.

Die 3-2-1-Regel erklärt: 3 Kopien, 2 Medien, 1 Offsite

Die 3-2-1-Regel ist der bewährte Mindeststandard für ein robustes NIS2 Backup, weil sie einen einfachen Grundsatz in eine hohe Ausfallsicherheit übersetzt. Drei Kopien derselben Daten, zwei unterschiedliche Medien oder Speicherklassen und eine Offsite-Kopie reduzieren das Risiko von Datenverlust, Sabotage und gleichzeitiger Beschädigung erheblich.

Die drei Elemente bedeuten im Unternehmensalltag:

Die Regel wirkt gerade deshalb so stark, weil sie mehrere Angriffsszenarien gleichzeitig adressiert. Ein versehentlich gelöschter Datenbestand lässt sich aus einer zweiten Kopie zurückholen. Ein Hardware-Ausfall zerstört nicht alle Medien zugleich. Ein Ransomware-Angriff, der Produktivsysteme und lokal erreichbare Shares verschlüsselt, scheitert eher an einer unveränderbaren oder isolierten Offsite-Kopie.

Für NIS2 reicht es allerdings nicht, die 3-2-1-Regel formal zu behaupten. Sie müssen sie technisch sauber ausprägen. Zwei Kopien in derselben virtualisierten Umgebung mit denselben privilegierten Konten sind keine belastbare Diversifizierung. Ebenso wenig genügt ein Offsite-Backup, wenn dieselben Admin-Credentials, dieselben Management-Schnittstellen oder derselbe kompromittierte Cloud-Tenant Zugriff auf alle Ebenen haben.

Deshalb wird in der Praxis oft ein verschärfter Ansatz verwendet, etwa 3-2-1-1-0: zusätzlich eine unveränderbare oder air-gapped Kopie und null ungeprüfte Restore-Fehler. Auch wenn NIS2 diese Formel nicht wörtlich verlangt, ist ihre Stoßrichtung regulatorisch sinnvoll: Die Backup-Architektur muss nachweislich gegen reale Angriffsmuster standhalten. Für die Verbindung zu weiteren NIS2-Kontrollen sind besonders Schwachstellenmanagement und Verschlüsselung nach BSI relevant.

Backup-Strategie für den Mittelstand: Praxis-Leitfaden

Eine NIS2-taugliche Backup-Strategie für den Mittelstand beginnt nicht mit der Auswahl eines Tools, sondern mit einer Priorisierung der Geschäftsprozesse. Unternehmen müssen zuerst wissen, welche Systeme, Datenbestände und Schnittstellen für die Leistungserbringung kritisch sind. Ohne diese Einordnung sichern Teams oft zu viel Unwichtiges und zu wenig Kritisches.

Der praktikabelste Ablauf für KMU besteht aus sieben Schritten:

1. Kritische Dienste bestimmen. Identifizieren Sie ERP, E-Mail, Fileserver, Identitätsdienste, Kundenportale, Produktionssysteme, Cloud-Dienste und Konfigurationsdaten, deren Ausfall den Betrieb erheblich beeinträchtigt.
2. RTO und RPO festlegen. Definieren Sie pro kritischem System, wie schnell es wieder verfügbar sein muss und wie viel Datenverlust maximal akzeptabel ist.
3. Backup-Klassen zuweisen. Legen Sie fest, welche Systeme stündlich, täglich, wöchentlich oder versionsbasiert gesichert werden und wie lange Aufbewahrungsfristen gelten.
4. 3-2-1 technisch umsetzen. Trennen Sie Primärdaten, Backup-Repository und Offsite-Kopie technisch und organisatorisch voneinander.
5. Zugriffe härten. Schützen Sie Backup-Administrationskonten mit Multi-Faktor-Authentifizierung, Vier-Augen-Prinzip und separaten Berechtigungen.
6. Restore-Prozesse dokumentieren. Beschreiben Sie, wer im Notfall welche Systeme in welcher Reihenfolge zurückspielt und welche Freigaben dafür nötig sind.
7. Tests und Verbesserungen planen. Führen Sie regelmäßige Proberücksicherungen durch und gleichen Sie die Ergebnisse mit Ihren RTO- und RPO-Zielen ab.

Die häufigste Fehlannahme im Mittelstand lautet, dass eine moderne SaaS- oder Cloud-Umgebung das Backup-Problem bereits löst. Viele Dienste bieten Verfügbarkeit, aber kein vollwertiges kundenseitiges Recovery für versehentliche Löschung, böswillige Änderungen oder länger unentdeckte Manipulationen. NIS2 fragt jedoch nach der Fähigkeit zur Wiederherstellung, nicht nur nach einem laufenden Dienst im Normalbetrieb.

Ebenso problematisch ist der Fokus auf Serverdaten ohne Berücksichtigung der Identitäts- und Steuerungsebene. Wenn etwa Active Directory, Microsoft 365, Entra-ID, Firewall-Konfigurationen oder Virtualisierungs-Manager fehlen, dauert der Wiederanlauf oft deutlich länger als geplant. Ein belastbares NIS2 Backup muss deshalb nicht nur Geschäftsdaten, sondern auch Konfigurationen, Schlüsselmaterial, Infrastruktur-Templates und Recovery-Dokumentation umfassen.

Die folgende Übersicht zeigt, wie Mittelständler typische Systemklassen priorisieren können:

Praktisch wirksam wird die Strategie erst, wenn die Zuständigkeiten klar verteilt sind. Die Geschäftsleitung verantwortet die Freigabe der Risikostrategie, die IT oder Informationssicherheit definiert Architektur und Schutzmaßnahmen, die Fachbereiche priorisieren Geschäftsprozesse, und externe Provider müssen vertraglich zu Backup-, Restore- und Meldepflichten eingebunden werden. Gerade bei Managed Services ist das entscheidend: Ausgelagerte IT entbindet nicht von der Verantwortung für NIS2-konforme Wiederherstellungsfähigkeit.

Backup-Tests und Recovery-Zeiten: RTO und RPO richtig steuern

Ein NIS2 Backup ist erst dann belastbar, wenn es unter realistischen Bedingungen getestet wurde. Die zentrale Managementfrage lautet daher nicht „Haben wir ein Backup?“, sondern „Können wir innerhalb unseres Zielkorridors wieder anlaufen, und können wir das nachweisen?“ Genau hier kommen RTO und RPO ins Spiel.

Das Recovery Time Objective (RTO) beschreibt die maximal tolerierbare Zeit bis zur Wiederherstellung eines Systems oder Prozesses. Das Recovery Point Objective (RPO) beschreibt den maximal tolerierbaren Datenverlust gemessen als Zeitspanne zwischen letztem verwertbaren Datenstand und dem Vorfall. Beide Kennzahlen übersetzen Geschäftsanforderungen in technische und organisatorische Vorgaben.

Ein Beispiel macht den Unterschied greifbar:

Diese Werte dürfen nicht aus der IT heraus geraten werden, sondern müssen mit den Fachbereichen abgestimmt werden. Ein Vertriebssystem, das laut Fachbereich acht Stunden ausfallen darf, braucht eine andere Architektur als ein Produktionsleitsystem mit enger Taktung. Genau deshalb sind RTO und RPO nicht nur Technikparameter, sondern Ausdruck des akzeptierten Geschäftsrisikos.

Für die Testpraxis sollten Unternehmen mindestens vier Testarten unterscheiden:

1. Datei-Restore-Test: Einzelne Dateien, Postfächer oder Datenbankobjekte werden gezielt wiederhergestellt.
2. System-Restore-Test: Ein komplettes System oder eine virtuelle Maschine wird aus dem Backup neu aufgebaut.
3. Anwendungs-Restore-Test: Die Anwendung wird technisch und fachlich geprüft, also nicht nur gestartet, sondern funktional verifiziert.
4. Notfallübung: Rollen, Kommunikationswege, Freigaben und Prioritäten werden als Tabletop oder Live-Test durchgespielt.

Die häufigste Audit-Lücke entsteht zwischen erfolgreichem Backup-Job und nicht belegter Anwendungsfähigkeit. Ein Restore kann technisch gelingen und trotzdem operativ scheitern, wenn Zertifikate fehlen, Abhängigkeiten zu externen Schnittstellen übersehen werden oder Fachanwender die Datenkonsistenz nicht bestätigen können. NIS2 denkt Resilienz aus gutem Grund als Managementsystem, nicht als Einzeldisziplin.

Ebenso wichtig ist die Frequenz der Tests. Kritische Systeme sollten so oft getestet werden, dass Konfigurationsänderungen, Software-Updates, neue Abhängigkeiten und geänderte Datenmengen berücksichtigt bleiben. In der Praxis heißt das oft: häufige kleine Restore-Proben, quartalsweise Systemtests und mindestens jährliche durchgängige Notfallübungen. Entscheidend ist weniger ein starres Kalenderdatum als der belastbare Nachweis, dass die Testtiefe zum Risiko passt.

Typische Fehler bei NIS2 Backups

Die meisten Compliance- und Resilienzlücken entstehen nicht durch fehlende Technik, sondern durch falsche Annahmen. Unternehmen investieren in Backup-Lösungen, lassen aber die organisatorischen Schwachstellen bestehen. Gerade unter NIS2 ist das riskant, weil die Norm ausdrücklich auf wirksame Maßnahmen und dokumentierte Umsetzung abstellt.

Die fünf häufigsten Fehler sind:

1. Kein Offsite oder kein echter Medienbruch. Zwei Sicherungen im selben Storage-Cluster sind kein belastbares 3-2-1-Modell.
2. Backup-Admin gleich Domänen-Admin. Wenn kompromittierte Hauptkonten auch auf die Sicherung zugreifen können, fällt die Schutzschicht weg.
3. Keine getestete Wiederherstellung. Ungeprüfte Backups sind bestenfalls Hoffnung, aber kein Nachweis.
4. Kritische Konfigurationen fehlen. Identitätssysteme, Netzwerkregeln, Zertifikate und Automatisierung werden oft vergessen.
5. Business Continuity und Backup laufen getrennt. Ohne Priorisierung, Kommunikationsplan und Notbetriebskonzept bleibt Recovery unkoordiniert.

Wer diese Fehler systematisch vermeiden will, sollte Backup immer gemeinsam mit Vorfallbehandlung, Schwachstellenmanagement und kryptografischem Schutz betrachten. Die Verbindung zu NIS2 Schwachstellenmanagement und NIS2 Verschlüsselung nach BSI ist deshalb keine SEO-Beilage, sondern inhaltlich zwingend: ungepatchte Systeme erhöhen die Ausfallwahrscheinlichkeit, unzureichend geschützte Backups erhöhen den Wiederherstellungsaufwand.

NIS2 Backup-Checkliste für den Mittelstand

Eine kompakte Checkliste macht die Umsetzung für Teams handhabbar. Die folgende Liste ist bewusst so formuliert, dass sie in Richtlinien, Projektplänen oder Management-Reviews übernommen werden kann:

1. Sind alle kritischen Systeme, Daten und Konfigurationen im Backup-Scope enthalten?
2. Gibt es mindestens drei Kopien auf zwei getrennten Speicherklassen und eine Offsite-Kopie?
3. Sind Backup-Zugänge separiert, mit Multi-Faktor-Authentifizierung geschützt und dokumentiert?
4. Sind RTO und RPO pro kritischem Dienst freigegeben und fachlich abgestimmt?
5. Gibt es dokumentierte Restore-Abläufe mit Rollen, Reihenfolge und Freigaben?
6. Werden Restore-Tests regelmäßig durchgeführt und mit Ergebnis, Dauer und Abweichungen protokolliert?
7. Ist die Backup-Strategie in Business Continuity, Krisenmanagement und Meldeprozesse eingebettet?

Diese Struktur ist auch für Lenkungskreise hilfreich, weil sie technische und organisatorische Verantwortung zusammenführt. Führungskräfte sehen damit nicht nur, ob eine Sicherung existiert, sondern ob die Wiederherstellung zur Risikoakzeptanz des Unternehmens passt.

Fazit: NIS2 Backup ist Wiederherstellungsfähigkeit, nicht Datensammlung

NIS2 Backup bedeutet in der Sache Wiederherstellungsfähigkeit nach Art. 21 Abs. 2 Buchst. c NIS2 und § 30 Abs. 2 Nr. 3 BSIG. Für mittelständische Unternehmen ist die 3-2-1-Regel der richtige Ausgangspunkt, aber erst in Verbindung mit Offsite-Trennung, privilegiengesicherten Zugängen, dokumentierten RTO- und RPO-Zielen sowie regelmäßigen Restore-Tests entsteht daraus eine belastbare Compliance- und Resilienzmaßnahme.

Wenn Sie Ihre Backup-Strategie nicht nur technisch, sondern auch regulatorisch sauber aufsetzen wollen, ist eine strukturierte Einordnung der Rollen und Pflichten sinnvoll. Dafür bietet die NIS2 Online-Schulung einen kompakten Einstieg für Geschäftsleitung, Compliance und IT; wenn Sie eine konkrete Umsetzungsplanung benötigen, ist zusätzlich eine Beratung zur Verzahnung von Backup, Business Continuity und Vorfallmanagement der nächste sinnvolle Schritt.

FAQ zu NIS2 Backup

Ist Backup unter NIS2 Pflicht?

Ja. Art. 21 Abs. 2 Buchst. c NIS2 nennt Business Continuity, Backup-Management, Disaster Recovery und Krisenmanagement ausdrücklich als Mindestmaßnahmen des Cyberrisikomanagements. In Deutschland konkretisiert § 30 Abs. 2 Nr. 3 BSIG dieselbe Erwartung für regulierte Einrichtungen.

Wie implementiere ich Backup für NIS2-Compliance?

Sie implementieren NIS2-konformes Backup am pragmatischsten in fünf Schritten: kritische Systeme bestimmen, RTO und RPO festlegen, die 3-2-1-Regel technisch umsetzen, Restore-Prozesse dokumentieren und die Wiederherstellung regelmäßig testen. Ohne Tests und klare Zuständigkeiten bleibt die Maßnahme unvollständig.

Reicht die 3-2-1-Regel allein für NIS2 aus?

Nein. Die 3-2-1-Regel ist der technische Kern, aber NIS2 verlangt zusätzlich wirksame organisatorische Maßnahmen. Dazu gehören Rollen, Dokumentation, Schutz der Backup-Administrationskonten, Verzahnung mit Krisenmanagement und belastbare Nachweise der Wirksamkeit.

Welche Systeme werden bei Backups am häufigsten vergessen?

Am häufigsten fehlen Identitätsdienste, Netzwerk- und Firewall-Konfigurationen, Zertifikate, Cloud-Konfigurationen, Automatisierungsroutinen und Integrationen zwischen Kernsystemen. Genau diese Komponenten entscheiden jedoch oft darüber, ob ein Unternehmen seinen Betrieb schnell wieder aufnehmen kann.

Wie oft muss ein Restore getestet werden?

Es gibt keine pauschale NIS2-Taktung, aber die Testfrequenz muss zum Risiko und zu den Zielwerten Ihrer kritischen Dienste passen. Für zentrale Systeme sind regelmäßige Restore-Proben und mindestens periodische End-to-End-Tests üblich, damit Änderungen an Architektur und Datenvolumen nicht unbemerkt die Wiederherstellbarkeit verschlechtern.

Was ist der Unterschied zwischen Backup und Disaster Recovery?

Backup sichert Daten und Konfigurationen, Disaster Recovery organisiert die vollständige Wiederherstellung von Systemen und Betriebsfähigkeit nach einem Notfall. NIS2 nennt beide Begriffe bewusst nebeneinander, weil Datenkopien ohne geordneten Wiederanlaufplan keine ausreichende Resilienz schaffen.