Business-Continuity-Plan nach NIS2: BCP, Risikoanalyse und Krisenübungen wirksam verbinden

Ein auf die Anforderungen der NIS2 ausgerichteter Business-Continuity-Plan darf keine isolierte, allein von der IT gepflegte Verfahrensanweisung sein. Er muss aus der Business-Impact-Analyse und der Risikoanalyse abgeleitet werden, klare Prioritäten für die Wiederherstellung von Prozessen setzen und regelmäßig erprobt werden. Seine Wirksamkeit zeigt sich nicht in Absichtserklärungen, sondern in der Fähigkeit der Organisation, Entscheidungen zu treffen, Notbetriebsverfahren zu aktivieren, ein definiertes Mindestbetriebsniveau zu erreichen und anschließend sicher in den Normalbetrieb zurückzukehren.

Business Continuity ist eine Managemententscheidung

Ein Business-Continuity-Plan beginnt weder mit einer Verfahrensvorlage noch mit einer Liste der IT-Systeme. Ausgangspunkt sind Dienstleistungen, Produkte und Prozesse, deren Unterbrechung die Erfüllung von Verpflichtungen, die Sicherheit, die Einhaltung relevanter Anforderungen oder die finanzielle Stabilität des Unternehmens gefährden kann. Der Umfang des Plans ist aus einer Business-Impact-Analyse abzuleiten. Dabei muss die Organisation feststellen, wie sich Auswirkungen im Zeitverlauf verschärfen, wann sie die vom Management akzeptierte Schwelle überschreiten und in welcher Reihenfolge die betrieblichen Fähigkeiten wiederherzustellen sind.

Die maximal tolerierbare Ausfallzeit und das akzeptable Verlustniveau dürfen nicht allein durch die IT festgelegt werden. Diese Parameter sind von der Leitung auf Grundlage der Informationen der Prozesseigner sowie der Bereiche Finanzen, Compliance, Sicherheit und Technologie zu genehmigen. Der Prozesseigner definiert die Kontinuitätsanforderungen, während der Planverantwortliche die Entwicklung und Aufrechterhaltung der Lösung koordiniert. Fehlt ein gemeinsamer Entscheidungsmechanismus, schützt die IT zwar die Infrastruktur und der operative Bereich verantwortet die Leistungserbringung, doch der Unternehmensleitung fehlt ein konsistentes Bild der Wiederanlaufprioritäten und tolerierbaren Unterbrechungen.

In einem Produktionsbetrieb bedeutet die Wiederherstellung des Planungs- oder Steuerungssystems noch nicht, dass der Versand wieder aufgenommen werden kann. Die Produktion kann weiterhin stillstehen, weil technologische Daten, autorisierte Bediener, Energieversorgung, die vom Dienstleister bereitgestellte Kommunikation oder ein genehmigtes Notbetriebsverfahren fehlen. Operative Resilienz entsteht erst, wenn der Plan die vollständige Abhängigkeitskette des Prozesses abbildet und nicht nur die von der IT kontrollierten Ressourcen.

Zudem sind Business Continuity, IT-Wiederherstellung, Incident Response und Krisenmanagement voneinander abzugrenzen. Business Continuity betrifft die Aufrechterhaltung oder Wiederaufnahme von Prozessen, IT-Wiederherstellung die Wiederherstellung von Technologie und Daten, Incident Response die Eindämmung und Bearbeitung eines Ereignisses und Krisenmanagement die Entscheidungsfindung unter den Bedingungen einer schwerwiegenden Störung. Diese Mechanismen sollten gemeinsame Szenarien, Eskalationsschwellen und Verantwortungsregeln nutzen, sind jedoch nicht austauschbar.

