Business Impact Analysis: die 10 wichtigsten Aufgaben bei der BIA
IT-Recovery kostet Geld, aber der Ertrag ist oft erst nach einer Katastrophe ersichtlich. Korrekte Business Impact Analysis hilft bei der Umsetzung.
Business Impact Analysis oder BIA hat einen zentralen Stellenwert, wenn es um die Planung von Business Continuity (BC) und Disaster Recovery (DR) geht. Beides sind notwendige Maßnahmen, um den langfristigen Geschäftserfolg zu sichern, werden aber im Alltag der IT häufig vernachlässigt. Umso wichtiger ist es, bestimmte Regeln und Verfahrensweisen für Business Impact Analysis zu beachten.
Und das sagt das BSI zu BIA
„Eine Business Impact Analyse (Folgeschädenabschätzung) ist eine Analyse zur Ermittlung von potentiellen direkten und indirekten Folgeschäden für eine Institution, die durch das Auftreten eines Notfalls oder einer Krise und Ausfall eines oder mehrerer Geschäftsprozesse verursacht werden.“
(Quelle: Bundesamt für die Sicherheit in der Informationstechnik (BSI), Glossar und Begriffsdefinitionen)
BIA lässt sich dabei als ein Set von Anforderungen an Recovery bei Datenverlust definieren, bei dem Prioritäten und Investmentempfehlungen für das obere Management festgelegt werden. Dabei geht es um Budgets für Backup, Spiegelung der Datenbestände, Ausweichrechenzentren, oder -Gebäude, redundante Geräte und weitere Ressourcen. Es muss auch im Vorhinein festgelegt werden, welche Beschädigungen und Ausfälle besonders zu berücksichtigen sind und was an Vorsichtsmaßnahmen getroffen werden muss, bevor überhaupt ein relevanter Schaden eingetreten ist.
Leider machen viele IT- und Business-Verantwortliche Fehler, wenn sie BIA einsetzen. Ich spreche aus Erfahrung, da ich selbst mehr als 100 BIA-Prozesse durchgeführt habe. Und dabei habe ich jeden nur möglichen Fehler begangen. Ich habe hier die 10 am meisten verbreiteten Fehler zusammen getragen, damit sich jeder an BIA Interessierte rechtzeitig ein Bild machen kann von dem, was man tun und was man besser unterlassen sollte.
Checkliste: Die Top 10 der Aufgaben für eine BIA
- Nicht nur auf Ausfälle der Applikationen achten, sondern auch auf die Geschäftsfunktionen: Der Motor einer Business Impact Analysis ist das Unternehmen als Ganzes. Die erste Frage, die man sich bei BIA stellen muss, sind die möglichen Auswirkungen auf die gesamte Organisation, wenn eine einzelne Geschäftsfunktion nicht mehr durchgeführt werden kann. Die zweite Frage dreht sich darum, auf welchen Anwendungen diese Funktion beruht.
- Applikationen nicht isoliert betrachten: Während Business User gewöhnlich wissen, welche Anwendungen für sie wichtig sind, sind sie sich oft nicht darüber im Klaren, von welchen anderen Software- oder Infrastruktur-Komponenten diese abhängen. Will man die Bedeutung einzelner Applikationen genauer eingrenzen, muss man die Gesamtheit der IT-Umgebung verstehen: Diese besteht nun einmal aus Servern, Storage, Netzwerk, weiteren Infrastrukturelementen und dem ganzen Software-Portfolio.
- Finanzielle Auswirkungen entsprechende Aufmerksamkeit schenken: Man sollte sich nicht fragen: „Wieviel Geld geht verloren, wenn eine bestimmte Anwendung nicht mehr läuft?“ Das würde zu viele andere Fragen nach sich ziehen, zum Beispiel: Können die Verluste wieder hereingeholt werden, wenn das System wieder hergestellt ist? Werden bei einem Ausfall neben sinkenden Verkaufserlösen auch Kunden verloren gehen? Wie viel konkreter Verlust kann einer einzelnen Applikation zugeordnet werden? Wenn man eine Business Impact Analysis durchführt, werden oft finanzielle Informationen gesammelt und dann doch nicht für die Auswahl von Recovery-Anforderungen genutzt, weil es zu kompliziert ist. Man sollte sich stattdessen bei einem größeren Ausfall mit den Auswirkungen auf die Gewinn- und Verlustrechnung konzentrieren, sowie auf die Kapital- und Betriebskosten, die bei der Wiederherstellung der betroffenen Systeme anfallen.
- Nicht nur die finanziellen Auswirkungen im Blick haben: Neben dem finanziellen Verlust gibt es Folgeschäden, die für das Top-Management von größerer Bedeutung sein können. Dazu gehören die möglichen Auswirkungen auf den Ruf des Unternehmens und auf die Kundenbindung. Darüber hinaus können Missverständnisse darüber bestehen, welche Rolle einige Geschäftsverantwortliche selbst im Unternehmen spielen. Deshalb schreiben sie die finanziellen Auswirkungen vorschnell den für sie wichtigen Anwendungen zu und nicht dem gesamten Geschäftsumfang.
- Enterprise-Anwendungen richtig einschätzen: Einige Anwendungen sind wichtiger als andere, weil sie dem Unternehmen als Ganzes dienen. Welche es genau sind, ist für das Management oft schwierig einzuschätzen. Applikationen, die nur für eine einzelne Geschäftsfunktion eingesetzt werden oder die vielen Aufgaben in unterschiedlicher Weise dienen, sind oft schwer in ihrer Bedeutung zu erkennen. Bei anderen Applikationen wie Enterprise Resource Planning (ERP) und Customer Relationship Management (CRM) liegt ihr geschäftlicher Stellenwert dagegen auf der Hand.
- Data-Center-Applikationen erkennen: Einige Applikationen dienen nicht direkt den Geschäftsanforderungen. Dazu gehören Betriebssysteme, Managementsysteme für Datenbanken oder Data-Center-Tools, die Geschäftsanwendungen unterstützen. Es ist leicht zu behaupten, dass alle Infrastrukturkomponenten noch vor den eigentlichen Applikationen geschützt und wiederhergestellt werden müssen. Aber muss zum Beispiel das Betriebssystem auf irgendeinem obskuren Server, der sich mit Datenauswertung befasst, wirklich noch vor den Kredit-, Handels- oder Inventarsystemen wiederhergestellt werden?
- Risikobewertung nicht mit Business Impact Analysis verwechseln: Eine Risikobewertung definiert, was einen Ausfall verursachen könnte, während eine Business Impact Analysis die Auswirkungen aufzeigt, wenn ein solcher Katastrophenfall eingetreten ist. Es hat in den letzten Jahren zu viele ursprünglich für unwahrscheinlich erachtete Ereignisse gegeben, die dazu geführt haben, dass beide Ansätze miteinander verwechselt werden. Dies liegt zum Teil an der unterschiedlichen Zeitdauer von Betriebsunterbrechungen, ungeachtet ihrer tatsächlichen Ursachen.
- Risikoakzeptanz nicht mit Business Impact Analysis verwechseln: Wenn ein Manager bereit ist, das Risiko der Nichtverfügbarkeit einer Anwendung auf sich zu nehmen, bedeutet das nicht, dass man eventuelle Auswirkungen außer Acht lassen sollte. Allerdings verzichten die Verantwortlichen oft darauf, Zeit und Aufwand in die Durchführung einer Business Impact Analysis zu investieren. Damit machen sie es sich zu leicht, da sie sich nicht im Klaren über die möglichen Auswirkungen eines Ausfalls sind. Es ist eine Sache, wenn ein Verantwortlicher das Risiko für seinen Bereich und „seine“ Applikationen in Kauf nimmt, es ist aber etwas total anderes, damit das ganze Unternehmen zu gefährden.
- BIA-Resultate abwarten: Manchmal erscheinen die Resultate eines BIA-Prozesses den verantwortlichen Managern so offensichtlich, dass sie automatisch die Antworten antizipieren, ohne sich die Mühe zu machen, den ganzen BIA-Prozess zu durchlaufen. Solche Annahmen sind vielleicht bis zu 80 Prozent korrekt, aber das bedeutet nichts anderes, als dass sie zu 20 oder mehr Prozent nicht korrekt sind. Mit anderen Worten: Eine von fünf Geschäftsfunktionen oder Applikationen ist nur unzureichend analysiert worden. Die wirkliche Konsequenz solcher Unterlassungen wird vielleicht erst dann bemerkt, wenn eine Katastrophe voll eingetreten ist – aber dann ist es zu spät.
- Sich nicht ausschließlich auf BIA-Resultate verlassen: IT- und Geschäftsverantwortliche tendieren manchmal dazu, die finanziellen, betrieblichen oder rufschädlichen Auswirkungen eines Ausfalls „ihrer“ Applikationen zu unterschätzen, weil sie nur die Kosten einer späteren Wiederherstellung im Auge haben. Von den 10 hier aufgeführten Fehlern ist dieser der bei weitem am heimtückischste: Er negiert in voller Absicht die offensichtliche Notwendigkeit, sich rechtzeitig per BIA auf ein notwendiges Recovery vorzubereiten. Es mag noch angehen, Verständnis dafür aufzubringen, dass Manager eher die aktuellen Budget-Probleme sehen als mögliche zukünftige Katastrophen, die eintreten können – oder auch nicht eintreten können. Aber mit dieser Haltung gefährden sie letztlich das ganze Unternehmen.
Über den Autor: Steven Ross ist Executive Principal bei Risk Masters Inc. und ist zertifiziert als Master Business Continuity Professional (MBCP). Er arbeitet als Spezialist für Business Continuity Management, Crisis Management und IT Disaster Recovery Planning. Er ist Herausgeber der Buchreihe “e-Commerce Security” und hat dort als Autor auch mehrere Bücher verfasst, darunter „e-Commerce Security: Business Continuity Planning“.
Folgen Sie SearchStorage.de auch auf Twitter, Google+, Xing und Facebook!
