Ein Backup zu haben reicht unter NIS2 nicht aus. Es geht um nachweisbare Wiederherstellung. In einem früheren Artikel haben wir beschrieben, warum die Registrierung beim BSI erst der Anfang ist. Dieser Artikel widmet sich der Folgefrage, wie Sie diesen Nachweis aufbauen. Anhand unseres Webinars mit Dr. Carsten Csambal von Pink Elephant zeigen wir, was dafür nötig ist. 

Carsten begann das Webinar am 8. Oktober mit einer Frage an die Teilnehmenden. Können Sie gegenüber Geschäftsleitung, Kunden oder Prüfern belegen, dass Ihre kritischen Systeme innerhalb der vereinbarten Zeit sauber wiederhergestellt werden können? Wer darauf mit einem Jein antwortet, ist hier richtig, sagte er. 

Laut Carsten ist die eigentliche Frage nicht mehr, ob oder wann es ein Unternehmen trifft. Die Frage ist, wie oft. Und wenn es passiert, sollte es bei einem Mal bleiben. Wer so auf Cyberresilienz blickt, kann Wiederherstellung nicht als Plan auf Papier behandeln. Sie müssen zeigen können, dass sie funktioniert. 

Was das NIS2-Umsetzungsgesetz zur Wiederherstellung verlangt 

Seit dem 6. Dezember 2025 gilt in Deutschland das NIS2-Umsetzungsgesetz. Es überführt die europäische NIS2-Richtlinie in deutsches Recht und hat das BSI-Gesetz (BSIG) neu gefasst. Betroffene Einrichtungen müssen geeignete, verhältnismäßige und wirksame Maßnahmen umsetzen. § 30 BSIG nennt dafür zehn Mindestanforderungen. Eine davon betrifft ausdrücklich die Aufrechterhaltung des Betriebs, wie Backup-Management und Wiederherstellung nach einem Notfall, und Krisenmanagement. Mit anderen Worten, nicht nur verhindern, dass etwas schiefgeht, sondern auch dafür sorgen, dass Sie weiterarbeiten und wiederherstellen können, wenn es schiefgeht. 

Das Gesetz schreibt nicht im Detail vor, wie Sie das umsetzen. Die Maßnahmen müssen zu Ihrer Organisation und Ihrem Risikoprofil passen. Diese Freiheit klingt angenehm, legt die Beweislast aber auch bei Ihnen. Eine weitere Mindestanforderung verlangt Konzepte und Verfahren, mit denen Sie die Wirksamkeit Ihrer Maßnahmen bewerten. Sie entscheiden also selbst, was angemessen ist, solange Sie nachweisen können, dass es funktioniert. Carsten brachte es so auf den Punkt. Ein erfolgreiches Backup ist ein technisches Ereignis. Ein dokumentierter Recovery-Test ist ein Nachweis. 

Genau da liegt in der Praxis oft der Unterschied zwischen Vertrauen und Nachweis. Veeam befragte für den Data Trust and Resilience Report 2026 mehr als 900 IT- und Sicherheitsverantwortliche. Neunzig Prozent erwarten, nach einem Cybervorfall innerhalb der vereinbarten Wiederherstellungszeit wieder arbeitsfähig zu sein. Dieselbe Studie zeigt, dass von den Organisationen, die von Ransomware getroffen wurden, 28 Prozent alle Daten zurückbekamen. Die beiden Zahlen messen nicht dasselbe. Die erste betrifft die erwartete Wiederherstellungszeit, die zweite die tatsächlich wiederhergestellten Daten. Zusammen zeigen sie aber, dass Vertrauen in die Wiederherstellung etwas anderes ist als nachgewiesene Wiederherstellung. 

Genau hier setzt NIS2 an. Solange nichts passiert, ist Wiederherstellung vor allem eine interne Einschätzung. Nach einem Vorfall wird sie zum Beweisstück. Dann müssen Sie zeigen können, welche Systeme kritisch sind, welche Wiederherstellungszeiten vereinbart sind, wann getestet wurde und mit welchem Ergebnis. 

Erst die Anforderungen, dann die Technik 

