Die Festlegung des Geltungsbereichs ist keine triviale Fragestellung. Wenn man sich erst auf einen Geltungsbereich festgelegt und mit der Planung oder Implementierung des BCMS begonnen hat, ist eine spätere Modifikation schwierig bis unmöglich. Der Geltungsbereich muss deshalb in enger Zusammenarbeit mit der Leitungsebene erstellt und von dieser abgesegnet werden.

Die folgenden Überlegungen sollten bei der Definition des Geltungsbereichs berücksichtigt werden.

Andere Managementsysteme
Wenn es schon ein anderes funktionierendes Managementsystem gibt, kann man bei den BCMS-Überlegungen mit dessen Geltungsbereich starten. Stellt man später bei der Zusammenstellung der für BCM kritischen Geschäftsprozesse fest, dass diese nicht alle enthalten sind, wird der Geltungsbereich entsprechend erweitert.

BCMS und ISMS
Es muss berücksichtigt werden, dass das Notfallmanagement für Informationen und IT-Systeme bereits Bestandteil eines ISMS ist. Es ist daher wichtig, beim allgemeinen Notfallmanagement auch die Geschäftsprozesse zu betrachten, die nichts oder nur wenig mit Informationen und/oder IT-Systemen zu tun haben.

Notfallszenarien
Zur Erleichterung dieser Betrachtung sollten einige Notfallszenarien durchgespielt werden. Dabei wird ermittelt, welche Szenarien sich wie auf die Fortführung des Geschäftsbetriebs auswirken. Betrachtet werden in der Regel die Szenarien

Je nach Geschäftsmodell kann es sinnvoll sein, weitere Szenarien in die Überlegungen einzubeziehen.

Produkte und Dienstleistungen zur Wertschöpfung
Es ist sinnvoll, sich zunächst nur auf die wirklich kritischen Geschäftsprozesse zu beschränken und diese in den Geltungsbereich aufzunehmen. Dabei sollte von den Produkten und Dienstleistungen ausgegangen werden, mit denen die eigene Organisation ihre Wertschöpfung betreibt. Die damit zusammenhängenden Prozesse gehören in jedem Fall in den Geltungsbereich.

Beispiel: Eine Onlinebank bietet als Produkt ein Girokonto an. Dieses lässt sich in drei Top-Level-Prozesse aufteilen:

In dieser frühen Phase der BCMS-Entwicklung sollten die Geschäftsprozesse nur ganz grob modelliert werden. Mehr ins Detail wird dann später in der BIA gegangen.

Die Fragestellung lautet dabei: Wenn ein Geschäftsprozess x ausfällt, welche Auswirkungen hat das auf die Funktionsfähigkeit unserer Organisation?

Folgen eines Prozessausfalls
Ein solcher Prozessausfall kann verschiedene Folgen haben:

Je nach dem Zweck der Organisation können noch andere Kategorien hinzukommen, etwa die körperliche Unversehrtheit von Mitarbeitern oder Kunden.

Einsatz der ISO 31000
Organisationen, die schon ein Risikomanagement (etwa nach ISO 31000) aufgebaut haben, können die dort definierten Risikokategorien auch für BCM übernehmen. Auch spezifische für die IT-Sicherheit nach ISO 27005 aufgesetzte Risikokategorien können berücksichtigt werden.

Wie detailliert diese Modellierung sein muss, hängt von der Komplexität der Geschäftsprozesse ab. Als Faustformel gilt dabei, mit der Modellierung spätestens dann aufzuhören, wenn der betrachtete Teilprozess innerhalb einer einzelnen Anwendung oder in einem einzelnen IT-System abgebildet wird.

Beispiel
Als Beispiel soll wieder das Online-Girokonto dienen.

Der Prozess „Eröffnung des Kontos” lässt sich in fünf Teilprozesse aufteilen:

Diese Teilprozesse lassen sich prinzipiell noch weiter untergliedern. Das ist aber nur dann sinnvoll, wenn unterschiedliche Assets und/oder IT-Systeme innerhalb eines Teilprozesses involviert sind.

Im vorliegenden Beispiel endet die Modellierung bei den fünf Teilprozessen.

Übernahmen aus anderen Managementsystemen
Falls vor der Einführung des BCMS schon andere Managementsysteme implementiert wurden, kann die dort gemachte Prozessmodellierung übernommen werden.

