Der Teufel steckt im Delta : Aufbau eines IT-Service-Continuity-Managements mithilfe des BSI-Standards 200-4

Es bestehen aber auch wesentliche Unterschiede zwischen BCM und ITSCM:

• Fokus: Während das BCM Geschäftsprozesse fokussiert, konzentriert sich das ITSCM auf IT-Services, -Infrastruktur und -Organisation.
• Stakeholder: BCM ist Aufgabe des Managements, der Fachabteilungen und gegebenenfalls des Risikomanagements. Demgegenüber liegt das ITSCM üblicherweise in der Hand der IT-Abteilung.
• Normen: Es gibt sehr wohl eigene Standards für das ITSCM – am populärsten ist die ISO 27031 „Cybersecurity – Information and communication technology readiness for business continuity“, die aber nicht den Detailgrad eines BSI-Standards erreicht. Auch in der IT Infrastructure Library (ITIL) gibt es Praktiken zur ITKontinuität – diese stellen aber nur einen Teilaspekt im IT-Service-Management dar und sind ebenfalls nicht so detailliert erläutert.
• Maßnahmen: Während im BCM manuelle Workarounds, der Einsatz alternativer Ressourcen sowie Outsourcingoptionen beschrieben werden, stehen im ITSCM technisch-organisatorische Maßnahmen (TOM) für Backups, Redundanzen, Wiederanlauf (Recovery) und Failover im Mittelpunkt.
• Dienstleisterüberwachung und -steuerung: Sofern kein übergreifendes Supplier-Management zum Einsatz kommt, werden in der Praxis häufig extern beschaffte ITServices via ITSCM überwacht sowie gesteuert und die Non-IT-Dienstleister dem BCM zugeordnet.
• Pläne und Maßnahmen: Im BCM bilden das Notfallhandbuch sowie die Geschäftsfortführungspläne die wichtigen Notfallpläne. Im ITSCM wird es anhand von Wiederanlauf- und/oder Wiederherstellungsplänen sowie szenariobasierten „Playbooks“ (bspw. für Ransomware) operativ und technisch konkreter. Wenn kein BCM etabliert ist, werden die organisatorischen Regelungen der IT-Notfallstabsarbeit in einem „IT-Notfallhandbuch“ beschrieben.
• Üben und Testen: Während im BCM die Fähigkeit zur Geschäftsfortführung im Fokus steht, nehmen im ITSCM technische Tests zur Wiederanlauf- und Wiederherstellungsfähigkeit größeren Raum ein.

Dennoch gibt es gute Möglichkeiten, um BCMStandards für das ITSCM zu nutzen. Da hierbei das Vorgehen je nach Quelle variiert, werden im Folgenden die fünf wichtigsten Aspekte beleuchtet.

ITSCM-Framework

Als Managementdisziplin braucht ITSCM ein klares Fundament: Es gilt, grundlegende organisatorische Dinge vorab zu definieren und so ein einheitliches, wiederkehrendes Vorgehen sicherzustellen. Dies umfasst die durchzuführenden Tätigkeiten im ITSCM (Prozess), die jeweiligen Zuständigkeiten (Rollen) sowie die Art der verbindlichen Verschriftlichung (Dokumentation). Der Einfachheit halber seien diese Punkte als „ITSCM-Framework“ zusammengefasst.

ITSCM-Prozess

Ein ITSCM-Prozess kann sich im Aufbau stark unterscheiden. Das liegt zum einen daran, dass die IT-Abteilung je nach Geschäftszweck entweder eine rein unterstützende Funktion in der Organisation wahrnimmt oder selbst Teil davon ist – beispielsweise bei IT-Service-Providern, Systemhäusern oder Anbietern von Hard- und Software. Als Schnittstellenthema greift das ITSCM zudem auf Ergebnisse und Anforderungen anderer Sicherheitsthemen zurück – je nachdem, ob und wie stark diese in der Organisation etabliert sind. Ein ITSCM, das sich einem vorhandenen BCM untergliedert, wird etwa anders aufgebaut als ein ITSCM, das nicht darauf zurückgreifen kann.

