NIS2 Business Continuity: Notfallplanung, die im Ernstfall funktioniert

Ein Ransomware-Angriff legt die Produktion lahm. Der zentrale Cloud-Dienst fällt aus. Ein Rechenzentrum wird durch einen Wasserschaden unbrauchbar. In jedem dieser Szenarien entscheidet nicht die Technik allein darüber, wie schnell ein Unternehmen wieder arbeitsfähig ist. Es entscheidet der Notfallplan, und ob ihn jemand kennt.

Das NIS2UmsuCG macht Business Continuity Management (BCM) zur gesetzlichen Pflicht. §30 Abs. 2 Nr. 3 BSIG verlangt von betroffenen Unternehmen Maßnahmen zur "Aufrechterhaltung des Betriebs", konkret: Backup-Management, Wiederherstellung nach einem Notfall und Krisenmanagement. Dieser Artikel zeigt, wie Unternehmen diese Anforderung von der Pflicht zur funktionierenden Praxis bringen.

Was verlangt das NIS2UmsuCG für Business Continuity?

§30 Abs. 2 Nr. 3 BSIG nennt drei Säulen der Betriebskontinuität: Backup-Management, Wiederherstellung nach einem Notfall und Krisenmanagement. Die NIS2UmsVO konkretisiert diese Anforderung in Annex 4.1 mit einem detaillierten Anforderungskatalog für Notfallpläne.

In der Praxis heißt das: Ein Unternehmen muss nicht nur Backups erstellen, sondern einen durchdachten Plan haben, der beschreibt, was bei einem Vorfall passiert, wer welche Entscheidungen trifft und wie der Betrieb wiederhergestellt wird. Die Geschäftsleitung trägt persönliche Verantwortung dafür, dass dieser Plan existiert und funktioniert.

Die vollständige Liste der zehn Maßnahmenbereiche nach §30 behandeln wir im Überblick zu den NIS2-Anforderungen. Dieser Artikel konzentriert sich auf den BCM-Baustein und wie er praktisch umgesetzt wird.

Business Impact Analyse: Welche Prozesse sind kritisch?

Der Ausgangspunkt jedes Notfallplans ist die Business Impact Analysis (BIA). Darin werden geschäftskritische Prozesse identifiziert und bewertet: Welche Systeme und Prozesse sind für die Geschäftstätigkeit unverzichtbar? Welche Auswirkungen hat der Ausfall? Wie lange kann ein Ausfallfall akzeptiert werden?

Die BIA ist mehr als eine IT-Aufgabe. Der CIO sitzt nicht allein im Zimmer und rät, was kritisch ist. Die Geschäftsbereiche (Produktion, Vertrieb, Verwaltung, Forschung) müssen ihre eigenen Abhängigkeiten beschreiben. Ein Produktionsausfallfall von einer Stunde kostet anders viel als ein Ausfall der Email für eine Stunde. Die BIA macht diese Unterschiede explizit.

Praktisch hat sich ein Workshop bewährt, in dem die Geschäftsbereiche und die IT zusammensitzen und folgende Fragen durchgehen: 1. Welche Prozesse sind für unser Geschäft unverzichtbar? 2. Wie lange können diese Prozesse ausfallen, bevor es kritisch wird? 3. Welche IT-Systeme unterstützen diese Prozesse? 4. Wie schnell müssen diese Systeme wieder verfügbar sein?

RPO und RTO: Wiederherstellungsziele festlegen

Aus der BIA ergeben sich zwei Kennzahlen, die das Rückgrat jedes Notfallplans bilden. Das Recovery Point Objective (RPO) definiert den maximal akzeptablen Datenverlust. Ein RPO von 4 Stunden bedeutet: Im schlimmsten Fall gehen die Daten der letzten 4 Stunden verloren. Das Recovery Time Objective (RTO) definiert die maximale Ausfallzeit. Ein RTO von 8 Stunden bedeutet: Der Prozess muss innerhalb von 8 Stunden wieder laufen.

Diese Kennzahlen bestimmen die technische Strategie. Ein RPO von 15 Minuten erfordert synchrone Replikation oder sehr häufige Backups. Ein RPO von 24 Stunden kann mit täglichen Backups erreicht werden. Die technischen Details der Backup-Strategie nach NIS2 behandelt der verlinkte Artikel.

Notfallplan: Das BCM in die Praxis übersetzen

Die BIA liefert die Daten, der Notfallplan ist das Dokument, das aus diesen Daten konkrete Maßnahmen macht. Ein Notfallplan enthält typischerweise folgende Abschnitte:

Ein gut dokumentierter Notfallplan ist das Artefakt, das bei einer NIS2-Prüfung vorgezeigt wird. Ohne Notfallplan lässt sich nicht nachweisen, dass §30 Abs. 2 Nr. 3 erfüllt ist.

Notfallplan testen: Tabletop und Full-Scale-Test

Der besten Notfallplan hilft nichts, wenn ihn niemand kennt oder wenn er im Ernstfall nicht funktioniert. NIS2 fordert daher regelmäßige Tests. Zwei Formate haben sich etabliert:

Die Ergebnisse jedes Tests müssen dokumentiert werden: Welche Mängel wurden identifiziert? Welche Korrekturmaßnahmen sind eingeleitet? Die Dokumentation ist später der Nachweis, dass BCM nicht nur auf dem Papier existiert, sondern tatsächlich gepflegt wird.

Business Continuity im ISO-27001-Kontext

Unternehmen, die bereits ein ISO-27001-ISMS haben, werden feststellen, dass BCM keine neuen Anforderungen auf grüner Wiese erzeugt. ISO 27001 fordert in der neuesten Fassung (2022) in Annex A.8.14 ebenfalls einen Plan zur Wiederherstellung nach Störungen. Der §30 Abs. 2 Nr. 3 BSIG konkretisiert diese Anforderung mit zusätzlichem Detaillierungsgrad, insbesondere beim Nachweis regelmäßiger Tests.

Praktisch heißt das: Unternehmen können ihre bestehende ISO-27001-Dokumentation um die NIS2-spezifischen Anforderungen erweitern (Notfallplan, Krisenmanagement, regelmäßige Tests), statt alles von vorn anzufangen.

Praktischer Anhang: Notfallplan-Template

Ein einfaches Notfallplan-Template kann aus diesen Abschnitten bestehen:

Ein solcher Plan ist nicht glamourös, aber die Vorlage einer solchen Dokumentation bei einer BSI-Prüfung zeigt konkret, dass die Anforderung ernst genommen und nicht nur in der IT-Ecke abgehandelt wurde. Das ist genau das, was die Regulierung mit BCM im §30 BSIG bezweckt.