IT-Notfallvorsorge
Die IT-Notfallvorsorge ist die Disziplin des Managements der Informationsverarbeitung (IT) in einem Unternehmen, die Notfallpläne entwickelt und pflegt. Diese Pläne werden benötigt, wenn es infolge eines Störfalls zu einem Ausfall kritischer IT Services kommt. Sie beschreiben den gesamten notwendigen Weg bis hin zum Wiederanlauf dieser Services, einschließlich Erfassung der Gesamtproblemsituation, Etablierung von Workarounds, Alarmierungen, Personalmanagement für die Notfalllage, Einrichtung eines Notbetriebs, Wiederbeschaffung verloren gegangener Komponenten. Am Schluss sind alle IT Services vollständig wiederhergestellt.

Vorsorgemaßnahmen wirken begrenzt
Mit präventiv wirkenden Maßnahmen zur Notfallvorsorge, zum Beispiel Redundanz von Rechenzentren und Systemen oder Backup von Daten, sollen Serviceausfälle verhindert werden, aber das ist nur begrenzt möglich. Wenn es trotz solcher Maßnahmen zu einem Serviceausfall kommt, muss die IT in der Lage sein, den Wiederanlauf in ausreichender Zeit durchzuführen, nämlich ehe der Ausfall zu einem kritischen Schaden führt. Das wird nicht gelingen, wenn der Wiederanlauf bzw. Wiederaufbau kompliziert ist, es sei denn, die IT hat sich im Voraus eine erfolgversprechende Strategie (Notfallplan bzw. Disaster Recovery Plan) überlegt und in Form eines Notfallhandbuchs dokumentiert. Außerdem wurden die nötigen Mittel zur Umsetzung der Strategie, zum Beispiel Ersatzteile, beschafft. Mit IT-Notfallvorsorge ist genau das gemeint.

Begriff
Der Begriff IT-Notfallvorsorge ist wie viele Fachbegriffe der IT nicht eindeutig. Alternativ werden oft Begriffe wie IT Continuity, IT Service Continuity, Disaster Recovery und viele andere meist englische Begriffe, mal mit, mal ohne Zusatz des Begriffs Management, benutzt. In diesem Beitrag wird immer von IT-Notfallvorsorge die Rede sein. Damit wird auch betont, dass es um die Services der IT geht.

BCM
IT-Notfallmanagement ist ein Spezialfall des allgemeinen, übergeordneten Begriffs Business Continuity Management (BCM). BCM (siehe auch Kap. 01710) adressiert die kritischen Geschäftsprozesse und mögliche Auswirkungen, wenn diese ausfallen. Dabei geht BCM von verschiedenen Szenarien aus, von denen eines der Ausfall der IT ist. Geschäftsprozesse werden heutzutage fast immer mittels IT abgebildet oder von dieser unterstützt, so dass IT-Notfallmanagement ein wichtiger Block innerhalb von BCM ist.

IT-Notfallvorsorge ist eine sehr komplexe Aufgabe. Sie besteht aus vielen Teildisziplinen, die jeweils ganz unterschiedliche Arbeitsergebnisse liefern sollen. BCM-Standards wie ISO 22301 [1] (s. a. Kap. 07342) bemühen sich, Aufgaben und Resultate der IT-Notfallvorsorge innerhalb des allgemeinen Notfallmanagements zu definieren und zu vereinheitlichen, doch es ist das Wesen von Standards, eher zu sagen, was gemacht werden muss als wie. Dieser Beitrag will dieses Problem nicht lösen. Es wird zum Beispiel nur sehr grob beschrieben, wie ein Notfallhandbuch aussehen sollte, und Gleiches gilt auch für andere wichtige Arbeiten der IT-Notfallvorsorge und deren Resultate, etwa die Durchführung von Risikoanalysen. Stattdessen wird der Frage nachgegangen, wie ein Unternehmen mit einfachen Mitteln und wenig Arbeitsaufwand über alle Einzelaufgaben der IT-Notfallvorsorge hinweg die Übersicht behalten kann. Durch das Controlling der IT-Notfallvorsorge soll bekannt sein, was benötigt wird, was vorhanden ist, in welchem Zustand sich die Notfallhandbücher und die anderen elementaren Bestandteile der IT-Notfallvorsorge befinden, und wo es demzufolge Handlungsbedarf gibt. Dafür wird ein Verfahren vorgestellt, das so flexibel ist, dass es unabhängig von der Größe des Unternehmens anwendbar ist.

Controlling der IT-Notfallvorsorge
Viele Menschen im Unternehmen müssen aufgrund ihrer Position oder einer ihnen zugewiesenen Rolle dafür Sorge tragen, dass die IT auf eventuelle Notfälle gut vorbereitet ist. Neben der Leitung der IT, dem Information Security Officer, dem Datenschutzbeauftragten, der Geschäftsführung und der Revision gehört dazu auch eine spezielle IT-Notfallvorsorgeorganisation mit einem Notfallbeauftragten an der Spitze. Ihnen allen fällt es schwer, die Übersicht zu behalten, zu wissen, worauf man bauen kann, und ebenso, wo es Defizite gibt, die es abzustellen gilt, zum Beispiel fehlende, veraltete oder aus anderen Gründen unbrauchbare Notfallhandbücher. Das zu ändern ist die Aufgabe des Controllings der IT-Notfallvorsorge.

Hauptaufgaben des Controlling
Wie jedes Controlling hat es drei Hauptaufgaben:

Hier werden vor allem die beiden ersten Punkte behandelt. Es wird beschrieben, welche Fakten ermittelt werden müssen und wo sie herkommen. Es wird erläutert, wie die Fakten zu bewerten sind und was aus der Bewertung für die einzelnen Prozessschritte folgt.

Das Thema „Initiierung von Maßnahmen” wird hier hingegen nicht im Detail betrachtet. Welche Maßnahmen nötig sind, ergibt sich jeweils unmittelbar aus den Bewertungen. Wird etwa festgestellt, dass etwas fehlt, besteht die Maßnahme darin, das Fehlende zu erzeugen oder zu beschaffen. Ist etwas schlecht, muss es überarbeitet werden. Die Nachverfolgung der Umsetzung von beschlossenen Maßnahmen schließlich sollte eine Standardaufgabe der IT sein.

