BCM einfach erklärt: So finden Sie die richtigen Ausfallszenarien

In vielen BCM-Workshops passiert ungefähr Folgendes: Jemand schreibt „Brand“, „Hochwasser“, „Cyberangriff“ und „Stromausfall“ an ein Whiteboard. Danach blickt die Runde auf diese vier Begriffe und fragt sich, ob noch eine Pandemie, ein Flugzeugabsturz oder wenigstens eine kaputte Kaffeemaschine fehlt.

Das Problem ist nicht, dass diese Ereignisse unmöglich wären. Das Problem entsteht, wenn sie die einzige Quelle für Ausfallszenarien bleiben. Wer ausschließlich bei beliebigen Katastrophen beginnt, kann sehr lange sammeln und weiß hinterher trotzdem nicht, für welche Ausfälle tatsächlich ein Continuity-Plan benötigt wird. Wer ausschließlich auf die direkt mit einem Prozess verbundenen Assets schaut, kann dagegen übergreifende Störungen übersehen.

Business Continuity Management lässt sich sauberer aufbauen. Man beginnt bei den Anforderungen an das Unternehmen, geht von dort zu den kritischen Prozessen und prüft anschließend, wovon diese Prozesse abhängen. Ergänzend betrachtet man allgemeine Störungen, die mehrere Abhängigkeiten gleichzeitig treffen können. So entstehen nicht möglichst viele, sondern die richtigen Ausfallszenarien.

Die kurze Antwort

Um die richtigen BCM-Szenarien zu finden, gehen Sie rückwärts durch die Abhängigkeiten Ihres Unternehmens:

1. Welche interessierten Parteien haben welche Anforderungen an Ihre Verfügbarkeit?
2. Welche Prozesse erfüllen diese Anforderungen?
3. Wie lange dürfen diese Prozesse ausfallen und auf welchem Mindestniveau müssen sie weiterlaufen?
4. Welche Auslöser für Prozessausfälle gibt es?
5. 1. Welche Assets werden für die Prozesse benötigt? Was kann mit diesen Assets geschehen, sodass der Prozess nicht mehr oder nicht ausreichend funktioniert?
   2. Welche allgemeinen oder übergreifenden Störungen könnten den Prozess treffen?
5. Wie hoch sind die daraus entstehenden Risiken?
6. Welche Risiken akzeptieren Sie – und für welche benötigen Sie eine Behandlung, z.B. in Form eines Business Continuity-Plans?

Die Kette lautet also: interessierte Partei → Anforderung → Prozess → Ausfalltoleranz → abhängige Assets und übergreifende Störungen → möglicher Ausfall → Risiko → Behandlung.

Was BCM in der ISO 27001 bedeutet

Business Continuity Management, kurz BCM, soll dafür sorgen, dass kritische Tätigkeiten bei Störungen weitergeführt oder innerhalb einer vertretbaren Zeit wieder aufgenommen werden können. Im Zusammenhang mit der ISO 27001 geht es besonders darum, die Informationssicherheit auch während einer Störung aufrechtzuerhalten und die benötigte Informations- und Kommunikationstechnik für die Geschäftsfortführung vorzubereiten.

Dazu passen insbesondere die Maßnahmen A.5.29 zur Informationssicherheit bei Störungen und A.5.30 zur IKT-Bereitschaft für Business Continuity. Die ISO 27001 verlangt damit nicht automatisch ein vollständiges Business-Continuity-Managementsystem nach ISO 22301. Sie erwartet aber sehr wohl, dass ein Unternehmen seine Anforderungen kennt, seine Kontinuität plant und die vorgesehenen Lösungen regelmäßig überprüft.

Ein hübscher Notfallordner allein erfüllt diese Idee nicht. Entscheidend ist, ob das Unternehmen im Ausfall weiß, was unbedingt weiterlaufen muss, welche Ersatzlösung greift und wer was tut.

1. Beginnen Sie bei den interessierten Parteien

Der Ausgangspunkt sind die interessierten Parteien des Informationssicherheitsmanagementsystems. Dazu können Kunden, Behörden, Eigentümer, Mitarbeiter, Versicherer, Dienstleister oder andere Geschäftspartner gehören. Schon beim Einstieg in ein ISO 27001-Projekt lohnt sich deshalb die Frage, wer eigentlich Erwartungen an die Informationssicherheit des Unternehmens hat.

