Grundschutz-Notfallvorsorge am Beispiel eines Standortausfalls: Gebäude und Notfallplanung prüfen

Ein Szenario prüft, ob vorhandene Vorkehrungen für einen bestimmten Ausfall zusammenpassen. Es beantwortet Fragen wie: Liegen die Datensicherungen woanders als die Server? Wer alarmiert wen, wenn das Telefon im Gebäude ausfällt? Es beantwortet nicht, welche Geschäftsprozesse zeitkritisch sind, wie lange sie ausfallen dürfen und mit welchem Notbetriebsniveau sie weiterlaufen müssen. Diese Größen ermittelt im Business Continuity Management (BCM) die Business-Impact-Analyse: maximal tolerierbare Ausfallzeit, geforderte Wiederanlaufzeit, maximal zulässiger Datenverlust und Notbetriebsniveau (BSI-Standard 200-4, Kap. 7). Die Business-Impact-Analyse geht dabei vom Totalausfall eines Geschäftsprozesses aus und fragt nicht nach der Ursache; ein Szenario setzt umgekehrt bei einer bestimmten Ursache an.

Der Anwenderkatalog zieht dieselbe Linie. Die Erläuterung zu NOT.3.1 (Wiederanlaufplan) sagt sinngemäß: Gibt es ein BCMS, kommen die kritischen Ressourcen und Wiederanlaufzeiten aus der Business-Impact-Analyse; gibt es keines, lassen sich zeitkritische IT-Ressourcen über die Schutzbedarfsfeststellung (erhöhter, nach 300-1 hoher Schutzbedarf in der Verfügbarkeit) bestimmen, die Wiederanlaufzeit aber nur grob schätzen. Geschäftsfortführungspläne ordnet die Erläuterung zu NOT.3.2 der Verantwortung eines BCMS zu; im ISMS ist die Anforderung als KANN optional. Wer ein BCMS braucht oder aufbauen will, findet die Einordnung auf der Seite BSI-Standard 200-4.

Auch die Begriffe sind in 200-4 genau gefasst (Kap. 2.1). Eine Störung wird im Normalbetrieb behoben. Nach 200-4 ist ein Notfall „eine Unterbrechung des Geschäftsbetriebs, die mindestens einen zeitkritischen Geschäftsprozess betrifft, der nicht im Normalbetrieb innerhalb der maximal tolerierbaren Ausfallzeit wiederhergestellt werden kann“ (Kap. 2.1); anders als bei einer Krise liegen dafür Pläne vor oder lassen sich anpassen. Als Krise bezeichnet 200-4 ein Schadensereignis, „das sich in erheblicher Weise negativ auf die Institution auswirkt und dessen Auswirkungen auf die Institution nicht im Normalbetrieb bewältigt werden können“ (Kap. 2.1); für ihre Bewältigung liegen keine spezifischen Notfallpläne vor, oder vorhandene greifen nicht. Ohne Business-Impact-Analyse lässt sich damit nicht sicher sagen, ob ein Standortausfall ein Notfall im Sinne von 200-4 ist. Das Szenario auf dieser Seite setzt deshalb nur voraus, was im ISMS ohnehin feststeht.

Die Praktik GEB umfasst im Katalog vom 29.10.2026 75 Anforderungen (5 MUSS, 35 SOLLTE, 35 KANN), rekursiv über alle Ebenen gezählt. Alle haben eine Zielobjektkategorie, 55 davon die Kategorie Standorte (53 ausschließlich, zwei zusammen mit Nutzende), weitere unter anderem Räume, Serverräume, Räume für technische Infrastruktur und IT-Systeme. Sie kommen also über die Zuordnung der Assets ins Anforderungspaket. Weil die übergeordneten Zielobjektkategorien einem Asset nach 300-1 Kap. 3.4.2 ebenfalls zuzuordnen sind, erhält ein Serverraum auch die Anforderungen für Räume für technische Infrastruktur, Räume und Standorte.

Die Praktik NOT umfasst 37 Anforderungen (5 MUSS, 25 SOLLTE, 7 KANN). 25 davon haben keine Zielobjektkategorie und sind nach 300-1 Kap. 3.4.1 verpflichtend in das Anforderungspaket aufzunehmen, darunter das Verfahren zur Notfallvorsorge (NOT.1.1, MUSS), die Besondere Aufbauorganisation (NOT.2.1), der Wiederanlaufplan (NOT.3.1), Ausweich-Telekommunikation (NOT.3.5) und 9 der 20 Anforderungen zur Datensicherung. Ein BCMS nach 200-4 nennt der Katalog in NOT.1.1.4 als KANN-Anforderung. Die Erläuterung dazu empfiehlt, die Anforderungen der Praktik idealerweise über ein BCMS zu erbringen, und verweist auf das Stufenmodell in 200-4 Kap. 2.6.