Es muss allerdings sorgfältig überprüft werden, ob die bei den anderen Managementsystemen vorgenommene Modellierung für das Notfallmanagement geeignet ist. Bei einer Prozessmodellierung für ein ISMS ist das in der Regel gegeben, da auch dort die Zuordnung von Teilprozessen zu Assets und IT-Systemen im Vordergrund steht. Bei einem Qualitätsmanagementsystem nach ISO 9001 ist das nicht automatisch gegeben.

Maximale Ausfallzeit eines Prozesses
Als Maximum Tolerable Period of Disruption (MTPD) wird die maximal tolerierbare Ausfallzeit eines Prozesses bezeichnet. Die MTPD wird für Produkte und/oder Geschäftsprozesse ermittelt. Wenn ein Prozess ausfällt und nicht nach Ablauf der MTPD wieder hochgefahren ist, erleidet das Unternehmen einen bestandsgefährdenden Schaden. Die MTPD wird über eine BIA ermittelt und/oder von der Geschäftsleitung vorgegeben.

Geforderte Wiederanlaufzeit
Als Recovery Time Objective (RTO) wird die zeitliche Anforderung für den Wiederanlauf von Prozessen und den mit diesen verbundenen Ressourcen bezeichnet (geforderte Wiederanlaufzeit). Das RTO wird immer im Rahmen einer BIA ermittelt.

Es ist offensichtlich, dass RTO immer kleiner oder gleich MTPD sein muss. In der Regel ist RTO aber kleiner als MTPD, da

Das erforderliche Feintuning kann erst nach Abschluss der BIA beim Aufstellen des Wiederanlaufplans vorgenommen werden. Dann werden die diversen Zeiten zum Hochfahren der Ressourcen berücksichtigt und kontrolliert, ob die MTPD überschritten wird.

Fällt ein Geschäftsprozess aus, gehen in der Regel Daten verloren, was am Beispiel von Onlinebanking verdeutlicht werden kann. Angenommen, es sind 200 Kunden aktuell im Onlinebanking angemeldet und der Onlinebankingprozess fällt aus. Damit sind die von den Kunden gerade bearbeiteten Transaktionen in einem unsauberen, nicht definierten Zustand. Wenn der Prozess wieder hochgefahren wird, muss auf einem sauberen Datenbestand aufgesetzt werden. In der Regel müssen die 200 Kunden ihre Transaktionen neu erfassen. Im Worst Case sind aber auch weiter zurückliegende Transaktionen betroffen, da auch deren Daten ganz oder teilweise verloren gegangen sind.

Maximal zulässiger Datenverlust
Als Recovery Point Objective (RPO) wird die Zeitspanne bezeichnet, in der der Verlust an Daten bei einem Prozessausfall noch tolerabel ist. RPO ist damit eine Vorgabe an die IT, wie häufig die Daten zu sichern sind.

Wenn beim Beispiel des Onlinebankings die Daten z. B. jede Minute gesichert oder auf ein anderes System gespiegelt werden, dürften außer bei den 200 vom direkten Prozessausfall betroffenen Kunden keine weiteren Transaktionen betroffen sein.

Liegt die letzte Datensicherung aber eine Stunde zurück, sind mit Sicherheit Tausende andere Transaktionen betroffen, die im System zurückgesetzt und damit (von den Kunden) neu erfasst werden müssen.

RPO wird innerhalb der BIA ermittelt.

Nutzung einer CMDB sinnvoll
Die BIA muss für alle Prozesse und Assets nach einer identischen Vorgehensweise durchgeführt werden. In der Regel wird die Erstellung der BIA von einem Tool unterstützt. Im Idealfall steht eine Configuration Management Database (CMDB) zur Verfügung, in der alle Assets schon erfasst und die Bewertungskriterien hinterlegt sind. Dann kann sich der Asset Owner am hinterlegten Workflow orientieren, sodass wenige Fehler passieren und die BIA-Ergebnisse der einzelnen Ressourcen vergleichbar sind.

Zudem sollten in der CMDB hinterlegt sein:

Natürlich kann eine BIA auch per Excel-Tabelle durchgeführt werden. In diesem Fall ist es empfehlenswert, über Makros den Asset Owner durch den BIA-Prozess zu leiten.

Folgende Bewertungskriterien sollten für die BIA definiert werden:

Verlauf des Schadens über die Zeit
Für jeden Schadenstyp wird der Verlauf des Schadens bei Ausfall eines Prozesses für alle betroffenen Assets durchdacht. Zu einem bestimmten Zeitpunkt erreicht oder überschreitet der Schaden die maximal tolerierbare Schadenshöhe. Damit ist ein Teil-RTO für den jeweiligen Schadenstyp bestimmt.

Zeitintervalle
Das soll mit einem Beispiel verdeutlich werden. Die Zeitintervalle in den folgenden Abbildungen sind zu

P1: 0–4 Stunden

P2: 4–8 Stunden

P3: 8–24 Stunden

P4: > 24 Stunden

gewählt. Dann ermittelt der Asset Owner etwa

RTOfinanz ergibt sich zu P4 = 24 Stunden (s. Abbildung 1).

RTOReputation ergibt sich zu P3 = 8 Stunden (s. Abbildung 2).

RTOKunde ergibt sich zu P4 = 24 Stunden (s. Abbildung 3).

Der RTOCompliance ist für diesen Prozess nicht relevant, da die maximal tolerierbare Schadenshöhe nie erreicht wird (s. Abbildung 4).

Berechnung des Gesamt-RTO
Der Gesamt-RTO für dieses Asset ergibt sich aus dem kleinsten Teil-RTO. Dieser ist der RTOReputation mit acht Stunden.

Nachdem die RTOs von allen Assets berechnet wurden, müssen die Abhängigkeiten der Teilprozesse untereinander betrachtet und die RTOs ggf. korrigiert werden. Dazu werden die Uptream- und Downstream-Assets innerhalb der Prozesskette betrachtet und auf Engpässe hin untersucht.

Wenn beispielsweise die Teilprozesse TP1, TP2 und TP3 mit ihren Assets nacheinander einen Geschäftsprozess abbilden und RTOTP1 und RTOTP3 jeweils eine Stunde ist, RTOTP2 jedoch zwei Stunden, muss RTOTP2 auf eine Stunde korrigiert werden.

Sicherheitspuffer einplanen
Für den Fall, dass der MTPD nicht von der Geschäftsleitung vorgegeben wurde, lässt er sich aus dem Maximum der korrigierten RTOs sowie einem Sicherheitspuffer berechnen.

MTPD = max(RTOTPx) + Sicherheitspuffer

Es gibt noch einen weitergehenden Ansatz zur Analyse von Prozessen, bei dem sogenannte Kritikalitätsstufen berechnet werden. Das Modell zur Berechnung der RTOs macht lediglich eine Aussage darüber, nach welcher Zeit der Prozess wieder laufen muss. Es wird kein Unterschied gemacht, ob dieses RTO lediglich von einem Schadensdtyp ausgelöst wurde oder ob nicht vielleicht alle Schadenstypen ihren kritischen Wert erreicht haben.

Schadenstypen zusammenfassen
Bei der Berechnung der Kritikalitätsstufen werden alle Schadenstypen zu einem Gesamtschaden zusammenfasst und der Verlauf des Gesamtschadens wird betrachtet.

Dazu werden Wichtungsfaktoren für die Schadensszenarien vergeben (je nach Priorität der Organisation) und die Schäden bei Ausfall des Prozesses direkt mit den Wichtungsfaktoren multipliziert und zu einem Gesamtschaden aufaddiert.

Wichtungsfaktoren
In unserem Beispiel werden folgende Wichtungsfaktoren vergeben:

Finanzieller Schaden = 2

Reputationsverlust = 1

Kundennutzen = 3

Compliance = 3

Dann ergibt sich aus den Schadensverläufen in den Abbildungen 1 bis 4 ein gewichteter Gesamtschadensverlauf wie in Tabelle 1 angegeben.

Priorisierung des Wiederanlaufs
Dieser Schaden kann im Beispiel maximal einen Wert von 27 annehmen, die Kritikalität des Assets ist also 27. Die Kritikalität ist ein Hinweis darauf, welche Assets mit ihren Ressourcen bei einem Notfall zuerst anlaufen sollen und welche ggf. warten müssen.

Anmerkung
Die Berechnung der Kritikalität ist optional, viele BCMS kommen ohne diese Kenngröße aus.

Die zweite wichtige Kenngröße, der maximal erlaubte Datenverlust, muss ebenfalls vom Asset Owner ermittelt werden. Das geschieht durch eine Abschätzung, eine mathematische Formel zur Berechnung des RPO gibt es nicht.

