Eine Business-Impact-Analyse (BIA) ist eine Recherche zur Sammlung und Identifizierung von Prozessen innerhalb einer Organisation, um die Kritikalität jedes Prozesses und die Auswirkungen bei einem möglichen Ausfall festzustellen.

Inhaltsverzeichnis

• Definition Business Impact Analyse
• Was ist der Unterschied zwischen Business Impact Analyse und Risikobewertung?
• Beispiel eines Fragebogens einer Business Impact Analyse
• Durchführung einer Business Impact Analyse

Während einer Business Impact Analyse untersuchen Unternehmen, welche Auswirkungen es hat, wenn bestimmte Geschäftsprozesse durch Zwischenfälle wie Brände, Unwetter oder Malware ausfallen. Ihr Ziel ist es, der Geschäftsführung des Unternehmens Empfehlungen für die Erstellung eines Business Continuity Plans oder eines Disaster Recovery Plans zu geben. 

Meist führen der Notfallkoordinator und sein Team die Business Impact Analyse durch. Dabei gehen sie in mehreren Schritten vor. Zunächst machen sie eine Untersuchung, die meist aus einer Reihe von Interviews und Workshops mit den Mitarbeitern des Unternehmens besteht, um Geschäftsprozesse zu identifizieren, mögliche Schäden durch ihren Ausfall zu beziffern und Abhängigkeiten zu erkennen. Auf die Recherche folgt ein Planungs- und Analyseteil, bei dem das Notfallteam eine Priorisierung trifft und festlegt, für wie lange der Ausfall eines bestimmten Prozesses für das Unternehmen tolerierbar ist. 

Schließlich erstellt das Notfallteam einen Business Impact Report, den es der Geschäftsführung vorlegt. Dieser stellt die Auswirkungen von Geschäftsprozessen dar, legt maximal tolerierbare Ausfallzeiten fest und priorisiert Geschäftsfunktionen. Zudem gibt er konkrete Empfehlungen für Maßnahmen, um Auswirkungen von Ausfällen zu begrenzen und einen Disaster Recovery Plan oder ein Notfallhandbuch zu erstellen.

Sowohl die Business Impact Analyse als auch die Risikobewertung sind wichtige Schritte bei der Erstellung eines Disaster Recovery- oder Business Continuity Plans. Dabei konzentriert sich die Business Impact Analyse jedoch allein auf die Konsequenzen, welche die Unterbrechung bestimmter Geschäftsprozesse haben kann, wobei die Gründe und die Wahrscheinlichkeit für ihren Ausfall nicht im Fokus stehen. 

Die Risikobewertung dagegen identifiziert potenzielle Gefahren wie Unwetter, Erdbeben, IT-Zwischenfälle oder Ausfälle von Zulieferern. Sie spielt diese Szenarien durch und schätzt ab, wie wahrscheinlich ihr Eintritt ist und wie groß die Auswirkungen für das Unternehmen wären, um schließlich Empfehlungen für Maßnahmen zur Vorbeugung und zur Begrenzung der möglichen Schäden zu geben. 

Die Business Impact Analyse und die Risikobewertung ergänzen sich gegenseitig. Die Business Impact Analyse wird jedoch meist vor der Risikobewertung durchgeführt, da Auswirkungen eines Zwischenfalls einfacher nachvollziehen sind, wenn alle Abhängigkeiten bekannt sind.

Ein strukturierter Fragebogen zur Vorbereitung der Interviews spart dem Notfallteam Zeit und liefert präzise, vergleichbare Daten. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) stellt auf seiner Website einen beispielhaften Fragebogen zur Verfügung, der für die meisten KMUs geeignet ist. Dieser umfasst die folgenden Punkte:

• Welche Auswirkungen (1 - niedrig, 2 - mittel, 3 - hoch, 4 - sehr hoch) hat es auf das Unternehmen, wenn der Kernprozess ausfällt?
• Welche Auswirkungen (1 - niedrig, 2 - mittel, 3 - hoch, 4 - sehr hoch) hat ein Datenverlust auf das Unternehmen?
• Welche IT-Systeme sind für einen Notbetrieb des Prozesses zwingend erforderlich?
• Welche der IT-Systeme enthalten Daten, die bei einem Verlust nicht wiederbeschafft werden können?
• Gibt es Alternativen oder alternative Arbeitsabläufe zu diesen IT-Systemen?
• Welche IT-Dienstleister sind für einen Notbetrieb des Prozesses zwingend erforderlich?
• Gibt es Alternativen oder alternative Arbeitsabläufe zu diesen IT-Dienstleistern?

Den Fragebogen stellt das BSI als Template einer Word-Formatvorlage zum Download bereit. Zudem bietet es beispielhaft einen bereits ausgefüllten Fragebogen für die Geschäftsbereiche Finanzbuchhaltung, Vertrieb und Produktion als PDF.

Eine Business Impact Analyse ist ein mehrstufiger Prozess, der folgende Schritte umfasst:

1. Sammeln von Informationen.
2. Evaluierung und Analyse der Informationen.
3. Ausarbeiten von Empfehlungen.
4. Präsentation des Reports vor dem Management.

Verschiedene Standards für Business Continuity Management geben eine Leitlinie, wie das Notfallteam bei einer BIA vorgehen soll. So ist zum Beispiel die Dokumentation der ISO-Richtlinien ISO 22301 ein guter Startpunkt. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) stellt in seinem Standard BSI 100-4 eine Methodik zur Etablierung eines Notfallmanagements vor, der detailliert die Schritte für eine Business Impact Analyse darstellt. Mit dem Umsetzungsrahmenwerk zum Standard 100-4, kurz UMRA, stellt das BSI zudem nicht nur einzelne Vorlagen, sondern einen kompletten Werkzeugkasten kostenlos zur Verfügung. Hier eine Zusammenfassung der Empfehlungen des BSI für das Vorgehen bei einer BIA:

Der erste Schritt einer Business Impact Analyse ist immer, eine umfassende Übersicht aller Geschäftsprozesse zu erstellen. Es gibt allerdings keine exakte Definition, was genau unter einem Prozess zu verstehen ist. Es hat sich aber bewährt, unter einem Prozess den gesamten Weg eines Produkts vom Hersteller bis zum Verbraucher zu sehen. Jeder Prozess erhält einen bestimmten Input – dies kann ein Rohstoff, Bauteile, Vorprodukte aber auch Daten oder Dienstleistungen sein – und schafft einen Output. In- und Output stellen die Verbindungen zwischen mehreren Prozessen her. Für jeden Geschäftsprozess sollte das Notfallteam folgende Angaben festhalten:

• Eine klare Bezeichnung des Prozesses.
• Eine kurze Beschreibung.
• Den benötigte Input.
• Den Output.
• Teilprozesse, in die der Prozess aufgeteilt ist.
• Verknüpfungen zu anderen Prozessen wie Vorgänger und Nachfolger.
• Den Grad der Abhängigkeiten zu anderen Prozessen.
• Den Ansprechpartner für den Prozess.

Um den Aufwand und die Kosten der Business Impact Analyse zu verringern, kann das Notfall-Team Abteilungen und Geschäftsprozesse, bei denen ein durchgängiger Betrieb offensichtlich nicht kritisch ist, aussparen – zum Beispiel das Marketing.

Der nächste Schritt ist, die Geschäftsprozesse einen nach dem anderen durchzugehen und in Interviews mit den Verantwortlichen festzustellen, wie groß die Schäden bei einem Ausfall wären. Schäden können einerseits finanziell sein durch entfallenden Umsatz oder Strafzahlungen, andererseits immateriell durch Imageschäden oder Verluste von Marktanteilen. 

