03910 Business Continuity Management

BCMS
Es ist sinnvoll, das Thema BCM nach einem etablierten Standard anzugehen, beispielsweise nach der ISO 22301. Dazu wird, ganz analog etwa zu einem Information Security Management System (ISMS) nach ISO 27001, ein risikoorientiertes Business Continuity Management System (BCMS) aufgebaut. Wer schon ein anderes Managementsystem (Qualität, Informationssicherheit) eingeführt hat, kann dabei Synergieeffekte nutzen, denn einige grundsätzliche Arbeiten wie etwa die Aufstellung der kritischen Geschäftsprozesse oder die Klassifizierung von Risiken müssen nur einmal erledigt werden.

BCMS als Führungsaufgabe
Wie jedes Managementsystem muss auch ein BCMS in der Führungsebene der Organisation verankert sein. Nur so können die erforderlichen Ressourcen zu Aufbau und Betrieb des BCMS bereitgestellt und kann für die Kompetenz der mit dem BCMS befassten Mitarbeiter gesorgt werden.

BCM-Beauftragter
Die Einführung von BCM sollte als ganz normales Projekt angegangen werden, d. h., es ist ein Verantwortlicher zu benennen (etwa ein BCM-Beauftragter), der entsprechende Kompetenzen, ein Budget sowie Zugriff auf interne oder externe Mitarbeiter hat.

Dabei ist zu beachten, dass bei einem BCM-Projekt in der Regel viele Personen beteiligt sind. Insbesondere ist die Business Impact Analysis (BIA), bei der der Verlauf eines Schadens über die Zeit bei Ausfall eines Prozesses bestimmt wird, eine dezentrale Aufgabe.

Asset Owner
Für jeden Prozess bzw. für jede Anwendung, mit der ein Prozess modelliert wird, gibt es einen verantwortlichen Asset Owner. Dieser kennt sein Asset so gut, dass er die mit BCM verbundenen Überlegungen etwa zum Schaden oder zum maximal vertretbaren Datenverlust bei Ausfall treffen kann. Der Asset Owner ist in der Regel ein Mitarbeiter aus dem Business, der die geschäftlichen Auswirkungen seines Assets abschätzen kann, aber nicht über fundierte IT-Kenntnisse verfügt.

System Owner
Sofern ein Asset mittels IT unterstützt wird, benötigt der Asset Owner Unterstützung seitens der IT. Dazu wird ihm ein System Owner (auch Asset Manager oder IT Custodian genannt) zu Seite gestellt, der Fragestellungen zur IT dieses Assets bearbeiten kann (etwa Wiederanlaufpläne). In der Regel ist der System Owner die Person, die für die Administration der für das Asset benötigten IT-Systeme zuständig ist.

Asset Owner und System Owner der an kritischen Geschäftsprozessen beteiligten Assets sind also in jedem Fall beim BCM-Projekt involviert. In der Summe können da erhebliche Aufwände entstehen, die in die BCM-Projektplanung einzubeziehen sind.

Der Geltungsbereich, auch Anwendungsbereich oder Scope genannt, umfasst alle Prozesse, Anwendungen und Systeme, für die das BCMS gelten soll. Bei der Definition des Geltungsbereichs sind auch die Schnittstellen nach außen zu benennen, die aus Sicht des BCMS wie Kunden-/Lieferantenverhältnisse zu betrachten sind.

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.

In dieser ersten Phase der Entwicklung eines BCMS fallen einige Referenzdokumente an, entsprechend dem Standard, nach dem gearbeitet wird. Ein Referenzdokument ist ein Dokument, das verpflichtend zu erstellen ist, um dem jeweils genutzten Standard zu genügen.