Der rote Faden
Populäre Vorschläge für den Aufbau einer IT-Notfallvorsorge, zum Beispiel der des Bundesamtes für Sicherheit in der Informationstechnik (BSI) [2], sind wichtige Hilfsmittel für jeden, der mit dieser Aufgabe befasst ist. Sie beschreiben zahlreiche sinnvolle Einzelaufgaben und geben Hinweise zur Umsetzung. Gerade dann, wenn die IT-Notfallvorsorge ganz am Anfang steht, ist oft nicht klar, was der sinnvolle erste Schritt ist und was danach logischerweise in welcher Reihe folgen sollte. Wenn jedoch ein Weg nicht vom Start bis zum Ziel bekannt ist, kann auch nicht bestimmt werden, wie nahe das Ziel ist bzw. wie weit der restliche Weg noch ist und mit wie viel Aufwand noch zu rechnen ist. Damit wird das ganze Projekt unkalkulierbar. Ein Scheitern droht. Ein Controlling will genau das ändern, und deshalb muss zunächst der rote Faden gesponnen werden. Um es mit einem Wort zu sagen, das viele der handelnden Personen in der Organisation fürchten und wegen seiner möglichen bürokratischen Folgen gar verachten: der Prozess der IT-Notfallvorsorge muss definiert sein. Wie der Prozess aussehen kann, zeigt Abbildung 1.

Natürlich gibt es Alternativen, und es wird ausdrücklich dazu ermuntert, den Prozess der IT-Notfallvorsorge entsprechend den eigenen Anforderungen und Rahmenbedingungen zu gestalten. Die hier im Weiteren folgenden Vorschläge beziehen sich allerdings auf den Prozess in Abbildung 1.

Für das Verständnis der nachfolgend beschriebenen Methodik des Controllings der IT-Notfallvorsorge sind die nun folgenden Hinweise wichtig.

Notfallbeauftragter
Es muss im Unternehmen eine Person geben, die für die IT-Notfallvorsorge in übergeordneter Funktion zuständig ist. In Anlehnung an die Vorschläge in Standards soll diese Rolle Notfallbeauftragter (für IT Services) genannt werden.

Der Notfallbeauftragte wird die wenigsten Arbeiten in der IT-Notfallvorsorge selbst durchführen. Aber er sorgt dafür, dass alles, was gemäß dem Konzept der IT-Notfallvorsorge geplant ist, von den jeweils Zuständigen auch getan wird.

Pragmatische Notfallvorsorge
Viele der von der IT-Notfallvorsorge genutzten Teilprozesse, zum Beispiel die Risikoanalyse, sind in einer idealen IT-Organisation Standard und erfüllen dort Aufgaben, die weit über das hinausgehen, was die IT-Notfallvorsorge braucht. Entsprechend komplex und aufwändig können sie sein. Wenn es diese Methoden und Verfahren jedoch nicht bereits gibt und sie im Kontext der IT-Notfallvorsorge eingeführt werden müssen, können sie sehr schlank gehalten werden. Das gilt etwa für die Identifikation von Risiken, die Sicherheitsziele wie Vertraulichkeit und Datenschutz betreffen. Die Notfallvorsorge interessiert sich nur für die Verfügbarkeit. Natürlich ist keinem Unternehmen anzuraten, sich ausschließlich um die IT-Notfallvorsorge zu kümmern. Für die übergeordnete Sicht der Informationssicherheit ist in der klassischen Organisation jedoch eine andere Rolle zuständig, nämlich der Informationssicherheitsbeauftragte.

Die IT-Notfallvorsorge kann nicht alle Defizite der IT-Organisation beseitigen. Sie kann und will nicht alle Analysen durchführen, die längst hätten durchgeführt werden müssen, und alle Dokumente liefern, die längst hätten geliefert werden müssen. Sie soll sich in erster Linie um die eigenen Probleme kümmern. Das Controlling, das hier vorgeschlagen wird, wird sich dementsprechend nur mit Fragen befassen, die für die IT-Notfallvorsorge wichtig sind.

Wenn alles Unnötige konsequent außen vor gelassen wird, dann erfordert das IT-Notfall-Controlling, geschickt organisiert, nur geringen Aufwand. Dafür ist es wichtig, bei den erforderlichen Analysen und Bewertungen einen vernünftigen Grad der Detaillierung zu wählen. Manches Managementsystem scheitert, weil sich die angewandten Methoden in pseudowissenschaftlicher Genauigkeit verlieren. Für das Risikomanagement eines Unternehmens mag es interessant sein, wie hoch genau ein Einzelrisiko ist, und es möchte die Auskunft am liebsten in Euro ausgedrückt bekommen. Für die IT-Notfallvorsorge reicht es jedoch völlig, zu erkennen, ob das Risiko kritisch ist oder nicht. Entsprechend grob kann die Methode der Risikoanalyse hier sein. Ein einfaches „ja” oder „nein” als Auskunft genügt.

80:20-Regel
Pragmatismus bedeutet vielfach, die goldene 80:20-Regel zu befolgen: 80 % der Ergebnisse lassen sich mit 20 % des Gesamtaufwands erreichen. Es ist häufig besser, sich an dem zu orientieren, was möglich ist, etwa im Hinblick auf das Budget, das der Notfallbeauftragte zur Verfügung hat, als das anzustreben, was im Sinn der reinen Lehre maximal wünschenswert wäre. Deshalb werden nachfolgend die Metriken bewusst sehr einfach gehalten, auf das Risiko hin, nicht jeden Spezialfall individuell zu behandeln, aber mit dem Lohn, für den großen Rest in kurzer Zeit zu guten Notfallplänen zu kommen. Es kann zum Beispiel gar nicht das Ziel sein, für alle IT Services und alle denkbaren Ausfallszenarien ausformulierte Notfallhandbücher zu haben, das kann so gut wie keine IT-Organisation der Welt leisten. Aber es sollte das Ziel sein, für die kritischsten 80 % der IT Services und die kritischsten 80 % der Ausfallszenarien solche Pläne zu haben.