Wo möglich, sollte das Notfallteam bei den Interviews Schäden sowohl quantitativ, also in Form von Geldsummen, und qualitativ durch eine Kategorisierung wie “niedrig”, “ normal”,  “hoch” und “sehr hoch” bewerten. Üblicherweise legen Notfallteams drei bis fünf solcher Kategorien fest. 

Bei solch einer qualitativen Kategorisierung ist es entscheidend, dass die Bewertungen unmissverständlich definiert sind. Denn Mitarbeiter in verschiedenen Bereichen des Unternehmens interpretieren diese Kategorien vielleicht unterschiedlich. Für den IT-Leiter fällt der Ausfall eines Servers vielleicht in die Kategorie “sehr hoch”, weil er daran denkt, wie viel Arbeit die Wiederherstellung des Systems für sein Team bedeutet, während der Geschäftsführer die finanziellen Auswirkungen für das Unternehmen eher als “niedrig” einstuft. Hier ein Beispiel:

Notfallteams müssen auch berücksichtigen, dass Schäden zu unterschiedlichen Zeitpunkten verschieden starke Auswirkungen haben. Einen Online-Handel trifft ein Ausfall während des Vorweihnachtsgeschäfts zum Beispiel ungleich härter als während des Sommers. Während der Gehaltsabrechnung hat ein Ausfall der Lohnbuchhaltung stärkere Auswirkungen als sonst.

Wenn Notfallteams das Schadensniveau jedes Prozesses kennen, können sie festlegen, wie lange der Vorgang ausfallen darf, bevor die Konsequenzen für das Unternehmen nicht mehr tolerierbar sind. Diese Zeitspanne nennt man die maximal tolerierbare Ausfallzeit (MTA). Ziel muss es sein, dass die Prozesse vor Ende der MTA wieder funktionieren. Dieses Zeitziel nennt man Recovery Time Objective (RTO) oder auf Deutsch Wiederanlaufzeit. Das RTO setzt sich aus der Zeit bis zur Entdeckung des Vorfalls, der Reaktionszeit und der benötigten Zeit für den eigentlichen Wiederanlauf, also dem Beginn des Notbetriebs zusammen. Zu den Parametern, die das Notfallteam für jeden Prozess festlegen muss, gehört auch das Wiederanlaufniveau. Es bestimmt, welche Funktionen des Betriebs verfügbar sein müssen, bevor der Normalbetrieb wieder hergestellt werden kann.

Abhängigkeiten zwischen Prozessen können dazu führen, dass Wiederanlaufzeiten einzelner Vorgänge angepasst werden müssen. Benötigt ein Prozess den Output oder die Dienstleistung eines anderen, müssen beide Prozesse wiederhergestellt werden und daher auch dasselbe RTO haben. Daher ist es notwendig, Abhängigkeiten jedes Prozesses festzustellen und bei Bedarf Verfügbarkeitsanforderung auf zuarbeitende Vorgänge zu vererben. Solche Vererbungen der RTO können auch granular getroffen werden. Empfehlenswert sind dabei drei bis sechs Abhängigkeitsstufen wie 1=”sehr hoch” oder 6=”gering”. Dabei drückt “sehr hoch” eine 1-zu-1-Übernahme der Wiederanlaufzeit aus, während gering bedeutet, dass keine Vererbung notwendig ist.

Sind die RTOs für die Geschäftsprozesse festgelegt und abgestimmt, liegt damit auch eine Priorisierung der Prozesse vor. Da das RTO nach dem Schadensniveau festgelegt wird, bedeutet eine kürzere Wiederanlaufzeit automatisch auch eine höhere Kritikalität des Prozesses. Es hilft jedoch im Sprachgebrauch, die Prozesse in Klassen wie “hoch kritisch”, “kritisch” bis hin zu “unkritisch” zu kategorisieren. So kann sich das Notfallmanagement auf die als kritisch identifizierten Prozesse konzentrieren.

