Notfallmanagement nach BSI-Standard 200-4

Einordnung von BSI-Standard 200-4

Der BSI-Standard 200-4 gehört zur Reihe der BSI-Standards 200-1 bis 200-4 und beschreibt den Aufbau eines Business Continuity Management Systems (BCMS). Er löst den älteren BSI-Standard 100-4 ab. Zum Standard gibt es einen Anforderungskatalog mit einem Mapping auf ISO 22301:2019, damit sich die Kompatibilität nachvollziehen lässt. Eine eigene Zertifizierung nach 200-4 ist laut BSI derzeit nicht geplant. Ergänzend veröffentlicht das BSI Hilfsmittel, unter anderem ein Glossar, eine Dokumentvorlage für Wiederanlauf- und Wiederherstellungspläne und Hinweise zur Bewältigung.

BCM ist dabei weiter gefasst als IT-Notfallmanagement. Der Standard betrachtet Geschäftsprozesse und alle Ressourcen, die sie brauchen: Personal, Gebäude, IT, Dienstleister. Das IT-Notfallmanagement (im Standard ITSCM genannt) ist ein Teilbereich mit eigenen Synergien.

Störung, Notfall, Krise

Das Glossar zum Standard unterscheidet drei Stufen von Schadensereignissen:

• Störung: Prozesse oder Ressourcen funktionieren nicht wie vorgesehen, das lässt sich aber im Normalbetrieb durch die übliche Organisation beheben, etwa über das Incident-Management.
• Notfall: Mindestens ein zeitkritischer Geschäftsprozess ist unterbrochen und kann im Normalbetrieb nicht innerhalb der maximal tolerierbaren Ausfallzeit wiederhergestellt werden. Für einen Notfall gibt es geeignete Pläne, oder vorhandene Pläne lassen sich anpassen. Es genügt bereits die Gefahr einer Unterbrechung.
• Krise: Ein Schadensereignis mit massiven Auswirkungen, für das keine passenden Notfallpläne vorliegen oder die vorhandenen nicht greifen.

Zur Bewältigung von Notfällen braucht es eine Besondere Aufbauorganisation (BAO): eine zeitlich begrenzte Organisationsform mit eigenen Zuständigkeiten und Entscheidungswegen, die vom Normalbetrieb abweichen, typischerweise ein Notfallstab.

Das Stufenmodell

Der Standard bietet drei Stufen an:

Reaktiv-BCMS

Ziel ist eine schnelle Fähigkeit zur Notfallbewältigung. Es werden nur ausgewählte zeitkritische Geschäftsprozesse und Ressourcen priorisiert abgesichert, soweit das mit vorhandenen Mitteln oder kleineren Investitionen geht. Nach einem BCM-Zyklus soll das Reaktiv-BCMS zu einem Aufbau- oder Standard-BCMS weiterentwickelt werden. Laut Standard sind für den Aufbau keine besonderen Voraussetzungen nötig, deshalb eignet es sich für Einsteiger.

Aufbau-BCMS

Ein eingeschränkter Umfang an Geschäftsprozessen wird gründlich analysiert und abgesichert. So lassen sich Ressourcen schrittweise einplanen und über mehrere Zyklen erweitern.

Standard-BCMS

Alle Geschäftsprozesse im Geltungsbereich werden betrachtet. Ein vollständig umgesetztes Standard-BCMS kann die Reife für eine Zertifizierung nach ISO 22301 erreichen.

Der Ablauf im Überblick

Die Kapitel des Standards bilden den BCM-Prozess ab. Kennzeichnungen wie (R), (A) und (S) zeigen, für welche Stufe ein Schritt gilt:

1. Initiierung durch die Institutionsleitung: Verantwortung übernehmen, Ziele und Geltungsbereich festlegen, eine oder einen BC-Beauftragten benennen.
2. Konzeption und Planung: Aufbauorganisation, Dokumentation, Ressourcen, Schulung, Sensibilisierung, Leitlinie.
3. Aufbau und Befähigung der BAO: Detektion, Alarmierung und Eskalation, Sofortmaßnahmen, Stabsarbeit, Notfall- und Krisenkommunikation.
4. BIA-Vorfilter (Reaktiv- und Aufbau-BCMS) und Business Impact Analyse.
5. Soll-Ist-Vergleich: Reichen die heutigen Wiederanlaufzeiten der Ressourcen für die geforderten Zeiten?
6. BCM-Risikoanalyse und BC-Strategien (Aufbau- und Standard-BCMS).
7. Geschäftsfortführungsplanung sowie Wiederanlauf- und Wiederherstellungsplanung.
8. Üben und Testen und die kontinuierliche Verbesserung.