Die Musterhafen Logistik GmbH (MHL) ist erfunden. Sie hat einen Standort mit Bürogebäude, darin im Untergeschoss den Serverraum mit Virtualisierungshosts, Speichersystem, Telefonanlage und der Sicherungsbibliothek. Der Geschäftsprozess Disposition hat in der Verfügbarkeit den Schutzbedarf hoch. Eine Business-Impact-Analyse gibt es nicht.

Das Szenario: Nach Starkregen steht Wasser im Untergeschoss. Der Netzbetreiber schaltet das Gebäude ab, die Feuerwehr sperrt es. Die Sperrung dauert voraussichtlich drei Tage, ob der Serverraum Wasser abbekommen hat, ist zunächst unklar. Beschäftigte können von zu Hause arbeiten, wenn die Dienste erreichbar sind. Bewusst ausgeschlossen sind Personenschäden, ein gleichzeitiger Cyberangriff und der Ausfall von Dienstleistern. Diese Begrenzung macht das Szenario prüfbar; sie ist auch der Grund, warum es kein Notfallkonzept ersetzt.

GEB.1.4 verlangt, schützenswerte Assets oder zugehörige Infrastrukturen nur außerhalb exponierter oder besonders gefährdeter Bereiche zu platzieren. Die Erläuterung nennt den überflutungsgefährdeten Keller ausdrücklich als Beispiel. Bei der MHL ist die Anforderung nicht erfüllt, und ein Umzug des Serverraums ist auf absehbare Zeit nicht geplant. Das ist eine dauerhafte Nichterfüllung einer SOLLTE-Anforderung; nach 300-1 Kap. 2.11 und 4.1.2 ist dafür eine Risikobetrachtung durchzuführen, das Restrisiko nach der Behandlung geht der Institutionsleitung zur Freigabe zu. Eine Risikobetrachtung ist bei der MHL ohnehin fällig: Die Disposition hat in der Verfügbarkeit hohen Schutzbedarf, und das ist nach Kap. 2.11 ein eigener Anlass.

Die Risikobetrachtung führt zu Maßnahmen aus anderen GEB-Anforderungen. GEB.10.3 (SOLLTE) verlangt mindestens eine physische Schutzmaßnahme vor Wasser zwischen Assets und Wassergefahrenstellen; die Erläuterung nennt Wasser von oben und von unten und als Maßnahmen etwa Abdichtungen, Entwässerung oder eine erhöhte Aufstellung. GEB.10.3.2 sieht Leckagesensoren als KANN-Anforderung vor. Die MHL stellt die Racks auf einen Sockel, lässt einen Rückstauschutz einbauen und installiert Wassersensoren mit Meldung an die Rufbereitschaft. Für die Stromversorgung verlangt GEB.9.1 eine norm- und bedarfsgerechte Versorgung, GEB.9.1.3 und GEB.9.1.4 sehen redundante Versorgung für eine kürzere oder längere Stützzeit als KANN vor. Eine USV überbrückt bei der MHL das geordnete Herunterfahren; einen Weiterbetrieb bei gesperrtem Gebäude leistet sie nicht.

Zwei weitere GEB-Anforderungen werden im Szenario sichtbar: GEB.1.5 verlangt, Strukturpläne zu dokumentieren; nach der Erläuterung gehören Versorgungsleitungen, Netzanschlüsse sowie Aus- und Zugänge für Notfälle dazu. Im Szenario zeigen sie, wo Leitungswege und Serverraum liegen. GEB.6.2.1 verlangt, Hostsysteme ausschließlich in Serverräumen zu platzieren. Bei der MHL steht ein Host für die Zeiterfassung im Büro des Erdgeschosses; auch er ist von der Sperrung betroffen.

Wer entscheidet, wenn das Gebäude gesperrt ist? NOT.2.1 verlangt Verfahren und Regelungen für eine Besondere Aufbauorganisation (BAO) zur Behandlung von Notfällen und Krisen, NOT.2.1.1 die Zuweisung der Rollen einschließlich Stab und Notfallteams, NOT.2.1.2 die Alarmierung. Einen Stabsraum sieht NOT.2.1.3 als KANN vor; die Erläuterung lässt auch eine virtuelle Arbeitsumgebung zu. Bei der MHL liegt die Alarmierungsliste nur auf dem Dateiserver im Serverraum. Befund: Die Liste existiert, ist im Szenario aber nicht erreichbar; die Alarmierung gilt damit für diesen Ausfall als nicht erfüllt.