Wer unter NIS2 nachweisen will, dass die Wiederherstellung funktioniert, muss zuerst wissen, was genau wiederhergestellt werden muss. Die Technik kommt danach. Nachweisbare Wiederherstellung beginnt deshalb mit einer Business Impact Analyse. Darin legen Sie fest, welche Prozesse kritisch sind und welche Systeme nötig sind, um diese Prozesse am Laufen zu halten. 

Anschließend legen Sie pro Dienst zwei Grenzen fest. Die Recovery Time Objective, kurz RTO, bestimmt, wie lange ein Dienst maximal ausfallen darf. Die Recovery Point Objective, kurz RPO, bestimmt, wie viel Datenverlust akzeptabel ist. Diese Grenzen sind nicht für jeden Dienst gleich. Ein Archivsystem darf meist länger ausfallen als das System, auf dem Ihr Kernprozess läuft. 

Carsten nutzt dafür den Begriff Minimum Viable Company, den kleinsten funktionsfähigen Betriebszustand nach einer schweren Störung. Statt sofort die komplette Umgebung wiederherzustellen, priorisieren Sie zuerst die Prozesse, Anwendungen, Daten und Zugänge, die für Ihre Kernleistungen nötig sind. Die praktische Frage lautet, welche Services in den ersten Stunden funktionieren müssen und welche später folgen können. 

Daraus ergibt sich die Wiederanlaufreihenfolge. Zuerst kommen Basisdienste und Kernprozesse, danach abhängige und weniger kritische Funktionen. Carsten wies dabei auf einen Punkt hin, der oft vergessen wird. Wenn Forensiker nach einem Angriff die alte Umgebung für ihre Analyse stilllegen, brauchen Sie Ersatzkapazität, um Ihre Minimum Viable Company überhaupt aufbauen zu können. Auch diese Kapazität planen Sie besser vorher als im Ernstfall. 

Sorgen Sie dafür, dass das Backup den Angriff übersteht 

Ein Backup war früher vor allem für Pech gedacht. Denken Sie an eine defekte Festplatte, eine versehentlich gelöschte Datei oder einen Wasserschaden im Rechenzentrum. Bei Ransomware ist das anders. Dann steckt Absicht dahinter. Klassische Backup-Konzepte wurden für Ausfälle entwickelt, nicht für einen intelligenten Gegner, so Carsten. Ein Angreifer weiß, dass ein funktionierendes Backup der Grund sein kann, nicht zu zahlen. Deshalb versucht er oft zuerst, die Backups unbrauchbar zu machen. 

Deshalb müssen Sie nicht nur ein Backup haben, sondern auch dafür sorgen, dass es den Angriff übersteht. Ein praktischer Ausgangspunkt ist die 3-2-1-1-0-Regel. Sie halten drei Kopien Ihrer Daten vor, die Produktionsdaten eingeschlossen. Diese liegen auf zwei verschiedenen Speichermedien. Eine Kopie liegt außer Haus und eine Kopie ist unveränderlich. Die Null steht für null Fehler nach der Prüfung. Sie prüfen nicht nur, ob das Backup gelaufen ist, sondern auch, ob Sie tatsächlich daraus wiederherstellen können. Genau dort beginnt der Nachweis. 

Für die unveränderliche Kopie gibt es grob zwei Wege. Der erste ist Air-Gapping. Dabei besteht keine dauerhafte, offene Verbindung zwischen Produktion und Backup, und Daten bewegen sich nur über kontrollierte Wege wie ein separates Gateway. Carsten betonte, dass ein wirksamer Air-Gap Datenpfad, Managementpfad und Identitätspfad trennt. Bleibt einer davon offen, kann ein Angreifer die Isolation umgehen. Der zweite Weg ist Speicher, der nach dem Schreiben nicht mehr verändert werden kann, etwa Object Storage mit Object Lock oder ein Offline-Medium wie ein Band im Tresor. 