Auswirkungen eine Datenverlusts
Bei der Abschätzung wird überlegt, welche Auswirkungen ein Datenverlust auf den Neustart eines Prozesses hat. Dabei sollten folgende Fragen berücksichtigt werden:

RPO-Klassen
Es ist sinnvoll, für den RPO vordefinierte Klassen zu definieren, die der Asset Owner dann nutzen kann. Beispiel:

RPO1: 1 Stunde

RPO2: 4 Stunden

RPO3: 8 Stunden

RPO4: 24 Stunden

Reale Wiederanlaufzeit
Dazu muss für jede am Prozess beteiligte Ressource eine reale Wiederanlaufzeit (WAZ) ermittelt werden. Das ist Aufgabe der Asset Owner, vor allem aber der System Owner der beteiligten IT-Systeme.

Zunächst wird für jede Ressource eine eigene Wiederanlaufzeit abgeschätzt. Diese ist die maximale Zeit, die für das Hochfahren dieser Ressource benötigt wird, sofern alle Voraussetzungen für das Hochfahren erfüllt sind.

Beispiel
Das soll am Beispiel einer Webanwendung erläutert werden. Die Anwendung benötigt einen Webserver, einen Applikationsserver, eine Datenbank, Netzwerkverbindungen sowie eine Stromversorgung (eine USV ist nicht vorhanden). Als WAZ für die Ressourcen wurde abgeschätzt:

Abhängigkeiten von Ressourcen
Da die Ressourcen teilweise voneinander abhängen, lässt sich die Gesamt-WAZ erst über einen (vorläufigen) Wiederanlaufplan ermitteln:

Insgesamt ergibt sich so eine WAZ von sieben Stunden und 15 Minuten.

WAZ mit RTO und MPTD abgleichen
Die ermittelten realen Wiederanlaufzeigen (WAZ) müssen in einem weiteren Schritt mit den geforderten Wiederanlaufzeigen (RTO) und letztlich auch mit den MTPD abgeglichen werden. Wenn die WAZ kleiner als die RTO ist, ist alles in Ordnung.

WAZ-Verkleinerung
Falls die WAZ aber größer als die RTO ist, müssen Maßnahmen getroffen werden. Ansonsten sind bei Prozessausfall Probleme vorprogrammiert. Im Fall der Webanwendung ist der Engpass die Stromversorgung, da keine USV vorhanden ist. Mit einer ausreichend dimensionierten USV ist die WAZ um volle vier Stunden kürzer, da Hard- und Software ohne Verzögerung neu aufgesetzt werden können.

Wenn aber die WAZ von drei Stunden noch immer zu groß ist, muss über weitergehende Maßnahmen nachgedacht werden. Das können etwa sein:

Restrisiken werden getragen
Die Vorsorgemaßnahmen müssen so ausgelegt sein, dass alle RTOs bzw. MTPDs unter Berücksichtigung eines verbleibenden, von der Führungsebene zu tragenden Restrisikos eingehalten werden.

Aus den bei der Ermittlung der WAZ erstellten vorläufigen Wiederanlaufplänen sowie eventuellen Korrekturen durch Maßnahmen zur Notfallvorsorge werden nun für alle Ressourcen eines Geschäftsprozesses die finalen Wiederanlaufpläne erstellt.

Zeitliche Reihenfolge und Anleitungen
Diese enthalten neben der zeitlichen Reihenfolge des Hochfahrens von Ressourcen auch Anleitungen, wie die einzelnen Ressourcen wieder an den Start gebracht werden. Dabei müssen diese Anleitungen nicht zu detailliert sein. System Owner oder deren Vertretung kennen die betroffenen Ressourcen in der Regel gut, sodass in einer Anleitung nur die wesentlichen Schritte zur Wiederherstellung beschrieben werden müssen.

Referenzdokument
Die Wiederanlaufpläne müssen dokumentiert werden, da sie ein Referenzdokument des BCMS sind.

Notbetrieb erforderlich?
Bei der Entwicklung der BCM-Strategie muss zunächst geklärt werden, für welche Prozesse ein Notbetrieb mit eingeschränkten Ressourcen möglich ist. Das ist beispielsweise bei Webservices denkbar. Beim Betrieb mit eingeschränkten Ressourcen ist die Verarbeitung dann langsamer als im Normalbetrieb.