Für BCM interessieren vor allem Anforderungen an die Verfügbarkeit und Fortführung von Leistungen. Diese Anforderungen stehen manchmal sehr deutlich in Verträgen oder Service Level Agreements. Manchmal ergeben sie sich aus Gesetzen, regulatorischen Vorgaben oder schlicht aus einer berechtigten Kundenerwartung. Einen Überblick über solche Quellen brauchen Sie ohnehin bei den rechtlichen und vertraglichen Anforderungen.

Ein Beispiel: Ein Kunde hat einen Premiumtarif gebucht. Darin wird ein Customer Service rund um die Uhr zugesagt. Die interessierte Partei ist der Kunde, sein Interesse ist die Verfügbarkeit der vereinbarten Unterstützung und die konkrete Anforderung lautet: Der Customer Service muss 24/7 erreichbar sein.

Das ist sehr viel brauchbarer als die abstrakte Frage: „Welche Katastrophen könnten uns treffen?“

2. Ordnen Sie die Anforderungen den Prozessen zu

Nun wird geklärt, welcher Prozess die Anforderung erfüllt. Im Beispiel ist das der Prozess „Customer Service Premium“. Dieser muss natürlich innerhalb des Anwendungsbereichs des ISMS liegen, wenn er durch das zertifizierte Managementsystem abgedeckt werden soll.

Geschäftsprozesse sind für das BCM besonders wertvolle Assets: An ihnen hängt die Leistung, für die Kunden bezahlen. Ein Ticketsystem kann wichtig sein. Wirklich kritisch wird sein Ausfall aber erst dadurch, dass ohne dieses System ein benötigter Geschäftsprozess nicht mehr funktioniert.

Deshalb sollten Sie nicht sofort bei Servern, Gebäuden oder einzelnen Anwendungen beginnen. Stellen Sie zuerst fest, welche Geschäftsprozesse Anforderungen interessierter Parteien erfüllen und welche davon für das Unternehmen kritisch sind.

3. Bestimmen Sie die Ausfalltoleranz

„Kritisch“ bedeutet nicht automatisch „darf keine Sekunde ausfallen“. Eine sinnvolle BCM-Betrachtung benötigt deshalb eine zeitliche und eine qualitative Grenze.

Fragen Sie für jeden relevanten Prozess:

• Wie lange kann der Prozess ausfallen, bevor die Folgen nicht mehr tragbar sind?
• Ab wann werden vertragliche Zusagen verletzt?
• Welches Mindestniveau muss während der Störung erhalten bleiben?
• Wie schnell muss der normale Betrieb wiederhergestellt werden?
• Wie viel Datenverlust wäre im äußersten Fall vertretbar?

Beim Customer Service könnten zehn Minuten Ausfall verkraftbar sein. Acht Stunden wären im Premiumtarif vielleicht nicht mehr akzeptabel. Während einer Störung könnte es genügen, Anfragen über einen alternativen Kanal entgegenzunehmen, sie manuell zu dokumentieren und später in das eigentliche Ticketsystem zu übertragen.

Diese Ausfalltoleranz verhindert zwei typische Fehler: Zum einen wird nicht jede kurze Störung gleich zum Unternehmensnotfall erklärt. Zum anderen erkennt man, wann eine Ersatzlösung tatsächlich bereitstehen muss. Eine Lösung, die nach drei Tagen funktioniert, hilft wenig, wenn der Prozess spätestens nach vier Stunden wieder verfügbar sein muss.

4. Erfassen Sie die verbundenen Assets

Jetzt kommt das Assetverzeichnis ins Spiel. Darin sollten nicht nur Laptops und Server stehen. Für einen Geschäftsprozess können ganz unterschiedliche Assets benötigt werden:

• Mitarbeiter (d.h. deren Wissen und Kompetenzen);
• Anwendungen, Datenbanken und Cloud-Dienste;
• Identitäts- und Zugangsmanagement;
• Telefonie, Internet und andere Kommunikationswege;
• Gebäude, Arbeitsplätze, Energie und technische Infrastruktur;
• Lieferanten und ausgelagerte Dienstleistungen;
• Daten und benötigte Dokumentationen.

