Was 200-4 ist und wo er steht
200-4 ist laut Änderungshistorie eine Neukonzeption auf Basis von 100-4, angepasst an ISO 22301:2019. Neu gegenüber 100-4 sind unter anderem das Stufenmodell, der Begriff Business Continuity Management (BCM) statt Notfallmanagement, die Prozessschritte Voranalyse, heute BIA-Vorfilter, und Soll-Ist-Vergleich, die Berücksichtigung der Schnittstellen zu Informationssicherheit, IT-Service-Continuity-Management und Krisenmanagement sowie eine ausführlichere Beschreibung der Bewältigungsorganisation. Die Version 1.0 vom Mai 2023 passte die Definition der Wiederanlaufzeit an, führte die BAO-Reaktionszeit ein und benannte die Voranalyse in BIA-Vorfilter um.
Ein BCMS lässt sich in drei Stufen aufbauen: Reaktiv-BCMS, Aufbau-BCMS und Standard-BCMS (Kap. 2.6). Das Reaktiv-BCMS soll eine Institution schnell in die Lage versetzen, auf Notfälle zu reagieren, und ist nach einem Zyklus weiterzuentwickeln; das Aufbau-BCMS sichert zunächst einen eingeschränkten Umfang an Geschäftsprozessen ab; das Standard-BCMS betrachtet alle Geschäftsprozesse im Geltungsbereich. Die Stufe Standard-BCMS ist nach Kap. 1.3 konform zu ISO 22301:2019, ein vollständig eingeführtes und betriebenes Standard-BCMS erreicht die Reife für eine Zertifizierung nach ISO 22301. Zum Standard selbst schreibt das BSI auf seiner Webseite: „Derzeit ist noch keine Zertifizierung zu dem Standard geplant.“ (abgerufen am 01.11.2026). Erfahrenen Anwendenden bietet das BSI einen Anforderungskatalog mit den MUSS- und SOLLTE-Anforderungen des Standard-BCMS und einer Zuordnung zu ISO 22301:2019.
Für die Verbindung mit Grundschutz ist ein Satz aus Kap. 1.3 wichtig: „Ein ISMS wird explizit für diesen BSI-Standard nicht vorausgesetzt.“ 200-4 setzt die Reihe 200-1 bis 200-3 fort und weist an vielen Stellen in eigenen Kästen auf Synergiepotenzial mit dem ISMS hin. Die Beispiele dort beziehen sich auf ein ISMS nach BSI-Standard 200-2 oder ISO 27001. Für Grundschutz++ gibt es solche Hinweise im Standard noch nicht; die Übertragung auf 300-1 in den Tabellen unten ist unsere Einordnung.
Verhältnis zu BSI-Standard 300-1 und zum Anwenderkatalog
300-1 erwähnt ein BCMS an einer Stelle: Bei der Identifizierung der Geschäftsprozesse kann nach Kap. 2.5 auf Prozesslandkarten und bestehende Managementsysteme wie ein BCMS zurückgegriffen werden. Einen Satz, der 200-4 ersetzt oder für Grundschutz++ außer Kraft setzt, enthält 300-1 nicht. Der Meilensteinplan des BSI (Stand Oktober 2026) nennt für 2027 und später die Integration anderer Managementsysteme in Grundschutz++; welche und in welcher Form, steht dort nicht.
Der Anwenderkatalog Grundschutz++ (Build vom 29.10.2026) stellt die Verbindung in der Praktik NOT her. NOT.1.1.4 sieht als KANN-Anforderung vor, ein BCMS nach BSI-Standard 200-4 zu verankern; Parameter sind die Stufe (Reaktiv-, Aufbau- oder Standard-BCMS) und der Standard. Die Erläuterung empfiehlt, die Anforderungen der Praktik idealerweise über ein BCMS zu erbringen, mit einem Reaktiv-BCMS als erstem Schritt. Die Erläuterungen zu acht weiteren NOT-Anforderungen verweisen auf einzelne Kapitel von 200-4. Ein BCMS ist damit optional, die Praktik NOT bleibt es nicht: 25 ihrer 37 Anforderungen haben keine Zielobjektkategorie und sind nach 300-1 Kap. 3.4.1 verpflichtend in das Anforderungspaket aufzunehmen.
Im klassischen IT-Grundschutz ist der Baustein DER.4 Notfallmanagement des Kompendiums für den gesamten Informationsverbund einmal anzuwenden. In der Edition 2023 (Stand Februar 2023) verweist er für die Phasen des Notfallmanagements noch auf BSI-Standard 100-4; die Version 1.0 von 200-4 stammt vom Mai 2023. Da 200-4 den Standard 100-4 laut seiner Änderungshistorie ablöst, ist für diese Inhalte heute 200-4 die aktuelle Fassung. Wie das Kompendium bis zum Ende der klassischen Zertifizierbarkeit weiter genutzt wird, beschreibt die Seite IT-Grundschutz-Kompendium.
Was BCMS und ISMS teilen können und was getrennt bleibt
Beide Managementsysteme fragen nach Geschäftsprozessen, Ressourcen, Schäden und Risiken. Sie fragen aber mit unterschiedlichem Ziel. Ein ISMS sichert den Normalbetrieb in allen drei Schutzzielen ab, BC-Maßnahmen begrenzen vor allem das Ausmaß eines eingetretenen Schadensereignisses (200-4 Kap. 2.4.1). 200-4 bringt dazu ein Beispiel: Eine Anwendung mit hoher Verfügbarkeit im ISMS kann im BCM ohne Kontinuitätsanforderung bleiben, wenn der Notbetrieb ohne sie auskommt; bei einer anderen kann die Business-Impact-Analyse die Anforderung verschärfen, weil der Prozess nach wenigen Stunden wieder laufen muss. Die Tabelle ordnet die Berührungspunkte. Die Fundstellen für 200-4 sind die Synergiekästen und der zugehörige Fließtext des Standards, die für Grundschutz++ die Kapitel von 300-1.
| Thema | BCM nach 200-4 | ISMS nach Grundschutz++ | Gemeinsam nutzbar | Getrennt halten |
|---|---|---|---|---|
| Geltungsbereich | Orientierung am ISMS-Geltungsbereich kann sinnvoll sein, muss aber zur Zielsetzung passen (Kap. 3.3) | Anwendungsbereich und Informationsverbund (300-1 Kap. 3.1) | Abgrenzung und bekannte Ressourcen als Ausgangspunkt | Zielsetzung des BCMS, die einen anderen Zuschnitt verlangen kann |
| Geschäftsprozesse | Prozesse aus dem ISMS als Grundlage; derselbe Detaillierungsgrad wie im ISMS kann sinnvoll sein (Kap. 7.1.1) | Geschäftsprozesse sind zu identifizieren und zu dokumentieren, ein BCMS darf herangezogen werden (Kap. 2.5) | eine gemeinsame Prozessliste, in beide Richtungen | Einstufung als zeitkritisch: Im Fokus des BCM stehen die zeitkritischen Geschäftsprozesse (Kap. 2.1), die erst die BIA ermittelt |
| Interessengruppen | Übernahme der Interessengruppenanalyse prüfen (Kap. 4.2) | Analyse der interessierten Parteien (Kap. 2.4) | Liste der Parteien und ihrer Anforderungen | Erwartungen, die nur die Kontinuität betreffen |
| Schadenskategorien | Schadensszenarien und -kategorien aus der Schutzbedarfsfeststellung als Grundlage (Kap. 7.1.2) | zwei Kategorien normal und hoch je Geschäftsprozess (Kap. 2.6) | Beschreibung der Schadensszenarien | zeitliche Staffelung und Untragbarkeitsniveau der BIA; zwei Kategorien reichen dafür nicht |
| Bewertung | BIA betrachtet Ressourcen für den Notbetrieb, die Schutzbedarfsfeststellung für den Normalbetrieb; eine gemeinsame Erhebung ist nicht in allen Fällen vorteilhaft (Kap. 7.1.5) | Schutzbedarfsfeststellung je Geschäftsprozess (Kap. 2.6) | gemeinsame Termine und Hilfsmittel, wenn dieselben Kategorien gelten | Ergebnisse: Verfügbarkeit im Normalbetrieb und Kontinuität im Notbetrieb sind verschiedene Werte |
| Ressourcen | Bezeichnungen aus der Strukturanalyse übernehmen; deren Gruppenbildung passt voraussichtlich nicht zu den BCM-Ressourcenclustern (Kap. 7.1.3) | Assets und Abhängigkeiten (Kap. 3.2) | Asset- und Ressourcenbezeichnungen, Zuständige (Kap. 8.1) | Cluster und Gruppen |
| Risiko | keine eigene Methode; Fokus auf Risiken für die Verfügbarkeit zeitkritischer Ressourcen (Kap. 9.1, 9.3); gleiche Kategorien wie im ISMS sehr sinnvoll (Kap. 9.5) | Verfahren frei, Mindestkriterien aus Anhang 3 verbindlich (Kap. 2.11) | Methode, Skalen, Risikokategorien, ein integrierter Risikobehandlungsplan (Kap. 2.4.1) | Gefährdungsauswahl: Vertraulichkeit und Integrität bleiben Aufgabe des ISMS |
| Rollen | Personalunion von ISB und BC-Beauftragten möglich, wenn keine konfliktträchtigen Themen bestehen und die Ressourcen reichen; von einer Personalunion mit dem IT-Service-Continuity-Management rät der Standard ab (Kap. 3.5) | Rollen und Zuständigkeiten (Kap. 2.8) | Abstimmung und Vertretung | Prozessverantwortung je Managementsystem |
| Notbetrieb und Schutzziele | Schnittstellen zwischen BCMS und ISMS früh festlegen, weil im Notbetrieb Schutzziele konkurrieren können (Kap. 4.2.3) | alternative Sicherheitsmechanismen für Notfälle (NOT.3.6) | gemeinsame Regel für Ausnahmen im Notbetrieb | die Entscheidung im Ereignis liegt bei der BAO |
| Übungen und Berichte | Jahresübungsplanung mit anderen Übungen abstimmen (Kap. 13.3); gemeinsame Berichterstattung hat Vorteile (Kap. 2.4.1) | Leistungsbewertung und Managementbewertung (Kap. 5) | ein Übungskalender, ein Bericht an die Leitung mit zwei Teilen | Ziele und Kennzahlen je Managementsystem |
Spalte „BCM nach 200-4“: Synergiekästen und Fließtext in BSI-Standard 200-4, Version 1.0; die Synergiekästen beziehen sich auf ein ISMS nach 200-2 oder ISO 27001. Spalte „ISMS nach Grundschutz++“: BSI-Standard 300-1, Version 1.0. Die Spalten „Gemeinsam nutzbar“ und „Getrennt halten“ sind eigene Einordnung.