Auch der Zugriff muss getrennt sein. Gehen Sie bei einem erfolgreichen Angriff davon aus, dass die Authentifizierungsdomäne Ihrer Produktionsumgebung kompromittiert ist. Vor zehn Jahren war es noch üblich, den Backup-Server aus Bequemlichkeit in die Produktionsdomäne aufzunehmen. Heute ist genau das ein ideales Angriffsszenario. Die Backup-Umgebung gehört deshalb in eine eigene Authentifizierungsdomäne, ohne Vertrauensstellung zur Produktion und mit Multi-Faktor-Authentifizierung für die Administratorkonten. 

Wiederherstellen, ohne die Infektion zurückzuspielen 

Angenommen, es geht schief. Tagelang laufen die Backups ohne Fehlermeldung, dann stellt sich heraus, dass die Umgebung infiziert ist. Die erste Frage ist, ab welchem Punkt Sie sicher wiederherstellen können. Schadsoftware sitzt oft schon in einem System, bevor sie entdeckt wird, und damit auch in Ihren Backups. 

Carsten zeigte den Ablauf Schritt für Schritt. Zuerst scannen Sie die vorhandenen Backups mit den aktuellen Bedrohungsinformationen, damit Sie wissen, welche Stände sauber sind. In seinem Beispiel hätte die vollständige Rücksicherung des ältesten sauberen Backups sehr viele Änderungen gekostet, obwohl einzelne Datensegmente nie angegriffen wurden und aus der letzten Sicherung kommen konnten. Bei Synthetic Recovery setzen Sie die wiederhergestellte Umgebung deshalb pro Objekt aus der jüngsten sauberen Version zusammen. 

Diese Wiederherstellung erfolgt zuerst in einen Cleanroom, eine vom Produktionsnetz isolierte Umgebung. Dort prüfen Sie, ob die Daten sauber und konsistent sind und ob die Systeme tun, was sie sollen. Der Cleanroom sollte realitätsnah genug sein, um Abhängigkeiten zu prüfen, aber strikt von der Produktion getrennt bleiben. Diese Validierung bleibt Handarbeit. Erst nach der dokumentierten Freigabe geht die Umgebung in Produktion. 

Was ein Prüfer sehen will 

Bis hierhin ging es darum, wiederherstellen zu können. Nachweisbar wird es erst, wenn Sie es dokumentieren. Carsten sprach von einem doppelten Auftrag für Recovery-Teams. Schnell handeln und gleichzeitig Zeiten, Entscheidungen und Wiederherstellungsschritte so festhalten, dass sie später nachvollziehbar sind. Jeder Schritt braucht einen Verantwortlichen und ein dokumentiertes Ergebnis. 

Was gehört in den Bericht eines Recovery-Tests? Mindestens das Datum des Tests und die beteiligten Systeme. Außerdem die gemessene Wiederherstellungszeit neben der vereinbarten RTO, der Punkt, bis zu dem Sie Daten zurückbekamen, neben der RPO, und die Abweichungen mit einem Maßnahmenplan. Ein Dokument, in dem steht, dass Sie wiederherstellen können, ist eine Absicht. Eine gemessene Wiederherstellungszeit ist ein Nachweis. 

Ein einziger Test reicht dabei nicht, denn Pläne altern. Neue Versionen, Schnittstellen und Standorte verändern die Umgebung. Laut Carsten sollte deshalb jede Änderung eine Prüfung der Recovery-Dokumentation auslösen. Sie müssen nicht mit einem vollständigen Failover beginnen. Eine Tabletop-Übung für Entscheidungen oder ein Teil-Failover für einzelne Komponenten liefert bereits eine erste Messung. 

Cyber Resilience Assessment

Möchten Sie zuerst wissen, wie Ihre eigene Organisation aufgestellt ist? Das kostenlose Cyber Resilience Assessment gibt Ihnen in wenigen Fragen einen ersten Eindruck Ihrer Wiederherstellungsfähigkeit. 

Cyber-Resilienze beginnt auf der Storage-Ebene

Die nächste Data Resilience Session findet am 19 November statt und behandelt den Schutz Ihrer Backups auf Storage-Ebene. Melde dich jetzt an

Häufige Fragen zu nachweisbarer Wiederherstellung und NIS2