Ist ein Notbetrieb vorgesehen, muss dessen Niveau definiert werden. Die im Folgenden beschriebenen Notfallmaßnahmen werden dann für den Notbetrieb und den später folgenden Normalbetrieb ermittelt.

Maßnahmen zur Wiederherstellung
Notfallmaßnahmen beschreiben die Tätigkeiten, die im Fall eines Ausfalls durchgeführt werden müssen, also etwa

Anmerkung
Bei redundanten Systemen muss unterschieden werden zwischen wirklich vollständig redundanten Systemen (mehrfache Kapazität dauerhaft im Betrieb) und redundanten Systemen mit Lastverteilung, bei denen aber nicht jedes Teilsystem die gesamte Betriebslast alleine verarbeiten kann. Dann bedarf es zusätzlicher Maßnahmen zur Priorisierung, falls ein Ast des redundanten Aufbaus ausfällt.

Kostenbetrachtung
Neben der reinen Aufstellung der Maßnahmen müssen diese auch bewertet werden, ob sie ihren Zweck erfüllen und die Kosten in einem vertretbaren Rahmen bleiben.

Um eine vorgegebene MTPD zu erreichen, können in der Regel mehrere unterschiedliche Maßnahmen ergriffen werden. So können etwa Prozesse an einen Remote-Standort oder an einen Dienstleister ausgelagert werden. Von der Bewertung hängt es ab, welche Maßnahmen konkret ergriffen werden.

Bewertungskriterien
Folgende Bewertungskriterien haben sich in der Praxis als sinnvoll erwiesen:

Aufgaben
Die Aufgaben der strategischen Ebene lassen sich wie folgt zusammenfassen:

Die Führungsebene einer Organisation hat beim BCMS folgende Funktionen:

Notfallvorsorge
Das Thema BCMS ist wie andere Managementsysteme eine Führungsaufgabe. Die oberste Ebene muss die mit BCM verbundenen Prozesse initiieren und mit Ressourcen unterstützen. Zudem gibt sie die Ziele des Notfallmanagements vor und ist verantwortlich für Vorgaben in der BCM-Strategie.

Notfallbewältigung
Das Krisenentscheidungsgremium trifft in einem Notfall strategische Entscheidungen, die längerfristige Auswirkungen auf das Unternehmen haben. Das kann etwa die Aufgabe von Geschäftsprozessen sein, wenn diese in einem Notfall nicht wieder aufgesetzt werden können. Die Entscheidungen dieses Gremiums werden risikoorientiert getroffen. Die für die Entscheidung nötigen Grundlagen werden aber nicht vom Krisenentscheidungsgremium, sondern vom Krisenstab (auf der taktischen Ebene) geschaffen.

Aufgaben
Die Aufgaben der taktischen Ebene lassen sich wie folgt zusammenfassen:

Notfallvorsorge
Bei der Notfallvorsorge sind die Rollen des Notfallbeauftragten sowie der Notfallkoordinatoren sinnvoll. In kleineren Organisationen sind die Koordinatoren allerdings nicht nötig, dort werden deren Aufgaben vom Notfallbeauftragten übernommen.

Die Rollen lassen sich wie folgt beschreiben:

Notfallbewältigung
Ist ein Notfall eingetreten, werden die Aufgaben auf der taktischen Ebene der Notfallbewältigung durch den Krisenstab geleistet. Dieses Gremium ist die zentrale Einheit bei der Notfallbewältigung. Alle Aktivitäten der Notfallbewältigung werden vom Krisenstab aus angestoßen, koordiniert und überwacht.

Mitglieder des Krisenstabs
Mitglieder des Krisenstabs können sein:

Anmerkung
Der Begriff „Krisenstab” ist etwas missverständlich formuliert. Eine Krise ist von der Definition her ein Ereignis, das dann eintritt, wenn die Notfallpläne versagen. Ein Krisenstab tagt aber auch bei Notfällen.

In der operativen Ebene werden die in der taktischen Ebene gemachten Konzepte und Entscheidungen umgesetzt.

Notfallvorsorge
Die Notfallvorsorgeteams setzen die Notfallvorsorgemaßnahmen um, wie von der taktischen Ebene vorgegeben.

Notfallbewältigung
Die Notfallteams kümmern sich vor Ort darum, die ausgefallenen Prozesse und Systeme gemäß den Wiederanlaufplänen und ggf. Entscheidungen der taktischen Ebene wieder hochzufahren.