Erst ein so definiertes Betriebsmodell kann den aus NIS2 und den jeweils einschlägigen nationalen Vorschriften resultierenden Pflichten zu Risikomanagement, Business Continuity, Incident Management und Leitungsverantwortung gegenübergestellt werden. Dabei ist zu berücksichtigen, ob und in welchem Umfang die Organisation in den persönlichen Anwendungsbereich fällt. Einen breiteren Kontext bietet der Beitrag NIS2 für Produktionsunternehmen: Wer ist betroffen, welche Pflichten entstehen und wie lässt sich die Organisation vorbereiten, ohne das Thema auf die IT zu reduzieren.

Aus Risiken müssen belastbare Szenarien entstehen

Ein Risikoregister steuert den Business-Continuity-Plan nur dann wirksam, wenn es den Zusammenhang zwischen Bedrohung, Schwachstelle, Ressource, Prozess und geschäftlicher Auswirkung erkennen lässt. Eine reine Liste von Cyberbedrohungen beantwortet nicht die Frage, wie der Betrieb aufrechterhalten werden soll. Szenarien sollten deshalb um die Auswirkungen einer Störung aufgebaut werden, beispielsweise die Nichtverfügbarkeit eines Steuerungssystems, Datenverlust, Kommunikationsausfall, Personalausfall oder die Nichtverfügbarkeit eines Dienstleisters. Unterschiedliche Ursachen können zum gleichen Betriebszustand führen und dieselbe Kontinuitätsstrategie erfordern.

Business-Impact-Analyse und Risikoanalyse erfüllen unterschiedliche, aber sich ergänzende Aufgaben. Die Business-Impact-Analyse bewertet die Bedeutung einer Unterbrechung, die zeitliche Zunahme der Schäden und den Zeitpunkt, an dem die vom Management akzeptierte Schwelle überschritten wird. Die Risikoanalyse identifiziert mögliche Ereignisursachen, Schwachstellen und die Wirksamkeit vorhandener Kontrollen. Methode und Bewertungsskala müssen den Vergleich von Szenarien und eine bewusste Akzeptanz des Restrisikos im Einklang mit der Risikobereitschaft ermöglichen.

Die Zahl der Szenarien sollte auf klar unterscheidbare Auswirkungen begrenzt werden, die andere Entscheidungen, Ressourcen oder Wiederherstellungsreihenfolgen erfordern. Jede technische Variante separat zu analysieren, erhöht meist nicht den praktischen Nutzen des Plans, erschwert aber seine Pflege und Anwendung unter Zeitdruck.

Für jedes Szenario sind die tolerierbare Ausfallzeit, das Mindestbetriebsniveau, die benötigten Ressourcen, die Wiederherstellungsreihenfolge und die zur Aktivierung des Plans befugte Person festzulegen. Diese Parameter sollten sich auf reale Stillstands- und Wiederherstellungszeiten aus Vorfällen, Ausfällen und Übungen sowie auf vertragliche Anforderungen an Verfügbarkeit, Liefertermine und Störungsmeldungen stützen. Auf dieser Grundlage lassen sich die Zeit bis zur Entscheidung, bis zum Erreichen des Mindestbetriebs und bis zur vollständigen Wiederherstellung messen.

Die Analyse muss die tatsächlichen Abhängigkeiten des Prozesses von Anwendungen, Daten, Infrastruktur, Standorten, Versorgungsmedien, Schlüsselkompetenzen, IT-Dienstleistern, Integratoren und Unterauftragnehmern berücksichtigen. Setzt die Strategie die Unterstützung Dritter voraus, sind deren Verfügbarkeit, Reaktionszeiten, Eskalationswege und Ersatzlösungen praktisch zu prüfen. Vertragliche Zusagen allein reichen nicht aus. Dieses Thema vertieft der Beitrag NIS2 und Sicherheit der Lieferkette: IT-Dienstleister, Integratoren und Unterauftragnehmer bewerten.

Der Plan muss durch die Störung führen

