NIS2 Business Continuity: Anforderungen gemäß Artikel 21 Absatz 2 Buchstabe c

Zuletzt geprüft: Oktober 2026. Maßgeblich in Deutschland ist § 30 Absatz 2 Satz 2 Nummer 3 des BSI-Gesetzes (BSIG) in der Fassung des NIS2UmsuCG (BGBl. 2025 I Nr. 301), der Artikel 21 Absatz 2 Buchstabe c der Richtlinie (EU) 2022/2555 umsetzt. Die technischen Anforderungen in Anhang Nummer 4 der Durchführungsverordnung (EU) 2024/2690 (CIR) gelten verbindlich nur für die elf dort genannten Einrichtungsarten.

Besonders wichtige und wichtige Einrichtungen müssen nach § 30 Absatz 1 BSIG geeignete, verhältnismäßige und wirksame technische und organisatorische Maßnahmen ergreifen. Zu den Mindestinhalten gehört nach § 30 Absatz 2 Satz 2 Nummer 3 BSIG die „Aufrechterhaltung des Betriebs, wie Backup-Management und Wiederherstellung nach einem Notfall, und Krisenmanagement“ [1]. Der Wortlaut entspricht Artikel 21 Absatz 2 Buchstabe c der NIS2-Richtlinie, einer der zehn Mindestmaßnahmen des Artikels 21 [4]. Die Pflicht gilt für besonders wichtige und wichtige Einrichtungen gleichermaßen; wie umfangreich die Maßnahmen ausfallen, richtet sich nach der Verhältnismäßigkeit (§ 30 Absatz 1 Satz 2 BSIG). Ausnahmen bestehen unter anderem für Betreiber öffentlicher Telekommunikationsnetze und bestimmte Energieanlagenbetreiber, für die Sonderregeln im TKG bzw. EnWG gelten, sowie für Finanzunternehmen unter DORA (§ 28 Absätze 5 und 6 BSIG) [9].

Für viele kleine und mittelständische Organisationen ist dies das erste Mal, dass sie gesetzlich verpflichtet sind, ein formales Business-Continuity-Programm zu dokumentieren. Möglicherweise verfügen Sie bereits über informelle Backup-Prozesse oder eine ungefähre Vorstellung davon, was zu tun wäre, wenn Ihr primärer Server ausfällt. Das BSIG verlangt jedoch, dass die Einhaltung der Maßnahmen dokumentiert wird (§ 30 Absatz 1 Satz 3 BSIG) [1]. In der Praxis bedeutet das einen schriftlichen Plan, festgelegte Verantwortlichkeiten, getestete Wiederherstellungsverfahren und nachvollziehbare Wiederherstellungsziele für die kritischen Abläufe.

Dieser Leitfaden erläutert, was § 30 BSIG und die Durchführungsverordnung für die Aufrechterhaltung des Betriebs verlangen, wie Sie ein Programm von Grund auf aufbauen und welche Dokumente sich als Nachweis eignen. Falls Sie noch prüfen, ob NIS2 für Ihre Organisation gilt, lesen Sie zunächst die Übersicht zur NIS2-Richtlinie, bevor Sie hierher zurückkehren.

Was § 30 BSIG und Artikel 21(2)(c) verlangen

§ 30 Absatz 2 Nummer 3 BSIG — die deutsche Rechtsgrundlage

Der Gesetzestext ist bewusst knapp gehalten. § 30 Absatz 2 Satz 2 Nummer 3 BSIG nennt als Mindestmaßnahme die „Aufrechterhaltung des Betriebs, wie Backup-Management und Wiederherstellung nach einem Notfall, und Krisenmanagement“ [1]. Das Wort „wie“ zeigt, dass Backup-Management und Wiederherstellung Beispiele sind, keine abschließende Liste. Drei weitere Vorgaben aus § 30 BSIG prägen die Umsetzung:

• Stand der Technik und Normen — die Maßnahmen „sollen den Stand der Technik einhalten, die einschlägigen europäischen und internationalen Normen berücksichtigen und müssen auf einem gefahrenübergreifenden Ansatz beruhen“ (§ 30 Absatz 2 Satz 1 BSIG). Für Business Continuity sind das vor allem ISO 22301 und der BSI-Standard 200-4 (siehe unten).
• Dokumentation — „Die Einhaltung der Verpflichtung nach Satz 1 ist durch die Einrichtungen zu dokumentieren“ (§ 30 Absatz 1 Satz 3 BSIG).
• Notfallkommunikation — § 30 Absatz 2 Satz 2 Nummer 10 BSIG nennt zusätzlich „gegebenenfalls gesicherte Notfallkommunikationssysteme innerhalb der Einrichtung“, was unmittelbar in die Krisenkommunikation hineinwirkt.

Wer die Maßnahmen nicht, nicht richtig, nicht vollständig oder nicht rechtzeitig ergreift oder ihre Einhaltung nicht dokumentiert, handelt ordnungswidrig (§ 65 Absatz 2 Nummern 2 und 3 BSIG) [3]. Konkrete Wiederherstellungszeiten, Backup-Intervalle oder Testfrequenzen schreibt das BSIG nicht vor.

Wann die Durchführungsverordnung (EU) 2024/2690 gilt

Detaillierte technische Anforderungen enthält Anhang Nummer 4 der Durchführungsverordnung (EU) 2024/2690 („Betriebskontinuitäts- und Krisenmanagement“) [5]. Verbindlich ist er nur für die elf Einrichtungsarten aus Artikel 1 der Verordnung: DNS-Diensteanbieter, TLD-Namenregister, Anbieter von Cloud-Computing-Diensten, Anbieter von Rechenzentrumsdiensten, Betreiber von Inhaltszustellnetzen, Anbieter verwalteter Dienste (MSP), Anbieter verwalteter Sicherheitsdienste (MSSP), Anbieter von Online-Marktplätzen, Online-Suchmaschinen, Plattformen für Dienste sozialer Netzwerke und Vertrauensdiensteanbieter. Für diese Einrichtungsarten hat die Verordnung nach § 30 Absatz 3 BSIG Vorrang [1]. Alle übrigen Einrichtungen können den Anhang als Orientierung nutzen, was „Stand der Technik“ für Business Continuity bedeuten kann. Viele Anforderungen gelten „soweit angemessen“; wer eine solche Anforderung für nicht angemessen hält, muss das nach Artikel 2 Absatz 2 der Verordnung nachvollziehbar begründen und dokumentieren [5].