In jedem Controlling werden Fakten zusammengetragen, korreliert und aggregiert, bewertet und schließlich in Berichten präsentiert. Schon aufgrund der Menge der Daten wird dafür ein Werkzeug benötigt, für die Erstellung ansprechender und aussagekräftiger Berichte sowieso. Dieses Werkzeug wird hier Notfall-Monitor genannt.

Software
Für die Art von Controlling, die hier vorgeschlagen wird, reicht ein Spreadsheet, wie es mit üblicher Office-Software bearbeitet werden kann. Für Aufgaben des allgemeinen Business Continuity Managements (BCM) wird am Markt zum Teil sehr leistungsstarke, aber auch entsprechend teure kommerzielle Software angeboten. Wenn das BCM eine gewisse Komplexität erreicht, mögen solche Applikationen nützlich sein. Zu Beginn genügen Anwendungen wie OpenOffice Calc, Microsoft Excel oder Apple Numbers. In überschaubaren IT-Organisationen wird das sogar auf Dauer ausreichen.

Daten im Notfall-Monitor
Der Begriff Notfall-Monitor könnte die Vorstellung auslösen, dass es sich dabei um ein sehr komplexes Gebilde handelt. Das muss nicht so sein. Im einfachsten Fall ist der Notfall-Monitor nur eine große Tabelle und sieht so aus, wie es die Abbildung 2 andeutet.

Ein einfacher Rumpf einer solchen Excel-Tabelle ist hier als Arbeitshilfe beigefügt. Diese orientiert sich an den hier im Folgenden vorgestellten Elementen. Die Tabelle kann nur eine Orientierung geben und muss an die tatsächlichen Anforderungen im konkreten Fall angepasst werden. Berichte oder Auswertefunktionen sind nicht enthalten, da diese in besonderem Maße von betrieblichen Gegebenheiten abhängig sind.[ 01720_a.xlsx]

In den folgenden Abschnitten wird beschrieben, welche Informationen in dieser Tabelle enthalten sein sollten und welche Aussagekraft sie im Sinn des Controlling-Gedankens haben. Natürlich kann die Tabelle bzw. das Werkzeug der Wahl um beliebige weitere Angaben ergänzt werden. Es ist aber in jedem Einzelfall kritisch zu hinterfragen, ob es nützlich ist, über diese Zusatzinformation zu verfügen. Der Versuchung, über eine möglichst breite Datensammlung verfügen zu wollen, ist wegen des mit der Datenpflege verbundenen Arbeitsaufwands unbedingt zu widerstehen. Überdies ist der Erkenntnisgewinn in vielen Fällen gering. Tatsächlich dürften die hier beschriebenen Einzelinformationen, nachfolgend mit Daten im Notfall-Monitor gekennzeichnet, für ein wirksames Controlling der IT-Notfallvorsorge völlig ausreichen.

Datenpflege
Unabhängig von der eingesetzten Software müssen die Daten im Notfall-Monitor gepflegt werden. Das beginnt mit der erstmaligen Erhebung und Erfassung. Anschließend bedarf es einer regelmäßigen Überprüfung und Aktualisierung. Dies ist die Aufgabe des Notfallbeauftragten, und es ist wahrscheinlich, dass dies weitgehend manuell erfolgen wird. Wenn es zum Beispiel interessant ist, für welche IT Services es Notfallhandbücher gibt und wie aktuell diese sind, dann könnte die Information in einem entsprechend organisierten System vielleicht automatisch ermittelt werden. Agenten, die Dateiablagen durchsuchen und aus Files Informationen wie das Datum der letzten Änderung ermitteln, sind prinzipiell denkbar. Ein solches System wäre aber technisch anspruchsvoll, nicht zuletzt, weil es kaum eine IT-Organisation schafft, über alle Themen und Fachteams hinweg eine einheitliche Dokumentenablage zu etablieren. Zudem würde die automatische Auswertung ein Maß an Disziplin bei der Formatierung und der Ablage zentraler Dokumente voraussetzen, das in einer durchschnittlichen IT-Organisation unerreichbar ist. Qualitative Aussagen, etwa „Wie gut ist ein Recovery Plan?” oder „In welchem Umfang werden die Verfügbarkeitszusagen der IT an die User erfüllt?” sind gar nicht automatisiert zu ermitteln.

Aufgrund dessen lautet der Vorschlag, die Datenpflege komplett manuell durchzuführen. Der Notfallbeauftragte schaut sich von Zeit zu Zeit seine Informationsquellen an und überträgt wichtige Daten in sein Werkzeug. Konzentriert sich das Controlling auf das Wesentliche, nämlich die Daten, die wirklich benötigt werden, um die IT-Notfallvorsorge effektiv zu steuern, ist der mit der manuellen Datenpflege verbundene Arbeitsaufwand gering.

Natürlich weiß jeder, dass es unvernünftig ist, nach einer Lösung zu suchen, wenn das Problem bestenfalls vage beschrieben werden kann, und doch wird immer wieder genau das gemacht. Die IT-Notfallvorsorge soll dazu beitragen, kritische IT Services abzusichern. Dabei ist fast immer unklar, was denn die Services der IT sind. Nicht selten ist nicht einmal eindeutig, was IT ist.

Liste der IT Services
Die erste Aufgabe der IT-Notfallvorsorge und somit auch das erste, was im Controlling der IT-Notfallvorsorge überwacht werden muss, ist die Pflege des Servicekatalogs der IT. Das ist eine Liste derjenigen Leistungen, die der Bereich IT für seine internen und externen Kunden, also die Nutzer der IT Services, erbringt. Zu den absoluten Grundregeln aller Aktivitäten wird nämlich ab sofort gehören: Was immer es ist – wenn es nicht auf der Liste der IT Services erscheint, wird es dafür auch keine Notfallvorsorge geben.