Die Telefonanlage steht im Serverraum. NOT.3.5 verlangt, Ausweich-Telekommunikationsdienste zu verankern; die Erläuterung denkt an Mobilfunk, andere Anbieter oder Satellitenanschlüsse und an die Erreichbarkeit der zuständigen Personen und Dienstleister. NOT.3.6 verlangt alternative Sicherheitsmechanismen, die in Notfällen greifen, etwa hinterlegte Einmalpasswörter, ohne die Vorkehrungen des Normalbetriebs zu untergraben. NOT.3.3 verlangt, Nutzende zum Vorgehen in Notfällen und Krisen zu sensibilisieren; im Szenario heißt das: Alle wissen, dass sie nicht zum Standort fahren und wo sie Informationen bekommen.

Am härtesten trifft das Szenario die Datensicherung. NOT.4.10 verlangt, die Datensicherung getrennt von den Originaldaten zu platzieren; die Erläuterung begründet das mit Brand, Wasserschaden oder Einbruch, die Systeme und Sicherungen gleichzeitig treffen können. Bei der MHL steht die Sicherungsbibliothek neben den Hosts. NOT.4.14 verlangt eine regelmäßige Offline-Kopie, NOT.4.12 sieht eine georedundante Kopie als KANN vor. Ohne eine Kopie außerhalb des Gebäudes hilft auch der Wiederanlaufplan nach NOT.3.1 nicht, und das dokumentierte Vorgehen zur Wiederherstellung (NOT.4.15) setzt voraus, dass Sicherungen und Ersatzsysteme erreichbar sind. NOT.4.16.1 verlangt, die Wiederherstellung mindestens anhand repräsentativer Stichproben regelmäßig zu überprüfen; bei der MHL wurde sie bisher nur im selben Serverraum getestet.

Das Szenarioblatt fasst den Durchlauf zusammen. Es lässt sich für Ihr eigenes Szenario übernehmen: Spalte drei enthält die Prüffrage, die Sie an Ihren Stand stellen, Spalte vier den Befund im Fall, Spalte fünf die Folge im Anforderungspaket. Alle Befunde sind erfunden.

NOT.1.2 verlangt als MUSS-Anforderung, die Verfahren und Regelungen regelmäßig und anlassbezogen auf Aktualität zu überprüfen. Ob die Pläne tatsächlich funktionieren, prüft NOT.3.4, als KANN-Anforderung: Die Erläuterung meint damit, soweit möglich auch die konkreten Ressourcen zu prüfen, etwa ob Meldewege laufen und Ersatzgeräte nutzbar sind. Ist die Reife dafür noch nicht erreicht, nennt sie als ersten Schritt Planbesprechungen, in denen ein Plan nur gedanklich durchgegangen wird, und verweist auf 200-4 Kap. 13.5 und 13.9. Die Funktionsfähigkeit der BAO durch Stabsübungen zu prüfen, sieht NOT.2.1.4 als KANN vor.

Für die MHL ist eine Planbesprechung des Szenarios der nächste Schritt: Stab, IT-Betrieb und Hausverwaltung gehen das Szenarioblatt Zeile für Zeile durch und prüfen, ob die beschlossenen Maßnahmen die Befunde schließen. 200-4 empfiehlt, die Übungsplanung des BCM mit anderen Übungen abzustimmen, etwa mit Brand- und Räumungsübungen oder Wiederherstellungstests (Kap. 13.3). Das gilt auch ohne BCMS: Wird an eine Räumungsübung eine Alarmierung des Stabs angehängt, lässt sich die Alarmierung nach NOT.2.1.2 ohne eigenen Übungstermin prüfen.

Die Befunde gehen als Status in die Bewertung des Anforderungspakets ein. Für eingeplante, noch nicht erfüllte SOLLTE-Anforderungen ist das verbleibende Risiko der Institutionsleitung mitzuteilen und von ihr freizugeben; dauerhafte Nichterfüllungen und der hohe Schutzbedarf der Disposition gehen in die Risikobetrachtung (300-1 Kap. 2.11, 4.1.1, 4.1.2). Ob sich ein BCMS nach 200-4 lohnt, ist eine Entscheidung der Institutionsleitung; der Katalog lässt sie mit NOT.1.1.4 als KANN-Anforderung offen, die Anforderungen der Praktik NOT bleiben in jedem Fall im Anforderungspaket.