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

Zuletzt geprüft: März 2026. Dieser Leitfaden behandelt Article 21(2)(c) der Richtlinie (EU) 2022/2555 sowie die technischen Mindestanforderungen gemäß Commission Implementing Regulation (EU) 2024/2690 (CIR), Annex 4.

Article 21(2)(c) der NIS2-Richtlinie verpflichtet jede betroffene Einrichtung zur Umsetzung von Maßnahmen für Business Continuity, einschließlich Backup-Management, Disaster Recovery und Krisenmanagement. Es handelt sich dabei um eine der zehn verpflichtenden Cybersicherheits-Risikomanagementmaßnahmen gemäß Article 21 — und sie gilt gleichermaßen für wesentliche Einrichtungen und wichtige Einrichtungen, unabhängig von Größe oder Sektor.

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 — doch NIS2 fordert etwas Strukturierteres: einen dokumentierten Plan, definierte Verantwortlichkeiten, getestete Wiederherstellungsverfahren und klare Wiederherstellungsziele für jeden kritischen Prozess.

Dieser Leitfaden erläutert genau, was Article 21(2)(c) verlangt, wie Sie ein konformes Programm von Grund auf aufbauen und welche Dokumente Sie als Nachweis der Compliance benötigen. 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 Article 21(2)(c) verlangt

Der Text der NIS2-Richtlinie in Article 21(2)(c) ist bewusst knapp gehalten: “Business Continuity, wie etwa Backup-Management und Disaster Recovery sowie Krisenmanagement.” Die operativen Details ergeben sich aus Commission Implementing Regulation (CIR) 2024/2690, Annex 4, der die technischen Mindestmaßnahmen in drei Teilbereichen festlegt.

Annex 4.1 — Business-Continuity- und Disaster-Recovery-Plan

Die CIR verlangt einen dokumentierten Business-Continuity- und Disaster-Recovery-Plan, der:

• Kritische Prozesse und die davon abhängigen Ressourcen identifiziert — Systeme, Daten, Personal, Einrichtungen und Drittanbieter
• Rollen und Verantwortlichkeiten definiert für alle Business-Continuity-Aktivitäten, einschließlich namentlich benannter Stellvertreter für jede Schlüsselrolle
• Wiederherstellungsverfahren festlegt für verschiedene Störungsszenarien, darunter Ransomware, Hardwareausfall, Ausfall von Betriebsstätten und Ausfall von Schlüsselpersonal
• Kommunikationsprotokolle für Krisensituationen definiert — wer wen benachrichtigt, über welche Kanäle und bei welchen Schwellenwerten
• Recovery Time Objectives (RTOs) und Recovery Point Objectives (RPOs) festlegt für alle kritischen Dienste, basierend auf einer formalen Folgenabschätzung

Annex 4.2 — Backup und Redundanz

Die CIR verlangt eine dokumentierte Backup-Richtlinie, die Folgendes festlegt:

• Geltungsbereich — welche Daten, Systeme und Konfigurationen abgedeckt sind
• Häufigkeit — Backup-Zeitpläne, die mit den für jedes System festgelegten RPOs übereinstimmen
• Methode und Speicherorte — wo Backups aufbewahrt werden, in welchem Format und wer Zugang hat
• Regelmäßige Wiederherstellungstests — Überprüfung, dass Backups erfolgreich wiederhergestellt werden können, nicht nur erstellt wurden
• Schutz vor denselben Risiken wie primäre Systeme — Backups dürfen nicht denselben Ransomware-Angriffen oder Betriebsstättenausfällen ausgesetzt sein, die die Produktion beeinträchtigen könnten
• Offline- oder unveränderliche Backups — insbesondere zum Schutz vor Ransomware, die auf Backup-Repositories abzielt und diese verschlüsselt

Annex 4.3 — Krisenmanagement

Die CIR verlangt Krisenmanagementverfahren, die Folgendes etablieren:

• Eine Krisenmanagementstruktur mit definierten Befugnissen und Eskalationspfaden
• Eskalationskriterien — welches Ausmaß einer Störung das Krisenmanagement gegenüber der normalen Incident-Response auslöst
• Kommunikationskanäle — sowohl intern als auch extern, einschließlich der Erreichbarkeit des Krisenteams bei Ausfall primärer IT-Systeme
• Koordination mit den Verfahren zur Incident-Behandlung gemäß Annex 3, um sicherzustellen, dass BC und Krisenmanagement direkt mit Ihrem Incident-Response-Workflow verbunden sind

Zusammen bilden diese drei Teilanforderungen ein vollständiges BC-Programm. Die meisten KMU müssen alle drei von Grund auf aufbauen. Die folgenden Abschnitte führen Sie in der richtigen Reihenfolge durch den Prozess. Für den übergeordneten Kontext aller zehn Article-21-Maßnahmen lesen Sie die Übersicht zu den NIS2-Anforderungen.

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 muss abgeschlossen sein, bevor Sie ein einziges Wiederherstellungsverfahren verfassen. Ohne sie sind Ihre Wiederherstellungsziele bloße Schätzungen.

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 ist für die meisten KMU ausreichend 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: 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 ist die absolute maximale Zeitspanne, die Ihre Organisation ohne einen Prozess überbrücken kann, bevor die Folgen inakzeptabel werden. Ihr Recovery Time Objective (RTO) muss stets kürzer sein als Ihre MTD — andernfalls ist Ihre Wiederherstellungskapazität zu langsam, um ernsthaften Schaden zu verhindern. 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 veranschaulicht fünf typische Geschäftsprozesse:

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. Sie sollte mindestens jährlich überprüft und nach wesentlichen Änderungen an Ihren Systemen, Lieferanten oder Ihrem Geschäftsmodell aktualisiert werden.