Ein praxistauglicher Business-Continuity-Plan beschreibt nicht jedes denkbare Ereignis. Er führt die Verantwortlichen strukturiert durch die erforderlichen Entscheidungen. Er muss festlegen, wer die Lage bewertet, wer den Kontinuitätsmodus ausruft, welche Prozesse auf Mindestniveau aufrechterhalten werden, in welcher Reihenfolge Fähigkeiten wiederherzustellen sind, wie die Krisenkommunikation erfolgt und nach welchen Kriterien der Notbetrieb beendet wird.

Der Detaillierungsgrad ist angemessen, wenn der Plan den Interpretationsbedarf unter Zeitdruck reduziert, ohne technische und prozessbezogene Arbeitsanweisungen zu ersetzen. In größeren Organisationen bewährt sich ein übergeordneter Plan, der Führungs-, Eskalations- und Kooperationsregeln festlegt und durch prozessbezogene Teilpläne ergänzt wird.

Für die Aktivierung sind messbare Kriterien erforderlich. Die Formulierung „bei einer schwerwiegenden Störung“ verlagert die Diskussion darüber, was als schwerwiegend gilt, auf den ungünstigsten Zeitpunkt. Ein Kriterium kann die Überschreitung der tolerierbaren Ausfallzeit, der Verlust der Datenvertrauenswürdigkeit, die Unmöglichkeit eines sicheren Betriebs, die Nichtverfügbarkeit von Schlüsselpersonen oder ein absehbares Unterschreiten des vom Prozesseigner genehmigten Mindestbetriebsniveaus sein. Jede Abweichung ist mit einer Maßnahme, einer entscheidungsbefugten Funktion, einer Eskalationsfrist und dem erforderlichen Nachweis zu verknüpfen. Eine vergleichbare Logik auf einer anderen operativen Ebene beschreibt der Beitrag Reaktionsplan im Control Plan – Maßnahmen bei Überschreitung von Prozessgrenzen beschreiben.

Rollen sollten Funktionen und nicht ausschließlich einzelnen Namen zugeordnet werden. Eine Verantwortungsmatrix muss Stellvertretungen, Befugnisumfang, Verfügbarkeit sowie primäre und alternative Kommunikationswege abbilden. Eine personenbezogene Kontaktliste kann als gelenkte Anlage geführt werden, sodass personelle Änderungen keine grundlegende Überarbeitung des gesamten Plans erfordern.

Die Unternehmensleitung muss über Entscheidungen befinden, die den genehmigten operativen Rahmen überschreiten. Dazu gehören die Akzeptanz wesentlicher Geschäftsrisiken, die Freigabe außergewöhnlicher Maßnahmen oder Kommunikation von strategischer Bedeutung. Die Entscheidung zur Aktivierung eines bereits genehmigten Notbetriebs sollte dagegen möglichst nah am betroffenen Prozess getroffen werden können.

Fällt das Auftragssystem aus, kann der Bereitschaftsdienst die Nichtverfügbarkeit und die voraussichtliche Ausfallzeit bestätigen, der Prozesseigner die Ersatzdokumentation aktivieren und der Business-Continuity-Koordinator nach Erreichen der festgelegten Schwelle eskalieren. Der Plan muss auch die Grenzen eines solchen Workarounds definieren: Kapazität, maximale Einsatzdauer, Anforderungen an Schutz und Integrität der Daten, erforderliche manuelle Abstimmungen und die spätere Übertragung der Aufzeichnungen in das reguläre System.

Die Rückkehr in den Normalbetrieb darf erst erfolgen, wenn die Stabilität der Lösung, die Vollständigkeit der Daten und die Abstimmung der manuell durchgeführten Vorgänge bestätigt wurden. Die dabei entstehenden Aufzeichnungen müssen eine Bewertung der Entscheidungszeit, der Zeit bis zum Mindestbetrieb und der Zeit bis zur vollständigen Wiederherstellung ermöglichen.

Die größten Verluste entstehen an den Schnittstellen der Pläne