Hat das Notfallteam schließlich die kritischen Geschäftsprozesse identifiziert, muss es nun feststellen, welche Ressourcen für ihren Normal- und Notbetrieb notwendig sind. Ressourcen können die Stromversorgung sein, der Zugriff auf eine Datenbank oder SAP, eine Internet-Anbindung oder ein bestimmter Mitarbeiter, der ein spezielles Fachwissen besitzt. Hier eine Liste möglicher Ressourcen:

• Personal
• Informationen
• IT-Technologie
• Spezialgeräte
• Dienstleistungen
• Infrastruktur
• Betriebsmittel

Bei jeder Ressource sollte das Notfallteam den Nutzungsgrad für den Prozess feststellen und in Kategorien von 1= sehr hoch, also unentbehrlich für den Prozess, bis 4=gering einordnen. So kann es die Single Points of Failure identifizieren, also sehr kritische Ressourcen, deren Ausfall einen Komplettausfall des Prozesses auslösen würden. Diese muss es dokumentieren und schnellstmöglich Maßnahmen zu ihrer Absicherung einleiten. 

Neben den Ressourcen für den Normalbetrieb muss das Notfallteam auch die erforderlichen Ressourcen für den Notbetrieb dokumentieren. Dies kann darin bestehen, dass das Unternehmen auf einen Alternativprozess wechselt oder den Prozess mit reduzierten Kapazitäten fährt.

Der Bericht der Business Impact Analyse sollte alle wichtigen Informationen, die bei der BIA erhoben wurden, enthalten. Dazu gehören zum Beispiel Rahmenbedingungen und verwendete Methoden sowie eine Übersicht, die Prozesse und Abhängigkeiten darstellt. Für jeden Prozess sollte es eine Einzelbewertung mit Schadensanalyse, eine Priorisierung für die Wiederherstellung sowie eine Übersicht der notwendigen Ressourcen und ihrer Single Points of Failure geben.

Stellen Sie während einer Business Impact Analyse technische Lücken beim Notfallmanagement fest, kann eine Cloud-Lösung eine einfach zu implementierende Option sein. In einem Vergleichstest der Fachzeitschrift the cloud report belegte die Open Telekom Cloud in der Kategorie Backup den ersten Platz. Die Redaktion wies darauf hin, dass die Open Telekom Cloud den „größten Funktionsumfang bei moderaten Kosten“ von allen getesteten Cloud-Anbietern habe. 

Einige unserer Dienste werden standardmäßig in einem Hochverfügbarkeitscluster ausgeführt, das vor katastrophalen Ereignissen schützt. So stellt der Object Storage Service (OBS) der Open Telekom Cloud zum Beispiel identische und ständig aktualisierte Kopien der Daten in zwei deutsche Rechenzentren innerhalb von 3 Verfügbarkeitszonen zur Verfügung. Auch für Virtual Machines aus dem Elastic-Cloud-Server-Angebot und Blockspeicher des Elastic Volume Service (EVS), kann mit Hilfe des Storage Disaster Recovery Service (SDRS) ein solches Hochverfügbarkeitscluster mit Failover-Funktionen geschaffen werden. 

Zum Schutz vor kleineren Vorfällen wie Ransomware-Attacken, versehentlicher Löschung oder mutwilliger Manipulation durch Hacker, bietet die Open Telekom Cloud Backup-Lösungen wie Cloud-Backup Recovery (CBR) Service oder den Cloud Server Backup Service (CSBS) an, mit dem sich ganze Systemlandschaften automatisch sichern lassen können. 

Benötigen Sie zusätzlich geografische Redundanz mit größeren Entfernungen zwischen den Rechenzentren, können Sie auch unsere zweite Region in Amsterdam nutzen, um eine Backup- oder Disaster-Recovery-Lösung auf virtuellen Maschinen zu betreiben. Die Standorte sowie die Entfernung zwischen unseren deutschen und niederländischen Rechenzentren genügen den Empfehlungen des BSI für Georedundanz.

Welche weiteren Lösungen die Open Telekom Cloud hier anbietet, erfahren Sie auf unserer Übersichtsseite Disaster Recovery.