Für den Customer-Service-Prozess könnten das Ticketsystem, die Telefonanlage, der Identitätsdienst, die Kundendatenbank, die Wissensdatenbank, diensthabende Mitarbeiter, der Rufbereitschaftsplan, die Internetverbindung und mehrere externe Anbieter sein.

Wichtig sind auch Abhängigkeiten zweiter Ordnung. Das Ticketsystem hängt möglicherweise von einem Cloud-Anbieter ab. Der Zugriff auf die Cloud hängt wiederum vom Identitätsdienst ab. Der Identitätsdienst benötigt vielleicht einen externen Mehrfaktorauthentifizierungsdienst. Ein einzelner Prozess kann auf diese Weise an einer erstaunlich langen Kette hängen.

5 Untersuchen Sie die verbundenen Assets

Nun kommt die zentrale Frage für die Szenariofindung. Nehmen Sie jedes verbundene Asset und fragen Sie:

„Was kann mit diesem Asset schiefgehen, sodass der Prozess nicht mehr innerhalb seiner Anforderungen funktioniert?“

Für unser Beispiel entstehen unter anderem folgende Ausfallkandidaten:

• Das Ticketsystem ist nicht erreichbar.
• Der Identitätsdienst funktioniert nicht, sodass sich niemand anmelden kann.
• Telefonie oder Internetverbindung fallen aus.
• Die Kundendaten oder die Wissensdatenbank sind nicht verfügbar.
• Die benötigten Mitarbeiter sind gleichzeitig nicht verfügbar.
• Eine Schlüsselperson mit besonderem Wissen fällt aus.
• Ein externer Anbieter kann seine Leistung nicht erbringen.
• Das vorgesehene Gebäude oder eine ganze Region ist nicht nutzbar.

Damit betrachten Sie nicht nur spektakuläre Ursachen. Für den Geschäftsprozess ist es zunächst zweitrangig, ob das Ticketsystem wegen eines Cyberangriffs, eines Bedienfehlers oder einer technischen Störung ausfällt. Entscheidend ist, dass es nicht verfügbar ist und der Customer Service deshalb seine Zusage möglicherweise nicht mehr erfüllt.

Das macht die Methode zugleich vollständiger und einfacher. Sie suchen nicht im gesamten Universum nach Unglücken, sondern prüfen systematisch die tatsächlichen Abhängigkeiten Ihrer wichtigen Prozesse.

6. Ergänzen Sie allgemeine und übergreifende Störungen

Mit den verbundenen Assets ist die Szenariosuche allerdings noch nicht beendet. Es gibt Störungen, die nicht sinnvoll bei genau einem Asset beginnen. Manche Ereignisse treffen mehrere Abhängigkeiten gleichzeitig, wirken von außen auf das Unternehmen ein oder verändern die gesamte Umgebung, in der ein Prozess stattfinden soll.

Dazu gehören beispielsweise:

• ein länger andauernder Stromausfall in der Stadt oder Region;
• eine großflächige Störung von Internet- oder Telekommunikationsnetzen;
• Hochwasser, Starkregen, Sturm, extreme Hitze oder ein Vulkanausbruch;
• eine Pandemie oder eine andere Ursache, durch die viele Mitarbeiter gleichzeitig ausfallen;
• Verkehrsstörungen, Evakuierungen oder die Sperrung eines größeren Gebiets;
• politische Unruhen, Krieg oder erhebliche Störungen internationaler Lieferketten;
• ein flächendeckender Cybervorfall bei einer verbreiteten technischen Infrastruktur.

Die Liste lässt sich ohne große Mühe bis zum interstellaren Krieg verlängern. Genau deshalb braucht auch dieser Suchweg einen klaren Bezug zum Geschäftsprozess. Fragen Sie nicht nur „Kann dieses Ereignis theoretisch eintreten?“, sondern vor allem: „Kann es unseren Prozess innerhalb des betrachteten Zeitraums so beeinträchtigen, dass seine Ausfalltoleranz überschritten wird?“

