ISO 27001 & BS 25999

Ist es Ihnen schon passiert, dass Ihr Management Ihnen die Verantwortung für Umsetzung des betrieblichen Kontinuitätsmanagements übertragen hat, nur weil Sie in der IT-Abteilung arbeiten? Warum wird betriebliches Kontinuitätsmanagement in der Regel mit Informationstechnologie in Verbindung gebracht?

Das liegt wahrscheinlich daran, dass betriebliches Kontinuitätsmanagement aus dem ‚Disaster Recovery‘ (DR) entstanden ist, und Disaster Recovery im Grunde auf Informationstechnologie basiert. Vor 20 oder 30 Jahren gab es das betriebliche Kontinuitätsmanagement als Konzept noch nicht, dafür aber Disaster Recovery (DR) – das Hauptanliegen war, im Falle einer Katastrophe die Daten zu retten. Damals war es sehr beliebt, teure Geräte zu kaufen und an einem entfernten Ort aufzustellen, so dass alle wichtigen Daten eines Unternehmens zum Beispiel im Falle eines Erdbebens erhalten blieben. Nicht nur erhalten, sondern auch, dass die Daten mit mehr oder weniger der gleichen Kapazität verarbeitet würden, als ob sie sich am Hauptstandort befunden hätten.

Nach einer Weile wurde jedoch klar – was würde mit den Daten gemacht werden können, falls es keine Geschäftstätigkeit mehr gäbe, um diese Daten zu nutzen? So wurde die Idee des betrieblichen Kontinuitätsmanagements geboren – sein Zweck bestand darin, den fortlaufenden Betrieb des Unternehmens selbst im Falle eines größeren Vorfalls zu ermöglichen.

Definitionen

Werfen wir einen Blick auf die Definitionen – betriebliches Kontinuitätsmanagement ist die „strategische und taktische Fähigkeit des Unternehmens, für Vorfälle Störungen des Geschäftsbetriebs zu planen und auf diese zu reagieren, um betriebliche Abläufe auf einem vorab definierten akzeptablen Niveau weiterzuführen“ (BS 25999-2:2007), während die Wiederherstellung im Notfall die „Prozesse, Leitlinien und Verfahren für die Wiederherstellung oder Fortsetzung der kritischen technologischen Infrastruktur eines Unternehmens nach einer natürlichen oder vom Menschen verursachten Katastrophe“ umfasst (englischsprachige Wikipedia).

Wie Sie den Definitionen entnehmen können, liegt der Schwerpunkt in der DR auf der Technologie, während es im BC vor allem um den Geschäftsbetrieb geht. Daher ist Disaster Recovery Teil des betrieblichen Kontinuitätsmanagements. Sie können DR als einen der wichtigsten Faktoren des Geschäftsbetriebs oder als den technologischen Teil des betrieblichen Kontinuitätsmanagements betrachten.

Vielleicht haben Sie auch etwas anderes bemerkt: Die Definition des BC entstammt der BS 25999-2, der führenden Norm für betriebliches Kontinuitätsmanagement, während die Definition von DR aus der Wikipedia zitiert wird. Eigentlich ist „Betriebliches Kontinuitätsmanagement“ eine offizielle, in Normen anerkannte Bezeichnung, „Disaster Recovery“ ist es dagegen nicht.

Auswirkungen auf Umsetzung

Warum ist es eine schlechte Idee, dass die IT-Abteilung das betriebliche Kontinuitätsmanagement für das gesamte Unternehmen umsetzt? Weil betriebliches Kontinuitätsmanagement vor allem ein Thema für das Unternehmen und kein IT-Problem ist. Falls die IT-Abteilung betriebliches Kontinuitätsmanagement für das gesamte Unternehmen umsetzt, so könnte sie weder die kritische Bedeutung der Geschäftstätigkeit noch die Wichtigkeit von Informationen zu definieren. Außerdem steht infrage, ob die IT-Abteilung das Engagement der geschäftlichen Unternehmensteile erreichen würde.

Der beste Weg, um betriebliches Kontinuitätsmanagement umzusetzen und zu organisieren, besteht darin, dass der geschäftliche Teil des Unternehmens ein solches Projekt leitet – so werden ein größeres Bewusstsein und stärkere Akzeptanz aller Unternehmensteile erreicht. Die IT-Abteilung sollte natürlich ihre Rolle in einem solchen Projekt – eine entscheidende Rolle – wahrnehmen, um Disaster Notfallpläne vorzubereiten.