Anhang Nummer 4.1 — Notfallplan für die Aufrechterhaltung und Wiederherstellung des Betriebs

Die betreffenden Einrichtungen legen einen Notfallplan fest, „der bei Sicherheitsvorfällen Anwendung findet“ (Nummer 4.1.1). Der Plan beruht auf der Risikobewertung nach Nummer 2.1 und umfasst nach Nummer 4.1.2 – soweit angemessen – folgende acht Elemente [5]:

• a) Zweck, Umfang und Zielgruppe
• b) Rollen und Verantwortlichkeiten
• c) wichtige Kontaktangaben und (interne und externe) Kommunikationskanäle
• d) Bedingungen für die Aktivierung und die Deaktivierung des Plans
• e) Reihenfolge der Wiederherstellung der Betriebsabläufe
• f) Wiederherstellungspläne für bestimmte Betriebsabläufe, einschließlich der Wiederherstellungsziele
• g) erforderliche Ressourcen, einschließlich Sicherungen und Redundanzen
• h) Wiederherstellung und Wiederaufnahme der Tätigkeiten nach vorübergehenden Maßnahmen

Hinzu kommen eine Analyse der betrieblichen Auswirkungen (Business-Impact-Analyse), aus deren Ergebnissen Kontinuitätsanforderungen für die Netz- und Informationssysteme abgeleitet werden (Nummer 4.1.3), sowie Tests, Überprüfung und Aktualisierung des Plans „in geplanten Zeitabständen sowie bei erheblichen Sicherheitsvorfällen oder wesentlichen Änderungen der Betriebsabläufe oder der Risiken“; die Lehren aus den Tests müssen in die Pläne einfließen (Nummer 4.1.4).

Anhang Nummer 4.2 — Backup-Sicherungs- und Redundanzmanagement

Die Einrichtungen machen Sicherungskopien der Daten und stellen ausreichend Ressourcen – Betriebsstätten, Netz- und Informationssysteme sowie Personal – für ein angemessenes Maß an Redundanz bereit (Nummer 4.2.1). Auf Grundlage der Risikobewertung und des Betriebskontinuitätsplans legen sie Sicherungspläne fest, die nach Nummer 4.2.2 Folgendes umfassen [5]:

• a) Wiederherstellungszeiten
• b) die Gewährleistung, dass Sicherungskopien vollständig und genau sind, einschließlich Konfigurationsdaten und Daten, die in der Umgebung von Cloud-Computing-Diensten gespeichert sind
• c) Speicherung der Sicherungskopien (online oder offline) an einem oder mehreren sicheren Orten, die sich nicht im selben Netz wie das System und in ausreichend großer Entfernung befinden, um Schäden durch einen Notfall am Hauptstandort zu vermeiden
• d) geeignete physische und logische Zugangskontrollen zu den Sicherungskopien entsprechend der Klassifizierungsstufe der Anlagen und Werte
• e) Wiederherstellung von Daten aus Sicherungskopien
• f) Aufbewahrungsfristen entsprechend geschäftlichen und regulatorischen Anforderungen

Ergänzend verlangt der Anhang regelmäßige Integritätsprüfungen der Sicherungskopien (Nummer 4.2.3), eine zumindest teilweise Redundanz von Netz- und Informationssystemen, Anlagen und Werten, Personal und Kommunikationskanälen (Nummer 4.2.4), eine an den Sicherungs- und Redundanzanforderungen ausgerichtete Ressourcenplanung (Nummer 4.2.5) sowie regelmäßige, dokumentierte Wiederherstellungstests mit Korrekturmaßnahmen bei Bedarf (Nummer 4.2.6).

Anhang Nummer 4.3 — Krisenmanagement

Die Einrichtungen legen ein Verfahren für das Krisenmanagement fest (Nummer 4.3.1). Es deckt nach Nummer 4.3.2 mindestens ab [5]:

• Rollen und Verantwortlichkeiten des Personals und – soweit angemessen – der Anbieter und Diensteanbieter, einschließlich der Rollenzuweisung in Krisensituationen und spezifischer zu befolgender Schritte
• geeignete Kommunikationsmittel zwischen der Einrichtung und den zuständigen Behörden — dazu gehören sowohl obligatorische Mitteilungen wie Meldungen von Sicherheitsvorfällen und deren Fristen als auch freiwillige Mitteilungen
• Maßnahmen zur Aufrechterhaltung der Sicherheit von Netz- und Informationssystemen in Krisensituationen

Außerdem verlangt der Anhang ein Verfahren für die Verwaltung und Nutzung von Informationen der CSIRTs oder zuständigen Behörden über Sicherheitsvorfälle, Schwachstellen, Bedrohungen und mögliche Risikominderungsmaßnahmen (Nummer 4.3.3) sowie Tests und Aktualisierung des Krisenmanagementplans in geplanten Zeitabständen oder nach erheblichen Sicherheitsvorfällen oder wesentlichen Änderungen (Nummer 4.3.4). Die Verbindung zur Vorfallbehandlung stellt Nummer 3.1.2 her: Das Konzept für die Bewältigung von Sicherheitsvorfällen muss mit dem Notfallplan nach Nummer 4.1 im Einklang stehen.

Zusammen bilden diese drei Teilbereiche ein vollständiges BC-Programm. Viele KMU haben bislang höchstens einzelne Bausteine davon, etwa ein Backup-Konzept. Die folgenden Abschnitte führen Sie in einer praxistauglichen Reihenfolge durch den Aufbau. Für den übergeordneten Kontext aller zehn Mindestmaßnahmen lesen Sie die Übersicht zu den NIS2-Anforderungen; einen Überblick über alle 13 Anhangsabschnitte der Verordnung gibt der Leitfaden zur Durchführungsverordnung (EU) 2024/2690.

Methodik der Business-Impact-Analyse