Die Liste der IT Services ergibt sich aus den kritischen Geschäftsprozessen einer Organisation. Alle IT Services, die von kritischen Geschäftsprozessen genutzt werden, sind Bestandteil der IT-Notfallvorsorge. Man kann entweder direkt eine Liste der kritischen Geschäftsprozesse erstellen oder aber auf der Ebene von Produkten und Dienstleistungen beginnen und sich die Frage stellen, welche Geschäftsprozesse und IT Services benötigt werden, um das Produkt bzw. die Dienstleistung anzubieten.

Definition IT Services
Was ist eigentlich ein IT Service bezogen auf die IT-Notfallvorsoge? Dafür gibt es keine klaren Regeln. Im Wesentlichen dürften aber folgende Leistungsarten als IT Service anzusehen sein:

Daten im Notfall-Monitor
Der Servicekatalog muss im einfachsten Fall nicht mehr sein als die Liste der Namen der Services (vgl. Tabelle 1). Hilfreich kann es sein, die Services in Typen einzuteilen, wie sich im Weiteren noch zeigen wird.

Service Manager
Wie granular bzw. komplex ein Service ist, kann individuell festgelegt werden. Ob der Service „Server” zum Beispiel auch das Betriebssystem und die Middleware einschließt oder ob statt eines einzelnen Servers eine Serverfarm betrachtet wird, ist aus Sicht der IT-Notfallvorsorge erst einmal unerheblich. Hauptsache ist, dass am Ende die Service-Liste alles abdeckt, worum sich die IT-Notfallvorsorge kümmern soll. Ein Kriterium hilft jedoch, zu prüfen, ob ein Service sinnvoll abgegrenzt ist. Es muss möglich sein, eine Person zu benennen, die für den Service in Gänze Verantwortung trägt. Solche Personen werden gerne Service Manager genannt.

Ein Service Manager muss nicht unbedingt der technische Experte für seinen Service sein, doch er trägt die Verantwortung, zum Beispiel für die Entscheidung, ob ein Notfallhandbuch benötigt wird, und in dem Fall, dass es so ist, auch dafür, dass das Notfallhandbuch vorhanden ist. Der Service Manager ist das Äquivalent zum Asset Owner im allgemeinen BCM. Wenn er kein IT-Experte ist, steht ihm für jedes IT Asset seines Services ein System Owner zur Verfügung, der über die notwendigen IT-Kenntnisse verfügt.

Grenzen der IT
Spannend ist bei der Erstellung des Servicekatalogs die Frage, wo die Grenzen der IT liegen. Sind zum Beispiel das Rechenzentrum oder die Stromversorgung noch Teil der IT und muss also die IT-Notfallvorsorge Pläne für deren Wiederaufbau pflegen? Und falls nicht: Wer tut es dann?

BCM-Policy
Solche übergeordneten Klärungen werden im Regelfall in Policies vorgenommen, weswegen allgemeine BCM-Standards auch durchgängig fordern, dass es eine BCM-Policy geben muss. Allerdings können BCM-Themen auch in anderen Policies mit behandelt werden, etwa in der Information Security Policy.

Zweiter Schritt
Auch im zweiten Prozessschritt widmet sich der Prozess einer Aufgabe, die an sich gar nicht Kernthema der IT-Notfallvorsorge ist, sondern eine Grundaufgabe für jede IT-Organisation. Wenn der Titel eines IT Service bekannt ist, ist damit noch lange nicht klar, von was genau die Rede ist. Findet sich zum Beispiel in der Service-Liste die Angabe „E-Mail”, gibt es viele Möglichkeiten, was damit gemeint sein könnte und was demzufolge im zugehörigen Notfallhandbuch behandelt werden muss.

Die Liste solcher Fragen lässt sich beliebig erweitern, und alle Fragen müssen beantwortet werden. Wenn nicht eindeutig klar ist, welche Funktionen und Komponenten mit einem Servicenamen verbunden sind – im Englischen spricht man vom Scope – ist auch unbestimmt, was die Notfallvorsorge schützen soll.

Steckbrief
Unter der Bezeichnung Servicesteckbrief wird vorgeschlagen, ein kurzes Dokument zu verfassen, das definiert, was zum diskutierten Service gehört und wo die Grenzen liegen. Wichtige Detailinformationen in einem Servicesteckbrief sind:

Form
Der Steckbrief kann ein ausführliches Text-Dokument sein, aber manchmal reicht auch ein kurzes Summary, aus dem auf weiterführende Informationen verwiesen wird, zum Beispiel die eigentliche Systemdokumentation.

Der Steckbrief muss für alle Services eine einheitliche Form haben. Nur so lässt sich effizient prüfen, ob er den qualitativen Anforderungen der IT-Notfallvorsorge genügt, das heißt, ob alle nötigen Informationen vorhanden sind. Ein einfaches Beispiel ist als Arbeitshilfe im Excel-Format beigefügt. Diese kann nur eine grobe Orientierung geben und muss an die tatsächlichen Anforderungen im konkreten Fall angepasst werden. Größere Organisationen verfügen häufig über eine Configuration Management Database (CMDB), in die ein solcher Steckbrief integriert werden kann.[ 01720_b.xlsx]

Big Picture
Es ist äußerst hilfreich, die Architektur des Service in einer Grafik zu visualisieren, und zwar „end-to-end”. Dieses Bild muss auf eine Seite passen. Solche Übersichten werden Big Picture genannt. Sie sind eine wichtige Anlage zum Steckbrief.

Daten im Notfall-Monitor
Bezüglich des Status der Servicedokumentation werden für das Controlling der IT-Notfallvorsorge je Service die in Tabelle 2 aufgeführten Angaben benötigt.