Beim Customer Service könnte ein stadtweiter Stromausfall gleichzeitig Büroarbeitsplätze, Internetzugang, Telefonie und Teile der Mobilfunkversorgung treffen. Ein Continuity-Plan, der lediglich vorsieht, bei einem defekten Büro-PC den nächsten freien Laptop zu verwenden, würde an dieser Stelle erkennbar zu kurz greifen.

Dieser zweite Suchweg deckt außerdem gemeinsame Ursachen ab. Wenn Ticketsystem, Identitätsdienst und Telefonie alle beim selben Cloud-Anbieter, im selben Rechenzentrum oder an derselben Stromversorgung hängen, sind sie auf dem Papier verschiedene Assets. In einer übergreifenden Störung können sie trotzdem gemeinsam ausfallen.

Für eine belastbare Szenarioliste brauchen Sie deshalb beides:

• den Blick von innen nach außen: Welche verbundenen Assets benötigt der Prozess und was kann mit ihnen schiefgehen?
• den Blick von außen nach innen: Welche allgemeinen Störungen können den Prozess oder mehrere seiner Abhängigkeiten gleichzeitig treffen?

7. Bilden Sie sinnvolle Szenariogruppen

Trotzdem kann die Liste lang werden. Das bedeutet nicht, dass Sie für jede Ursache ein eigenes 40-seitiges Dokument schreiben sollten. Mehrere Ausfälle können dieselbe Wirkung haben und mit derselben Kontinuitätslösung behandelt werden.

Typische Gruppen sind beispielsweise:

• Arbeitsort nicht verfügbar;
• kritischer IT-Dienst nicht verfügbar;
• Kommunikationsverbindung nicht verfügbar;
• Mitarbeiter oder benötigte Kompetenz nicht verfügbar;
• kritischer Lieferant oder Dienstleister nicht verfügbar;
• wichtige Daten nicht verfügbar oder nicht vertrauenswürdig.

Beim Ausfall des Ticketsystems, des Identitätsdienstes oder der zentralen Internetverbindung könnte in allen drei Fällen ein ähnlicher Ersatzprozess greifen: Anfragen werden über einen alternativen Kanal angenommen, in einer vorbereiteten Liste dokumentiert und nach Wiederherstellung in das Ticketsystem übertragen.

Ein guter Continuity-Plan orientiert sich deshalb meist an der beeinträchtigten Fähigkeit oder am vorgesehenen Ersatzbetrieb – nicht mechanisch an jedem einzelnen kaputten Asset.

8. Lassen Sie das Risikomanagement priorisieren

Jetzt liegen vielleicht 27 Ausfallkandidaten vor. Aber welche davon verdienen tatsächlich eine Behandlung? Diese Entscheidung trifft das Risikomanagement.

Bewertet werden insbesondere die Wahrscheinlichkeit des Ausfalls und seine möglichen Auswirkungen. Dabei helfen die zuvor bestimmten Anforderungen und Ausfalltoleranzen. Ein Prozess, dessen Ausfall nach zwei Stunden hohe Vertragsstrafen, erhebliche Kundenverluste oder regulatorische Konsequenzen verursacht, wird anders bewertet als eine interne Tätigkeit, die problemlos einige Tage warten kann.

Das Ergebnis kann zu unterschiedlichen Entscheidungen führen:

• Risiko mindern: Sie schaffen Redundanz, einen alternativen Kommunikationsweg, Vertretungen, eine manuelle Ersatzlösung oder einen getesteten Wiederanlaufplan.
• Risiko vermeiden: Sie beenden die besonders riskante Tätigkeit oder bieten die betroffene Leistung nicht mehr in dieser Form an.
• Risiko teilen oder übertragen: Sie sichern Teile der Leistung über geeignete Vertragspartner oder Versicherungen ab.
• Risiko akzeptieren: Sie nehmen den möglichen Ausfall bewusst hin, weil weitere Maßnahmen nicht bezahlbar wären, d.h. in keinem wirtschaftlichen Verhältnis zum Schaden stehen.