Ein glaubwürdiges BC-Programm lässt sich nicht ohne ein vorheriges Verständnis der für Ihre Organisation wichtigsten Elemente aufbauen. Eine Business-Impact-Analyse (BIA) bildet das Fundament — sie identifiziert, welche Prozesse kritisch sind, wie schnell sie wiederhergestellt werden müssen und wie viel Datenverlust tolerierbar ist. Die BIA sollte abgeschlossen sein, bevor Sie Wiederherstellungsverfahren verfassen. Ohne sie sind Ihre Wiederherstellungsziele bloße Schätzungen.

Wo diese Pflicht rechtlich verankert ist — für die elf Einrichtungsarten der Durchführungsverordnung verlangt Nummer 4.1.3 des Anhangs die Analyse verbindlich, während maximal tolerierbare Ausfallzeit, RTO und RPO als Kennzahlensatz nur als Empfehlung in Erwägungsgrund 13 stehen — und wie Sie die Kennzahlen nach BSI-Standard 200-4 herleiten, zeigt der Leitfaden zur Business-Impact-Analyse (BIA).

Schritt 1 — Alle Geschäftsprozesse identifizieren

Listen Sie jeden Geschäftsprozess und jeden Dienst auf, den Ihre Organisation erbringt – sowohl kundenseitige als auch interne. Berücksichtigen Sie IT-gestützte Prozesse, manuelle Prozesse und hybride Prozesse. Typische Kategorien: Vertrieb und Umsatzgenerierung, Kundendienst und -support, Lieferkette und Betrieb, Finanzen und Zahlungsverkehr, regulatorisches Berichtswesen, Personal- und Mitarbeitermanagement sowie IT-Infrastrukturdienste.

Schritt 2 — Abhängigkeiten erfassen

Dokumentieren Sie für jeden Prozess dessen Abhängigkeiten: IT-Systeme und Anwendungen, Datensätze und Datenbanken, Personal und spezialisierte Fähigkeiten, Drittanbieter und SaaS-Plattformen, physische Einrichtungen sowie Versorgungsleistungen. Ein einseitiges Abhängigkeitsdiagramm pro kritischem Prozess reicht für viele KMU aus und liefert einen klaren Prüfpfad.

Schritt 3 — Auswirkungen einer Störung über die Zeit bewerten

Bewerten Sie für jeden Prozess die Folgen einer Nichtverfügbarkeit über zunehmende Zeiträume, zum Beispiel 1 Stunde, 4 Stunden, 24 Stunden, 48 Stunden und 1 Woche. Bewerten Sie die Auswirkungen in vier Dimensionen:

• Finanziell — entgangene Einnahmen, vertragliche Strafen, Notfallwiederherstellungskosten
• Operativ — Unfähigkeit, Produkte oder Dienstleistungen zu erbringen, Störungen der Lieferkette
• Rechtlich und regulatorisch — Verletzung von SLAs, Nichterfüllung von NIS2-Meldepflichten, regulatorische Sanktionen
• Reputationsbezogen — Vertrauensverlust bei Kunden, Medienaufmerksamkeit, Belastung von Partnerbeziehungen

Schritt 4 — Maximale tolerierbare Ausfallzeit (MTD) bestimmen und Ziele festlegen

Die MTD (im BSI-Standard 200-4: MTPD, „Maximum Tolerable Period of Disruption“) ist die Zeitspanne, die Ihre Organisation ohne einen Prozess überbrücken kann, bevor die Folgen inakzeptabel werden. Ihr Recovery Time Objective (RTO) muss kürzer sein als Ihre MTD — andernfalls ist Ihre Wiederherstellungskapazität zu langsam, um ernsthaften Schaden zu verhindern. Der BSI-Standard 200-4 empfiehlt, von der MTPD neben der Reaktionszeit auch die Ausführungszeit des Prozesses abzuziehen und einen zeitlichen Puffer einzuplanen [7]. Ihr Recovery Point Objective (RPO) definiert den maximal tolerierbaren Datenverlust, ausgedrückt als Zeitraum, und bestimmt direkt Ihre Anforderungen an die Backup-Häufigkeit.

BIA-Ergebnis: Beispieltabelle zur Prozessklassifizierung

Das BIA-Ergebnis für jeden Prozess sollte MTD, RTO, RPO und eine Prioritätsklassifizierung enthalten. Die folgende Tabelle ist ein fiktives Beispiel für fünf typische Geschäftsprozesse. Weder das BSIG noch die Durchführungsverordnung nennen konkrete Werte; die Ziele ergeben sich allein aus Ihrer eigenen BIA:

Geschäftsprozess	MTD	RTO	RPO	Klassifizierung
E-Commerce / Online-Verkaufsplattform	4 Stunden	2 Stunden	1 Stunde	Kritisch
Kundensupport-CRM	8 Stunden	4 Stunden	4 Stunden	Kritisch
Interne E-Mail und Kommunikation	24 Stunden	8 Stunden	4 Stunden	Wichtig
Finanzen / ERP-System	48 Stunden	24 Stunden	24 Stunden	Wichtig
HR-Managementsystem	1 Woche	72 Stunden	24 Stunden	Normal

Die BIA bildet die Evidenzbasis für jedes Wiederherstellungsziel und jede Ressourcenentscheidung in Ihrem Programm. Eine feste Frist für ihre Überprüfung nennt das Gesetz nicht. Bewährt hat sich eine regelmäßige, etwa jährliche Überprüfung sowie eine Aktualisierung nach wesentlichen Änderungen an Ihren Systemen, Lieferanten oder Ihrem Geschäftsmodell; für die elf Einrichtungsarten der Verordnung ergibt sich das aus den „geplanten Zeitabständen“ der Nummer 4.1.4.

Entwicklung Ihrer BC-Strategie

Sobald die BIA abgeschlossen ist, wählen Sie Wiederherstellungsstrategien aus, die Ihre RTOs und RPOs innerhalb des Budgets und der Risikobereitschaft Ihrer Organisation erfüllen können. Die Strategie ist nicht der Plan selbst — sie umfasst die bewussten Entscheidungen darüber, wie Sie jeden kritischen Prozess wiederherstellen werden.

Optionen für Wiederherstellungsstrategien

Bewerten Sie für jeden kritischen Prozess, welcher Ansatz am geeignetsten ist:

• Cloud-Failover — Betrieb der Produktion in der Cloud mit Replikation in eine sekundäre Region; ein Failover kann je nach Architektur innerhalb von Minuten bis Stunden erreicht werden. Für viele KMU eine vergleichsweise kostengünstige Option.
• Verwalteter DR-Dienst — ein externer DR-Anbieter repliziert Ihre Umgebung und aktiviert die Wiederherstellungsinfrastruktur innerhalb vereinbarter SLAs. Geeignet für Organisationen ohne eigene Infrastrukturkenntnisse.
• Manuelle Ausweichlösung — für Prozesse, die nicht IT-intensiv sind, kann ein dokumentiertes manuelles Verfahren ausreichen. Aufträge werden telefonisch entgegengenommen, Daten nach Systemwiederherstellung abgeglichen. Typischerweise geeignet für Prozesse der Klassen Wichtig und Normal.
• Alternativer Lieferant — präqualifizieren Sie einen Ersatzlieferanten für kritische Abhängigkeiten. Besonders relevant für Lieferkette, Logistik und spezialisierte SaaS-Plattformen.
• Cold- oder Warm-Standby — vorkonfigurierte Ersatzhardware oder virtuelle Maschinen, die bei Bedarf aktiviert werden können. Geringere Kosten als Hot-Standby, jedoch längere RTO; akzeptabel, wenn Ihre MTD dies erlaubt.

Verhältnismäßigkeit

Nach § 30 Absatz 1 Satz 2 BSIG sind bei der Bewertung der Verhältnismäßigkeit „das Ausmaß der Risikoexposition, die Größe der Einrichtung, die Umsetzungskosten und die Eintrittswahrscheinlichkeit und Schwere von Sicherheitsvorfällen sowie ihre gesellschaftlichen und wirtschaftlichen Auswirkungen zu berücksichtigen“ [1]. Ein produzierendes Unternehmen mit 50 Mitarbeitern wird in der Regel kein Hot-Standby-Rechenzentrum benötigen. Naheliegend sind jedoch eine getestete Backup-Wiederherstellung für alle kritischen Daten, dokumentierte manuelle Ausweichverfahren für die prioritären Prozesse und ein Krisenteam, das innerhalb eines festgelegten Zeitrahmens zusammentreten kann. Verhältnismäßigkeit ist keine Rechtfertigung für Untätigkeit — sie bedeutet, dass die Strategie dem tatsächlichen Risiko angemessen sein muss.

Der Business-Continuity-Plan

Der Business-Continuity-Plan (BCP) setzt Ihre BC-Strategie in die operative Praxis um. Es ist das Dokument, auf das Ihre Mitarbeiter während eines echten Vorfalls zurückgreifen werden, daher muss es praktisch, handlungsorientiert und auch bei Ausfall Ihrer IT-Systeme zugänglich sein. Die folgenden Bausteine decken die acht Elemente aus Anhang Nummer 4.1.2 der Durchführungsverordnung ab [5].

Geltungsbereich und Aktivierungskriterien

Definieren Sie ausdrücklich, was die Planaktivierung auslöst — und wann der Plan wieder deaktiviert wird (Nummer 4.1.2 Buchstabe d). Aktivierungskriterien sollten objektiv und eindeutig sein — zum Beispiel: „Der Plan wird aktiviert, wenn ein zentrales Geschäftssystem länger als zwei Stunden nicht verfügbar ist, wenn ein erheblicher Teil der Mitarbeiter keinen Zugang zum primären Arbeitsplatz hat oder wenn das Incident-Management-Team einen schwerwiegenden Vorfall erklärt.“ Aktivierungskriterien sollten möglichst keine Ermessensentscheidung des Managements erfordern — sie sollten sachliche Schwellenwerte sein.

Rollen und Verantwortlichkeiten

Benennen Sie den BC-Koordinator (primär und Stellvertreter), die Mitglieder des Krisenmanagementteams und deren Stellvertreter, den IT-Wiederherstellungsverantwortlichen, den Kommunikationsverantwortlichen sowie den externen Ansprechpartner für Lieferanten- und Behördenkontakte. Führen Sie dienstliche und alternative Kontaktmöglichkeiten auf; private Nummern nur mit Einverständnis der Betroffenen. Verlassen Sie sich nicht ausschließlich auf Berufsbezeichnungen — in einer Krise sind die konkrete Person und ihre Erreichbarkeit entscheidend.

Benachrichtigungs- und Eskalationsverfahren

Dokumentieren Sie die Benachrichtigungskette: wer zuerst kontaktiert wird, in welcher Reihenfolge und über welche Kanäle. Fügen Sie Kontaktdaten für Zeiten außerhalb der Geschäftszeiten ein. Legen Sie Eskalationsschwellen fest — wann eskaliert der BC-Koordinator an das Krisenmanagementteam? Wann eskaliert das Krisenteam an die Geschäftsleitung? Diese Schwellen sollten vorab vereinbart und dokumentiert sein, nicht unter Druck improvisiert werden.

Wiederherstellungsverfahren

Stellen Sie für jeden kritischen Prozess schrittweise Wiederherstellungsanweisungen bereit: was zu tun ist, in welcher Reihenfolge und mit welchen Ressourcen (Nummer 4.1.2 Buchstaben e bis g). Diese müssen so konkret sein, dass ein kompetentes Teammitglied, das diese Wiederherstellung noch nicht durchgeführt hat, ihnen erfolgreich folgen kann. Jedes Verfahren sollte enthalten: Schritte zur Systemwiederherstellung, Schritte zur Datenwiederherstellung, Anweisungen für manuelle Ausweichlösungen, Kriterien für die Rückkehr zum Normalbetrieb (Buchstabe h) sowie den Namen des verantwortlichen Eigentümers.

Kommunikationsplan

Legen Sie Kommunikationsverantwortlichkeiten und abgestimmte Botschaften für fünf Zielgruppen fest: interne Mitarbeiter (was sie während der Störung wissen und tun müssen), Kunden (was Sie ihnen mitteilen und in welchen Abständen), Schlüssellieferanten (wer sie kontaktiert und mit welcher Befugnis), Behörden (Meldepflichten nach § 32 BSIG — siehe den NIS2-Leitfaden zur Vorfallmeldung für Fristen) sowie Medien (nur der benannte Sprecher kommuniziert nach außen).

Offline-Zugänglichkeit

