Eine Sicherung zählt nur, wenn Sie auch getestet haben, dass Sie damit wiederherstellen können — nicht nur, ob die Datei vorhanden ist, sondern ob der Quellcode, die Entwicklungs-Pipeline und die zugehörigen Geheimnisse nach einem Vorfall wieder funktionsfähig zurückkommen. Bei der Softwareentwicklung geht es nicht nur um ein Repository, das Sie zurücksetzen können, sondern um eine ganze Kette: Versionskontrolle, Build-Server, Pipelines, Testumgebungen und die Schlüssel und Token, die dazugehören. Ohne ein getestetes Wiederherstellungsverfahren wissen Sie erst während eines Vorfalls, ob es funktioniert, und das ist der schlechteste Zeitpunkt, um das herauszufinden.
Die NIS2-Sorgfaltspflicht nennt Kontinuität und Wiederherstellung ausdrücklich als Teil der zehn Maßnahmen aus Artikel 21. Die Richtlinie schreibt keine feste Testhäufigkeit vor und auch keine konkrete Form — das wird je nach Organisation ausgefüllt, und die landsspezifische Umsetzung kann eigene Schwerpunkte setzen. Was aber immer wieder auftaucht, in Fragenlistenabfragen von Kunden und in dem, was Aufsichtsbehörden als angemessen betrachten, ist der Unterschied zwischen einer Sicherung und einer Sicherung, die Sie wiederhergestellt haben und von der Sie wissen, dass das Ergebnis funktioniert.
Was 'getestet' genau bedeutet
Ein Test ist nicht dasselbe wie ein grüner Haken in der Sicherungssoftware. Getestet bedeutet, dass jemand die Sicherung tatsächlich in einer separaten Umgebung wiederhergestellt hat, überprüft hat, ob der Code kompiliert, ob der Build erfolgreich ist und ob die Anwendung wie erwartet funktioniert. Nur dann wissen Sie, ob der Wiederherstellungsmoment nutzbar ist und wie lange es dauert. Eine Sicherung, die zwar erstellt wird, aber nie wiederhergestellt wird, ist in der Praxis eine Annahme über Wiederherstellung, keine bewiesene Wiederherstellung.
Was Sie in der Entwicklungs-Pipeline genau wiederherstellen
Bei der Softwareentwicklung ist der Quellcode selten das Einzige, das Sie verlieren können. Denken Sie an die Konfiguration der CI/CD-Pipeline, die Build-Skripte, die Abhängigkeiten von externen Paketen, die Zugangsschlüssel für Registries und Cloud-Umgebungen und die Historie im Versionskontrollsystem selbst. Ein Wiederherstellungsplan, der nur den Code abdeckt, aber nicht die Pipeline oder die Geheimnisse, lässt eine Organisation nach einem Vorfall immer noch still stehen. Es ist daher sinnvoll, für jede dieser Komponenten separat zu bestimmen: wo steht die Sicherung, wer kann sie wiederherstellen, und wurde das je geübt.
Wie oft Testen angemessen ist
Es gibt in der Richtlinie keine feste Frist dafür, wie oft Sie einen Wiederherstellungstest durchführen müssen. Was in der Praxis als angemessen gilt, hängt davon ab, wie oft sich die Umgebung ändert: eine Entwicklungs-Pipeline, die wöchentlich die Pipeline-Konfiguration wechselt, erfordert häufigere Tests als eine stabile Umgebung, die Monate lang unverändert bleibt. Viele Organisationen wählen einen festen Kalenderrhythmus — beispielsweise jedes Quartal — kombiniert mit einem Test nach jeder großen Änderung der Infrastruktur. Wichtiger als die Häufigkeit ist, dass es überhaupt einen Moment gegeben hat und dass Sie angeben können, wann.
Was Sie als Nachweis dokumentieren
Ein Kunde, der eine Sicherheitsfrageliste sendet, fragt selten nach der Technik hinter Ihrer Sicherung. Die Frage ist meist einfacher: wann wurde dies zuletzt getestet, von wem, und was war das Ergebnis. Für diese Antwort ist es ausreichend, drei Dinge dokumentieren: das Datum des letzten Wiederherstellungstests, wer den Test durchgeführt hat, und welche Komponente wiederhergestellt wurde — Code, Pipeline, Geheimnisse oder alle drei. Ohne diese Dokumentation bleibt die Antwort auf die Frageliste eine Erinnerung statt eines Nachweises, und genau dieser Unterschied ist es, den ein Bewerter auf der anderen Seite des Tisches sehen möchte.
Die Verbindung mit dem Rest des Dossiers
Sicherung und Wiederherstellung stehen selten für sich allein. Wer das Wiederherstellungsverfahren durchführen darf, hängt mit der Zugriffskontrolle auf die Entwicklungspipeline zusammen; was während eines Ausfalls schiefging, gehört in dieselbe Vorfallregistrierung, die auch für andere Maßnahmen gepflegt wird. Ein solches Dossier aufzubauen muss kein separates Projekt sein: die zehn Maßnahmen aufgeschlüsselt nach Situation zeigt auf, wo Sicherung und Wiederherstellung genau in das Gesamtbild passen, und welche anderen Maßnahmen direkt damit verbunden sind.
Ob Sicherung und Wiederherstellung für Ihre Organisation als Sorgfaltspflicht-Maßnahme gelten, hängt davon ab, ob Sie selbst unter NIS2 fallen oder ob Sie diese Frage von einem Auftraggeber bekommen, der das tut. in ein paar Fragen sehen, wo Sie stehen gibt dazu einen ersten Anhaltspunkt, mit Erklärung, warum. Wie wir zu diesem Anhaltspunkt gelangen und welche Quellen dafür zugrunde liegen, wird erläutert auf der Seite über unser Vorgehen.
Eine Sicherung, die noch nie wiederhergestellt wurde, ist keine Garantie — es ist eine Frage, die auf eine Antwort wartet. Möchten Sie wissen, ob und wie diese Maßnahme für Ihre Organisation relevant ist, und was sonst noch dazugehört? Führen Sie den kostenlosen Quick-Check durch oder blättern Sie durch die häufigsten Fragen zu NIS2 für die Fragen, die andere Unternehmer bereits gestellt haben.