Das Ausmaß eines Schadens wird nicht nur durch die Ursache des Ausfalls bestimmt. Verzögerungen entstehen auch durch ausstehende Freigaben, uneindeutige Ereignisklassifizierungen, widersprüchliche Wiederherstellungsprioritäten oder mangelnde Transparenz über Abhängigkeiten zwischen Prozessen, Systemen und Lieferanten. Der Incident-Response-Plan dient in erster Linie der Erkennung, Bewertung, Eindämmung und Bearbeitung eines Ereignisses. Der Business-Continuity-Plan soll dagegen den Betrieb auf einem akzeptierten Niveau aufrechterhalten. Beide Mechanismen müssen gemeinsame Übergabepunkte für Informationen und Entscheidungen festlegen: Wer erkennt die Gefährdung der Kontinuität, wer aktiviert den Notbetrieb und wer genehmigt die Rückkehr zum Normalbetrieb?

Die technische Wiederherstellungspriorität muss aus der Priorität des Geschäftsprozesses abgeleitet werden, darf sie aber nicht einfach eins zu eins abbilden. Ein System für den wichtigsten Prozess kann voraussetzen, dass Identitäts-, Netzwerk-, Datenbank- oder Integrationsdienste zuerst verfügbar sind. Gleichzeitig müssen Datenintegrität, korrekte Startreihenfolgen und Sicherheitsmechanismen gewährleistet bleiben. Die Übereinstimmung von geschäftlichen und technischen Prioritäten wird geprüft, indem die erforderliche Prozessverfügbarkeit mit den tatsächlichen Ergebnissen von Wiederherstellungstests, dem tolerierbaren Datenverlust und den Infrastrukturabhängigkeiten verglichen wird.

Der operative Bereich kann erwarten, dass die Auftragsannahme vor der Abrechnung wieder aufgenommen wird. Die IT plant möglicherweise, zuerst die Abrechnung wiederherzustellen, weil dort das zentrale Geschäftspartnerregister geführt wird. Wurde diese Abhängigkeit nicht vorab abgestimmt, fällt die Entscheidung unter Zeitdruck, und ein manueller Workaround kann Daten erzeugen, die später nicht sicher abgeglichen werden können. Ein solcher Fall ist anhand der tatsächlichen Zeiten für Erkennung, Eskalation, Entscheidung und Wiederherstellung sowie anhand der Testergebnisse zur Vollständigkeit und Integrität der Daten zu bewerten.

Eine vergleichbare Lücke entsteht an der Verantwortungsgrenze zum Dienstleister. Eine vertragliche Verfügbarkeitszusage ersetzt weder einen personenbezogenen oder funktionsbezogenen Eskalationsweg noch abgestimmte Wiederherstellungsparameter, Zugang zu Informationen über den Störungsverlauf oder die Verpflichtung zur Mitwirkung an Übungen. Die Anforderungen kritischer Prozesse müssen mit den Vertragsbedingungen und den tatsächlichen Fähigkeiten des Dienstleisters abgeglichen werden. Erst dann kann fundiert entschieden werden, ob eine Ersatzlösung vorzuhalten, ein Ausfall zu akzeptieren oder auf interne beziehungsweise externe Ressourcen zurückzugreifen ist.

Das Budget sollte auf Fähigkeitslücken ausgerichtet sein und nicht auf die Anzahl erstellter Dokumente. Investitionen können zusätzliche Redundanz, kürzere Entscheidungswege, häufigere Wiederherstellungstests, geänderte Vertragsbedingungen oder alternative Verfahren zur Prozessdurchführung betreffen. Die Strukturierung solcher Kosten wird im Beitrag Was kostet die Umsetzung von NIS2 und uKSC – Budget für Audit, Dokumentation, Schulungen und Sicherheitsmaßnahmen ohne kostspielige Fehlentscheidungen planen erläutert.

Übungen müssen Entscheidungen auf die Probe stellen