Der BCP muss auch bei vollständigem Ausfall aller IT-Systeme zugänglich sein. Ein Plan, der ausschließlich in SharePoint oder auf einem Netzlaufwerk existiert, ist genau dann nicht verfügbar, wenn Sie ihn am dringendsten benötigen. Bewährt haben sich mindestens zwei gedruckte Exemplare an sicheren, zugänglichen Orten, ergänzend ein verschlüsselter USB-Stick, der extern oder bei einem leitenden Krisenteammitglied aufbewahrt wird. Wörtlich schreibt die Durchführungsverordnung das nicht vor; ein Plan, „der bei Sicherheitsvorfällen Anwendung findet“ (Nummer 4.1.1), muss im Ernstfall aber erreichbar sein.

Krisenmanagement

Krisenmanagement unterscheidet sich von Business Continuity. Business Continuity befasst sich mit der Aufrechterhaltung und Wiederherstellung von Diensten. Krisenmanagement betrifft die Koordination der Gesamtreaktion der Organisation — Führungsentscheidungen, Kommunikation mit Stakeholdern und die Handlungsfähigkeit bei einer erheblichen Störung. Anhang Nummer 4.3 der Durchführungsverordnung verlangt dafür ein festgelegtes Krisenmanagementverfahren mit Rollen, Kommunikationsmitteln zu den Behörden und Maßnahmen zur Aufrechterhaltung der Sicherheit in der Krise [5]. Wie Sie den Krisenstab organisatorisch über Incident-Response- und BC-Teams einordnen, legen Sie selbst fest.

Zusammensetzung des Krisenmanagementteams

Eine typische Zusammensetzung des Krisenmanagementteams (CMT) für ein KMU mit 50–500 Mitarbeitern:

• Krisenmanager — Gesamtverantwortung und abschließende Entscheidungsbefugnis; in der Regel ein Mitglied der Geschäftsleitung oder der COO
• BC-Koordinator — überwacht die operative Wiederherstellung aller Prozesse; koordiniert mit IT und Betrieb
• IT- / Sicherheitsverantwortlicher — technische Entscheidungsfindung; koordiniert mit dem Incident-Response-Team
• Kommunikationsverantwortlicher — verwaltet interne Nachrichten, externe Statements, Medienanfragen und Kundenbenachrichtigungen
• Rechts- und Compliance-Verantwortlicher — berät zu regulatorischen Verpflichtungen, vertraglichen Haftungen und Offenlegungsanforderungen

Binden Sie – soweit angemessen – auch kritische Anbieter und Dienstleister ein, etwa Ihren Managed Service Provider; Nummer 4.3.2 Buchstabe a nennt sie ausdrücklich.

Entscheidungsbefugnis

Krisenmanagementpläne sollten bestimmte weitreichende Entscheidungen vorab autorisieren, damit das CMT schnell handeln kann, ohne für jede Maßnahme eine außerordentliche Sitzung der Geschäftsleitung einberufen zu müssen. Typischerweise vorab autorisierte Entscheidungen umfassen: Aktivierung der DR-Umgebung, Beauftragung externer Incident-Response-Spezialisten, Benachrichtigung von Kunden über einen Datenschutzverstoß und Isolierung betroffener Netzwerksegmente. Dokumentieren Sie die erforderliche Befugnisebene für jede Entscheidungsklasse und stellen Sie sicher, dass alle CMT-Mitglieder die Grenzen kennen.

Koordination mit der NIS2-Vorfallmeldung

Nach § 32 Absatz 1 BSIG melden besonders wichtige und wichtige Einrichtungen einen erheblichen Sicherheitsvorfall an die gemeinsame Meldestelle von BSI und BBK: unverzüglich, spätestens innerhalb von 24 Stunden nach Kenntniserlangung, eine frühe Erstmeldung; spätestens innerhalb von 72 Stunden nach Kenntniserlangung eine Meldung mit erster Bewertung; spätestens einen Monat nach dieser Meldung eine Abschlussmeldung (bei andauerndem Vorfall eine Fortschrittsmeldung) [2]. Ihre Krisenmanagementverfahren sollten diese Pflichten integrieren — der Rechts-/Compliance-Verantwortliche muss Auslöser, Fristen und Meldeweg über das BSI-Portal kennen. Eine nicht, nicht richtig oder nicht rechtzeitig abgegebene Meldung ist bußgeldbewehrt (§ 65 Absatz 2 Nummer 4 BSIG) [3]. Deshalb gehört die Meldung in den Krisenworkflow und darf nicht ad hoc behandelt werden.

Nachkrisenbewertung

Führen Sie nach Abschluss einer Krise zeitnah eine formale Lessons-Learned-Überprüfung durch. Dokumentieren Sie, was geschah, was funktionierte, was scheiterte und welche konkreten Änderungen an Plänen, Verfahren, Systemen oder Schulungen vorgenommen werden. Die Erkenntnisse helfen zugleich bei der Abschlussmeldung nach § 32 BSIG, die unter anderem Ursache und Abhilfemaßnahmen beschreibt. Für die elf Einrichtungsarten der Verordnung sind Überprüfung und Aktualisierung der Pläne nach erheblichen Sicherheitsvorfällen ausdrücklich vorgesehen (Nummern 4.1.4 und 4.3.4). Ein abgelegtes Lessons-Learned-Dokument ohne Planrevisionen hat wenig Wert und belegt gegenüber einer Aufsichtsbehörde keine Verbesserungskultur.

Backup- und Wiederherstellungsanforderungen

Backup und Wiederherstellung ist der technisch präziseste Teil von Anhang Nummer 4. Die Durchführungsverordnung legt für ihre elf Einrichtungsarten Anforderungen fest, die deutlich über das bloße „Erstellen von Backups“ hinausgehen; für alle anderen Einrichtungen sind sie ein guter Maßstab für den Stand der Technik. Wer seine Verfahren anhand von Nummer 4.2 prüft, stellt häufig Lücken fest.

Backup-Geltungsbereich