Sie können sich auch unser Webinar BS 25999-2 Foundations Part 1: Business Impact Analysis ansehen (kommerzielles Training).

Wenn Sie mit der Umsetzung des betrieblichen Kontinuitätsmanagements begonnen haben, so besteht die größte Herausforderung darin, die Pläne für das betriebliche Kontinuitätsmanagement zu verfassen.

Warum ist es so schwierig? Sie müssen sich verschiedene Szenarien vorstellen, unter denen eine Katastrophe (oder eine andere Störung der Geschäftstätigkeit) auftreten kann. Sie müssen über eine Möglichkeit nachdenken, wie diese außerordentlich seltenen, aber möglicherweise katastrophalen Vorfälle bewältigt werden können.

Ein häufiges Problem beim Verfassen dieser Pläne ist die Frage, was der Plan enthalten sollte (was sind die wichtigsten Elemente), wie lange (wie detailliert) er sein sollte, welche Schritte dazugehören usw.

Eine der besten Lösungen dieser schwierigen Probleme ist die Verwendung der Norm BS 25999-2, die zusammen mit BS 25999-1 einen Rahmen für das Schreiben dieser Pläne vorgibt.

Gemäß diesen Normen sollten die Pläne für betriebliches Kontinuitätsmanagement aus einem (1) Störfallreaktionsplan sowie (2) Wiederherstellungsplänen bestehen. Ein Störfallreaktionsplan ist in der Regel ein einzelner Plan für das gesamte Unternehmen, in dem beschrieben wird, was unmittelbar nach einer Katastrophe getan werden muss – um die Auswirkungen des Vorfalls einzudämmen, mit den Notdiensten zu kommunizieren, das Gebäude zu evakuieren, an Sammelstellen zusammenzukommen, den Transport zu alternativen Standorten zu organisieren usw.

Notfallpläne werden in der Regel separat für jede kritische Tätigkeit geschrieben. Die Schritte eines Notfallplans sehen in der Regel wie folgt aus: wann und wie mit verschiedenen Beteiligten kommuniziert wird (Mitarbeiter und deren Familien, Aktionäre, Kunden, Partner, Behörden, öffentliche Medien usw.), wie ein Team zusammengestellt wird, wie die Infrastruktur wiederhergestellt wird, wie geprüft wird, ob die Anwendungen funktionieren und ob die Zugriffsrechte angemessen sind, wie überprüft wird, welche Daten fehlen oder durch die Katastrophe beschädigt wurden, wie die Daten wiederhergestellt werden und wie entschieden wird, wann die Wiederherstellung abgeschlossen ist, damit der normale Betrieb wieder einsetzen kann.

IT-Notfallpläne (Notfallpläne der IKT-Infrastruktur) müssen mit großer Sorgfalt verfasst werden, weil sie beschreiben sollten, wie jedes System innerhalb des Recovery Time Objective einer bestimmten kritischen Tätigkeit eingestellt werden sollte. Dies geschieht normalerweise durch Verfassen eines detaillierten Wiederherstellungsplans für jedes System, das wiederhergestellt werden soll.

Die Faustregel besagt, dass sämtliche dieser Pläne so detailliert sein sollten, dass andere Mitarbeiter (oder externes Personal) in der Lage sind, den Plan auszuführen, falls die Mitarbeiter dieser kritischen Aktivität nicht verfügbar sind. Schreiben Sie diese Pläne also mit Vernunft – sie sollten für jeden verständlich sein, nicht nur für Sie.

Nach meiner Erfahrung besteht die größte Herausforderung beim Verfassen dieser Pläne darin, dass Mitarbeiter mit etwas ganz anderem konfrontiert werden, über das sie vorher nicht nachzudenken brauchten. Zur Überwindung solcher Probleme ist es am besten, einen Workshop mit oder ohne Moderator zu organisieren, in dem sich die Mitarbeiter austauschen können, was passieren würde, wenn … wie man reagiert, wenn … usw.

Tatsächlich ist mit dem Umstand, dass Ihre Mitarbeiter damit begonnen haben, über betriebliches Kontinuitätsmanagement nachzudenken, bereits die halbe Arbeit geleistet – mit einem solchen Ansatz wird ein viel besserer Plan für betriebliches Kontinuitätsmanagement ermöglicht.

Sie können sich auch unser Webinar BS 25999-2 Foundations Part 3: Business Continuity Planning ansehen (kommerzielles Training).