Was im Anforderungspaket auch mit BCMS bestehen bleibt
Ein BCMS nach 200-4 kann viele NOT-Anforderungen mit Inhalt füllen. Die Erläuterung zu NOT.2.1 sagt sinngemäß, dass bei einem BCMS nach 200-4, gleich in welcher Stufe, die Anforderungen an die Besondere Aufbauorganisation in der Regel erfüllt sind. Der Status bleibt trotzdem je Anforderung zu prüfen und zu belegen: Nach 300-1 Kap. 4.1.1 muss für jede Anforderung der aktuelle Umsetzungsstatus vollständig überprüft werden. Die Tabelle zeigt, wohin die Erläuterungen im Katalog verweisen und was dann im ISMS bleibt.
| Anforderung (Modalverb) | Verweis der Erläuterung auf 200-4 | Was ein BCMS dazu liefert | Was im ISMS bleibt |
|---|---|---|---|
| NOT.1.1.4 BCMS (KANN) | Kap. 2.6 Stufenmodell | das Managementsystem selbst, in der gewählten Stufe | die Entscheidung, ob und in welcher Stufe, und ihr Status im Paket |
| NOT.2.1 BAO (SOLLTE) | Kap. 5 Aufbau und Befähigung der BAO | Stab, Kernteam, Bewältigungsteams, Geschäftsordnung | Nachweis des Status; Schnittstelle zur Behandlung von Sicherheitsvorfällen |
| NOT.2.1.1 Rollen (SOLLTE) | Kap. 5.1 | Besetzung der BAO | Nachweis der Zuweisung |
| NOT.2.1.2 Alarmierung (SOLLTE) | Kap. 5.2 | Detektion, Meldung, Einstufung, Alarmierung | Anbindung der Meldewege für Sicherheitsereignisse |
| NOT.2.1.3 Stabsraum (KANN) | Kap. 5.6.3 | Festlegung und Ausstattung des Stabsraums | Schutz des Stabsraums, auch eines virtuellen |
| NOT.2.1.4 Stabsübung (KANN) | Kap. 13.6 | Übungsplanung, Durchführung, Auswertung | Szenarien mit Bezug zur Informationssicherheit, etwa Schadsoftware |
| NOT.3.1 Wiederanlaufplan (SOLLTE) | Kap. 12 Wiederanlauf- und Wiederherstellungsplanung | kritische Ressourcen und Wiederanlaufzeiten aus der BIA, Rahmen aus den BC-Strategien | ohne BCMS: zeitkritische IT-Ressourcen aus der Schutzbedarfsfeststellung, Wiederanlaufzeit nur grob geschätzt |
| NOT.3.2 Geschäftsfortführungsplan (KANN) | Kap. 11 Geschäftsfortführungsplanung | Notbetrieb je zeitkritischem Geschäftsprozess | laut Erläuterung im ISMS nur optional |
| NOT.3.4 Funktionstest (KANN) | Kap. 13.9 Funktionstest und 13.5 Planbesprechung | Tests der Pläne und Notbetriebsressourcen | Prüfung, ob Sicherheitsvorkehrungen im Notbetrieb greifen |
| NOT.1.1 bis NOT.1.1.3 und NOT.1.2 (MUSS) | keiner | Leitlinie und Verfahren des BCMS | Verfahren zur Vorsorge für Notfälle der Informationssicherheit, Dokumentation, Zuweisung, Bekanntgabe, Überprüfung |
| NOT.3.5, NOT.3.6 (SOLLTE) | keiner | Ausweichkommunikation als BC-Lösung | Ausweich-Telekommunikation und alternative Sicherheitsmechanismen im Notfall |
| NOT.3.3 (SOLLTE), NOT.4 Datensicherung (20 Anforderungen) | keiner | Anforderungen an Wiederanlaufzeit und zulässigen Datenverlust | Sensibilisierung der Nutzenden für das Vorgehen im Notfall; Konzept, Aufbewahrung, Verschlüsselung, Offline-Kopie und Tests der Datensicherung |
Spalte „Verweis“: Erläuterungen im Anwenderkatalog Grundschutz++, Build 2026-10-29. Die Spalten „Was ein BCMS dazu liefert“ und „Was im ISMS bleibt“ sind eigene Einordnung.
Was ein ISMS nach Grundschutz++ nicht übernimmt
Umgekehrt ersetzt das Anforderungspaket kein BCMS. Eine Business-Impact-Analyse mit maximal tolerierbarer Ausfallzeit, geforderter Wiederanlaufzeit, maximal zulässigem Datenverlust und Notbetriebsniveau (200-4 Kap. 7) verlangt der Anwenderkatalog nicht; der Geschäftsfortführungsplan ist dort eine KANN-Anforderung. Die zwei Schutzbedarfskategorien normal und hoch sagen nicht, wie lange ein Prozess ausfallen darf. Und die Risikobetrachtung des ISMS lässt sich nicht an die BCM-Risikoanalyse abgeben: Diese betrachtet nach 200-4 Kap. 9.1 in der Regel die Risiken für die Verfügbarkeit, während 300-1 Kap. 2.11 eine explizite Risikobetrachtung schon dann verlangt, wenn ein Geschäftsprozess in mindestens einem Schutzziel hohen Schutzbedarf hat, auch in Vertraulichkeit oder Integrität.
Wie weit eine Institution ein BCMS braucht, ergibt sich aus ihren Geschäftsprozessen und aus Vorgaben, die für sie gelten. Wir ordnen die Vorgaben ein, die Sie nennen oder die in Ihren Unterlagen stehen; ob sie rechtlich gelten, prüft Ihre Rechtsabteilung. 200-4 empfiehlt für den Einstieg bei gesetzlichen oder regulatorischen Anforderungen eher das Aufbau- oder Standard-BCMS als das Reaktiv-BCMS (Kap. 2.6.1). Wie sich Lücken an einem konkreten Ausfall zeigen, spielt die Seite Gebäude und Notfallvorsorge an einem Standortausfall durch.
Lesepfad durch 200-4 für Grundschutz-Anwender
200-4 ist umfangreich und nach dem BCM-Prozess gegliedert. Hinter jeder Kapitelüberschrift ab Kapitel 3 steht, für welche Stufe das Kapitel gilt: R für Reaktiv-BCMS, A für Aufbau-BCMS, S für Standard-BCMS, AS für Aufbau- und Standard-BCMS gemeinsam (Kap. 1.3). Wer zunächst nur ein Reaktiv-BCMS umsetzen will, liest nur die Kapitel mit R. Die folgende Reihenfolge ist auf Leserinnen und Leser zugeschnitten, die ein ISMS nach Grundschutz++ betreiben oder aufbauen.
- Begriffe und Stufen zuerst: Kap. 2.1 (Störung, Notfall, Krise; zeitkritische Geschäftsprozesse; BAO), 2.3 (zeitlicher Ablauf der Bewältigung) und 2.6 (Stufenmodell). Diese drei Kapitel empfiehlt der Standard selbst allen mit Vorerfahrung im BCM als Mindestlektüre.
- Schnittstelle zum ISMS: Kap. 2.4.1, mit den Unterschieden zwischen Verfügbarkeit im Normalbetrieb und Kontinuität im Notbetrieb. Danach Kap. 2.4.2 zum IT-Service-Continuity-Management, falls der IT-Betrieb eigene Notfallpläne führt.
- Für die Leitung: Kap. 3, die Initiierung durch die Institutionsleitung mit Zielen, Geltungsbereich, Stufenwahl und Benennung der BC-Beauftragten.
- Neben NOT.2.1 legen: Kap. 5 zur BAO, insbesondere 5.1, 5.2 und 5.6.
- Neben die Schutzbedarfsfeststellung legen: Kap. 6 (BIA-Vorfilter, für Reaktiv- und Aufbau-BCMS) und Kap. 7 (Business-Impact-Analyse). Hier entscheidet sich, welche Daten Sie gemeinsam erheben.
- Neben Anhang 3 von 300-1 legen: Kap. 9 (BCM-Risikoanalyse, für Aufbau- und Standard-BCMS). Prüfen Sie, ob Ihr Risikoverfahren beide Zwecke abdeckt.
- Für NOT.3.1 und NOT.3.2: Kap. 12 (Wiederanlaufplanung, AS) und Kap. 11 (Geschäftsfortführungsplanung).
- Für NOT.2.1.4 und NOT.3.4: Kap. 13 zum Üben und Testen, mit Planbesprechung, Stabsübung, Alarmierungsübung und Funktionstest.
- Zum Abgleich am Ende: den Anforderungskatalog zum Standard, der die MUSS- und SOLLTE-Anforderungen des Standard-BCMS kompakt zusammenfasst, und für den Betrieb Kap. 14 und 15.
Weiterlesen: Schutzbedarf je Geschäftsprozess auf der Seite Schutzbedarfsfeststellung, Risikoverfahren prüfen auf der Seite Risikomethode prüfen, das klassische Risikoverfahren auf der Seite BSI-Standard 200-3, der Standortausfall als Szenario auf der Seite Gebäude und Notfallvorsorge, die Methodik insgesamt auf der Seite BSI-Standard 300-1, der Baustein DER.4 im Kontext auf der Seite IT-Grundschutz-Kompendium.
Vorhandene BCM-Unterlagen in Grundschutz++ einordnen
Wer bereits ein Notfallhandbuch, eine BAO oder ein BCMS nach 100-4 oder 200-4 hat, muss für Grundschutz++ nicht neu anfangen. Die Unterlagen sind Nachweise für den Status der NOT-Anforderungen, soweit sie aktuell sind und die Anforderung abdecken. Im Paket Readiness und Migrationskonzept prüft Blackfort Technology, welche Anforderungen der Praktik NOT vorhandene Unterlagen schon belegen und wo Lücken bleiben.
- Bestand prüfen lassen: Readiness und Migrationskonzept
- Status je Anforderung dokumentieren: Anforderungen bewerten
- Leistungen insgesamt: Beratung
Rechtehinweis: Zitate und Angaben aus BSI-Standard 200-4 © Bundesamt für Sicherheit in der Informationstechnik 2023, Quelle: BSI-Standard 200-4; das Zitat zur Zertifizierung stammt von dieser Webseite. Angaben aus BSI-Standard 300-1 und dem Meilensteinplan © Bundesamt für Sicherheit in der Informationstechnik 2026, Quelle: BSI, Grundschutz++. Angaben aus dem IT-Grundschutz-Kompendium, Edition 2023 © 2023 Reguvis Fachmedien GmbH, © 2023 Bundesamt für Sicherheit in der Informationstechnik, Bonn (so im Impressum der Ausgabe), Quelle: IT-Grundschutz-Kompendium. Sie stehen nicht unter CC BY-SA 4.0; der Lizenzhinweis am Seitenende gilt für die Auszüge aus den Katalogdaten.