Alle kritischen Daten sollten abgedeckt sein: Geschäftsdatenbanken und Anwendungsdaten, System- und Anwendungskonfigurationen, Sicherheitskonfigurationen einschließlich Firewall-Regelwerken und Zugriffssteuerungslisten, E-Mail-Daten, sofern geschäftskritisch, sowie Cloud-Dienstkonfigurationen, die für den Wiederaufbau der Umgebung erforderlich wären. Nummer 4.2.2 Buchstabe b nennt Konfigurationsdaten und in Cloud-Umgebungen gespeicherte Daten ausdrücklich [5]. Wenn Sie Systeme nicht allein aus Backups in einen funktionsfähigen, produktionsbereiten Zustand wiederherstellen können, ist Ihr Backup-Geltungsbereich unvollständig.

Backup-Häufigkeit und RPO-Abstimmung

Die Backup-Häufigkeit sollte zu den in Ihrer BIA festgelegten RPOs passen. Wenn Ihr Kunden-CRM einen RPO von 4 Stunden hat, brauchen Sie mindestens alle 4 Stunden eine Sicherung oder eine laufende Replikation. Ein nächtlicher Backup-Zeitplan reicht für ein System mit einem RPO unter 24 Stunden nicht aus. Gleichen Sie Ihre aktuellen Backup-Zeitpläne mit Ihrem BIA-Ergebnis ab — hier finden sich häufig die größten Lücken.

Die 3-2-1-Backup-Regel

Die 3-2-1-Regel ist eine bewährte Faustregel, die ENISA in ihrer Umsetzungshilfe zur Durchführungsverordnung zur Erwägung empfiehlt („Consider the 3-2-1 backup rule“) [6]. Gesetzlich vorgeschrieben ist sie weder im BSIG noch in der Verordnung. Sie hilft aber, die Vorgabe aus Nummer 4.2.2 Buchstabe c umzusetzen, Sicherungskopien nicht im selben Netz und in ausreichender Entfernung vom Hauptstandort aufzubewahren:

• 3 Kopien der Daten — Produktionsumgebung plus zwei separate Backups
• 2 verschiedene Speichermedientypen — zum Beispiel lokale Festplatte plus Cloud-Speicher oder Bandlaufwerk
• 1 Kopie extern oder in einer geografisch getrennten Cloud-Region gespeichert

Unveränderliche und Offline-Backups

Ransomware-Angriffe zielen zunehmend gezielt auf Backup-Systeme ab. Wenn Angreifer Ihre Backup-Repositories gemeinsam mit Ihren Produktionsdaten verschlüsseln können, brechen Ihre Wiederherstellungsoptionen vollständig zusammen. Nummer 4.2.2 Buchstabe c verlangt deshalb, Sicherungskopien (online oder offline) an sicheren Orten zu speichern, die sich nicht im selben Netz wie das System und in ausreichender Entfernung vom Hauptstandort befinden — unabhängig davon, ob dies technisch über Offline-Speicherung, Air-Gapping oder unveränderliche (immutable) Speicherformate umgesetzt wird. Unveränderliche Backups nennt ENISA als eine Möglichkeit, Sicherungen innerhalb der Aufbewahrungsfrist vor Veränderung oder Löschung zu schützen [6].

Integritätsprüfungen und Wiederherstellungstests

Backups zu erstellen ist notwendig, aber nicht ausreichend. Die Durchführungsverordnung verlangt regelmäßige Integritätsprüfungen der Sicherungskopien (Nummer 4.2.3) und regelmäßige Tests der Wiederherstellung von Sicherungskopien und Redundanzen. Die Tests sollen sicherstellen, dass die Kopien im Ernstfall zuverlässig sind und alle Kopien, Verfahren und Kenntnisse abdecken, die für eine wirksame Wiederherstellung nötig sind; die Ergebnisse sind zu dokumentieren, bei Bedarf sind Korrekturmaßnahmen zu ergreifen (Nummer 4.2.6) [5]. Ein festes Intervall nennt die Verordnung nicht. ENISA empfiehlt, die Prüfhäufigkeit an der Kritikalität der Daten auszurichten [6]. Bewährt hat sich:

• Testintervalle nach Kritikalität staffeln — kritische Systeme häufiger als unterstützende Systeme
• jeden Test dokumentieren: Datum, getestetes System, Datenvolumen, tatsächliche Wiederherstellungsdauer im Vergleich zum RTO, Fehler oder Auffälligkeiten
• in eine separate, isolierte Umgebung wiederherstellen — nie über die Produktion

Viele Organisationen stellen erst beim Test fest, dass Backups unvollständig sind oder die Wiederherstellung deutlich länger dauert als das RTO erlaubt. Warten Sie nicht auf einen echten Ransomware-Vorfall, um herauszufinden, ob Ihre Backups funktionieren.

Ein oft unterschätzter Teil der Business-Continuity-Pflicht ist die Krisenkommunikation im Ernstfall — wer intern und extern was kommuniziert, sobald ein Vorfall die 24-Stunden-Frist für die frühe Erstmeldung nach § 32 BSIG auslöst.

Testen und Üben Ihrer Pläne

Ein nie getesteter BC-Plan ist eine ungeprüfte Annahme. Für die elf Einrichtungsarten der Durchführungsverordnung sind Tests ausdrücklich vorgeschrieben: der Notfallplan „in geplanten Zeitabständen sowie bei erheblichen Sicherheitsvorfällen oder wesentlichen Änderungen der Betriebsabläufe oder der Risiken“ (Nummer 4.1.4), der Krisenmanagementplan entsprechend nach Nummer 4.3.4 [5]. Für alle Einrichtungen verlangt § 30 Absatz 2 Satz 2 Nummer 6 BSIG zudem „Konzepte und Verfahren zur Bewertung der Wirksamkeit von Risikomanagementmaßnahmen“ [1] — Übungen sind der naheliegende Wirksamkeitsnachweis für Business Continuity.

Konkrete Testfrequenzen schreiben weder das BSIG noch die Verordnung vor. ENISA empfiehlt in ihrer (rechtlich nicht verbindlichen) Umsetzungshilfe, die Pläne mindestens jährlich zu testen, zu überprüfen und bei Bedarf zu aktualisieren, und nennt als Methoden unter anderem Simulationen und Tabletop-Übungen [6]. Der BSI-Standard 200-4 unterscheidet folgende Übungsarten [7]:

Übungsart (BSI-Standard 200-4)	Inhalt	Was sie prüft
Planbesprechung („Schreibtischtest“)	Moderierte Besprechung eines Notfallplans mit den vorgesehenen Rolleninhabern, ohne dass Handlungsschritte real ausgeführt werden	Ob Pläne plausibel, vollständig, korrekt, aktuell und untereinander widerspruchsfrei sind
Stabsübung	Der Stab bewältigt ein simuliertes, realitätsnahes Notfallszenario	Zusammenarbeit im Stab, Führungszyklus, Lagebesprechungen, Protokollierung
Stabsrahmenübung	Erweiterte Stabsübung, bei der weitere Stellen eingebunden werden, etwa das Kommunikationsteam oder Bereiche mit zeitkritischen Prozessen	Übergreifende Kommunikation und Zusammenarbeit zwischen Stab und operativen Teams
Alarmierungsübung	Aktivieren und Durchlaufen der Alarmierungskette	Kommunikationsmittel, Abläufe und Dokumentation der Alarmierung; Erreichbarkeits- und Rückrufquote im Zeitfenster
Funktionstest	Reale Ausführung eines Notfallplans, etwa Umschalttest redundanter Systeme, Wiederanlauftest, Restore-Test von Datenbanken oder Lesbarkeitstest von Backups	Einsatzbereitschaft und Funktionsfähigkeit der für die Notfallbewältigung benötigten Maßnahmen und Ressourcen

Wie oft Sie welche Übungsart durchführen, legen Sie in einer Übungsplanung risikobasiert fest. Der BSI-Standard 200-4 nennt dafür keine festen Intervalle; schon für die Einstiegsstufe Reaktiv-BCMS sieht er aber vor, dass Stabsübung und Alarmierungsübung regelmäßig durchgeführt werden [7].

Was jede Übung prüfen sollte

Jede Übung sollte untersuchen, ob die Kommunikationsketten funktionieren (kann das vollständige CMT im vorgesehenen Zeitrahmen zusammentreten?), wie gut unter Druck entschieden wird, ob die dokumentierten technischen Wiederherstellungsverfahren stimmen, wie IT, Betrieb und Kommunikation zusammenarbeiten und ob das Team die Meldepflichten nach § 32 BSIG richtig erkennt und auslöst. Dokumentieren Sie die Ergebnisse jeder Übung und aktualisieren Sie die Pläne vor der nächsten Übung. Prüfer werden sowohl die Übungsprotokolle als auch den Nachweis der daraus folgenden Planänderungen sehen wollen.

BSI-Standard 200-4 und ISO 22301

§ 30 Absatz 2 Satz 1 BSIG verlangt, die einschlägigen europäischen und internationalen Normen zu berücksichtigen [1]. Für Business Continuity sind zwei Rahmenwerke maßgeblich; keines davon ist gesetzlich vorgeschrieben:

• BSI-Standard 200-4 „Business Continuity Management“ — Version 1.0 vom Mai 2023; er löst den BSI-Standard 100-4 ab [7]. Er bietet ein Stufenmodell mit Reaktiv-BCMS, Aufbau-BCMS und Standard-BCMS. Laut BSI ist die Stufe Standard-BCMS konform zu den Anforderungen der ISO 22301:2019, ein Anforderungskatalog mit Mapping auf die ISO-Norm steht zur Verfügung. Eine Zertifizierung nach dem BSI-Standard selbst ist derzeit nicht geplant. Das Stufenmodell eignet sich besonders für KMU, die mit einem Reaktiv-BCMS beginnen und schrittweise ausbauen wollen.
• ISO 22301:2019 — internationale Norm für Business-Continuity-Managementsysteme, ergänzt durch die Änderung ISO 22301:2019/Amd 1:2024 (Klimawandel als zu prüfender Kontextfaktor) [8]. Eine Zertifizierung ist für NIS2 nicht erforderlich, kann gegenüber Aufsicht, Kunden und Prüfern aber als unabhängiger Nachweis dienen.

Für Organisationen, die bereits mit ISO/IEC 27001 oder IT-Grundschutz arbeiten, liegt die Kombination nahe: Beide Welten folgen einem Managementsystem-Zyklus und teilen Dokumentation, Managementbewertung und interne Audits.

Benötigte Vorlagen

Für ein vollständiges BC-Programm haben sich folgende Dokumente bewährt. Die Zuordnung zeigt, welche Anforderung des Anhangs der Durchführungsverordnung das jeweilige Dokument abbildet:

Dokument	Inhalt	Bezug
BIA-Methodik und BIA-Fragebogen	Kritische Prozesse, Abhängigkeiten, MTD, RTO und RPO	Anhang Nr. 4.1.3, Erwägungsgrund 13
Business-Continuity-Strategie	Gewählte Wiederherstellungsstrategien und Ressourcen je kritischem Prozess	Anhang Nr. 4.2.4 und 4.2.5
Business-Continuity-Plan	Aktivierung und Deaktivierung, Rollen, Kontakte, Wiederherstellungsreihenfolge und -verfahren	Anhang Nr. 4.1.1 und 4.1.2
Disaster-Recovery-Plan	Systemabhängigkeiten, Wiederherstellungsverfahren, Failover und Failback der IT	Anhang Nr. 4.1.2 Buchst. e bis h
Krisenmanagementplan	Krisenstab, Entscheidungsbefugnisse, Behördenkommunikation, Meldewege	Anhang Nr. 4.3
Backup-Richtlinie	Umfang, Häufigkeit, Speicherorte, Zugriffsschutz, Aufbewahrung, Integritäts- und Wiederherstellungstests	Anhang Nr. 4.2.1 bis 4.2.3 und 4.2.6
Übungsplan und Übungsprotokoll	Übungsziele, Szenario, Ergebnisse, Korrekturmaßnahmen, Planänderungen	Anhang Nr. 4.1.4 und 4.3.4

Für eine Gesamtübersicht über alle Dokumentationspflichten nach § 30 BSIG nutzen Sie die NIS2-Compliance-Checkliste. Wie Vorfallbehandlung und Notfallplan zusammenspielen, zeigt die Incident-Response-Plan-Vorlage.

Häufig gestellte Fragen

Verlangt NIS2 einen schriftlichen Business-Continuity-Plan?