Eine Business-Continuity-Übung darf sich nicht auf das Vorlesen einer Verfahrensanweisung oder die Bestätigung der Anwesenheit beschränken. Sie sollte eine klar formulierte Hypothese prüfen, beispielsweise: Kann die Organisation einen Ersatzprozess ohne das primäre System aktivieren, die Kontrolle über neu erfasste Daten behalten und diese nach der Wiederherstellung des Dienstes sicher abgleichen?

Das Übungsprogramm sollte schrittweise weiterentwickelt werden: von der Überprüfung der Rollen und einer Tabletop-Übung über den Test eines ausgewählten Verfahrens oder einer Wiederherstellung bis zu einer technisch-operativen Übung mit Beteiligung von Fachbereichen, IT, Leitung und Dienstleistern. Der Umfang ist entsprechend dem Risiko, der Bedeutung des Prozesses und dem Reifegrad der Organisation zu erhöhen.

Das Szenario muss Entscheidungen unter Bedingungen verlangen, die einer realen Störung möglichst nahekommen. Dazu können unvollständige Informationen, Zeitdruck, konkurrierende Prioritäten oder der Ausfall einer wesentlichen Abhängigkeit gehören, etwa einer freigabeberechtigten Person, eines Dienstleisters oder der aktuellen Kontaktliste. Die Übung darf jedoch nicht als Falle für die Teilnehmenden konzipiert sein. Bewertet wird das System: die Verteilung der Verantwortung, die Qualität der Informationen, die Umsetzbarkeit der Verfahren und die Eskalationsfähigkeit – nicht die individuelle Leistung einzelner Beschäftigter.

Die Leitung muss beteiligt werden, wenn das Szenario eine Risikoakzeptanz, eine Änderung der Prioritäten oder die Freigabe einer kostenintensiven Ersatzlösung erfordert. Ein Dienstleister ist einzubeziehen, wenn seine Reaktion für die Kontinuität des Prozesses entscheidend ist.

Eine beispielhafte Übung kann mit dem Ausfall des Auftragsbearbeitungssystems beginnen. Anschließend informiert die Übungsleitung über eine unvollständige Datensicherung und eine verzögerte Reaktion des Dienstleisters. Das Team muss entscheiden, ob die manuelle Bearbeitung aktiviert wird, welche Aufträge angenommen werden und wie Aufzeichnungen zu kennzeichnen sind, damit nach Wiederherstellung des Dienstes Dubletten und Integritätsverluste vermieden werden.

Während der Übung sind die Zeiten für die Erkennung der Störung, die Eskalation, die Aktivierung des Kontinuitätsmodus, das Erreichen des Mindestbetriebs und die Wiederherstellung zu messen. Parallel werden die Qualität des Informationsflusses und der Aufzeichnungen, die Verwendung veralteter Kontaktdaten, unwirksame Eskalationen und nicht durchführbare Planschritte bewertet. Die erreichten Zeiten sind mit den genehmigten Kontinuitätszielen zu vergleichen.

Häufigkeit und Form der Übungen sollten sich aus dem Risiko, Änderungen in den Prozessen, den Ergebnissen früherer Tests und der Bedeutung der Abhängigkeiten ergeben – nicht ausschließlich aus einem Jahresplan. Eine angekündigte Übung eignet sich besser zum Lernen und zur Abstimmung der Rollen. Eine unangekündigte Übung bewertet die tatsächliche Bereitschaft, erfordert aber eine kontrollierte Beherrschung des operativen Risikos. Produktivsysteme sollten nur dann eingesetzt werden, wenn Umfang, Schutzmaßnahmen und Abbruchmöglichkeit bewusst genehmigt wurden. Andernfalls ist eine Testumgebung vorzuziehen.

Jede Übung muss mit Feststellungen und Maßnahmen enden, für die Verantwortliche, Umsetzungsfristen, Wirksamkeitskriterien und eine Entscheidung über die erneute Prüfung festgelegt sind. Der Anteil fristgerecht abgeschlossener Maßnahmen ist eine nützliche Kennzahl, doch der Status „erledigt“ belegt noch keine Verbesserung. Maßgeblich ist das Ergebnis des Wiederholungstests. Bei der Strukturierung von Szenarien, Protokollen, Korrekturmaßnahmen und Kennzahlen kann der Ansatz aus dem Beitrag Vorlagenbibliothek für das Qualitätsmanagement aufbauen: FMEA, Control Plan, 8D, Audit, CAPA und KPI unterstützen.