Auch eine Änderung des SLA kann eine mögliche Behandlung sein. Wird aus einer zugesagten 24/7-Erreichbarkeit eine Leistung zu Geschäftszeiten, kann das vertragliche Risiko sinken oder entfallen. Der technische Ausfall des Customer Service ist damit allerdings nicht verschwunden. Geändert wurde zunächst die Verpflichtung gegenüber dem Kunden.

9. Aus der Risikobehandlung wird ein funktionierender Plan

Für ein nicht akzeptiertes Ausfallrisiko kann ein Continuity-Plan ein Teil der Risikobehandlung sein. Darin sollte so konkret stehen, dass die Beteiligten im Stress nicht erst gemeinsam Philosophie betreiben müssen:

• Woran wird erkannt, dass der Plan aktiviert werden muss? (Wenn es schnell gehen muss, ist ein Stuhlkreis mit Diskussionskeksen nicht das ideale Entscheidungsgremium)?
• Wer entscheidet über die Aktivierung?
• Wer macht jetzt was?
• Welcher Ersatzprozess oder welche technische Alternative wird genutzt?
• Welche Informationen und Hilfsmittel werden benötigt?
• Wer muss intern und extern informiert werden?
• Wie wird zum Normalbetrieb zurückgekehrt?

Der Plan gehört zu den dokumentierten Informationen, die im entscheidenden Moment verfügbar sein müssen. Es wäre daher etwas unglücklich, wenn der Plan zur Wiederherstellung des ausgefallenen Systems ausschließlich in genau diesem System gespeichert wäre.

Vor allem muss die im Plan beschriebene Fähigkeit wirklich existieren. Ein Satz wie „Bei Ausfall arbeiten die Mitarbeiter einfach manuell weiter.“ ist noch keine belastbare Lösung. Gibt es das benötigte Formular? Sind die Kontaktdaten verfügbar? Können die Mitarbeiter den Ersatzprozess anwenden? Reicht seine Kapazität für das vereinbarte Mindestniveau?

10. Testen Sie nicht nur das Dokument

Ein ungeprüfter Continuity-Plan ist zunächst eine Hypothese. Erst eine Übung zeigt, ob Rufnummern stimmen, Zugänge funktionieren, Zuständigkeiten verstanden wurden und die Ausfalltoleranz tatsächlich eingehalten werden kann.

Tests müssen nicht immer das gesamte Unternehmen für einen Tag lahmlegen. Je nach Risiko können ein gemeinsamer Durchgang am Tisch, ein technischer Wiederherstellungstest oder eine begrenzte praktische Übung angemessen sein. Entscheidend ist, dass die entscheidenden Annahmen überprüft und erkannte Schwächen verbessert werden.

Dabei ist auch eine klare Kommunikationsplanung wichtig. Ein technisch funktionierender Ersatzbetrieb hilft wenig, wenn Kunden, Mitarbeiter oder Dienstleister nicht wissen, welcher Kanal nun verwendet werden soll.

Was will der Auditor sehen?

In einem Audit ist keine möglichst dramatische Sammlung denkbarer Katastrophen gefragt. Überzeugend ist eine nachvollziehbare Herleitung:

• Die Anforderungen interessierter Parteien sind bekannt.
• Die davon betroffenen Prozesse und ihre Ausfalltoleranzen wurden bestimmt.
• Die Abhängigkeiten zu Menschen, Technik, Informationen, Standorten und Dienstleistern sind nachvollziehbar.
• Allgemeine Störungen und mögliche gemeinsame Ausfallursachen wurden ergänzend betrachtet.
• Relevante Ausfallrisiken wurden systematisch identifiziert und bewertet.
• Nicht akzeptierte Risiken wurden behandelt.
• Die vorgesehenen Continuity-Lösungen und Pläne wurden erprobt und verbessert.

Damit ist erkennbar, warum ein bestimmter Plan existiert – und ebenso, warum für einen anderen denkbaren Ausfall bewusst keiner benötigt wird.

Interesse geweckt?

Wenn Sie Ihr BCM nicht aus einer zufälligen Liste von Katastrophen, sondern nachvollziehbar aus Ihren Geschäftsprozessen, Abhängigkeiten und Risiken ableiten möchten, Sprechen Sie mit uns.