Die Business Impact Analyse

Die BIA ist der Kern. Sie ermittelt, welche Geschäftsprozesse und Ressourcen zeitkritisch sind, indem sie die direkten und indirekten Folgeschäden eines Ausfalls bewertet. Daraus ergeben sich die Anforderungen an den Wiederanlauf, etwa die maximal tolerierbare Ausfallzeit und die geforderte Wiederanlaufzeit (RTO).

Bezug zum IT-Grundschutz-Kompendium

Im IT-Grundschutz-Kompendium behandelt der Baustein DER.4 Notfallmanagement das Thema. In der Edition 2023 ist etwa die Erstellung eines Notfallhandbuchs (DER.4.A1) als Standard-Anforderung formuliert, Tests und Notfallübungen (DER.4.A10) als Anforderung bei erhöhtem Schutzbedarf. Der Baustein DER.2.1 Behandlung von Sicherheitsvorfällen regelt die Schnittstelle: Dort wird entschieden, ob ein Sicherheitsvorfall zum Notfall wird.

Notfallmanagement IT im kleinen Betrieb

Für Betriebe mit wenigen Mitarbeitenden ist das Reaktiv-BCMS der passende Einstieg. Praktisch heißt das:

• Die Geschäftsführung benennt eine verantwortliche Person und eine Vertretung.
• Gemeinsam mit den Fachbereichen werden die zeitkritischen Abläufe bestimmt, zum Beispiel Auftragsannahme, Produktion, Abrechnung oder Terminvergabe.
• Für diese Abläufe wird festgehalten, welche IT-Systeme, Daten, Personen und Dienstleister sie brauchen, und wie lange ein Ausfall tragbar ist.
• Es gibt eine einfache Alarmierungsliste, festgelegte Sofortmaßnahmen und einen kleinen Notfallstab, der im Ernstfall entscheidet.
• Die Pläne werden geübt, mindestens mit einer Alarmierungsübung und einer Stabsübung, wie es der Standard für das Reaktiv-BCMS vorsieht.

Wer bereits ein ISMS oder die Basis-Absicherung umsetzt, sollte beides verbinden: Datensicherung, Verantwortlichkeiten und Dienstleistersteuerung tauchen in beiden Themen auf. Der Standard betont selbst die Synergien zwischen Informationssicherheit, BCM und Krisenmanagement.

Rollen im BCM

Der Standard und sein Glossar nennen einige feste Rollen, die sich auch in kleinen Betrieben abbilden lassen:

• BC-Beauftragte (BCB): zuständig für Aufbau, Betrieb und Verbesserung des BCMS, auch Notfallbeauftragte genannt.
• BC-Koordinierende (BCK): fachliche Ansprechpersonen in einzelnen Bereichen, die die Umsetzung dort sicherstellen.
• Stab der BAO: das Gremium, das im Notfall Lage bewertet, entscheidet und die Bewältigung steuert. In einem kleinen Betrieb besteht er oft aus Geschäftsführung, IT-Verantwortlichen oder Dienstleister und einer Person für Kommunikation.

Wichtig sind Vertretungen für jede Rolle, denn Notfälle richten sich nicht nach Urlaubsplänen. Die Gesamtverantwortung bleibt nach dem Standard bei der Institutionsleitung.

Typische Stolpersteine

• Der Plan beschreibt nur die IT, nicht die Abläufe, die von ihr abhängen.
• Wiederanlaufzeiten sind geschätzt, aber nie getestet.
• Wichtige Dienstleister fehlen in der Betrachtung, etwa der Anbieter der Fachsoftware oder der Internetprovider.
• Das Notfallhandbuch liegt nur digital auf dem Server, der im Ernstfall nicht erreichbar ist.