Das BSIG verlangt Maßnahmen zur Aufrechterhaltung des Betriebs (§ 30 Absatz 2 Satz 2 Nummer 3) und deren Dokumentation (§ 30 Absatz 1 Satz 3) [1]. Ohne schriftlichen Plan lässt sich das kaum nachweisen. Für die elf Einrichtungsarten der Durchführungsverordnung ist ein Notfallplan für die Aufrechterhaltung und Wiederherstellung des Betriebs ausdrücklich vorgeschrieben (Anhang Nummer 4.1.1), mit den acht Inhaltselementen der Nummer 4.1.2 [5].

Was ist der Unterschied zwischen BC-Plan und Disaster-Recovery-Plan?

Ein Business-Continuity-Plan beschreibt, wie die Organisation kritische Geschäftsprozesse während und nach einer Störung aufrechterhält – einschließlich manueller Verfahren, Ausweichstandorte, Kommunikation und Personaleinsatz. Ein Disaster-Recovery-Plan konzentriert sich auf die Wiederherstellung von IT-Systemen und Daten. Die Durchführungsverordnung fasst beides als „Notfallplan für die Aufrechterhaltung und Wiederherstellung des Betriebs“ zusammen (englisch: „business continuity and disaster recovery plan“) [5]. Ob Sie ein Dokument oder zwei verknüpfte Dokumente führen, bleibt Ihnen überlassen.

Wie oft müssen wir den BC-Plan testen?

Ein festes Intervall schreibt das Gesetz nicht vor. Für die elf Einrichtungsarten gilt: Tests „in geplanten Zeitabständen“ sowie bei erheblichen Sicherheitsvorfällen oder wesentlichen Änderungen (Anhang Nummer 4.1.4) [5]. ENISA empfiehlt als nicht verbindliche Orientierung mindestens eine jährliche Prüfung [6]. Entscheidend ist, dass Tests geplant und dokumentiert werden und die Erkenntnisse in die Pläne einfließen.

Ist die 3-2-1-Backup-Regel gesetzlich vorgeschrieben?

Nein. Weder das BSIG noch die Durchführungsverordnung nennen die 3-2-1-Regel. Die Verordnung verlangt für ihre elf Einrichtungsarten unter anderem vollständige Sicherungskopien einschließlich Konfigurations- und Cloud-Daten sowie die Speicherung an sicheren Orten außerhalb des Systemnetzes und in ausreichender Entfernung vom Hauptstandort (Nummer 4.2.2 Buchstaben b und c) [5]. Die 3-2-1-Regel ist ein bewährter Weg, das umzusetzen; ENISA empfiehlt, sie in Erwägung zu ziehen [6].

Ist eine ISO-22301-Zertifizierung erforderlich?

Nein. Weder das BSIG noch die NIS2-Richtlinie verlangen eine Zertifizierung. § 30 Absatz 2 BSIG verlangt nur, einschlägige Normen zu berücksichtigen [1]. Eine Zertifizierung nach ISO 22301 oder ein BCMS nach BSI-Standard 200-4 kann den Nachweis gegenüber Prüfern aber erleichtern.

Welche Aufbewahrungsfrist gilt für Backups?

Eine feste Frist nennt die Durchführungsverordnung nicht. Nummer 4.2.2 Buchstabe f verlangt „Aufbewahrungsfristen entsprechend geschäftlichen und regulatorischen Anforderungen“ [5]. Legen Sie die Fristen anhand gesetzlicher Aufbewahrungspflichten, des Grundsatzes der Datenminimierung nach DSGVO, forensischer Anforderungen und vertraglicher Zusagen fest und dokumentieren Sie die Begründung.

Brauchen wir einen eigenen Ausweich-Standort (DR-Site)?

Nicht zwingend. Das BSIG schreibt keine bestimmte Wiederherstellungsarchitektur vor. Die Durchführungsverordnung verlangt für ihre elf Einrichtungsarten eine „zumindest teilweise Redundanz“ von Systemen, Betriebsstätten, Personal und Kommunikationskanälen auf Grundlage der Risikobewertung (Nummer 4.2.4) [5]. Für viele KMU kann eine Cloud-basierte Wiederherstellung oder ein DR-Dienstleister ausreichen, sofern sie die eigenen RTOs nachweislich erreicht.

Quellen

1. § 30 BSIG — Risikomanagementmaßnahmen besonders wichtiger Einrichtungen und wichtiger Einrichtungen, gesetze-im-internet.de — insbesondere Absatz 1 Sätze 1 bis 3, Absatz 2 Satz 1 und Satz 2 Nummern 3, 6 und 10, Absatz 3.
2. § 32 BSIG — Meldepflichten, gesetze-im-internet.de.
3. § 65 BSIG — Bußgeldvorschriften, gesetze-im-internet.de — Absatz 2 Nummern 2 bis 4.
4. Richtlinie (EU) 2022/2555 (NIS2-Richtlinie), deutsche Amtsblattfassung, EUR-Lex — Artikel 21 Absätze 1 und 2.
5. Durchführungsverordnung (EU) 2024/2690 der Kommission vom 17. Oktober 2024, deutsche Amtsblattfassung, EUR-Lex — Erwägungsgrund 13, Artikel 1 und 2, Anhang Nummern 3.1.2 und 4.1 bis 4.3.
6. ENISA. Technical Implementation Guidance on Cybersecurity Risk Management Measures, Version 1.0, Juni 2025 (PDF) — Leitfaden zu Anhang Nummern 4.1.4, 4.2.3 und 4.2.6.
7. BSI-Standard 200-4: Business Continuity Management, Bundesamt für Sicherheit in der Informationstechnik — Version 1.0, Mai 2023; Kapitel 1.3 (Stufenmodell) und 13 (Üben und Testen).
8. ISO 22301:2019 — Security and resilience — Business continuity management systems — Requirements, ISO, mit Amendment 1:2024 (Climate action changes).
9. § 28 BSIG — Besonders wichtige Einrichtungen und wichtige Einrichtungen, gesetze-im-internet.de — Absätze 5 und 6.

Eine vollständige Schritt-für-Schritt-Anleitung finden Sie unter Backup-Management und Wiederherstellung.

Welche Abschnitte davon in ein konkretes Dokument gehören — und unter welcher Bedingung Sie einen weglassen dürfen — zeigt unsere IT-Notfallplan-Vorlage: die 8 Abschnitte aus Anhang 4.1.2.