Den Zyklus mit Nachweisen und Managementbewertung schließen

Ein vollständiger Satz von Verfahrensanweisungen belegt noch keine Fähigkeit zur Aufrechterhaltung des Betriebs. Eine belastbare Nachweiskette muss die genehmigten Annahmen aus Risiko- und Kontinuitätsanalysen, Entscheidungen der Prozesseigner, Aufzeichnungen aus Tests, Übungsergebnisse, festgestellte Nichtkonformitäten, Korrekturmaßnahmen und deren Wirksamkeitsbewertung miteinander verknüpfen. Der Änderungsnachweis des Business-Continuity-Plans sollte nicht nur Datum und Urheber einer Änderung nennen, sondern auch das Ereignis, die Entscheidung oder das Analyseergebnis, das die Änderung ausgelöst hat.

Die Überprüfungshäufigkeit des Plans muss zur Kritikalität der Prozesse und zur Veränderlichkeit des Risikos passen. Ein fester Prüfzyklus allein genügt nicht. Eine Überprüfung ist auch nach einem Vorfall, einer Übung oder einer wesentlichen Änderung von Prozessen, Technologien, Standorten, Dienstleistern, Organisationsstruktur oder Risikoprofil auszulösen. Die Akzeptanzkriterien für Übungsergebnisse sind vor Beginn festzulegen, damit die Bewertung nicht auf der subjektiven Aussage beruht, die Organisation habe die Situation „bewältigt“.

Das monatliche Monitoring kann zeigen, dass das Übungsprogramm planmäßig umgesetzt wurde, während ein Prozess die geforderte Wiederherstellungszeit nicht erreicht hat und für einen kritischen Dienstleister weiterhin keine Ersatzlösung besteht. Ein solches Ergebnis darf nicht in einem technischen Protokoll verborgen bleiben. Der Leitung sind die Prozesse zu berichten, welche die erforderliche Fähigkeit nicht erreichen, ebenso nicht akzeptierte Abweichungen, bewusst übernommene Risiken und notwendige Investitionen oder organisatorische Entscheidungen. Die Managementbewertung muss mit dokumentierten Beschlüssen enden und darf sich nicht auf die Kenntnisnahme von Informationen beschränken.

Das interne Audit sollte die Übereinstimmung von Festlegungen und Praxis prüfen: Nimmt ein als kritisch eingestufter Prozess tatsächlich an Übungen teil? Entsprechen die technischen Wiederherstellungsziele den operativen Anforderungen? Wurden Maßnahmen aus Tests abgeschlossen und ihre Wirksamkeit bestätigt? Auditoren oder Aufsichtsstellen sollte eine durchgängige Nachweiskette vorgelegt werden können, die vom erkannten Risiko über Entscheidung und Erprobung bis zur verifizierten Verbesserung reicht. Unterstützende Kennzahlen sind der Umsetzungsgrad des genehmigten Übungsprogramms, die Termintreue bei Korrekturmaßnahmen und die Anzahl nicht akzeptierter Abweichungen zwischen geforderter und nachgewiesener Kontinuitätsfähigkeit.

Die abschließende Maßnahmenliste kann in den umfassenderen Zeitplan aus dem Beitrag NIS2-Umsetzung nach Aufnahme in das KSC-Verzeichnis – Maßnahmenplan bis zum 3. April 2027 eingebettet werden. Fristen, Pflichtenumfang und geeignete Maßnahmen sind jedoch jeweils anhand der aktuellen Rechtslage, des Status der Organisation im nationalen Cybersicherheitssystem und ihres tatsächlichen Risikoprofils zu verifizieren.