Fakten
Der Notfallbeauftragte muss einige Fakten sammeln und auswerten, wie etwa das Datum der letzten Revision eines Steckbriefs. Dafür steht beispielhaft Spalte 2A der Tabelle im vorigen Kapitel. Was genau heißt es aber, dass die Servicebeschreibung zu lange nicht mehr überprüft und verbessert wurde, und was folgt daraus? Das ist eine Bewertung, wie sie etwa in die Angabe in Spalte 2B einfließt. Neben der Feststellung von Tatsachen, zum Beispiel, ob es eine Servicebeschreibung gibt, geht es auch darum, sich ein Bild von der Qualität dessen zu machen, was unter der Überschrift IT-Notfallvorsorge produziert wurde. Es kommt nicht darauf an, ob es ein Dokument mit dem Titel „Notfallhandbuch für den Service E-Mail” gibt und wie dick das ist. Was bekannt sein muss, ist, ob dieses Dokument etwas taugt, und zwar in dem Sinn, ob es hilft, Versprechen zur Serviceverfügbarkeit einzuhalten, die den Kunden der IT gegeben wurden.

Bewertung
Wertende Aussagen spiegeln stets die subjektive Meinung eines Betrachters wider. Es ist weder falsch noch bedenklich, wenn verschiedene Personen in Anbetracht bestimmter Fakten zu unterschiedlichen Bewertungen kommen. Angenommen, dass ermittelt wurde, dass der letzte Review des Steckbriefs eines Service vor 18 Monaten erfolgte, wie sollte dieses Faktum bewertet werden? Der eine mag denken, dass Reviews im Abstand von zwei Jahren absolut in Ordnung sind, vielleicht, weil er weiß, dass wegen der dünnen Personaldecke bereits das ein Erfolg wäre. Für jemand anderen ist der gleiche Umstand gänzlich inakzeptabel, denn schon innerhalb eines deutlich kürzeren Zeitraums ändern sich technische Architekturen oft radikal. Wichtig ist am Ende zweierlei:

Metriken
Eine Metrik zeichnet sich durch folgende Eigenschaften aus:

Starre Metriken haben den Nachteil, dass nur selten einer der angebotenen Werte exakt passt. Darum ist es hilfreich, zu den bewertenden Aussagen Kommentare zu erfassen, um zu erläutern, warum die Bewertung so erfolgte. Siehe als Beispiel auch dazu Tabelle 2, Spalte 2B im letzten Abschnitt.

Metriken in der BCM-Policy
Die bei der IT-Notfallvorsorge genutzten Metriken sollten in der allgemeinen BCM-Policy formuliert werden. Dann können Sie auch für andere BCM-Szenarien genutzt werden, etwa dem Ausfall des Personals oder eines Dienstleisters.

Der Prozess der IT-Notfallvorsorge muss definieren, was aus einem bestimmten Fakt oder aus einer Bewertung folgt.

Transparenz
Metriken liefern die Voraussetzung dafür, dass ein konsequentes Controlling sehr klare Aussagen über den Zustand der Notfallvorsorge treffen kann. Beispiele für Metriken sind:

Solche Erkenntnisse werden ohne jede Beschönigung präsentiert, und weil das auf der Grundlage objektiver Fakten und nachvollziehbarer Bewertungen geschieht, sind sie auch nicht angreifbar.

Es wird häufig übersehen, dass die erste und vielleicht auch wichtigste Aufgabe der IT-Notfallvorsorge darin besteht, Transparenz zu schaffen. Das passiert nun ziemlich radikal. Nicht jedem wird das gefallen.

Mögliche kritische Schäden erkennen
IT-Notfallvorsorge ist ein aufwändiges und teures Unterfangen, das sich für einen einzelnen Service nur lohnt, wenn dieser hinreichend wichtig ist. Es gilt deshalb, für alle Services des Servicekatalogs herauszufinden, ob sie hinreichend wichtig sind. Aus dem Blickwinkel der IT-Notfallvorsorge ist das dann der Fall, wenn ein Serviceausfall einen kritischen Schaden verursachen könnte. Ob das der Fall ist, ermittelt ein Vorgang, der Business Impact Analysis oder kurz BIA genannt wird.

Drei wesentliche Fragen
Beschränkt auf die Anforderungen der IT-Notfallvorsorge ist eine BIA unkompliziert. Sie stellt zu jedem IT Service drei Fragen in den Vordergrund:

Recovery Time Objective
Mit der Antwort auf die letzte Frage ist der wichtigste Parameter für die IT-Notfallvorsorge ermittelt: die maximal tolerierbare Ausfallzeit eines IT Service. Dieser Parameter wird üblicherweise Recovery Time Objective, kurz RTO, genannt.

Recovery Point Objective
Ein zweiter Parameter, der bekannt sein muss, ist die maximal tolerierbare Zeitdauer eines Datenverlusts. Sie wird Recovery Point Objective, kurz RPO, genannt.

Metrik der BIA
Die BIA der IT-Notfallvorsorge konzentriert sich auf ganz wenige Fragen. Sie betrachtet nur bestimmte Schadensereignisse. Das macht es vergleichsweise einfach, sie durchzuführen. An sich ist eine BIA, etwa für das Corporate Risk Management, sehr viel komplexer.

Für die Durchführung einer BIA wird eine Methodik benötigt. Sie muss vor allem folgende Fragen klären:

Daten im Notfall-Monitor
Wenn in einem Unternehmen BIAs durchgeführt werden, ist das gewöhnlich ein wesentlich komplexerer Vorgang als hier beschrieben, doch das ist für die IT-Notfallvorsorge uninteressant. Ganz im Sinn der eingangs propagierten Pragmatik sind am Ende nur wenige Aussagen einer BIA wichtig, und zwar die in Tabelle 3 dargestellten.

Vereinfachte BIA
In bestimmten Fällen kann auf eine BIA sogar verzichtet werden, weil das Ergebnis mit hoher Wahrscheinlichkeit auch so bekannt ist. Dabei spielt der Servicetyp eine wichtige Rolle (siehe Abschnitt 4 Servicekatalog). Die Methodik der BIA kann dazu Regeln wie die folgenden vorsehen:

Durch die bisherigen Arbeiten ist bekannt, welche IT Services es gibt und welche davon so kritisch sind, dass sich die IT-Notfallvorsorge um sie kümmern muss. Für alle anderen ist der Prozess hier schon zu Ende. Für sie lohnt sich ein Notfallhandbuch nicht. Falls sich der Service Manager trotzdem die Zeit nehmen will, eine IT-Notfallvorsorge zu betreiben, so ist das seine eigene Entscheidung. Es stellt sich allerdings die Frage, ob die damit verbundenen Aufwände nicht einfach Verschwendung von Zeit und Geld sind.

Für die kritischen Services ist IT-Notfallvorsorge obligatorisch. Das Einzige, was eventuell noch zu klären ist, und zwar wegen der vermutlich begrenzten Mittel für die nun anstehenden Arbeiten, ist die Reihenfolge, in der diese Services behandelt werden. Dafür ist eine Priorisierung innerhalb der Gruppe der kritischen Services unvermeidlich. Siehe dazu Spalte 3C der Tabelle 3 im vorherigen Abschnitt.

Szenarien
Das wichtigste Ergebnis der IT-Notfallvorsorge für einen IT Service wird das Notfallhandbuch sein. Darin wird die Strategie beschrieben, mittels deren erreicht werden soll, dass bei einem Serviceausfall einerseits unvermeidliche Schäden begrenzt werden können und andererseits die Leistungen, die die Kunden benötigen, möglichst rasch wieder angeboten werden können.

Genau genommen gibt es nicht nur einen Plan für den Notfall, sondern zahlreiche, und zwar für jedes denkbare Schadensbild einen. Diese Schadensbilder sind zu unterschiedlich, als dass es möglich wäre, sie alle mit einem einzigen Plan in den Griff bekommen zu wollen. Die Maßnahmen, die zum Beispiel beim Verlust von Hardware zu ergreifen sind, sind ganz andere als die, die sinnvoll sind, falls ein Hacker eine Datenbank löscht oder falls das Personal streikt. Ein bestimmtes Schadensbild wird meist als Szenario bezeichnet. Für jedes Szenario, bei dem ein kritischer Schaden droht, muss ein passender Plan entworfen werden.

Schadensbilder identifizieren
Der nächste Prozessschritt der IT-Notfallvorsorge leitet sich unmittelbar aus folgender Frage ab: Welches sind die oben so beiläufig erwähnten „denkbaren Schadensbilder bzw. Störfallszenarien”? Sie zu identifizieren und in ihrer Wahrscheinlichkeit abzuschätzen ist Aufgabe einer Risikoanalyse.

Metrik der Risikoanalyse
Wie die BIA ist auch die Risikoanalyse grundsätzlich eine komplexe und schwierige Arbeit, und wie bei der BIA kann die IT-Notfallvorsorge sie sehr einfach halten, indem sie sich auf folgende Fragen konzentriert:

Qualität der Risikoanalyse
Es ist keine triviale Aufgabe, bei einer Betrachtung eines IT Service, etwa seiner technischen Struktur, mögliche Ausfallszenarien zu erkennen. Wenn es um IT-Notfallvorsorge geht, denken viele zunächst – und manchmal auch nur – an Ereignisse, die eine physische Zerstörung von Hardware zur Folge haben, wie der Ausfall eines Rechenzentrums nach einem Brand. Es ist extrem wichtig, sehr viel breiter zu denken. Der Verlust von Daten ist in der Regel dramatischer als der Verlust von Systemen oder Räumlichkeiten, und die Folgen eines vorsätzlichen Angriffs von Insidern sind nachhaltiger als die von Unfällen. Völlig übersehen werden häufig externe Einflüsse wie der Ausfall von Dienstleistern. Gerade mit Risikoanalysen müssen Fachleute beauftragt werden, die in diesem Metier eine gewisse Erfahrung mitbringen. Andernfalls kann es schnell passieren, dass nur die offensichtlichen, aber nicht unbedingt die kritischen Szenarien betrachtet werden.

Das Ergebnis der Risikoanalyse stellt sich im Notfall-Monitor wie in Tabelle 4 gezeigt dar.

Spalte 4D fasst das Ergebnis aller analytischen Tätigkeiten in einem Wort zusammen. Die bisherigen Überlegungen dienten nur dem Zweck, diese zentrale Entscheidung abzusichern. Lautet sie „nein”, sind alle weiteren Schritte des Notfallvorsorgeprozesses für das Szenario nicht mehr relevant.

Da es zu jedem IT Service beliebig viele Schadensszenarien geben kann, kommen die Werte 4B bis 4D im Notfall-Monitor mehrfach vor. Ein Beispiel zeigt der Auszug in Tabelle 5.

Die Tabelle 5 deutet bereits an, dass alle in den noch folgenden Prozessschritten ermittelten Fakten und vorgenommenen Bewertungen für jedes Szenario, für das ein Notfallhandbuch vorgesehen ist, separat zu dokumentieren sind.

Auch zu Beginn dieses Abschnitts zunächst ein Rückblick: Was ist der Erkenntnisstand an dieser Stelle im Prozess?

Es ist bekannt, welche Notfallhandbücher nötig sind, nämlich jeweils

Notfallhandbuch
Es muss nun ein Plan entworfen werden, der erklärt, wie ein Wiederanlauf des Service in hinreichend kurzer Zeit erreicht werden kann. Das Notfallhandbuch ist das Dokument, in dem dieser Plan beschrieben wird. In diesem Beitrag kann nicht im Detail darauf eingegangen werden, wie ein Notfallhandbuch aussieht. Es soll nur daran erinnert werden, dass ein Plan für den Notfall auf jeden Fall zwei Aspekte abdecken muss: den Continuity Plan für den Service und die Recovery Plans für die Ressourcen, die der Service nutzt.