Entwicklung Ihrer BC-Strategie

Sobald die BIA abgeschlossen ist, müssen Sie Wiederherstellungsstrategien auswählen, 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 innerhalb von Minuten bis Stunden erreicht werden. Kosteneffektiv und für die meisten KMU realisierbar.
• 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 die Anforderung erfüllen. Aufträge werden telefonisch entgegengenommen, Daten nach Systemwiederherstellung abgeglichen. Gültig 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

NIS2 Article 21(1) verlangt ausdrücklich, dass Maßnahmen proportional zum Risiko, zur Größe der Einrichtung und zu den Auswirkungen von Vorfällen sein müssen. Ein produzierendes Unternehmen mit 50 Mitarbeitern benötigt kein Hot-Standby-Rechenzentrum. Es benötigt jedoch: getestete Backup-Wiederherstellung für alle kritischen Daten, dokumentierte manuelle Ausweichverfahren für seine prioritären Prozesse und ein Krisenteam, das innerhalb eines definierten Zeitrahmens zusammengestellt werden kann. Verhältnismäßigkeit ist keine Rechtfertigung für Untätigkeit — sie bedeutet, dass Ihre Strategie Ihrem tatsächlichen Risikoexposure 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.

Geltungsbereich und Aktivierungskriterien

Definieren Sie ausdrücklich, was die Planaktivierung auslöst. 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 keine Managemententscheidung zur Feststellung 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 persönliche Mobiltelefonnummern und alternative Kontaktmethoden auf. 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 den Vorstand? 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. 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 sowie den Namen des verantwortlichen Eigentümers.

Kommunikationsplan

Legen Sie Kommunikationsverantwortlichkeiten und genehmigte 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), Aufsichtsbehörden (NIS2-Meldepflichten bei Vorfällen — 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. Bewahren Sie mindestens zwei gedruckte Exemplare an sicheren, zugänglichen Orten auf. Erwägen Sie außerdem einen passwortgeschützten USB-Stick, der extern oder bei einem leitenden Krisenteammitglied aufbewahrt wird. Die Zugänglichkeit ist keine optionale Bequemlichkeit — es ist eine CIR-Anforderung, dass Pläne während eines Störungsvorfalls nutzbar sind.

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. Annex 4.3 verlangt eine Krisenmanagementstruktur, die parallel zu und übergeordnet gegenüber Ihren Incident-Response- und BC-Teams operiert.

Zusammensetzung des Krisenmanagementteams

Typische Zusammensetzung des CMT für ein KMU mit 50–500 Mitarbeitern:

• Krisenmanager — Gesamtverantwortung und abschließende Entscheidungsbefugnis; in der Regel ein leitender Direktor oder 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

Entscheidungsbefugnis

Krisenmanagementpläne sollten bestimmte weitreichende Entscheidungen vorab autorisieren, damit das CMT schnell handeln kann, ohne für jede Maßnahme eine außerordentliche Vorstandssitzung 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

Gemäß NIS2 müssen erhebliche Vorfälle innerhalb von 24 Stunden nach erster Feststellung (Frühwarnung) an die zuständige nationale Behörde gemeldet werden, mit einer ausführlicheren Meldung innerhalb von 72 Stunden. Ihre Krisenmanagementverfahren müssen diese Verpflichtungen integrieren — der Rechts-/Compliance-Verantwortliche muss die Auslöser, Fristen und Meldekanäle kennen. Eine unterlassene Meldung stellt selbst einen Compliance-Verstoß dar, daher muss dies in den Krisenworkflow integriert und darf nicht ad hoc behandelt werden.

Nachkrisenbewertung

Führen Sie innerhalb von 30 Tagen nach Abschluss einer Krise 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 Überprüfung muss handlungsrelevante Aktualisierungen hervorbringen — ein abgelegtes Lessons-Learned-Dokument ohne Planrevisionen hat keinen Mehrwert und belegt gegenüber einer Aufsichtsbehörde keine Verbesserungskultur.

Backup- und Wiederherstellungsanforderungen

Backup und Wiederherstellung ist der technisch präziseste Teil von Annex 4. Die CIR legt Mindestanforderungen fest, die deutlich über das bloße „Erstellen von Backups“ hinausgehen. Viele Organisationen, die glauben, über angemessene Backup-Praktiken zu verfügen, stellen bei der Prüfung ihrer Verfahren anhand von Annex 4.2 kritische Lücken fest.

Backup-Geltungsbereich

Alle kritischen Daten müssen 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. 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 muss mit den in Ihrer BIA festgelegten RPOs übereinstimmen. Wenn Ihr Kunden-CRM einen RPO von 4 Stunden hat, müssen Sie mindestens alle 4 Stunden Backups erstellen. Ein nächtlicher Backup-Zeitplan ist für jedes System mit einem RPO unter 24 Stunden unzureichend. Gleichen Sie Ihre aktuellen Backup-Zeitpläne mit Ihrem BIA-Ergebnis ab — hier finden sich häufig die größten Compliance-Lücken.

Die 3-2-1-Backup-Regel

Die 3-2-1-Regel ist der branchenübliche Mindeststandard und erfüllt direkt die Anforderung aus Annex 4.2, dass Backups vor denselben Risiken wie primäre Systeme geschützt sind:

• 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. Annex 4.2 verlangt aus diesem Grund ausdrücklich die Ber