01714 Die Schnittstellen zwischen Business Continuity und IT Service Continuity Management
|
Die beiden Disziplinen Business Continuity Management (BCM) und IT Service Continuity Management (ITSCM) verfolgen die gleiche Zielsetzung, die Sicherstellung der Geschäftsfortführung nach einem Notfall. Dazu müssen BCM und ITSCM Hand in Hand arbeiten. Das BCM identifiziert die geschäftlichen Anforderungen, das ITSCM stellt die technischen Rahmenbedingungen für die Umsetzung.
Der Beitrag zeigt die zahlreichen Schnittstellen zwischen diesen beiden Disziplinen anhand des PDCA-Zyklus auf und gibt praktische Ratschläge für die Umsetzung. von: |
1 Einleitung
Die beiden Disziplinen Business Continuity Management (BCM) und IT Service Continuity Management (ITSCM) verfolgen die gleich Zielsetzung: die Sicherstellung der Verfügbarkeit geschäftskritischer Prozesse und Ressourcen des Unternehmens. Das BCM fokussiert dabei auf die Verfügbarkeit der kritischen Geschäftsprozesse sowie deren Prozess-Ressourcen Personal, Gebäude/Arbeitsplätze, Dokumente, Dienstleister und IT Services. Das ITSCM umfasst die präventiven und reaktiven Maßnahmen zur Sicherstellung der Verfügbarkeit der IT Services für die Geschäftsprozesse. Die beiden Disziplinen BCM und ITSCM mit ihren unterschiedlichen inhaltlichen Schwerpunkten stehen in einem Verhältnis wechselseitiger Abhängigkeit zueinander: Sie sind elementar miteinander verzahnt und bedingen sich gegenseitig. Eine enge Verzahnung der Ziele, Methoden und Verfahren ist kritischer Erfolgsfaktor für das Gelingen dieses Zusammenspiels und damit der Fähigkeit des Unternehmens, auf Notfälle angemessen vorbereitet zu sein. Aus diesem Grund legen nicht zuletzt Wirtschaftsprüfer und Aufsichtsbehörden mittlerweile besonderes Augenmerk auf das Zusammenspiel zwischen BCM und ITSCM. Die nachfolgende Darstellung soll anhand praxisorientierter Beispiele das Zusammenwirken der beiden Disziplinen BCM und ITSCM aufzeigen.
PDCA-Zyklus
Die Implementierung und der Betrieb sowohl von BCM als auch von ITSCM erfolgen in einem Plan-Do-Check-Act – Zyklus. Der PDCA-Zyklus wird daher in diesem Beitrag als Gliederungsstruktur für die Betrachtung der Schnittstellen von BCM und ITSCM zugrunde gelegt (vgl. Abbildung 1).
Die Implementierung und der Betrieb sowohl von BCM als auch von ITSCM erfolgen in einem Plan-Do-Check-Act – Zyklus. Der PDCA-Zyklus wird daher in diesem Beitrag als Gliederungsstruktur für die Betrachtung der Schnittstellen von BCM und ITSCM zugrunde gelegt (vgl. Abbildung 1).
2.1 Aufgaben der PLAN-Phase des PDCA-Zyklus für das BCM und ITSCM
In der Phase „PLAN” des PDCA-Zyklus erfolgt
| • | die Implementierung der Managementsysteme für das BCM und ITSCM, |
| • | die Identifikation der Anforderungen der Geschäftsprozesse für den Notbetrieb und Wiederanlauf in Form der Business-Impact-Analyse (BIA), |
| • | die Identifikation der Anforderungen an die IT Services und deren Ressourcen auf der Basis der identifizierten geschäftlichen Anforderungen aus der BIA, |
| • | die Identifikation von GAPs zwischen den aktuellen Verfügbarkeiten der IT Services und den geschäftlichen Anforderungen aus der BIA, |
| • | die Identifikation der internen und externen Risiken auf der Basis des Gefährdungskatalogs im Rahmen des Risk Assessment für BCM und ITSCM, |
| • | die Entwicklung von BCM- und ITSCM-Geschäftsfortführungsstrategien auf der Basis der identifizierten geschäftlichen Anforderungen aus der BIA und der identifizierten Risiken. |
2.2 Implementierung der Managementsysteme für BCM und ITSCM
Das Managementsystem bildet den organisatorischen und methodischen Rahmen für die nachfolgende Implementierungsphase von BCM und ITSCM.
Zu den wesentlichen Aufgaben der Etablierung des Managementsystems für das BCM und ITSCM zählen
| • | die Definition der (messbaren) Ziele sowie des Umfangs und der Abgrenzungen von BCM und ITSCM, |
| • | die Bereitstellung der erforderlichen personellen und finanziellen Ressourcen für die Implementierung und den Betrieb sowohl zentral als auch dezentral in den Fachbereichen, |
| • | die Benennung eindeutiger Verantwortlichkeiten für BCM und ITSCM im Topmanagement sowie auf operativer Umsetzungsebene, |
| • | die Dokumentation der Rahmenvorgaben und des Management-Commitments in einer Policy, |
| • | die Festlegung von Standards, Methoden und Vorgehensweisen für die Umsetzung sowie grundlegende Definitionen (Glossar) für BCM und ITSCM, |
| • | die Festlegung von Performance-Messkriterien zur Überprüfung des Reifegrads von BCM und ITSCM, |
| • | die Implementierung von Auditverfahren zur Überprüfung der Funktionsfähigkeit und Compliance von BCM und ITSCM. |
Ein System für BCM und ITSCM
Zwei getrennte Managementsysteme für BCM und ITSCM aufzubauen ist aufwendig, erzeugt Reibungsverluste und birgt das Risiko von Missverständnissen und Fehlern an den Schnittstellen beider Disziplinen. Häufig existiert in der Praxis schon eines der beiden Managementsysteme. Historisch betrachtet ist ITSCM die ältere Disziplin und BCM kommt meist als relativ junge Disziplin neu hinzu. Gerade in solchen Situationen gilt es den Fehler zu vermeiden, ein neues „Silo” neben ein bestehendes „Silo” zu stellen, um vielleicht möglichen Abstimmungsaufwänden und Konflikten aus dem Weg zu gehen.
Zwei getrennte Managementsysteme für BCM und ITSCM aufzubauen ist aufwendig, erzeugt Reibungsverluste und birgt das Risiko von Missverständnissen und Fehlern an den Schnittstellen beider Disziplinen. Häufig existiert in der Praxis schon eines der beiden Managementsysteme. Historisch betrachtet ist ITSCM die ältere Disziplin und BCM kommt meist als relativ junge Disziplin neu hinzu. Gerade in solchen Situationen gilt es den Fehler zu vermeiden, ein neues „Silo” neben ein bestehendes „Silo” zu stellen, um vielleicht möglichen Abstimmungsaufwänden und Konflikten aus dem Weg zu gehen.
Bei der Frage, wie die beiden Disziplinen BCM und ITSCM aufbauorganisatorisch im Unternehmen angeordnet sein sollen, ist es viel weniger entscheidend, ob die beiden Disziplinen auch organisatorisch oder disziplinarisch in einer gemeinsamen aufbauorganisatorischen Linie stehen. Vielmehr ist entscheidend, dass die Mitarbeiter ein gemeinsames Verständnis vom Vorgehen haben, die Schnittstellen, Kompetenzen und Verantwortlichkeiten eindeutig definiert sind und vor allem eine gemeinsame Sprache gesprochen wird.
Sprachliche Verwirrungen
Die zahlreichen unterschiedlichen Normen und Standards für BCM und ITSCM mit einem unterschiedlichen Vokabular erleichtern das Verständnis und die Zusammenarbeit zwischen BCM und ITSCM nicht gerade.
Die zahlreichen unterschiedlichen Normen und Standards für BCM und ITSCM mit einem unterschiedlichen Vokabular erleichtern das Verständnis und die Zusammenarbeit zwischen BCM und ITSCM nicht gerade.
In der IT sind die Standards ITIL, ISO 20000 und ISO 27001 [1] gebräuchlich. Im BCM dominieren in Deutschland die beiden BCM-Standards BSI 100-4 [2] des Bundesamts für Sicherheit in der Informationstechnik (BSI) sowie der internationale ISO-Standard für BCM ISO 22301 [3]. Diese Standards bringen jedoch jeweils ihr eigenes Vokabular mit sich. Die Begrifflichkeiten Incident, Störung, Ausfall, Notfall, Katastrophe, Krise sind ein gutes Beispiel für die unterschiedliche Verwendung von Begriffen in den Standards. Die Erstellung eines gemeinsam BCM/ITSCM-Glossars wird so schnell zu einer großen Herausforderung.
Die ISO-Standards kommen dieser Notwendigkeit der Vereinheitlichung mittlerweile entgegen. Der Standard Annex SL der ISO vereinheitlicht den Aufbau neuer ISO-Standards durch die Festlegung eines standardisierten Aufbaus der Dokumente. ISO 22301 und ISO 27001 sind die ersten Standards, die nach dieser Vorgabe aufgebaut sind. Dennoch gibt es über die Standards hinweg noch keine einheitliche Begriffswelt. Auch Gesetzgeber und Aufsichtsbehörden glänzen hierbei mit Kreativität, Wirtschaftsprüfer würzen diese „Begriffssuppe” noch weiter laufend mit ihren eigenen Begriffsschöpfungen in den Prüfungsberichten.
Abgestimmtes Glossar erstellen!
Die Investition in die Grundlagenarbeit eines abgestimmten Glossars und eines gemeinsamen Vorgehens zahlt sich aber gerade in den folgenden Schritten der Implementierung aus.
Die Investition in die Grundlagenarbeit eines abgestimmten Glossars und eines gemeinsamen Vorgehens zahlt sich aber gerade in den folgenden Schritten der Implementierung aus.
2.3 Identifikation der Anforderungen für BCM und ITSCM
In einem ersten Schritt sind die Anforderungen an BCM und ITSCM aus den geschäftlichen Erfordernissen der Geschäftsprozesse zu identifizieren. Dies erfolgt in einem mehrstufigen Prozess.
Business-Impact-Analyse
Zunächst werden in der Business-Impact-Analyse (BIA) die geschäftskritischen Geschäftsprozesse identifiziert. Für die kritischen Geschäftsprozesse werden die Anforderungen an deren Ressourcen für den Notbetrieb und Wiederanlauf identifiziert. Auf der Basis dieser Ergebnisse der BIA werden die Anforderungen an das IT Service Continuity Management (ITSCM) abgeleitet. Im Rahmen der GAP-Analyse werden Differenzen zwischen den Anforderungen aus der BIA und der tatsächlichen Wiederherstellfähigkeit der IT Services im Notfall identifiziert und die GAPs geschlossen. Nachfolgend wird auf die einzelnen Durchführungsschritte der BIA näher eingegangen.
Zunächst werden in der Business-Impact-Analyse (BIA) die geschäftskritischen Geschäftsprozesse identifiziert. Für die kritischen Geschäftsprozesse werden die Anforderungen an deren Ressourcen für den Notbetrieb und Wiederanlauf identifiziert. Auf der Basis dieser Ergebnisse der BIA werden die Anforderungen an das IT Service Continuity Management (ITSCM) abgeleitet. Im Rahmen der GAP-Analyse werden Differenzen zwischen den Anforderungen aus der BIA und der tatsächlichen Wiederherstellfähigkeit der IT Services im Notfall identifiziert und die GAPs geschlossen. Nachfolgend wird auf die einzelnen Durchführungsschritte der BIA näher eingegangen.
2.3.1 Die Business-Impact-Analyse (BIA) zur Identifikation der Anforderungen an BCM und ITSCM
Kritische Prozesse und Ressourcen ermitteln
Die Business-Impact-Analyse im BCM hat das Ziel, die zeitlichen und kapazitativen Anforderungen an die kritischen Geschäftsprozesse sowie deren Ressourcen zu identifizieren.
Die Business-Impact-Analyse im BCM hat das Ziel, die zeitlichen und kapazitativen Anforderungen an die kritischen Geschäftsprozesse sowie deren Ressourcen zu identifizieren.
Die Kritikalität eines Geschäftsprozesses für das Unternehmen bemisst sich an den Auswirkungen bei einer Unterbrechung des Geschäftsprozesses. Dazu werden durch die Fachbereiche die Auswirkungen bei einer Unterbrechung der Geschäftsprozesse in verschiedenen Impact-Kategorien eingeschätzt.
Mögliche Impact-Kategorien
Impact-Kategorien für die Einschätzung der Folgewirkung einer Geschäftsprozessunterbrechung sind z. B.
Impact-Kategorien für die Einschätzung der Folgewirkung einer Geschäftsprozessunterbrechung sind z. B.
| • | finanzielle Auswirkungen einer Geschäftsprozessunterbrechung(u. a. Umsatz-/Ertragsverluste, Vertragsstrafen, Mehrkosten und -aufwände), |
| • | Image- und Reputationsschäden(u. a. negative Pressemeldungen, Markenschäden), |
| • | Verstoß gegen Gesetze und regulatorische Vorgaben und Richtlinien und |
| • | Beeinträchtigung der Steuerungsfähigkeit des Unternehmens(u. a. Risikomanagement, Controlling). |
Zeitliche Abhängigkeit
Im Rahmen der Business-Impact-Analyse werden je Geschäftsprozess die Folgewirkungen nach einem Ausfall auf einer Zeitskala eingeschätzt. So lässt sich der Verlauf der Schadenswirkungen über den Zeitablauf ermitteln und darstellen. Die Abstufung der Betrachtungszeitpunkte der Schadensfolgen ist stark von der Zeitkritikalität der Produkte und Services des Unternehmens abhängig. Häufig reicht der Betrachtungshorizont von 0,5 Tagen bis zu vier oder sechs Wochen. Die Erhebung der Schadenswirkungen über die Zeit ist Grundlage für die Identifikation der kritischen Geschäftsprozesse. Dazu werden je Impact-Kategorie kritische Schwellenwerte für die Schadenshöhe und die Zeit durch das Management festgelegt.
Im Rahmen der Business-Impact-Analyse werden je Geschäftsprozess die Folgewirkungen nach einem Ausfall auf einer Zeitskala eingeschätzt. So lässt sich der Verlauf der Schadenswirkungen über den Zeitablauf ermitteln und darstellen. Die Abstufung der Betrachtungszeitpunkte der Schadensfolgen ist stark von der Zeitkritikalität der Produkte und Services des Unternehmens abhängig. Häufig reicht der Betrachtungshorizont von 0,5 Tagen bis zu vier oder sechs Wochen. Die Erhebung der Schadenswirkungen über die Zeit ist Grundlage für die Identifikation der kritischen Geschäftsprozesse. Dazu werden je Impact-Kategorie kritische Schwellenwerte für die Schadenshöhe und die Zeit durch das Management festgelegt.
Kritischer Prozess
Geschäftsprozesse werden als „kritisch” eingestuft, wenn die Ausfallwirkungen einer Unterbrechung in einer oder mehreren der Impact-Kategorien diese festgelegten Schwellenwerte überschreiten. Die Unterbrechung des Geschäftsprozesses hätte bei Überschreiten des Schwellenwerts nicht akzeptable Folgewirkungen für das Unternehmen. Für diese als geschäftskritisch eingestuften Geschäftsprozesse ist eine erhöhte Notfallvorsorge zu treffen. Ziel dieser Vorsorgemaßnahmen ist es, die Eintrittswahrscheinlichkeit einer Unterbrechung zu minimieren sowie das Schadensausmaß beim Eintritt einer Unterbrechung so gering wie möglich zu halten.
Geschäftsprozesse werden als „kritisch” eingestuft, wenn die Ausfallwirkungen einer Unterbrechung in einer oder mehreren der Impact-Kategorien diese festgelegten Schwellenwerte überschreiten. Die Unterbrechung des Geschäftsprozesses hätte bei Überschreiten des Schwellenwerts nicht akzeptable Folgewirkungen für das Unternehmen. Für diese als geschäftskritisch eingestuften Geschäftsprozesse ist eine erhöhte Notfallvorsorge zu treffen. Ziel dieser Vorsorgemaßnahmen ist es, die Eintrittswahrscheinlichkeit einer Unterbrechung zu minimieren sowie das Schadensausmaß beim Eintritt einer Unterbrechung so gering wie möglich zu halten.
BIA berücksichtigt Abhängigkeiten
Ein Geschäftsprozess ist jedoch nicht für sich allein funktionsfähig. Der Prozess ist auf die Zulieferung von Vorgänger- und Unterstützungsprozessen angewiesen, um das vorgesehene Prozessergebnis erzielen zu können. Der Prozess selbst ist wiederum Zulieferprozess für andere Geschäftsprozesse. Diese Abhängigkeiten der Geschäftsprozesse in Form von Wertschöpfungsketten zur Erzeugung von Produkten und Services müssen in der BIA berücksichtigt werden. Im Notfall ist die komplette Wertschöpfungskette wiederherzustellen, damit die Produkte und Services hergestellt werden können. Fehlt ein notwendiges Prozessglied im Notfall, misslingt der Notbetrieb. Vorgänger- und Unterstützungsprozesse, die zwingend für die kritischen Geschäftsprozesse im Notbetrieb erforderlich sind, erhalten daher durch Vererbung die Kritikalität des nachfolgenden Geschäftsprozesses. Die Abbildung 2 stellt die Abhängigkeiten in einer Übersicht dar.
Ein Geschäftsprozess ist jedoch nicht für sich allein funktionsfähig. Der Prozess ist auf die Zulieferung von Vorgänger- und Unterstützungsprozessen angewiesen, um das vorgesehene Prozessergebnis erzielen zu können. Der Prozess selbst ist wiederum Zulieferprozess für andere Geschäftsprozesse. Diese Abhängigkeiten der Geschäftsprozesse in Form von Wertschöpfungsketten zur Erzeugung von Produkten und Services müssen in der BIA berücksichtigt werden. Im Notfall ist die komplette Wertschöpfungskette wiederherzustellen, damit die Produkte und Services hergestellt werden können. Fehlt ein notwendiges Prozessglied im Notfall, misslingt der Notbetrieb. Vorgänger- und Unterstützungsprozesse, die zwingend für die kritischen Geschäftsprozesse im Notbetrieb erforderlich sind, erhalten daher durch Vererbung die Kritikalität des nachfolgenden Geschäftsprozesses. Die Abbildung 2 stellt die Abhängigkeiten in einer Übersicht dar.
RTO = maximale Wiederherstellungszeit
Für die kritischen Geschäftsprozesse wird durch die Fachbereiche festgelegt, wie lange eine Unterbrechung dieser Prozess akzeptabel ist, bevor nicht akzeptable Folgeschäden entstehen. Die maximale Zeitdauer bis zur Wiederherstellung des Geschäftsprozesses wird als Recovery Time Objective (RTO) bezeichnet. Der RTO gibt für jeden kritischen Geschäftsprozess die maximal tolerable Zeitdauer bis zur Wiederherstellung in den Einheit „Stunden”, „Tage” oder „Wochen” an.
Für die kritischen Geschäftsprozesse wird durch die Fachbereiche festgelegt, wie lange eine Unterbrechung dieser Prozess akzeptabel ist, bevor nicht akzeptable Folgeschäden entstehen. Die maximale Zeitdauer bis zur Wiederherstellung des Geschäftsprozesses wird als Recovery Time Objective (RTO) bezeichnet. Der RTO gibt für jeden kritischen Geschäftsprozess die maximal tolerable Zeitdauer bis zur Wiederherstellung in den Einheit „Stunden”, „Tage” oder „Wochen” an.
Start- und Endzeitpunkt entscheidend
Damit aus dem RTO korrekte Anforderungen an die Ressourcen, wie zum Beispiel die Wiederanlaufanforderungen an die IT Services, abgeleitet werden können, ist eine exakte Definition dieser Zeitspanne erforderlich. Leider weisen die BCM- und ITSCM-Standards bei dieser Begriffsdefinition erhebliche Schwächen auf. Für die Definition des RTO ist entscheidend, wann die Berechnung dieser Zeitspanne beginnt und wann sie endet.
Damit aus dem RTO korrekte Anforderungen an die Ressourcen, wie zum Beispiel die Wiederanlaufanforderungen an die IT Services, abgeleitet werden können, ist eine exakte Definition dieser Zeitspanne erforderlich. Leider weisen die BCM- und ITSCM-Standards bei dieser Begriffsdefinition erhebliche Schwächen auf. Für die Definition des RTO ist entscheidend, wann die Berechnung dieser Zeitspanne beginnt und wann sie endet.
Mögliche Zeitpunkte
Als möglicher Startzeitpunkt kommen beim RTO mehrere infrage:
Als möglicher Startzeitpunkt kommen beim RTO mehrere infrage:
| • | der tatsächliche Zeitpunkt des Ausfalls (dies kann auch ein Zeitpunkt außerhalb der vereinbarten Verfügbarkeitszeiten sein, zum Beispiel nachts oder am Wochenende), |
| • | der Zeitpunkt der Aufnahme der Störung im User Help Desk (Erstellungszeitpunkt des Tickets), |
| • | der Zeitpunkt der Ausrufung des Notfalls, |
| • | der Ausfall-Zeitpunkt innerhalb der vereinbarten Verfügbarkeitszeit mit den Fachbereichen, der zum Ausfall oder der Beeinträchtigung der Geschäftsprozesse führt. |
Auch für den Zeitpunkt des Erreichens des RTO stehen mehrere alternative Zeitpunkte zur Wahl:
| • | Verfügbarkeit des IT Services mit den Notbetriebsanforderungen, |
| • | Verfügbarkeit des IT Services im vollumfänglichen Normalbetrieb. |
Wichtig! Einheitliche Definition entscheidend
Für die Fachbereiche ist in der Regel der Zeitpunkt entscheidend, zu dem der Ausfall des IT Services Auswirkungen auf die Geschäftsprozesse hat. Aus Sicht der IT ist der tatsächliche Ausfallzeitpunkt entscheidend. Für Service-Level-Vereinbarungen ist wiederum die zugesagte Verfügbarkeitszeit relevant. Entscheidend ist auch hier wieder eine einheitliche Definition des RTO. An dieser Stelle wird die Bedeutung eines übergreifenden Glossars deutlich. Die Abbildung 3 stellt die Wiederherstellung im Ablauf dar.
Für die Fachbereiche ist in der Regel der Zeitpunkt entscheidend, zu dem der Ausfall des IT Services Auswirkungen auf die Geschäftsprozesse hat. Aus Sicht der IT ist der tatsächliche Ausfallzeitpunkt entscheidend. Für Service-Level-Vereinbarungen ist wiederum die zugesagte Verfügbarkeitszeit relevant. Entscheidend ist auch hier wieder eine einheitliche Definition des RTO. An dieser Stelle wird die Bedeutung eines übergreifenden Glossars deutlich. Die Abbildung 3 stellt die Wiederherstellung im Ablauf dar.
Ressourcen ermitteln
In einem weiteren Schritt werden für die kritischen Geschäftsprozesse die Ressourcen ermittelt, die im Notbetrieb für die Durchführung des Prozesses erforderlich sind. Zu diesen Ressourcen zählen:
In einem weiteren Schritt werden für die kritischen Geschäftsprozesse die Ressourcen ermittelt, die im Notbetrieb für die Durchführung des Prozesses erforderlich sind. Zu diesen Ressourcen zählen:
| • | Personal(Anzahl, erforderliches Know-how und Kompetenzen der Mitarbeiter), |
| • | Arbeitsplätze(Anzahl und Ausstattung), |
| • | Dienstleister und Lieferanten, |
| • | Dokumente und Informations-/Datenträger sowie |
| • | IT Services. |
IT Service
Bewusst wird hier statt des häufig verwendeten Begriffs der IT-Anwendung der Begriff des IT Service verwendet. Der IT Service wird hier weiter gefasst als die IT-Anwendung und umfasst alle erforderlichen IT-Anwendungen für den IT Service mit dem aktuellen Datenbestand, den erfolgten Hintergrund- und Vorverarbeitungen sowie mit akzeptabler Performance. Eine IT-Anwendung ohne aktuellen Datenbestand ist für die Durchführung eines Geschäftsprozesses nicht ausreichend.
Bewusst wird hier statt des häufig verwendeten Begriffs der IT-Anwendung der Begriff des IT Service verwendet. Der IT Service wird hier weiter gefasst als die IT-Anwendung und umfasst alle erforderlichen IT-Anwendungen für den IT Service mit dem aktuellen Datenbestand, den erfolgten Hintergrund- und Vorverarbeitungen sowie mit akzeptabler Performance. Eine IT-Anwendung ohne aktuellen Datenbestand ist für die Durchführung eines Geschäftsprozesses nicht ausreichend.
IT-Servicekatalog wichtige Grundlage für BIA
Für die Erhebung der erforderlichen IT Services sollte ein abgestimmter IT-Servicekatalog zugrunde gelegt werden. Bei den Fachbereichen sind IT-Anwendungen oftmals nicht einheitlich benannt oder die offizielle Bezeichnung in der IT unterscheidet sich von der umgangssprachlichen Bezeichnung in den Fachbereichen. Ohne diesen IT-Servicekatalog als Grundlage sind die erhobenen IT Services später kaum noch übereinander zu bekommen. Die Business-Impact-Analyse bildet einen guten Startpunkt für die IT, einen IT-Servicekatalog zu erstellen, sofern noch nicht vorhanden, oder diesen zu aktualisieren. So können zum Beispiel IT-Anwendungen im IT-Servicekatalog fehlen, die von den Fachbereichen als reine Web-Anwendungen (SaaS-Anwendungen) genutzt werden. Oftmals sind diese der IT nicht bekannt, da die Beschaffung innerhalb des Fachbereichs ohne Einbindung der IT abläuft.
Für die Erhebung der erforderlichen IT Services sollte ein abgestimmter IT-Servicekatalog zugrunde gelegt werden. Bei den Fachbereichen sind IT-Anwendungen oftmals nicht einheitlich benannt oder die offizielle Bezeichnung in der IT unterscheidet sich von der umgangssprachlichen Bezeichnung in den Fachbereichen. Ohne diesen IT-Servicekatalog als Grundlage sind die erhobenen IT Services später kaum noch übereinander zu bekommen. Die Business-Impact-Analyse bildet einen guten Startpunkt für die IT, einen IT-Servicekatalog zu erstellen, sofern noch nicht vorhanden, oder diesen zu aktualisieren. So können zum Beispiel IT-Anwendungen im IT-Servicekatalog fehlen, die von den Fachbereichen als reine Web-Anwendungen (SaaS-Anwendungen) genutzt werden. Oftmals sind diese der IT nicht bekannt, da die Beschaffung innerhalb des Fachbereichs ohne Einbindung der IT abläuft.
Soll-RTO
Als Ergebnis der BIA liegen die kritischen Geschäftsprozesse sowie die erforderlichen Ressourcen mit den jeweiligen Wiederherstellungsanforderungen (Soll-RTO) vor (s. Abbildung 4).
Als Ergebnis der BIA liegen die kritischen Geschäftsprozesse sowie die erforderlichen Ressourcen mit den jeweiligen Wiederherstellungsanforderungen (Soll-RTO) vor (s. Abbildung 4).
Kritische Termine erfassen
Geschäftsprozesse und deren Ressourcen sind in der Regel nicht zu jedem Zeitpunkt gleich kritisch. Dies gilt auch für die IT Services. IT Services, die für die Erstellung des Jahresabschlusses erforderlich sind, werden von den Fachbereichen zum Jahreswechsel mit hoher Kritikalität benötigt. Außerhalb dieses Zeitraums ist ein Ausfall über einen längeren Zeitraum verkraftbar. IT Services können auch nur zu bestimmten Tageszeiten (Bsp. Tagesabschlüsse) oder in festen Rhythmen kritisch sein (Bsp. Rechnungsläufe, internes und externes Berichtswesen). Diese kritischen Termine und Zeiträume werden in der BIA ebenfalls erhoben. Beim Ausfall eines Geschäftsprozesses oder eines IT Service ist es für die Priorität der Wiederherstellung in diesem Moment wichtig zu wissen, ob ein solcher kritischer Termin zum Ausfallzeitpunkt vorliegt.
Geschäftsprozesse und deren Ressourcen sind in der Regel nicht zu jedem Zeitpunkt gleich kritisch. Dies gilt auch für die IT Services. IT Services, die für die Erstellung des Jahresabschlusses erforderlich sind, werden von den Fachbereichen zum Jahreswechsel mit hoher Kritikalität benötigt. Außerhalb dieses Zeitraums ist ein Ausfall über einen längeren Zeitraum verkraftbar. IT Services können auch nur zu bestimmten Tageszeiten (Bsp. Tagesabschlüsse) oder in festen Rhythmen kritisch sein (Bsp. Rechnungsläufe, internes und externes Berichtswesen). Diese kritischen Termine und Zeiträume werden in der BIA ebenfalls erhoben. Beim Ausfall eines Geschäftsprozesses oder eines IT Service ist es für die Priorität der Wiederherstellung in diesem Moment wichtig zu wissen, ob ein solcher kritischer Termin zum Ausfallzeitpunkt vorliegt.
Neben IT-Anwendungen selbst sind die Daten von elementarer Bedeutung für das Funktionieren eines Geschäftsprozesses.
Recovery Point Objective
Die Messgröße Recovery Point Objective (RPO) definiert die Anforderungen an die Wiederherstellung von Daten nach einem Ausfall. Der RPO gibt an, über welchen Zeitraum ein Datenverlust für den kritischen Geschäftsprozess akzeptabel ist, d. h. für welchen Zeitraum die Daten durch den Fachbereich wiederhergestellt werden können. Die Erhebung des RPO im Rahmen der BIA kann für die IT Anforderungen an die Sicherung der Daten liefern. Können Daten zum Beispiel aufgrund der Datenmenge nur für einen kurzen Zeitraum durch den Fachbereich wiederhergestellt werden, ist ein kürzerer Sicherungszyklus für die Datensicherungen erforderlich. In der Praxis werden Datensicherungszyklen jedoch nicht je Anwendung oder IT Service festgelegt, sondern auf der Ebene von Plattformen (Bsp. Mainframe oder virtualisierte Umgebungen). Unterschiedliche RPOs je IT Service können von der IT in dieser Differenzierung dann häufig technisch nicht umgesetzt werden, oder die Differenzierung ist aufwendiger als ein einheitlich hoher Standard für die Datensicherung. Im Einzelfall ist daher zu prüfen, ob eine Erhebung des RPO im Rahmen der BIA sinnvoll und notwendig ist.
Die Messgröße Recovery Point Objective (RPO) definiert die Anforderungen an die Wiederherstellung von Daten nach einem Ausfall. Der RPO gibt an, über welchen Zeitraum ein Datenverlust für den kritischen Geschäftsprozess akzeptabel ist, d. h. für welchen Zeitraum die Daten durch den Fachbereich wiederhergestellt werden können. Die Erhebung des RPO im Rahmen der BIA kann für die IT Anforderungen an die Sicherung der Daten liefern. Können Daten zum Beispiel aufgrund der Datenmenge nur für einen kurzen Zeitraum durch den Fachbereich wiederhergestellt werden, ist ein kürzerer Sicherungszyklus für die Datensicherungen erforderlich. In der Praxis werden Datensicherungszyklen jedoch nicht je Anwendung oder IT Service festgelegt, sondern auf der Ebene von Plattformen (Bsp. Mainframe oder virtualisierte Umgebungen). Unterschiedliche RPOs je IT Service können von der IT in dieser Differenzierung dann häufig technisch nicht umgesetzt werden, oder die Differenzierung ist aufwendiger als ein einheitlich hoher Standard für die Datensicherung. Im Einzelfall ist daher zu prüfen, ob eine Erhebung des RPO im Rahmen der BIA sinnvoll und notwendig ist.
2.3.2 Business-Impact-Analyse für die IT-Prozesse
Der IT-Bereich wird in der Business-Impact-Analyse wie ein Fachbereich behandelt. Auch die IT verfügt über Geschäftsprozesse, die zur Bereitstellung der IT Services erforderlich sind. Dazu gehören zum Beispiel Prozesse zur Anwendungsentwicklung, Projektmanagement, User Help Desk, Informationssicherheitsmanagement sowie Prozesse zum Betrieb der IT-Systeme. Auch diese IT-Prozesse benötigen wiederum Ressourcen zu ihrer Durchführung. Zu diesen Prozessressourcen zählen beispielhaft die IT-Mitarbeiter, IT-Entwicklungsumgebungen für die Anwendungsentwicklung sowie Anwendungen für den IT-Betrieb und zur Produktionssteuerung. Gebäude und Räume mit IT-Infrastruktur (Bsp. Rechenzentren) und IT-Infrastrukturkomponenten (Bsp. Verteilerräume, Netze und Verkabelung) sind ebenfalls in der BIA zu betrachtende Ressourcen.
Zahlreiche kritische Ressourcen
Viele Dienstleistungen und Zulieferungen in der IT werden extern bezogen. In der BIA für die IT werden daher ebenfalls externe Dienstleister und Lieferanten identifiziert, die für die Aufrechterhaltung der kritischen Services im Notfall erforderlich sind. Dies kann vom Hardwarelieferanten über Techniker mit Spezial-Know-how bis hin zu Betreibern ausgelagerter Rechenzentren reichen. Auch der Freelancer, der unauffällig in der IT tagtäglich seine Arbeit leistet, kann ein kritisches „Kopfmonopol” für die Bewältigung eines Notfalls darstellen, da er über spezifische Kenntnisse verfügt, die im Notfall benötigt werden.
Viele Dienstleistungen und Zulieferungen in der IT werden extern bezogen. In der BIA für die IT werden daher ebenfalls externe Dienstleister und Lieferanten identifiziert, die für die Aufrechterhaltung der kritischen Services im Notfall erforderlich sind. Dies kann vom Hardwarelieferanten über Techniker mit Spezial-Know-how bis hin zu Betreibern ausgelagerter Rechenzentren reichen. Auch der Freelancer, der unauffällig in der IT tagtäglich seine Arbeit leistet, kann ein kritisches „Kopfmonopol” für die Bewältigung eines Notfalls darstellen, da er über spezifische Kenntnisse verfügt, die im Notfall benötigt werden.
Erst Fachbereiche analysieren, dann IT-Prozesse
Da IT-Prozesse nicht unmittelbar wertschöpfend sind, kann der Business Impact des Ausfalls eines IT-Prozesses nicht direkt aus den Marktwirkungen, wie zum Beispiel Umsatzverlusten, abgeleitet werden, wie dies bei Kernprozessen der Fall ist. Die Unterstützungsprozesse erben ihre Kritikalität aus der Zuordnung zu den kritischen Kernprozessen (vgl. Abbildung 5). Dazu werden in der Business-Impact-Analyse für die kritischen Geschäftsprozesse erforderliche Vorgänger- und Unterstützungsprozesse identifiziert. Für fachliche Zulieferprozesse ist dies meist sehr gut möglich. Die IT-Prozesse zur Entwicklung und für den Betrieb der Anwendungen sind den Fachbereichen allerdings nicht transparent und bekannt. Die Verknüpfung der IT-Prozesse mit den Geschäftsprozessen fällt daher aus Fachbereichssicht sehr schwer. Es ist daher sinnvoll, die Kritikalität der IT-Prozesse über die kritischen IT Services abzuleiten. Sind der IT die kritischen IT Services aus der BIA bekannt, können die IT-Prozesse und Ressourcen identifiziert werden, die zum Betrieb dieser kritischen IT Services erforderlich sind. Die BIA für die IT sollte aus diesem Grund nachgelagert zu den Business-Impact-Analysen in den Fachbereichen durchgeführt werden, um die Informationen über die kritischen IT Services für die BIA verfügbar zu haben.
Da IT-Prozesse nicht unmittelbar wertschöpfend sind, kann der Business Impact des Ausfalls eines IT-Prozesses nicht direkt aus den Marktwirkungen, wie zum Beispiel Umsatzverlusten, abgeleitet werden, wie dies bei Kernprozessen der Fall ist. Die Unterstützungsprozesse erben ihre Kritikalität aus der Zuordnung zu den kritischen Kernprozessen (vgl. Abbildung 5). Dazu werden in der Business-Impact-Analyse für die kritischen Geschäftsprozesse erforderliche Vorgänger- und Unterstützungsprozesse identifiziert. Für fachliche Zulieferprozesse ist dies meist sehr gut möglich. Die IT-Prozesse zur Entwicklung und für den Betrieb der Anwendungen sind den Fachbereichen allerdings nicht transparent und bekannt. Die Verknüpfung der IT-Prozesse mit den Geschäftsprozessen fällt daher aus Fachbereichssicht sehr schwer. Es ist daher sinnvoll, die Kritikalität der IT-Prozesse über die kritischen IT Services abzuleiten. Sind der IT die kritischen IT Services aus der BIA bekannt, können die IT-Prozesse und Ressourcen identifiziert werden, die zum Betrieb dieser kritischen IT Services erforderlich sind. Die BIA für die IT sollte aus diesem Grund nachgelagert zu den Business-Impact-Analysen in den Fachbereichen durchgeführt werden, um die Informationen über die kritischen IT Services für die BIA verfügbar zu haben.
Notfallrelevante IT-Prozesse
Neben diesen direkt für die Erbringung der kritischen IT Services erforderlichen IT-Prozessen kommt weiteren IT-Prozessen im Notfall eine besondere Bedeutung zu. Anwendern müssen im Notfall kurzfristig neue Zugriffsrechte für Laufwerke und IT Services zugeordnet werden können. Der Bedarf an Leistungen des User Help Desk steigt im Notfall kurzfristig stark an. Um diese notfallrelevanten Unterstützungsprozesse zu identifizieren, ist ein genauer Blick auf die Prozesse in der IT-Prozesslandkarte unter diesem Blickwinkel erforderlich, um auch diese notfallrelevanten IT-Prozesse zu identifizieren.
Neben diesen direkt für die Erbringung der kritischen IT Services erforderlichen IT-Prozessen kommt weiteren IT-Prozessen im Notfall eine besondere Bedeutung zu. Anwendern müssen im Notfall kurzfristig neue Zugriffsrechte für Laufwerke und IT Services zugeordnet werden können. Der Bedarf an Leistungen des User Help Desk steigt im Notfall kurzfristig stark an. Um diese notfallrelevanten Unterstützungsprozesse zu identifizieren, ist ein genauer Blick auf die Prozesse in der IT-Prozesslandkarte unter diesem Blickwinkel erforderlich, um auch diese notfallrelevanten IT-Prozesse zu identifizieren.
2.3.3 Anforderungsanalyse für das ITSCM
Die Anforderungsanalyse im ITSCM baut auf den Ergebnissen der Business-Impact-Analyse für die IT Services auf. Ergebnis der BIA sind die Wiederanlaufanforderungen (Recovery Time Objectives, RTOs) für die geschäftskritischen IT Services.
Gesamte IT-Architektur betrachten
Ausgehend von den Anforderungen an den IT Service wird die gesamte IT-Architektur betrachtet, die zur Erstellung eines IT Service erforderlich ist.
Ausgehend von den Anforderungen an den IT Service wird die gesamte IT-Architektur betrachtet, die zur Erstellung eines IT Service erforderlich ist.
Dazu gehören insbesondere
| • | vor- und nachgelagerte IT Services, |
| • | Hintergrundverarbeitungsprogramme („Batch-Programme”), |
| • | interne und externe Datenversorgungen für den IT Service, |
| • | Schnittstellen vom und zum IT Service, |
| • | IT-Middleware, die für den IT Service erforderlich ist, |
| • | Datenspeichersysteme für den IT Service, |
| • | IT-Systeme (Hardware) für den IT Service, |
| • | Netzwerke und Kommunikationsarchitektur. |
Abhängigkeitsanalyse
In Form einer Abhängigkeitsanalyse (Dependency Mapping) wird überprüft, ob jede einzelne dieser IT-Architekturkomponenten die Anforderungen an den Soll-RTO des IT Service erfüllt. Eine dokumentierte IT-Architektur mit den Angaben zu den bestehenden Ist-Verfügbarkeiten, zum Beispiel in einem Architekturmodell oder einer Configuration Management Database/CMS nach ITIL, erleichtert diesen Analyseprozess erheblich.
In Form einer Abhängigkeitsanalyse (Dependency Mapping) wird überprüft, ob jede einzelne dieser IT-Architekturkomponenten die Anforderungen an den Soll-RTO des IT Service erfüllt. Eine dokumentierte IT-Architektur mit den Angaben zu den bestehenden Ist-Verfügbarkeiten, zum Beispiel in einem Architekturmodell oder einer Configuration Management Database/CMS nach ITIL, erleichtert diesen Analyseprozess erheblich.
Die Abhängigkeitsanalyse wird auch für die IT-Dienstleister durchgeführt, die für den IT Service selbst oder die unterstützenden IT-Komponenten erforderlich sind.
Ergebnis der Anforderungsanalyse im ITSCM ist die aktuell realisierte Wiederherstellungszeit (Ist-RTO).
2.3.4 Die GAP-Analyse
Soll-/Ist-Abgleich
Im Rahmen der GAP-Analyse findet der Abgleich des aus der BIA abgeleiteten Soll-RTO mit dem Ist-RTO als Ergebnis der Abhängigkeitsanalyse des ITSCM statt.
Im Rahmen der GAP-Analyse findet der Abgleich des aus der BIA abgeleiteten Soll-RTO mit dem Ist-RTO als Ergebnis der Abhängigkeitsanalyse des ITSCM statt.
Die GAP-Analyse kann zu folgenden Ergebnissen führen:
| 1. | Die Anforderungen aus der BIA an den RTO (Soll-RTO) werden durch den Ist-RTO exakt erfüllt. |
| 2. | Der aktuelle Ist-RTO erfüllt die Anforderungen des Soll-RTO nicht, da die aktuellen Wiederherstellungszeiten (Ist-RTO) für den IT Service länger sind als gefordert. |
| 3. | Der aktuelle Ist-RTO des IT Service übererfüllt die Anforderungen des Soll-RTO. Die Wiederherstellungszeiten sind kürzer als aufgrund der BIA gefordert. |
Idealfall
Das perfekte Ergebnis ist die exakte Übereinstimmung der Anforderungen aus der BIA mit den aktuellen Ist-Verfügbarkeiten. Dies ist häufig dann der Fall, wenn es bereits vereinbarte Service Levels zwischen der IT und den Fachbereichen gibt und die Anforderungen im Rahmen der Erstellung der Service Levels bereits abgestimmt wurden. Die BIA stellt in diesem Falle eine Überprüfung und Qualitätssicherung dieser Service Levels dar. Der Vorteil der BIA ist die konsistente Herleitung der Anforderungen aus den Geschäftsprozessen. Änderungen in den Geschäftsprozessen können in diesem durchgehenden Modell später einfach gegen die IT Services geprüft werden.
Das perfekte Ergebnis ist die exakte Übereinstimmung der Anforderungen aus der BIA mit den aktuellen Ist-Verfügbarkeiten. Dies ist häufig dann der Fall, wenn es bereits vereinbarte Service Levels zwischen der IT und den Fachbereichen gibt und die Anforderungen im Rahmen der Erstellung der Service Levels bereits abgestimmt wurden. Die BIA stellt in diesem Falle eine Überprüfung und Qualitätssicherung dieser Service Levels dar. Der Vorteil der BIA ist die konsistente Herleitung der Anforderungen aus den Geschäftsprozessen. Änderungen in den Geschäftsprozessen können in diesem durchgehenden Modell später einfach gegen die IT Services geprüft werden.
Bei Abweichung mehrstufige Analyse
Im zweiten Fall ist die bestehende Wiederherstellungszeit des IT Service länger als die geforderte Zeit aus der BIA. Bevor jetzt jedoch direkt kostenintensive Maßnahmen in der IT geplant und umgesetzt werden, sollte ein mehrstufiger Analyseprozess des GAPs durchgeführt werden.
Im zweiten Fall ist die bestehende Wiederherstellungszeit des IT Service länger als die geforderte Zeit aus der BIA. Bevor jetzt jedoch direkt kostenintensive Maßnahmen in der IT geplant und umgesetzt werden, sollte ein mehrstufiger Analyseprozess des GAPs durchgeführt werden.
Sind „Work-arounds” möglich?
In einem ersten Schritt wird auf Seiten der Fachbereiche die Anforderung noch einmal hinterfragt. Ist die Wiederanlaufanforderung in dieser Form bestätigt, sollte geprüft werden, ob es auf Seiten der Fachbereiche prozessuale „Work-arounds” gibt, die es erlauben, den zeitlichen GAP ganz oder zumindest teilweise zu schließen. Organisatorische Lösungen stellen oftmals die kostengünstigste Alternative zur Behebung eines GAPs dar. Beispiele für derartige „Work-arounds” sind manuelle papiergestützte Verfahren wie zum Beispiel die vorübergehende Dokumentation von Vorgängen auf Papier statt elektronisch in der IT-Anwendung. Zu beachten bei der Definition dieser „Work-arounds” ist neben der Funktionsfähigkeit unter Last die Einhaltung der rechtlichen und regulatorischen Anforderungen. Diese Anforderungen sind oftmals innerhalb von IT-Anwendungen realisiert sind (Bsp. Vier-Augen-Prinzip in einem Workflow oder Plausibilitätsprüfungen innerhalb der IT-Anwendungen). Bei einem manuellen Ersatzprozess greifen diese automatisierten Prüfungen und Protokollierungen aber nicht mehr. In Abstimmung mit der Revision können diese Prüfungen für Notfälle zeitlich begrenzt ausgesetzt oder verringert werden. Andernfalls müssen die Prüfungen im „Work-around” abgebildet werden. Zudem müssen bei manuellen „Work-arounds” Nacharbeiten berücksichtigt werden. So ist für manuelle Dokumentationen eine Nacherfassung in den IT-Anwendungen erforderlich. Diese Nacharbeiten kommen nach der Bewältigung des Notfalls ergänzend zum Normalbetrieb hinzu, sodass die Bewältigung des Notfalls mit dem Wiederanlauf der Prozesse und IT Services nicht abgeschlossen ist.
In einem ersten Schritt wird auf Seiten der Fachbereiche die Anforderung noch einmal hinterfragt. Ist die Wiederanlaufanforderung in dieser Form bestätigt, sollte geprüft werden, ob es auf Seiten der Fachbereiche prozessuale „Work-arounds” gibt, die es erlauben, den zeitlichen GAP ganz oder zumindest teilweise zu schließen. Organisatorische Lösungen stellen oftmals die kostengünstigste Alternative zur Behebung eines GAPs dar. Beispiele für derartige „Work-arounds” sind manuelle papiergestützte Verfahren wie zum Beispiel die vorübergehende Dokumentation von Vorgängen auf Papier statt elektronisch in der IT-Anwendung. Zu beachten bei der Definition dieser „Work-arounds” ist neben der Funktionsfähigkeit unter Last die Einhaltung der rechtlichen und regulatorischen Anforderungen. Diese Anforderungen sind oftmals innerhalb von IT-Anwendungen realisiert sind (Bsp. Vier-Augen-Prinzip in einem Workflow oder Plausibilitätsprüfungen innerhalb der IT-Anwendungen). Bei einem manuellen Ersatzprozess greifen diese automatisierten Prüfungen und Protokollierungen aber nicht mehr. In Abstimmung mit der Revision können diese Prüfungen für Notfälle zeitlich begrenzt ausgesetzt oder verringert werden. Andernfalls müssen die Prüfungen im „Work-around” abgebildet werden. Zudem müssen bei manuellen „Work-arounds” Nacharbeiten berücksichtigt werden. So ist für manuelle Dokumentationen eine Nacherfassung in den IT-Anwendungen erforderlich. Diese Nacharbeiten kommen nach der Bewältigung des Notfalls ergänzend zum Normalbetrieb hinzu, sodass die Bewältigung des Notfalls mit dem Wiederanlauf der Prozesse und IT Services nicht abgeschlossen ist.
Ist ein manueller „Work-around” auf Seiten der Fachabteilungen nicht möglich, sollte die IT prüfen, ob es wirtschaftliche und akzeptable IT-Ersatzlösungen, IT-gestützte „Work-arounds”, gibt.
Übererfüllung
Ist der aktuelle Ist-RTO bereits kürzer als der angeforderte RTO für den IT Service, besteht ein Potenzial für Einsparungen. Oftmals sind Wiederherstellungszeiten kürzer als gefordert, weil der IT Service von den Verfügbarkeitszeiten einer ganzen Gruppe von IT Services auf einer gemeinsamen IT-Plattform profitiert. Bei Mainframe-Anwendungen oder virtualisierten Umgebungen können die Wiederherstellungszeiten technisch nicht oder nur sehr aufwendig zwischen den IT Services differenziert werden. In diesem Fall kann aus einer Verlängerung der Wiederanlaufzeit kein Einspareffekt erzielt werden.
Ist der aktuelle Ist-RTO bereits kürzer als der angeforderte RTO für den IT Service, besteht ein Potenzial für Einsparungen. Oftmals sind Wiederherstellungszeiten kürzer als gefordert, weil der IT Service von den Verfügbarkeitszeiten einer ganzen Gruppe von IT Services auf einer gemeinsamen IT-Plattform profitiert. Bei Mainframe-Anwendungen oder virtualisierten Umgebungen können die Wiederherstellungszeiten technisch nicht oder nur sehr aufwendig zwischen den IT Services differenziert werden. In diesem Fall kann aus einer Verlängerung der Wiederanlaufzeit kein Einspareffekt erzielt werden.
In den Fällen, in denen der Ist-RTO aus Unkenntnis der fachlichen Anforderung sehr kurz ist, bietet das Ergebnis der BIA die Chance, Einspareffekte zu erzielen, indem die Wiederherstellungszeit verlängert wird.
2.4 Risk-Assessment
Risiken für Prozesse und Ressourcen analysieren
Im Rahmen des Risk-Assessments werden auf der Basis eines Gefährdungskatalogs die Risiken identifiziert, die zu Unterbrechungen oder Ausfällen von Geschäftsprozessen im Unternehmen führen können. Die zu betrachtenden Gefährdungen für die Prozesse und Ressourcen Personal, Gebäude, IT-Systeme, Daten und Dienstleister sind für BCM und ITSCM weitgehend identisch. Im ITSCM kommen noch IT-spezifische Risiken wie Cyberattacken hinzu.
Im Rahmen des Risk-Assessments werden auf der Basis eines Gefährdungskatalogs die Risiken identifiziert, die zu Unterbrechungen oder Ausfällen von Geschäftsprozessen im Unternehmen führen können. Die zu betrachtenden Gefährdungen für die Prozesse und Ressourcen Personal, Gebäude, IT-Systeme, Daten und Dienstleister sind für BCM und ITSCM weitgehend identisch. Im ITSCM kommen noch IT-spezifische Risiken wie Cyberattacken hinzu.
Grundlage: übergreifender Gefährdungskatalog
Aus diesem Grund ist es zielführend, einen übergreifenden Gefährdungskatalog für das BCM und das ITSCM zu erstellen, auf dessen Basis das Risk-Assessment für die Prozesse und deren Ressourcen durchgeführt wird. Die Grundschutzkataloge des Bundesamts für Sicherheit in der Informationstechnik (BSI) bilden eine gute Basis dafür.
Aus diesem Grund ist es zielführend, einen übergreifenden Gefährdungskatalog für das BCM und das ITSCM zu erstellen, auf dessen Basis das Risk-Assessment für die Prozesse und deren Ressourcen durchgeführt wird. Die Grundschutzkataloge des Bundesamts für Sicherheit in der Informationstechnik (BSI) bilden eine gute Basis dafür.
Risikoreduzierende Maßnahmen abstimmen
Mittels risikoreduzierender Maßnahmen wird/werden die Eintrittswahrscheinlichkeit eines Schadensereignisses und/oder die Schadensfolgen gemindert. Sowohl im BCM als auch im ITSCM werden risikoreduzierende Maßnahmen identifiziert und umgesetzt. Diese Maßnahmen müssen aufeinander abgestimmt sein. Nur so lassen sich Synergieeffekte erzielen. Dies ist zum Beispiel bei der Absicherung von Gebäuden der Fall. In der Regel befinden sich in Gebäuden neben den Ressourcen des BCM auch IT-Infrastrukturkomponenten oder Rechenzentren. Maßnahmen des Zutrittsschutzes im Rahmen der physischen Sicherheit sind in diesem Fall so auszulegen, dass sie den Anforderungen sowohl des BCM als auch des ITSCM gerecht werden.
Mittels risikoreduzierender Maßnahmen wird/werden die Eintrittswahrscheinlichkeit eines Schadensereignisses und/oder die Schadensfolgen gemindert. Sowohl im BCM als auch im ITSCM werden risikoreduzierende Maßnahmen identifiziert und umgesetzt. Diese Maßnahmen müssen aufeinander abgestimmt sein. Nur so lassen sich Synergieeffekte erzielen. Dies ist zum Beispiel bei der Absicherung von Gebäuden der Fall. In der Regel befinden sich in Gebäuden neben den Ressourcen des BCM auch IT-Infrastrukturkomponenten oder Rechenzentren. Maßnahmen des Zutrittsschutzes im Rahmen der physischen Sicherheit sind in diesem Fall so auszulegen, dass sie den Anforderungen sowohl des BCM als auch des ITSCM gerecht werden.
2.5 Festlegung der BCM- und ITSCM-Strategien
Im Rahmen der BCM-Strategien werden auf der Grundlage der Ergebnisse der Business-Impact-Analyse und des Risk-Assessments Geschäftsfortführungs- und Wiederherstellungsstrategien für die Geschäftsprozesse und deren Ressourcen festgelegt.
Gebäudeevakuierung
Für den Ausfall von Arbeitsplätzen infolge einer Gebäudeevakuierung können folgende BCM-Strategien in Betracht gezogen werden:
Für den Ausfall von Arbeitsplätzen infolge einer Gebäudeevakuierung können folgende BCM-Strategien in Betracht gezogen werden:
| • | Nutzung der Arbeitsplätze an einem Standort, |
| • | Übernahme der betroffenen Geschäftsprozesse durch Mitarbeiter an einen anderen Standort, der nicht von dem Ereignis betroffen ist, |
| • | Durchführung der Geschäftsprozesse remote an mobilen Arbeitsplätzen, |
| • | Verlagerung der betroffenen Geschäftsprozesse an einen Dienstleister, |
| • | temporäres Aussetzen der betroffenen Geschäftsprozesse. |
Personalausfall
Für das Szenario Personalausfall, zum Beispiel verursacht durch eine Erkrankungswelle oder einen Streik an einem Standort, sind folgende strategische BCM-Optionen möglich:
Für das Szenario Personalausfall, zum Beispiel verursacht durch eine Erkrankungswelle oder einen Streik an einem Standort, sind folgende strategische BCM-Optionen möglich:
| • | Verlagerung der Geschäftsprozesse an einen anderen Standort, der nicht von dem Ereignis betroffen ist, |
| • | Übertragung der Geschäftsprozesse auf einen Dienstleister, |
| • | Remote-Arbeit an Heimarbeitsplätzen oder mobilen Zugängen. |
Für die Ressourcen Personal, Gebäude und Dienstleister der IT gelten die BCM-Strategien analog.
ITSCM-Ausfallstrategien
Für das ITSCM werden Strategien für den Ausfall
Für das ITSCM werden Strategien für den Ausfall
| • | einzelner IT Services, |
| • | von IT-Infrastrukturkomponenten (IT-Systeme, Hardware, Netzwerkkomponenten, Telekommunikationskomponenten), |
| • | von Daten, Datenspeicher, |
| • | eines gesamten Rechenzentrums, |
| • | von IT-Dienstleistern (Bsp. RZ-Provider) entwickelt. |
Keine isolierten Strategien!
BCM-Strategien funktionieren nicht isoliert und losgelöst von ITSCM-Strategien und umgekehrt. Für das Beispielszenario „Gebäudeausfall” muss die IT die entsprechenden technischen Vorkehrungen für die gewählten Strategieoptionen des BCM vorsehen. Bei der Nutzung einer Ausweichlokation als Ersatz für das ausgefallene Gebäude muss diese Lokation angemessen an die IT-Infrastruktur angebunden sein (Netze, Telekommunikation, VPN-Ports etc.). Es müssen ausreichend Arbeitsplätze mit Hard- und Software sowie Netzanbindung in der Ersatzlokation bereitgestellt werden. Ob diese Ausweicharbeitsplätze im hot, warm oder cold stand-by verfügbar sein müssen, entscheiden die Anforderungen aus der Business-Impact-Analyse an die zeitliche Verfügbarkeit nach Eintritt eines Notfalls. Bei der Nutzung von Remote-Zugangslösungen per VPN-Einwahl in das Netz müssen ausreichend VPN-Ports verfügbar sein, damit sich auch eine große Zahl an Mitarbeitern gleichzeitig in die Systeme einloggen kann. Die Geschäftsfortführung von Unternehmen in Notfällen ist schon an einer zu geringen Anzahl verfügbarer VPN-Ports gescheitert! Im Notfall kostet dies wertvolle Zeit und zieht finanzielle Schadensfolgen nach sich. Zudem leidet die Reputation des BCM und ITSCM unter solchen leicht vermeidbaren Fehlern.
BCM-Strategien funktionieren nicht isoliert und losgelöst von ITSCM-Strategien und umgekehrt. Für das Beispielszenario „Gebäudeausfall” muss die IT die entsprechenden technischen Vorkehrungen für die gewählten Strategieoptionen des BCM vorsehen. Bei der Nutzung einer Ausweichlokation als Ersatz für das ausgefallene Gebäude muss diese Lokation angemessen an die IT-Infrastruktur angebunden sein (Netze, Telekommunikation, VPN-Ports etc.). Es müssen ausreichend Arbeitsplätze mit Hard- und Software sowie Netzanbindung in der Ersatzlokation bereitgestellt werden. Ob diese Ausweicharbeitsplätze im hot, warm oder cold stand-by verfügbar sein müssen, entscheiden die Anforderungen aus der Business-Impact-Analyse an die zeitliche Verfügbarkeit nach Eintritt eines Notfalls. Bei der Nutzung von Remote-Zugangslösungen per VPN-Einwahl in das Netz müssen ausreichend VPN-Ports verfügbar sein, damit sich auch eine große Zahl an Mitarbeitern gleichzeitig in die Systeme einloggen kann. Die Geschäftsfortführung von Unternehmen in Notfällen ist schon an einer zu geringen Anzahl verfügbarer VPN-Ports gescheitert! Im Notfall kostet dies wertvolle Zeit und zieht finanzielle Schadensfolgen nach sich. Zudem leidet die Reputation des BCM und ITSCM unter solchen leicht vermeidbaren Fehlern.
Softwarelizenzen für den Notfall
Nicht zu vergessen sind die Regelungen der Lizenzen für Softwareanwendungen im Notbetrieb. Jeder Softwareanbieter regelt das Verfahren und die Abrechnung von Softwarelizenzen für den Notbetrieb anders. Um sich im Notfall nicht auch noch um fehlende Lizenzen kümmern zu müssen oder gar teure Verstöße gegen Lizenzbestimmungen zu begehen, ist es daher sehr ratsam, dies bereits in der Notfallplanung zu berücksichtigen. Auch gibt es noch Software mit Hardware-Dongles für die Legitimierung der Nutzung. Hier muss natürlich sichergestellt sein, dass ein solcher Dongle auch an den Ausweichlokationen im Notfall verfügbar ist.
Nicht zu vergessen sind die Regelungen der Lizenzen für Softwareanwendungen im Notbetrieb. Jeder Softwareanbieter regelt das Verfahren und die Abrechnung von Softwarelizenzen für den Notbetrieb anders. Um sich im Notfall nicht auch noch um fehlende Lizenzen kümmern zu müssen oder gar teure Verstöße gegen Lizenzbestimmungen zu begehen, ist es daher sehr ratsam, dies bereits in der Notfallplanung zu berücksichtigen. Auch gibt es noch Software mit Hardware-Dongles für die Legitimierung der Nutzung. Hier muss natürlich sichergestellt sein, dass ein solcher Dongle auch an den Ausweichlokationen im Notfall verfügbar ist.
Bei den BCM- und ISCM-Strategien ist die Kombinatorik von Szenarien zu berücksichtigen. Ist bei einem Schwenk des Rechenzentrums auf das Ausweich-RZ davon auszugehen, dass die Versorgung auch weiterhin an die ursprüngliche Lokation erfolgt? Wenn sich die Gebäude auf dem gleichen Areal befinden, muss bei einem Ereignis statt der normalen Lokation ggf. die Ausweichlokation(en) aus dem Ausweich-RZ versorgt werden. Dafür sind dann entsprechende Leitungsverbindungen und -kapazitäten vorzusehen.
Diese Beispiele zeigen, dass die Entwicklung von BCM- und ITSCM-Strategien sehr eng aufeinander abgestimmt sein muss. BCM und ITSCM müssen gerade bei der Notfallstrategieentwicklung „Hand in Hand” arbeiten, um zu funktionsfähigen und wirtschaftlichen Lösungen zu kommen.
3.1 Inhalte der DO-Phase des PDA-Zyklus für BCM und ITSCM
In der DO-Phase des PDCA-Zyklus erfolgt die Implementierung der BCM- und ITSCM-Strategien.
Implementierungsphase
Zur Implementierungsphase zählen:
Zur Implementierungsphase zählen:
| • | Verfahren, um notfallrelevante Ereignisse rechtzeitig erkennen und eskalieren zu können (Incident Management, Alarmierungs- und Eskalationsverfahren), |
| • | eine funktionsfähige Krisenmanagementorganisation, |
| • | BCM-Geschäftsfortführungs- und -Wiederanlaufpläne, |
| • | ITSCM-Geschäftsfortführungs- und -Wiederanlaufpläne, |
| • | Schulungen, Trainings, Awareness für BCM und ITSCM. |
3.2 Incident Management, Alarmierung und Eskalation
Ein wesentlicher kritischer Erfolgsfaktor für die erfolgreiche Bewältigung von Notfällen sind die frühzeitige Erkennung notfallrelevanter Ereignisse, deren Kommunikation in einem Alarmierungsverfahren, die geordnete Eskalation sowie das Krisenmanagement.
Notfälle können an ganz unterschiedlichen Stellen innerhalb und außerhalb des Unternehmens ihre Ursache haben. IT-Störungen gehören genauso dazu wie Stromausfälle, akute Personalausfälle infolge von Krankheitsausbrüchen oder der Fund einer Fliegerbombe auf dem Nachbargrundstück.
Zentrale Leitstelle sammelt Meldungen
Im Incident-Management-Prozess werden diese Störungen in einem strukturierten Verfahren erfasst und dokumentiert. Eine zentrale übergreifende Leitstelle, die Incidents aus allen Bereichen aufnimmt, erlaubt ein einheitliches Verfahren für alle Arten von Incidents und stellt die Dokumentation der Ereignisse und Maßnahmen sicher. BCM- und ITSCM-Incidents laufen in diesem Fall an einer Stelle zusammen. Zusammenhänge zwischen Einzelereignissen lassen sich so leichter erkennen und ein Team von Sicherheitsspezialisten kann für die Erkennung und Reaktion von bzw. auf Störungen und Notfälle(n) geschult werden. Von dieser zentralen Leitstelle gehen die qualifizierten Störungsmeldungen an einen Einsatzleiter, der Ad-hoc-Maßnahmen veranlasst und über die weitere Eskalation bis hin zur Einberufung des Krisenstabs entscheidet. Eine ständige Erreichbarkeit von Leitstelle und Einsatzleiter ist sicherzustellen. Dies kann nur durch eine ausreichende Anzahl an geschultem und trainiertem Personal für das BCM- und ITSCM-Incident-Management erreicht werden.
Im Incident-Management-Prozess werden diese Störungen in einem strukturierten Verfahren erfasst und dokumentiert. Eine zentrale übergreifende Leitstelle, die Incidents aus allen Bereichen aufnimmt, erlaubt ein einheitliches Verfahren für alle Arten von Incidents und stellt die Dokumentation der Ereignisse und Maßnahmen sicher. BCM- und ITSCM-Incidents laufen in diesem Fall an einer Stelle zusammen. Zusammenhänge zwischen Einzelereignissen lassen sich so leichter erkennen und ein Team von Sicherheitsspezialisten kann für die Erkennung und Reaktion von bzw. auf Störungen und Notfälle(n) geschult werden. Von dieser zentralen Leitstelle gehen die qualifizierten Störungsmeldungen an einen Einsatzleiter, der Ad-hoc-Maßnahmen veranlasst und über die weitere Eskalation bis hin zur Einberufung des Krisenstabs entscheidet. Eine ständige Erreichbarkeit von Leitstelle und Einsatzleiter ist sicherzustellen. Dies kann nur durch eine ausreichende Anzahl an geschultem und trainiertem Personal für das BCM- und ITSCM-Incident-Management erreicht werden.
Ereignisse dokumentieren!
Wichtig, auch aus Gründen der Haftung und für die Sicherung der Ansprüche aus Versicherungen, ist die durchgehende Dokumentation eines Ereignisses. Bereits nach wenigen Stunden sind Entscheidungen, Entscheidungszeitpunkte und handelnde Personen nicht mehr nachvollziehbar, sofern keine mitlaufende Dokumentation erfolgt.
Wichtig, auch aus Gründen der Haftung und für die Sicherung der Ansprüche aus Versicherungen, ist die durchgehende Dokumentation eines Ereignisses. Bereits nach wenigen Stunden sind Entscheidungen, Entscheidungszeitpunkte und handelnde Personen nicht mehr nachvollziehbar, sofern keine mitlaufende Dokumentation erfolgt.
3.3 Krisenmanagement
Krisenstab
Der Krisenstab ist eine temporäre Organisationsform zur Bewältigung von Notfällen und Krisen neben der Linienorganisation. Der Krisenstab entscheidet über
Der Krisenstab ist eine temporäre Organisationsform zur Bewältigung von Notfällen und Krisen neben der Linienorganisation. Der Krisenstab entscheidet über
| • | die Ausrufung eines Notfalls/einer Krise, |
| • | die Maßnahmen zur Bewältigung des Notfalls/der Krise im Rahmen der zugewiesenen Kompetenzen und |
| • | die Beendigung des Notfalls/der Krise. |
Der Krisenstab ist die oberste Instanz zur Bewältigung von Notfällen und Krisen jeglicher Art im Unternehmen. Neben BCM-Notfällen und IT-Ausfällen kann es sich dabei auch um Krisenstabslagen aus Erpressung, Geiselnahme, Entführung, Datenpannen, Pressekampagnen etc. handeln. Der Unternehmenskrisenstab ist daher kein reiner BCM- oder ITSCM-Krisenstab, auch wenn er oftmals aus dem BCM und/oder ITSCM initiiert und organisiert wird.
Krisenmanagementorganisation
Die Krisenmanagementorganisation besteht idealerweise aus drei Ebenen (s. a. Abbildung 6):
Die Krisenmanagementorganisation besteht idealerweise aus drei Ebenen (s. a. Abbildung 6):
| • | „Gold-Team”:Leitungsebene des Krisenmanagements, auf der die Entscheidungen zur Bewältigung der Krise getroffen werden.Das Gold-Team tritt in regelmäßigen Abständen physisch oder per Telefon- oder Videokonferenz zusammen, analysiert die aktuelle Lage und trifft die Entscheidungen zur Bewältigung der Krise. |
| • | „Silber-Team”:Unterstützungsteam des Gold-Teams, das die Umsetzung der Maßnahmen steuert und koordiniert, das Lagebild erstellt und aktualisiert, die mitlaufende Dokumentation der Entscheidungen und Maßnahmen führt sowie die interne und externe Kommunikation steuert |
| • | „Bronze-Team”:Dezentrale Umsetzungseinheiten, die die Maßnahmen vor Ort steuern, koordinieren und umsetzen sowie die aktuellen Informationen zum zentralen Lagebild zuliefern. |
Mitglieder im Krisenstab
Der Krisenstab sollte aus festen und temporären Mitgliedern bestehen, die bei Bedarf hinzugezogen werden können.
Der Krisenstab sollte aus festen und temporären Mitgliedern bestehen, die bei Bedarf hinzugezogen werden können.
| • | Feste Mitglieder der Krisenstabsorganisation:
| ||||||||||||||
| • | Temporäre Mitglieder der Krisenstabsorganisation:
|
Bei der Besetzung der Positionen des Krisenstabs ist auf eine Mehrfachbesetzung der Rollen zu achten. Abwesenheitsbedingt können einzelne Personen nicht verfügbar sein. Die Arbeit des Krisenstabs erstreckt sich über mehrere Tage oder Wochen. Dies erfordert den regelmäßigen Austausch der Krisenstabsmitglieder.
3.4 BCM- und ITSCM-Planung
In der DO-Phase des PDCA-Zyklus erfolgt die Implementierung der Maßnahmen für die gewählten Strategien. Im BCM und ITSCM werden die erforderlichen Planungsdokumentationen für die Geschäftsfortführung und den Wiederanlauf erstellt.
Inhalte eines BCM- und ITSCM-Plans:
| • | Rollen und Verantwortlichkeiten in einem Notfall mit entsprechenden Kompetenzen | ||||||||
| • | Das Verfahren zur Aktivierung des Notfallplans: Wer aktiviert wann und wie? | ||||||||
| • | Ad-hoc-Maßnahmen in einem Notfall | ||||||||
| • | Notbetrieb und Work-arounds für die BCM- und ITSCM-Szenarien
| ||||||||
| • | Welche Prozesse und Ressourcen sind in welcher Reihenfolge für den Notbetrieb wiederherzustellen? | ||||||||
| • | Interne und externe Kommunikation im Notfall: Wer muss mit wem wann kommunizieren? | ||||||||
| • | Wiederherstellungsverfahren in den Normalbetrieb | ||||||||
| • | Kontaktdaten |
Der grundsätzliche Aufbau ist für BCM- und ITSCM-Pläne identisch. Die Inhalte unterscheiden sich natürlich.
ITSCM-Pläne
Für ITSCM sind die Wiederanlaufprioritäten und -zeiten (RTO) als Ergebnis der Business-Impact-Analyse essenzielle Grundlage für die Planung. Die RTOs der IT Services in Kombination mit den kritischen Terminen geben den Takt für die Wiederherstellung der IT Services vor. In den ITSCM-Plänen wird für die einzelnen IT Services beschrieben, welche Prozeduren und Verfahren von welcher Rolle durchgeführt werden müssen, um den IT Service wiederherzustellen. Teile- und Herstellerverzeichnisse mit den Kontaktdaten und Service Levels der Zulieferer und Dienstleister ergänzen die ITSCM-Pläne.
Für ITSCM sind die Wiederanlaufprioritäten und -zeiten (RTO) als Ergebnis der Business-Impact-Analyse essenzielle Grundlage für die Planung. Die RTOs der IT Services in Kombination mit den kritischen Terminen geben den Takt für die Wiederherstellung der IT Services vor. In den ITSCM-Plänen wird für die einzelnen IT Services beschrieben, welche Prozeduren und Verfahren von welcher Rolle durchgeführt werden müssen, um den IT Service wiederherzustellen. Teile- und Herstellerverzeichnisse mit den Kontaktdaten und Service Levels der Zulieferer und Dienstleister ergänzen die ITSCM-Pläne.
BCM-Pläne
In den BCM-Plänen wird für die kritischen Geschäftsprozesse beschrieben, wie der Notbetrieb hergestellt wird, auf welche Produkte, Services und Kunden im Notbetrieb der Fokus gelegt wird und welche Ressourcen dafür notwendig sind. Die interne mit anderen Fachabteilungen und die externe Kommunikation mit Kunden und Geschäftspartnern ist in den BCM-Plänen ebenfalls beschrieben. Die Wiederanlaufverfahren beschreiben die schrittweise Rückführung in den Normalbetrieb mit den notwendigen Nacharbeiten.
In den BCM-Plänen wird für die kritischen Geschäftsprozesse beschrieben, wie der Notbetrieb hergestellt wird, auf welche Produkte, Services und Kunden im Notbetrieb der Fokus gelegt wird und welche Ressourcen dafür notwendig sind. Die interne mit anderen Fachabteilungen und die externe Kommunikation mit Kunden und Geschäftspartnern ist in den BCM-Plänen ebenfalls beschrieben. Die Wiederanlaufverfahren beschreiben die schrittweise Rückführung in den Normalbetrieb mit den notwendigen Nacharbeiten.
Mehrwert liegt in der Erstellung selbst
Ein großer Mehrwert der Erstellung der BCM-Pläne liegt im Erstellungsprozess selbst. Es findet eine intensive gedankliche Auseinandersetzung mit den Notfallszenarien und den gewählten BCM- und ITSCM-Strategien statt. Das Aufschreiben in BCM-Dokumentationen führt zu einer stärkeren Eindeutigkeit und zu einer Qualitätssicherung der Inhalte. Im Notfall sind vor allem Checklisten notwendig, die eine strukturierte Abarbeitung der Verfahren – vergleichbar mit einem Piloten im Cockpit – erlauben. Der Inhalt der BCM- und ITSCM-Notfallplanung bildet eine wichtige Grundlage für das Design und die Durchführung von Tests und Übungen. Ziel dieser Übungen ist neben der Überprüfung der Planung auf Funktionsfähigkeit die Einübung der Prozeduren als „Drill”. Die Verfahren gehen mit den Übungen in „Fleisch und Blut” über.
Ein großer Mehrwert der Erstellung der BCM-Pläne liegt im Erstellungsprozess selbst. Es findet eine intensive gedankliche Auseinandersetzung mit den Notfallszenarien und den gewählten BCM- und ITSCM-Strategien statt. Das Aufschreiben in BCM-Dokumentationen führt zu einer stärkeren Eindeutigkeit und zu einer Qualitätssicherung der Inhalte. Im Notfall sind vor allem Checklisten notwendig, die eine strukturierte Abarbeitung der Verfahren – vergleichbar mit einem Piloten im Cockpit – erlauben. Der Inhalt der BCM- und ITSCM-Notfallplanung bildet eine wichtige Grundlage für das Design und die Durchführung von Tests und Übungen. Ziel dieser Übungen ist neben der Überprüfung der Planung auf Funktionsfähigkeit die Einübung der Prozeduren als „Drill”. Die Verfahren gehen mit den Übungen in „Fleisch und Blut” über.
3.5 Schulungen, Trainings, Awareness
BCM und ITSCM sind keine „Selbstläufer”. Das Verständnis für die Investitionen in Maßnahmen zur Vorsorge für BCM- und ITSCM-Notfälle muss sowohl im Management als auch bei den Mitarbeitern erst geweckt werden. Das ITSCM hat dabei einen „Start-Vorteil”, da das Management und die Mitarbeiter selbst schon IT-Ausfälle erlebt haben und die Bedeutung der IT für Geschäftsprozesse außer Frage steht. Ganz anders sieht die Awareness für die BCM-Vorsorge aus. Warum für Personalausfälle vorsorgen, wenn die Pandemie doch nicht eintritt. Und wenn, „dann kann man eh nichts mehr tun”. Hier setzt das Thema Schulung, Trainings und Awareness an. Wichtig für die Awareness im Unternehmen ist es, wenigstens ein Mitglied des Topmanagements für das Thema zu gewinnen. Dies erleichtert die praktische Umsetzung im Unternehmen gewaltig. Dann gilt der Grundsatz „Steter Tropfen höhlt den Stein”. Die Implementierung von BCM und ITSCM muss als Change-Prozess im Unternehmen begriffen werden. Entsprechend viel Zeit und Aufwand muss dafür eingerechnet werden. Das Verständnis für die Notwendigkeit dieser Maßnahmen muss oftmals erst geweckt werden. Das Vermitteln von Wissen in Form von Schulungen und Trainings der Beteiligten sowie laufende Informationen über das Vorgehen sowie BCM-relevante Ereignisse im Intranet und in Mitarbeiterzeitschriften helfen dieses Bewusstsein bei den Mitarbeitern zu bilden.
4 CHECK – Überprüfung der Funktionsfähigkeit von BCM und ITSCM
Die Überprüfung der Funktionsfähigkeit des BCM und ITSCM und die Weiterentwicklung sowie Optimierung der Methoden und Verfahren erfolgt in der Check-Phase.
Hilfsmittel
Wesentliche Hilfsmittel zur Überprüfung der Funktionsfähigkeit von BCM und ITSCM sind
Wesentliche Hilfsmittel zur Überprüfung der Funktionsfähigkeit von BCM und ITSCM sind
| • | Tests und Übungen für BCM und ITSCM (s. a. Kap. 01715), |
| • | interne Audits durch BCM und die interne Revision, |
| • | externe Audits durch Wirtschaftsprüfer und Beratungsunternehmen, |
| • | Reifegradmessungen zum Stand des BCM und ITSCM. |
Die Schnittstellen zwischen BCM und ITSCM werden gerade bei der Durchführung von Tests und Übungen besonders deutlich. Wie bereits bei den Ausführungen zur Entwicklung der BCM- und ITSCM-Strategien deutlich wurde, sind beide Disziplinen sowohl in der Prävention als auch in der Bewältigung eng verzahnt und wie siamesische Zwillinge auf das beidseitige Funktionieren angewiesen. In der Strategie- und Planungsphase wird der Grundstein dafür gelegt. Ob die Theorie aber auch in der Praxis funktioniert, kann nur mittels Tests und Übungen überprüft werden. Reine BCM-Übungen greifen dabei genauso zu kurz wie reine IT-Tests.
Kombinierte Übungen
Kombinierte BCM- und ITSCM-Übungen bedeuten, Geschäftsprozesse in die Übung von IT-Szenarien mit einzubinden. Mitarbeiter aus den Fachbereichen testen im Rahmen der Übungen die IT-Verfahren unter realistischen Bedingungen. Wie funktioniert der Remote-Zugriff vieler Mitarbeiter auf die IT-Anwendungen zur gleichen Zeit? Sind Performance und Funktionalität der IT-Anwendungen an der Ausweichlokation auch unter Last gewährleistet? Welche Anforderungen kommen auf den User Help Desk in einem Notbetrieb zu?
Kombinierte BCM- und ITSCM-Übungen bedeuten, Geschäftsprozesse in die Übung von IT-Szenarien mit einzubinden. Mitarbeiter aus den Fachbereichen testen im Rahmen der Übungen die IT-Verfahren unter realistischen Bedingungen. Wie funktioniert der Remote-Zugriff vieler Mitarbeiter auf die IT-Anwendungen zur gleichen Zeit? Sind Performance und Funktionalität der IT-Anwendungen an der Ausweichlokation auch unter Last gewährleistet? Welche Anforderungen kommen auf den User Help Desk in einem Notbetrieb zu?
Auf der anderen Seite sollte die IT bei der Übung von BCM-Szenarien immer beteiligt werden.
Langfristige Planung von Tests und Übungen
Voraussetzung für das Gelingen von übergreifenden Tests und Übungen ist eine langfristige Planung der Tests und Übungen für BCM und ITSCM. Die Zeiträume in der IT für Tests und Übungen sind auf wenige Zeitfenster im Jahr begrenzt. Die Kapazitäten in den Fachbereichen sind durch das Tagesgeschäft, Projekte und Hochlastzeiten ebenso stark begrenzt. Größere übergreifende Tests und Übungen benötigen daher eine Vorlaufzeit von rund einem Jahr. Nur ein übergreifender Test- und Übungskalender mit einer rollierenden Planung über mindestens drei Jahre stellt sicher, dass die wenigen gemeinsam verfügbaren Zeiträume identifiziert und genutzt werden können. Dreijahresplanungen für BCM und ITSCM gehören heute zum Pflichtprogramm in der Prüfung durch Wirtschaftsprüfer und Aufsichtsbehörden.
Voraussetzung für das Gelingen von übergreifenden Tests und Übungen ist eine langfristige Planung der Tests und Übungen für BCM und ITSCM. Die Zeiträume in der IT für Tests und Übungen sind auf wenige Zeitfenster im Jahr begrenzt. Die Kapazitäten in den Fachbereichen sind durch das Tagesgeschäft, Projekte und Hochlastzeiten ebenso stark begrenzt. Größere übergreifende Tests und Übungen benötigen daher eine Vorlaufzeit von rund einem Jahr. Nur ein übergreifender Test- und Übungskalender mit einer rollierenden Planung über mindestens drei Jahre stellt sicher, dass die wenigen gemeinsam verfügbaren Zeiträume identifiziert und genutzt werden können. Dreijahresplanungen für BCM und ITSCM gehören heute zum Pflichtprogramm in der Prüfung durch Wirtschaftsprüfer und Aufsichtsbehörden.
Audits
Neben den Tests und Übungen überprüfen interne und externe Audits die Funktionsfähigkeit von BCM und ITSCM. Bei externen wie auch internen Prüfungen lässt sich eindeutig die Entwicklung feststellen, dass die Prüfungen zunehmend das Zusammenspiel von BCM und ITSCM prüfen.
Neben den Tests und Übungen überprüfen interne und externe Audits die Funktionsfähigkeit von BCM und ITSCM. Bei externen wie auch internen Prüfungen lässt sich eindeutig die Entwicklung feststellen, dass die Prüfungen zunehmend das Zusammenspiel von BCM und ITSCM prüfen.
Prüfpunkte
Zu den Prüfpunkten zählen die hier beschriebenen Schnittstellen zwischen BCM und ITSCM:
Zu den Prüfpunkten zählen die hier beschriebenen Schnittstellen zwischen BCM und ITSCM:
| • | Wurden die Anforderungen aus der Business-Impact-Analyse im ITSCM umgesetzt? |
| • | Wurden die GAPs aus der BIA identifiziert und behoben? |
| • | Sind BCM- und ITSCM-Strategien aufeinander abgestimmt? |
| • | Sind die Pläne von BCM und ITSCM aufeinander abgestimmt und konsistent? |
| • | Werden BCM- und ITSCM-Incidents konsistent in Verfahren bearbeitet? |
| • | Sind BCM und ITSCM Teil einer gemeinsamen übergreifenden Krisenmanagementorganisation? |
| • | Werden die Schnittstellen zwischen BCM und ITSCM durch Tests und Übungen auf Funktionsfähigkeit überprüft? |
| • | Gibt es eine gemeinsame oder zumindest abgestimmte Test- und Übungsplanung über drei Jahre? |
| • | Werden Tests und Übungen gemeinsam durchgeführt, ausgewertet und die Feststellungen abgearbeitet? |
| • | Findet eine laufende Kommunikation zwischen den Verantwortlichen für BCM und ITSCM statt? |
| • | Ist das Berichtswesen von BCM und ITSCM aufeinander abgestimmt? Gibt es ein gemeinsames Berichtswesen? |
| • | Sind ausreichend Ressourcen für BCM und ITSCM vom Management vorgesehen? |
Wenn Sie alle diese Fragen mit „ja” beantworten können, haben Sie eine sehr gute Ausgangsposition für Störungen und Notfälle geschaffen. Ansonsten möchte ich Sie ermutigen, sich auf diesen Weg zu begeben oder auch diesen Weg weiter unbeirrt fortzusetzen. Er ist steil und steinig, doch am Ende lohnt sich diese Investition. Spätestens bei einer/einem erfolgreich bewältigten Störung oder Notfall.
Be prepared
Quellen
1
ISO/IEC 27001:2013 – Information technology – Security techniques – Information security managementsystems – Requirements
2
BSI 100-4 Notfall-Management,www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzStandards/ITGrundschutzStandards_node.html
3
ISO 22301:2012 – Societal security – Business continuity management systems – Requirements