Continuity Plan
Nach einem Ausfall der IT muss das Augenmerk der IT-Notfallvorsorge zunächst auf dem Kunden liegen. Es müssen Sofortmaßnahmen eingeleitet werden, um Schäden zu begrenzen. Dann aber müssen den Kunden der IT Provisorien angeboten werden, die sie in die Lage versetzen, die wichtigsten Arbeiten erledigen zu können, solange die regulären IT Services nicht verfügbar sind. Das Kapitel des Notfallhandbuchs, in dem entsprechende Strategien beschrieben werden, ist der Continuity Plan.

Recovery Plan
Es muss für alle Ressourcen, die ein Service nutzt, zum Beispiel die einzelnen Systeme und Applikationen, eine Strategie geben, wie sie bei einem Komplettausfall bzw. Verlust wiederhergestellt werden können. Die Dokumentation dazu heißt Wiederanlaufplan bzw. Recovery Plan.

Das Controlling der IT-Notfallvorsorge stellt sicher, dass genau diese Dokumente bzw. Teile des Notfallhandbuchs existieren, und zwar nicht nur dem Namen nach, sondern als praxistaugliches Arbeitsdokument für den Notfall.

Daten im Notfall-Monitor
Die Tabelle 6 listet die Daten auf, die zum Notfallhandbuch im Notfall-Monitor geführt werden müssen.

Qualitätssicherung
Die Spalte 5B ist möglicherweise der Dreh- und Angelpunkt des gesamten Controllings der IT-Notfallvorsorge. Hier soll der Notfallbeauftragte bewerten, was er von dem Plan hält, der in dem ihm vorgelegten Notfallhandbuch dokumentiert ist.

Führt die Bewertung zu einem negativen Ergebnis, wird das Controlling den Fall so behandeln, als ob es gar kein Notfallhandbuch gäbe. Auch wenn das hart erscheinen mag: Angesichts dessen, was eventuell davon abhängt, ob ein Notfallhandbuch brauchbar ist, sind Gefälligkeitsaussagen an dieser Stelle fehl am Platz.

Templates
Ob ein Notfallhandbuch vollständig ist, lässt sich nur feststellen, wenn zuvor definiert wurde, was es enthalten muss. Darum müssen für Continuity Plans und Recovery Plans Vorlagen (Templates) entworfen werden, deren Verwendung vorgeschrieben wird.

Verlässlichkeit testen
Die im vorigen Abschnitt aufgeworfene Frage nach der Verlässlichkeit eines Plans für den Notfall (Spalte 5D) lässt sich am besten beantworten, indem der Plan im Rahmen einer Notfallübung getestet wird.

Grundvoraussetzung für einen Test, der verwertbare Aussagen liefert, ist, dass nicht irgendetwas getestet wird. Hier ist eine gesunde Skepsis gegenüber den Systemspezialisten angebracht. Diese neigen nämlich dazu, bevorzugt das zu testen, was sie eh einigermaßen im Griff haben.

Mit der bisher vorgeschlagenen Vorgehensweise ist allerdings klar, was Testgegenstand sein muss, nämlich das Vorgehen in einem der in der Risikoanalyse identifizierten Ausfallszenarien anhand des dafür dokumentierten Plans, und nichts anderes. Lautet das Szenario zum Beispiel „Ausfall der Datenbank” und wurde dabei die Annahme gemacht, dass der Datenbankserver inklusive Betriebssystem noch zur Verfügung steht, so muss der Test wenigstens die Schritte „Einrichten der Datenbank” und „Rückspielen der Daten aus dem Backup” umfassen. Das Aufsetzen des Servers selbst ist hingegen hier irrelevant. Es ist gegebenenfalls Teil der Übungen zum Notfallhandbuch für die Serverfarm.

Daten im Notfall-Monitor
Die Tabelle 7 listet die Daten auf, die der Notfallbeauftragte zu den Notfallübungen wissen möchte und die entsprechend im Notfall-Monitor geführt werden.

Testplan
Test ist nicht gleich Test. Es gibt die unterschiedlichsten Möglichkeiten, Pläne zu verifizieren. Spannend ist vor allem die Frage, wie viel praktisch getestet werden kann und wie viel davon in einer realen Umgebung, also unter Produktionsbedingungen. Jede Art von Test wird für ein bestimmtes Maß an Gewissheit sorgen. Es ist notwendig, für jedes betrachtete Schadensszenario zu bestimmen, welche Art von Test hilft, das jeweils nötige Maß an Gewissheit zu erreichen. Nicht in jedem Fall ist ein praktischer Test in der produktiven Umgebung zwingend nötig. Manchmal reicht ein Test in einer Testumgebung, manchmal ein simulierter Test am Schreibtisch („Table-Top-Übung”), manchmal ein Review des Notfallhandbuchs durch einen unabhängigen Fachmann. Die aus Sicht der Beteiligten, Systemspezialisten wie Notfallbeauftragter, angemessene Strategie soll als Testplan beschrieben werden, und zwar unabhängig von der Frage, ob ein solcher Test durchführbar ist. In Spalte 6A wird überwacht, ob es einen aktuellen Testplan gibt.

Auf Widersprüche unnachgiebig hinweisen!
Natürlich wird es in vielen Fällen an verfügbarem Budget und anderen wichtigen Ressourcen für Tests mangeln. Testsysteme sind teuer und Time Slots für die Tests schwer zu finden. Manchmal sind praktische Tests auch aus technischen Gründen kaum möglich oder mit einem unverantwortlich hohen Risiko verbunden, z. B. im Rechenzentrum einer Klinik. Dann können eigentlich als notwendig erachtete Tests nicht durchgeführt werden. Die Folge wird sein, dass die Gewähr sinkt, dass der Plan im Notfallhandbuch funktionieren würde, wenn er gebraucht wird. Ist das akzeptabel? Das ist eine Bewertung, für die es eine Metrik geben muss. Unter dieser Bedingung wird eine Aussage der Art „Verlässlichkeit des Notfallhandbuchs: zu gering” zu einem Fakt (vgl. Tabelle 5, Spalte 5D). Auch wenn begründet werden kann, warum ein an sich nötiger Test nicht durchgeführt wurde, macht das die Angelegenheit nicht weniger problematisch. Das Controlling soll auf solche Widersprüche hinweisen.