Anhaltspunkte für einen ITSCM-Prozess bieten unter anderem der (kostenpflichtige) Standard ISO 27031:2025 „Cybersecurity – Information and communication technology readiness for business continuity“ sowie die „Information Technology Infrastructure Library“ ITIL V3/V4 – in ITIL Version 4 wird dabei von der ITSCM-Praktik gesprochen. Beide genannten Standards erläutern zweckgemäß, welche Aktivitäten im Prozess auszuführen sind, nicht jedoch, wie diese umzusetzen sind – schließlich sind Standards keine Umsetzungshilfen.

Wer hingegen auf BSI 200-4 setzen möchte, um einen ITSCM-Prozess daraus abzuleiten, sollte konkret folgende Kapitel oder Aspekte daraus berücksichtigen:

• Kapitel 2.4.2 „BCM und ITSCM“ – zwecks Abgrenzung beider Diszipinen
• Kapitel 4.6 „Schulung“ sowie 4.7 „Sensibilisierung“ – bezogen auf die ITSCM-Rollen
• Kapitel 7 „Business-Impact-Analyse“ (BIA) – sofern kein BCM besteht und daher Kontinuitätsanforderungen im ITSCM erhoben werden müssen
• Kapitel 8 „Soll-Ist-Vergleich“
• Kapitel 9 „BCM-Risikoanalyse“ – bezogen auf IT-Assets
• Kapitel 10 „Business-Continuity-Strategien und -Lösungen“ – bezogen auf die IT-Continuity-Aspekte
• Kapitel 12 „Wiederanlauf- und Wiederherstellungsplanung“
• Kapitel 13 „Üben und Testen“ – mit Fokus auf Funktionstests
• Kapitel 14.2 „Bewertung und Überwachung von externen Dienstleistungsunternehmen“ – bezogen auf externe IT-Services

Rollenkonzept Der Bedarf an Rollen im ITSCM unterscheidet sich maßgeblich von denen im BCM: Primär wird die Rolle des ITSC-Managers* benötigt. Einen guten Anhaltspunkt hierzu liefert das ITIL Wiki [2].

Für reaktive Rollen, die im akuten IT-Notfall zum Einsatz kommen, sollte man im ITSCM bevorzugt auf die Rollendefinitionen des BCM und Krisenmanagements zurückgreifen – mehr Informationen dazu folgen weiter unten im Abschnitt „Besondere Aufbauorganisation (BAO)“ auf Seite 40.

Dokumentation

Bleibt die Frage nach einer geeigneten Dokumentation im ITSCM: Die Idee aus BSI 200-4, diese in anforderungsbeschreibende Dokumente (Leitlinie, Richtlinien etc.) sowie unterstützende Dokumente für den Ernstfall (Notfallpläne) zu unterteilen, bietet sich auch im ITSCM an. Als ideal haben sich in der Praxis folgende Dokumentenarten bewährt:

Eine ITSCM-Policy beschreibt Ziele, Anforderungen, Geltungsbereich, Kontrollhandlungen sowie wesentliche Rollen und Aktivitäten im ITSCM. Ähnlich wie in anderen Sicherheitsthemen kann man diese Policy um Richtlinien und Anweisungen erweitern, wenn einzelne Aktivitäten und Zuständigkeiten im ITSCM konkreter definiert werden sollen.

IT-Notfallpläne sind technik- und handlungsorientiert. Anders als im BCM stehen IT-Systeme und -Services beziehungsweise Zuständigkeiten in einem IT-Notfall im Fokus der Dokumentation. Hierbei sollten ab weichend vom BSI-Standard 200-4 folgende Dokumentenarten berücksichtigt werden:

• Wiederanlauf- und Wiederherstellungspläne: stellen ein Kernstück des ITSCM dar, da sie die erforderlichen technischen und organisatorischen Abläufe zum Wiederanlauf oder der Wiederherstellung von Komponenten, Systemen oder Systemgruppen erläutern. In einem akuten IT-Notfall sind damit sowohl die umzusetzenden Schritte als auch die erforderlichen Berechtigungen, Zuständigkeiten und Einschränkungen hinreichend dokumentiert und zugewiesen. Zudem lassen sich anhand der beschriebenen Aktivitäten des Wiederanlaufplans IT-Notfalltests planen und durchführen.
• Wiederanlaufkoordinationspläne: Damit Anwender Aufgaben IT-gestützt ausführen können, genügt es nicht, nur ein einzelnes System wiederherzustellen. Vielmehr funktionieren IT-Systeme nur dann, wenn auch Basisdienste wie Netzwerk, Storage, Firewall et cetera laufen (vertikaler Wiederanlauf). Zudem gibt es Abhängigkeiten zwischen verschiedenen Systemen – beispielsweise vom Active Directory (AD) über Datenbanken, Storageattached-Networks (SAN), Applikationsserver bis zum Service-Frontend (horizontaler Wiederanlauf). Um genau diese Abhängigkeiten zwischen Systemen und Systemgruppen zu visualisieren und den Wiederanlauf in eine zeitliche Reihenfolge zu bringen, bietet sich der Einsatz eines Wiederanlaufkoordinationsplans an.
• Datensicherungskonzept: IT-Continuity verfolgt das Ziel, neben der Betriebsfähigkeit von Systemen und Services, auch die Verfügbarkeit von Daten sicherzustellen. Ein Datensicherungskonzept legt die Ziele der Datensicherung, die betroffenen Daten und Systeme, anzuwendende Backup-Methoden sowie die Häufigkeit und Speicherorte der Datensicherung fest. Ferner lassen sich hierin Zuständigkeiten und Prozesse für die Wiederherstellung und Überwachung definieren. Einen sehr genauen Überblick darüber bietet der Grundschutzbaustein CON.3 „Datensicherungskonzept“ [3].
• Playbooks: Wie beispielsweise bei einem Ransomwarebefall oder einer Distributed-Denial-of-Service- (DDoS)-Attacke zu handeln ist, legen sogenannte Playbooks fest: Sie erläutern die jeweiligen Zuständigkeiten und umzusetzenden Aktivitäten in solchen außergewöhnlichen Ereignissen. Sie dienen als Checkliste für handelnde Personen und geben damit Sicherheit für Fälle, in denen die normalen Betriebsprozesse in der IT keine Antworten liefern. Playbooks werden häufig in Form von „SwimlaneDiagrammen“ dargestellt, die einen schnellen Überblick sowohl über die Zuständigkeiten als auch die Abfolge der notwendigen Aktivitäten ermöglichen (siehe etwa https://swimlane.info oder als „Multi-Column Process-Chart“ bereits in [4]).

BCM-Anforderungen erheben

Im ITSCM dreht sich alles um die Frage, wie die geforderten Wiederanlaufzeiten (Recovery-Time-Objective, RTO) sowie die notwendigen Datensicherungsintervalle (Recovery-Point-Objective, RPO) unter Berücksichtigung von Kosten, Nutzen und Risiken bestmöglich zu erfüllen sind. Da diese Anforderungen üblicherweise über die Fachbereiche ermittelt werden, erfolgt die Analyse über das BCM. Als wichtigstes Werkzeug hat sich hierbei die Business-Impact-Analyse (BIA) entwickelt, die im BSI-Standard 200-4 ausführlich beschrieben wird – zudem stellt der Standard hierzu auch entsprechende Hilfsmittel bereit (siehe www.bsi.bund.de/dok/200-4-hilfsmittel).

Die dargestellte Methodik und das Vorgehen in der BIA des BCM lassen sich uneingeschränkt auch im ITSCM einsetzen. Da die BIA jedoch die Endanwendersicht darstellt, beschränkt sich diese darauf, den Ressourcenbedarf anhand von IT-Services/-Anwendungen zu erheben. Das RPO sollte im ITSCM darüber hinaus nicht ausschließlich wie vom BSI-Standard 200-4 für zeitkritische IT-Anwendungen und Informationen vorgesehen erhoben werden, sondern für alle: Denn auch in nicht-zeitkritischen Prozessen können Daten enthalten sein, deren Verlust sich nicht oder nur sehr begrenzt tolerieren lässt.

Ferner ist es im ITSCM erforderlich, detaillierter in die IT-Infrastruktur zu blicken. Ausgehend von den als zeitkritisch betrachteten IT-Services und -Anwendungen sind die daran geknüpften IT-Systeme und -Dienste bis hinunter zur Basisinfrastruktur (Strom, Klima, Netze, Sicherheit) zu untersuchen. Ein gutes Asset-Management in der IT ist damit das A und O im ITSCM – man kann nur schützen, was man auch kennt.

Leider gibt es nur wenige frei verfügbare Quellen zum IT-Asset-Management. Primär hilft hierbei erneut ITIL mit dem Subprozess „Service Asset und Configuration Management“ (ITIL V3) beziehungsweise der Praktik „IT Asset Management“ (ITIL V4, vgl. [5]). Die ISO/ IEC 19770-1:2017 „Information technology – IT asset management, Part 1: IT asset management systems – Requirements“ setzt sich ebenfalls mit den Anforderungen eines IT-Asset-Managementsystems auseinander.

Werden IT-Services, wie inzwischen üblich, extern beschafft oder genutzt, nimmt ferner die Bedeutung eines guten IT-Provider-Managements mit Schnittstellen in das ITSCM zu. Hierzu liefert der BSI-Standard 200-4 bis auf ein kurzes Kapitel (14.2 „Bewertung und Überwachung von externen Dienstleistungsunternehmen“) nur wenige Informationen. Weiterhelfen können stattdessen der Grundschutzbaustein OPS 2.3 „Nutzung von Outsourcing“ [6] sowie die BSI-Veröffentlichungen bezüglich sicherer Lieferketten im Kontext von NIS-2 [7].

Ergänzend lassen sich die „Good Practices for Supply Chain Cybersecurity“ der ENISA (Kapitel 3.3 Supplier Relationship Management in [8]) nutzen. Im englischsprachigen Umfeld bietet sich ferner der US-Standard SP 800-161 [9] des National Institute of Standards and Technology (NIST) an, der sich speziell mit den „Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations“ auseinandersetzt.

IT-Continuity-Strategien

Im BCM werden Strategien definiert, die als Leitplanken vorgeben, wie eine Institution grundsätzlich auf Ausfallszenarien reagieren möchte. Ein Beispiel hierfür ist, bei Personalausfällen temporäre Überstunden anzuordnen, Stellvertreterregelungen zu aktivieren oder externe Dienstleister einzubinden. Die konkrete Umsetzung dieser Strategien erfolgt anschließend in der operativen Notfallplanung. Im ITSCM, wo häufig nicht nur organisatorische, sondern komplexe technische Strategien erforderlich sind, sollte die Strategieentwicklung besonders sorgfältig und fundiert erfolgen.

Der BSI-Standard 200-4 beschreibt ein geeignetes Vorgehen zur Entwicklung von BC-Strategien, das in vielen Aspekten über andere Standards hinausgeht und sich auch auf IT-Service-Continuity-Strategien übertragen lässt: Dabei werden zunächst grundlegende Handlungsoptionen identifiziert, bewertet und miteinander verglichen, bis eine geeignete Strategie ausgewählt ist. Der Standard liefert hierfür Kriterien – etwa ob durch die Strategie die erforderliche Wiederanlaufzeit (RTO) eingehalten werden kann oder ob zusätzliche Risiken entstehen.

Für das ITSCM sollten diese Kriterien um spezifische IT-Aspekte ergänzt werden. Der NIST-Standard 800- 34 „Contingency Planning Guide for Federal Information Systems“ [10] berücksichtigt beispielsweise Kostenfaktoren wie Beschaffung, Hardware, Software oder Implementierungstests und bietet damit eine kleine, aber hilfreiche Ergänzung. Weiter zu berücksichtigen sind zusätzlich auch limitierende Faktoren aufgrund der IT-Architektur, beispielsweise durch eingeschränkte Kapazität in Ausweichrechenzentren, Fähigkeiten zum Failover et cetera.

Als Orientierung stellt der BSI-Standard 200-4 zudem ein Hilfsmittel bereit, das eine Vielzahl möglicher BC-Strategien mit ihren jeweiligen Vor- und Nachteilen beschreibt – auch für die Szenarien IT- und IT-Dienstleister-Ausfall. Diese Sammlung ist nicht abschließend, bietet aber wertvolle Impulse für eigene Überlegungen.

Der NIST-Standard 800-34 geht hier teilweise weiter, indem er detaillierte ITSCM-Strategien aufführt, etwa unterschiedliche Backup-Methoden in Abhängigkeit vom akzeptablen Datenverlust – neben der reinen Beschreibung benennt er auch Vor- und Nachteile sowie wesentliche Aspekte für die Implementierung. Allerdings stammt der Standard bereits aus dem Jahr 2010 und bildet neuere Best Practices nicht ab – etwa Failover-Verfahren in oder zwischen Cloud-Systemen, hybride Ansätze oder SaaS-Lösungen. Da sich Methoden und deren sinnvolle Kombination kontinuierlich weiterentwickeln, sind jedoch auch aktuelle Verfahren zwingend in die Strategieplanung einzubeziehen.

Strategien abseits der selbst betriebenen IT werden im ITSCM häufig nur zweitrangig betrachtet. Besonders für IT-Dienstleister wird zu häufig eine gewisse BCM-Fähigkeit vorausgesetzt oder sich auf Service-Level Agreements (SLAs) verlassen, die oft nicht zu den realen BCM-Anforderungen passen. Für die Entwicklung entsprechender Strategien für einen Dienstleisterausfall bietet der BSI-Standard 200-4 eine große Bandbreite an Strategieoptionen, die auch auf IT-Dienstleister übertragen und im ITSCM genutzt werden können.

Besondere Aufbauorganisation (BAO) In einem Notfall bedarf es schneller Entscheidungen, guter Koordination und klarer Verantwortlichkeiten. Hier kommt der Notfallstab ins Spiel – das zentrale Gremium zur Steuerung eines Notfalls. Beim BSI-Standard 200-4 wird die Bewältigungsstruktur von IT- und Non IT-Ereignissen in einem einzigen Stab zusammengeführt.

Für kleine und mittlere (KMU) oder stark IT-fokussierte Unternehmen (z.B. IT-Dienstleister) kann ein einziger, zentraler Stab auch durchaus ausreichen: Die Zahl der Ansprechpartner ist begrenzt, die Abläufe sind vergleichsweise überschaubar und eine Trennung von IT und Fachbereichen bringt keine Effizienzgewinne.

In größeren Unternehmen oder komplexen Umgebungen mit vielfältigen Fachbereichen zeigen sich jedoch Herausforderungen, wenn IT-Lagen sich schneller oder in einem anderen Takt entwickeln als andere Bereiche oder wenn externe Dienstleister (Incident-ResponseTeams, Security-Operations-Center – SOCs, Cloud-Provider, Hardware-Lieferanten etc.) intensiv eingebunden werden müssen. Eine Auftrennung in einen allgemeinen Notfallstab und einen IT-Notfallstab kann dementsprechend sinnvoll sein.

• Der allgemeine Notfallstab übernimmt dann die Gesamtkoordination, steuert die Notfall- und Krisen Kommunikation sowie die Fortführung der Geschäftsprozesse in den Fachbereichen und bearbeitet organisatorische wie rechtliche Fragestellungen einschließlich der Kommunikation an die Geschäftsleitung. In gewissem Maße hält er hierdurch der IT den Rücken frei, um die IT-Lage zu bewältigen.
• Der IT-Notfallstab übernimmt die Orchestrierung von IT-Wiederanlaufmaßnahmen der verschiedensten Systeme, steuert die Schnittstellen zu Computer-Emergency-Response-Team (CERT) und Security-Operations-Center (SOC) sowie externen Dienstleistern wie Cloud- oder Infrastruktur-Providern, Forensik- und Incident-Response-Dienstleistern oder Materiallieferanten.

Ein sinnvoll besetzter IT-Notfallstab besteht idealerweise aus der IT-Notfallstabsleitung, der Leitung IT beziehungsweise dem CIO, den Leitungen der Teams für Infrastruktur, Anwendungen, Netzwerke, IT-Sicherheit sowie einem Wiederanlauf-Koordinator, der die Orchestrierung des Systemwiederanlaufs übernimmt. Hinzu kommen Verantwortliche für Protokollierung, Visualisierung und Kommunikation.

Dabei muss man jedoch beachten, dass nicht jeder IT-Notfall automatisch einen BCM-Fall bedeutet und die sofortige Aktivierung sämtlicher Stäbe erfordert. Vielmehr sollte eine klare Differenzierung getroffen werden: Ein ITNotfall liegt vor, wenn IT-Dienste erheblich beeinträchtigt sind – ein BCM-Notfall besteht, wenn (z.B. durch den IT-Notfall) kritische Geschäftsprozesse bedroht sind, der Geschäftsbetrieb akut gefährdet ist oder erhebliche rechtliche oder kommunikative Folgen drohen. Ein IT-Notfall führt also nicht zwangsläufig zu einem BCM-Fall, kann jedoch bei Überschreiten definierter Schwellen- oder Eskalationswerte in einen solchen übergehen. Folglich sollten im ITSCM eigene Schwellenwerte und Definitionen festgelegt und mit dem BCM abgestimmt werden.

Um das volle Potenzial zweier schlagkräftiger Stäbe sinnvoll auszuschöpfen, sollten ihre Arbeitsweisen eng aufeinander abgestimmt sein: Die Führungszyklen müssen einheitlich etabliert sein – etwa nach dem FORDEC-Modell (Facts, Options, Risks & Benefits – Decision, Execution, Check). Außerdem sind regelmäßige Lageberichte zwischen den Stäben erforderlich und die Dokumentation von Zuständigkeiten, Schnittstellen, Eskalationsstufen, Kommunikationswegen sowie Dienstleisterrollen muss klar definiert und jederzeit verfügbar sein.

Üben und Testen im ITSCM

Zweifelsohne eines der wichtigsten Themen in der Notfallvorbereitung und damit auch im ITSCM ist das Üben und Testen der erstellten (IT-)Notfallplanung. Der BSI-Standard 200-4 bietet hierfür ein geeignetes und bewährtes Testprogramm, das sich in der Methodik vollständig für das ITSCM adaptieren lässt. Dennoch sollte man spezifische Besonderheiten der technischen Tests sowie die Testdesigns berücksichtigen und für das ITSCM konkretisieren.

Schon bei der Planung der zu testenden Systeme sind deren Abhängigkeiten zu anderen Systemen deutlich detaillierter zu berücksichtigen als im BCM. Wenngleich auch im BCM isolierte Übungen und Tests von einzelnen Bereichen vermieden werden sollten, lassen sich doch durch Simulationen viele Schnittstellenthemen kompensieren – im Kontext technischer Wiederanlauftests ist dies durch reine Simulationen nicht möglich. Entsprechend ist für jedes System zu prüfen, ob es sich einzeln überhaupt sinnvoll testen lässt oder ob Systeme zu geeigneten Testgruppen zusammengefügt werden müssen. Testgruppen können beispielsweise aus einem spezifischen Ausfallszenario, logisch zusammenhängenden Einheiten oder „Ende zu Ende“ (von einer konkreten IT-Anwendung bis zu ihren Basisdiensten) abgeleitet werden. Hilfestellungen zu möglichen Clustern bilden etwa ITIL-Beschreibungen zum Thema Clustering entlang von Service-Strukturen oder „The Open Group Architecture Framework“ (TOGAF) im Zusammenspiel mit der Modellierungssprache ArchiMate hinsichtlich von Enterprise-Architecture Frameworks (siehe www.togaf.org bzw. www.opengroup.org/archimate-forum).

Darüber hinaus kann die Durchführung von Tests im ITSCM Risiken mit sich bringen, da realistische Tests ab einem gewissen Zeitpunkt auch in der Produktivumgebung stattfinden sollten. Bei der Gestaltung von Tests müssen die Risiken daher deutlich konkreter identifiziert und evaluiert werden als im BCM. Für die Durchführung von Funktionstests hat der BSI-Standard 200-4 den Aspekt genauer betrachtet und kann übernommen werden.

Ein weiterer Unterschied liegt in der Rolle der Ausfallursache: BCM-Übungen betrachten den Ausfall von Ressourcen häufig noch immer unabhängig von seiner Ursache. Im ITSCM beeinflusst hingegen der Grund eines Ausfalls maßgeblich, wie sich der Wiederanlauf gestalten lässt. So unterscheidet sich der Wiederanlauf des Active Directory nach einem schlichten Ausfall (z.B. durch einen Stromausfall) erheblich vom Wiederanlauf nach einer erfolgreichen Ransomware-Verschlüsselung und anschließender Forensik.

Obwohl der BSI-Standard 200-4 die Verbindung zwischen Ursache und Auswirkung grundsätzlich erwähnt, wird dies in der Testmethodik nicht vertieft – in der Praxis geht dieser Aspekt häufig verloren. Daher sollte man bei der Testkonzeption im ITSCM das zugrunde liegende Ursachenszenario stärker gewichten und direkt aus der Risikoanalyse ableiten. Leider gibt es derzeit kein einheitliches Glossar, wie sich unterschiedliche Ursachen auf den Wiederanlauf auswirken – somit ist dies bereits vor einem Test von der jeweiligen Institution zu überprüfen.

Darüber hinaus behandelt der BSI-Standard 200-4 keine gemeinsame Übung von Institutionen und Dienstleistern – dies ist schon im BCM eine dringende Empfehlung, im Kontext von IT-Dienstleistern und vielen „Single Point of Failures“ (SPoFs) umso mehr. Leider gibt es keinen einheitlichen Standard oder Leitfaden, wie sich derartige Übungen und Tests zwischen einer Institution und seinen Dienstleistern sinnvoll planen, umsetzen und nachbereiten lassen. Zu klären sind hierzu allem voran ein gemeinsames Verständnis zum Realitätsgrad der Übung, die gewählte Testumgebung, der Schwerpunkt (technische Bewältigung oder organisatorische Schnittstellen) sowie eine faire Kostenverteilung.

Über die klassischen Tests hinaus empfiehlt die ISO 27031 zudem ausdrücklich den Einsatz von Resilienztests: Deren Ziel ist es nicht zwingend, die Wiederanlauffähigkeit im Notfall zu überprüfen, sondern vor allem die Widerstandsfähigkeit der Systeme selbst. Dies umfasst beispielsweise die Stabilität und das Verhalten bei Teilausfällen oder Leistungseinschränkungen, die noch nicht unbedingt einen Ausfall bedeuten würden („Schlechtleistung“).

Fazit

Kann man den BSI-Standard 200-4 für den Aufbau eines ITSCM nutzen? Das kommt darauf an: Er bietet eine hervorragende methodische Grundlage, um Prozesse, Rollen und Dokumentationsstrukturen im ITSCM aufzubauen – gerade wenn kein übergeordnetes BCM existiert. Allerdings greift er in technischen und prozessualen Details zu kurz, sobald es um IT-spezifische Anforderungen geht.

Wer den BSI-Standard 200-4 nutzt, sollte ihn daher nicht als alleinige Quelle verstehen, seine Grenzen kennen und gezielt mit IT-orientierten Standards kombinieren. Dann entsteht ein praxistaugliches ITSCM, das die Stärken des BCM-Standards sinnvoll ergänzt, ohne seine Grenzen zu übersehen.

Jann-Christoph Sowa und Marcel Herder sind Security-Consultants bei HiSolutions.

Literatur

_{[1] Bundesamt für Sicherheit in der Informationstechnik (BSI), Business Continuity Management, BSI-Standard 200-4, Reguvis, Juni 2023, ISBN 978-3-8462- 1518-0, online verfügbar über www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standardsund-Zertifizierung/IT-Grundschutz/BSI-Standards/BSI-Standard-200-4-Business-Continuity-Management/bsi-standard-200-4_Business_Continuity_Management_node.html}    

_{[2] IT Process Maps GbR (Hrsg.), IT Service Continuity Manager – Prozess-Verantwortlicher, ITIL Wiki, Dezember 2023, https://wiki.de.it-processmaps.com/index.php/IT_Service_Continuity_Management#IT_Service_Continuity_Manager}

_{[3] Bundesamt für Sicherheit in der Informationstechnik (BSI), Datensicherungskonzept, IT-GrundschutzBaustein CON.3, Februar 2023, www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/IT-GSKompendium_Einzel_PDFs_2023/03_CON_Konzepte_und_Vorgehensweisen/CON_3_Datensicherungskonzept_Edition_2023.pdf}

_{[4] Executive Office of the President Bureau of the Budget, Process Charting, November 1945, online verfügbar auf https://hdl.handle.net/2027/mdp.35128000206076}

_{[5] IT Process Maps GbR (Hrsg.), Service Asset and Configuration Management, ITIL Wiki, Dezember 2023, https://wiki.de.it-processmaps.com/index.php/Service_Asset_and_Configuration_Management}

 _{[6] Bundesamt für Sicherheit in der Informationstechnik (BSI), Nutzung von Outsourcing, IT-Grundschutz-Baustein OPS.2.3, Juni 2023, www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/IT-GSKompendium_Einzel_PDFs_2023/04_OPS_Betrieb/OPS_2_3_Nutzung_von_Outsourcing_Edition_2023.pdf}

_{[7] Bundesamt für Sicherheit in der Informationstechnik (BSI), #nis2know – Sichere Lieferkette, August 2025, www.bsi.bund.de/dok/nis-2-sichere-lieferkette}

_{[8] European Union Agency for Cybersecurity (ENISA), Good Practices for Supply Chain Cybersecurity, Juni 2023, www.enisa.europa.eu/publications/goodpractices-for-supply-chain-cybersecurity}

_{[9] National Institute of Standards and Technology (NIST) Computer Security Resource Center (CSRC), Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations, NIST Special Publication SP 800-161 Rev. 1, Mai 2022 / November 2024, https://csrc.nist.gov/pubs/sp/800/161/r1/upd1/final bzw. https://doi.org/10.6028/NIST.SP.800-161r1-upd1}

_{[10] National Institute of Standards and Technology (NIST), Contingency Planning Guide for Federal Information Systems, NIST Special Publication SP 800-34 Rev. 1, Mai/November 2010, https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final bzw. https://doi.org/10.6028/NIST.SP.800-34r1}