Viele Personen wirken an der IT-Notfallvorsorge mit. Manche wie die Mitarbeiter der Fachbereiche müssen selbst aktiv werden, zum Beispiel an Dokumenten arbeiten und Übungen durchführen. Manager müssen einschreiten, wenn das nicht passiert. Zudem vertreten sie das Unternehmen oder ihren Bereich nach außen. Jedenfalls sollten sie wissen, was in ihm vorgeht.

Berichtswesen ist ein mächtiges Instrument
Der Notfallbeauftragte ist so etwas wie der Diener der IT-Notfallvorsorge. In ihrem Auftrag muss er alle, die hierbei Aufgaben und Pflichten zu erfüllen haben, immer wieder erinnern, diese zu erfüllen. Dazu sollte er ein geordnetes Berichtswesen einrichten. Das ist nicht nur eine lästige Pflicht. Der Notfallbeauftragte verfügt damit über ein mächtiges Instrument, um die Interessen der IT-Notfallvorsorge zu fördern, indem er den Fokus auf die Missstände legt, die aus seiner Sicht nicht akzeptabel sind.

Zwei Typen von Berichten sind zu unterscheiden.

KVP
Es gibt einerseits Berichte, die helfen sollen, Dinge voranzutreiben und Verbesserungen herbeizuführen. In einem Managementsystem ist das Teil des Prozesses der kontinuierlichen Verbesserung (KVP). Berichte des KVP werden eher die schlechten Nachrichten betonen. Mängel etwa werden beschrieben, um das Mandat zu bekommen, sie abstellen zu dürfen bzw. jemand anderen dazu anhalten zu dürfen. Vom Berichtsempfänger wird erwartet, dass er dafür die nötigen Mittel bereitstellt und Kompetenzen gewährt – oder die Verantwortung dafür übernimmt, dass am Status quo nichts geändert wird.

Compliance
Andererseits gibt es Berichte, bei denen es das Hauptziel ist nachzuweisen, dass die IT-Notfallvorsorge auf gutem Weg ist. Gewöhnlich passiert das im Kontext von Compliance, worunter die Einhaltung von Vorschriften, vorrangig von Gesetzen, aber auch von Verträgen, Normen oder ganz generell der Strategie des Unternehmens, zu verstehen ist. Wo die IT-Notfallvorsorge zu Compliance verpflichtet ist, muss sie belegen können, dass sie die betreffenden Regeln einhält. Dies erfolgt zum Beispiel gegenüber der Geschäftsführung und ihr nahestehenden Aufsichtsorganen wie der Revision oder dem Risk Management, gegenüber Auditoren oder Kunden, aber auch gegenüber dem Information Security Officer. Inhalt, Form und Häufigkeit diesbezüglicher Berichte sollten vom Empfänger festgelegt werden. Wo dies nicht der Fall ist, wird der Notfallbeauftragte Vorschläge machen müssen.

Prozessübersicht
Der Notfall-Monitor kann selbst dann, wenn er technisch einfach gehalten wird, vollautomatisch Berichte erzeugen und die Fakten und Bewertungen zielgerecht und ansprechend präsentieren. Dafür folgen nun einige Beispiele. Abbildung 3 zeigt, wie der Gesamtstatus des Prozesses der IT-Notfallvorsorge visualisiert werden kann.

KPIs
Ein wichtiger Teil von Management Reports sind Aussagen zu den sogenannten Key Performance Indicators (KPIs), also Kennzahlen, mit denen die Qualität der IT-Notfallvorsorge gemessen wird. Was ein KPI der IT-Notfallvorsorge ist, muss individuell vereinbart werden. In Abbildung 4 wird gezeigt, wie eine Grafik für den Fall aussehen könnte, dass die Qualität der IT-Notfallvorsorge (auch) daran gemessen wird, wie aktuell die Notfallpläne sind.

Abbildung 5 präsentiert den gleichen KPI, jedoch diesmal tabellarisch in einer Trendaussage: Hat sich die Situation seit dem letzten Bericht verbessert oder nicht?

Berichtsform abstimmen
Schwieriger als die automatisierte Generierung von Berichten dürfte es sein, sich mit den Berichtsempfängern darauf zu verständigen, welche Informationen die Berichte enthalten sollen. Oft wird der Notfallbeauftragte dazu Vorschläge machen müssen, da er am besten weiß, wie der Status kompakt und aussagekräftig dargestellt werden kann.

Das Controlling, also die Steuerung aller Teilaufgaben der IT-Notfallvorsorge, ist weder besonders kompliziert noch arbeitsaufwändig, sofern das Unternehmen dafür einige Vorbereitungen getroffen hat:

Aufwand für Aufbau
Der Aufbau eines solchen Systems muss kein Riesenprojekt sein. Aufwand wird es vor allem bei der Feinabstimmung der geforderten Metriken geben. Auch wenn eine Metrik letztlich nur aus wenigen Werten und den zugehörigen Erläuterungen bestehen wird, kann es ein langer Weg sein, um zu diesem Resultat zu gelangen.

Aufwand für Betrieb
Der Aufwand für den Betrieb des Controllings ist gering. Erwähnenswert wird am ehesten der Aufwand für das sein, was das Controlling anstoßen wird. Einen Missstand zu erkennen wird nicht mehr das Problem sein, aber die Lehren daraus zu ziehen und angemessene Maßnahmen einzuleiten und umzusetzen kann viel Arbeit sein.

Die wichtigen Liefereinheiten des Prozesses der IT-Notfallvorsorge sind:

Es war nicht Ziel dieses Beitrags, zu beschreiben, wie diese Dokumente aussehen sollen und wie sie gepflegt werden. Das kann, je nach Aufstellung des Unternehmens, eine einfache oder auch sehr komplexe Lösung sein. Jedoch lassen sich auch dafür sowohl Lösungen aufbauen, die selbst kleinste IT-Organisationen nicht überfordern, als auch solche, die den Anforderungen in großen Unternehmen angemessen sind.