01710 Business Continuity Management
Pandemien, Naturkatastrophen, Terrorakte oder der Ausfall wichtiger Produktionsfaktoren in der Lieferkette sind Ereignisse, die Ihr Unternehmen für Tage, Wochen, Monate oder sogar für immer lahmlegen können. Mit einem funktionierenden Business Continuity Management (BCM) können Sie Ihr Unternehmen für solche Fälle vorbereiten. Stellen Sie sicher, dass kritische Geschäftsprozesse und IT Services auch in schwierigen und unklaren Situationen ausreichend funktionieren.
Dieser Beitrag beschreibt auf der Basis etablierter Standards und praktischer Projekterfahrung die einzelnen Schritte zum Aufbau eines BCM im Unternehmen und seiner Etablierung, Aufrechterhaltung und Verbesserung als permanenter Prozess. Arbeitshilfen: von: |
1 BCM-Initiierung
BCMS
Es ist sinnvoll, das Thema BCM nach einem etablierten Standard anzugehen, beispielsweise nach der ISO 22301. Dazu wird, ganz analog etwa zu einem Information Security Management System (ISMS) nach ISO 27001, ein risikoorientiertes Business Continuity Management System (BCMS) aufgebaut. Wer schon ein anderes Managementsystem (Qualität, Informationssicherheit) eingeführt hat, kann dabei Synergieeffekte nutzen, denn einige grundsätzliche Arbeiten wie etwa die Aufstellung der kritischen Geschäftsprozesse oder die Klassifizierung von Risiken müssen nur einmal erledigt werden.
Es ist sinnvoll, das Thema BCM nach einem etablierten Standard anzugehen, beispielsweise nach der ISO 22301. Dazu wird, ganz analog etwa zu einem Information Security Management System (ISMS) nach ISO 27001, ein risikoorientiertes Business Continuity Management System (BCMS) aufgebaut. Wer schon ein anderes Managementsystem (Qualität, Informationssicherheit) eingeführt hat, kann dabei Synergieeffekte nutzen, denn einige grundsätzliche Arbeiten wie etwa die Aufstellung der kritischen Geschäftsprozesse oder die Klassifizierung von Risiken müssen nur einmal erledigt werden.
BCMS als Führungsaufgabe
Wie jedes Managementsystem muss auch ein BCMS in der Führungsebene der Organisation verankert sein. Nur so können die erforderlichen Ressourcen zu Aufbau und Betrieb des BCMS bereitgestellt und kann für die Kompetenz der mit dem BCMS befassten Mitarbeiter gesorgt werden.
Wie jedes Managementsystem muss auch ein BCMS in der Führungsebene der Organisation verankert sein. Nur so können die erforderlichen Ressourcen zu Aufbau und Betrieb des BCMS bereitgestellt und kann für die Kompetenz der mit dem BCMS befassten Mitarbeiter gesorgt werden.
1.1 BCMS als Projekt
BCM-Beauftragter
Die Einführung von BCM sollte als ganz normales Projekt angegangen werden, d. h., es ist ein Verantwortlicher zu benennen (etwa ein BCM-Beauftragter), der entsprechende Kompetenzen, ein Budget sowie Zugriff auf interne oder externe Mitarbeiter hat.
Die Einführung von BCM sollte als ganz normales Projekt angegangen werden, d. h., es ist ein Verantwortlicher zu benennen (etwa ein BCM-Beauftragter), der entsprechende Kompetenzen, ein Budget sowie Zugriff auf interne oder externe Mitarbeiter hat.
Dabei ist zu beachten, dass bei einem BCM-Projekt in der Regel viele Personen beteiligt sind. Insbesondere ist die Business Impact Analysis (BIA), bei der der Verlauf eines Schadens über die Zeit bei Ausfall eines Prozesses bestimmt wird, eine dezentrale Aufgabe.
Asset Owner
Für jeden Prozess bzw. für jede Anwendung, mit der ein Prozess modelliert wird, gibt es einen verantwortlichen Asset Owner. Dieser kennt sein Asset so gut, dass er die mit BCM verbundenen Überlegungen etwa zum Schaden oder zum maximal vertretbaren Datenverlust bei Ausfall treffen kann. Der Asset Owner ist in der Regel ein Mitarbeiter aus dem Business, der die geschäftlichen Auswirkungen seines Assets abschätzen kann, aber nicht über fundierte IT-Kenntnisse verfügt.
Für jeden Prozess bzw. für jede Anwendung, mit der ein Prozess modelliert wird, gibt es einen verantwortlichen Asset Owner. Dieser kennt sein Asset so gut, dass er die mit BCM verbundenen Überlegungen etwa zum Schaden oder zum maximal vertretbaren Datenverlust bei Ausfall treffen kann. Der Asset Owner ist in der Regel ein Mitarbeiter aus dem Business, der die geschäftlichen Auswirkungen seines Assets abschätzen kann, aber nicht über fundierte IT-Kenntnisse verfügt.
System Owner
Sofern ein Asset mittels IT unterstützt wird, benötigt der Asset Owner Unterstützung seitens der IT. Dazu wird ihm ein System Owner (auch Asset Manager oder IT Custodian genannt) zu Seite gestellt, der Fragestellungen zur IT dieses Assets bearbeiten kann (etwa Wiederanlaufpläne). In der Regel ist der System Owner die Person, die für die Administration der für das Asset benötigten IT-Systeme zuständig ist.
Sofern ein Asset mittels IT unterstützt wird, benötigt der Asset Owner Unterstützung seitens der IT. Dazu wird ihm ein System Owner (auch Asset Manager oder IT Custodian genannt) zu Seite gestellt, der Fragestellungen zur IT dieses Assets bearbeiten kann (etwa Wiederanlaufpläne). In der Regel ist der System Owner die Person, die für die Administration der für das Asset benötigten IT-Systeme zuständig ist.
Asset Owner und System Owner der an kritischen Geschäftsprozessen beteiligten Assets sind also in jedem Fall beim BCM-Projekt involviert. In der Summe können da erhebliche Aufwände entstehen, die in die BCM-Projektplanung einzubeziehen sind.
1.2 Geltungsbereich
Der Geltungsbereich, auch Anwendungsbereich oder Scope genannt, umfasst alle Prozesse, Anwendungen und Systeme, für die das BCMS gelten soll. Bei der Definition des Geltungsbereichs sind auch die Schnittstellen nach außen zu benennen, die aus Sicht des BCMS wie Kunden-/Lieferantenverhältnisse zu betrachten sind.
1.2.1 Einflussfaktoren
Die Festlegung des Geltungsbereichs ist keine triviale Fragestellung. Wenn man sich erst auf einen Geltungsbereich festgelegt und mit der Planung oder Implementierung des BCMS begonnen hat, ist eine spätere Modifikation schwierig bis unmöglich. Der Geltungsbereich muss deshalb in enger Zusammenarbeit mit der Leitungsebene erstellt und von dieser abgesegnet werden.
Die folgenden Überlegungen sollten bei der Definition des Geltungsbereichs berücksichtigt werden.
Andere Managementsysteme
Wenn es schon ein anderes funktionierendes Managementsystem gibt, kann man bei den BCMS-Überlegungen mit dessen Geltungsbereich starten. Stellt man später bei der Zusammenstellung der für BCM kritischen Geschäftsprozesse fest, dass diese nicht alle enthalten sind, wird der Geltungsbereich entsprechend erweitert.
Wenn es schon ein anderes funktionierendes Managementsystem gibt, kann man bei den BCMS-Überlegungen mit dessen Geltungsbereich starten. Stellt man später bei der Zusammenstellung der für BCM kritischen Geschäftsprozesse fest, dass diese nicht alle enthalten sind, wird der Geltungsbereich entsprechend erweitert.
BCMS und ISMS
Es muss berücksichtigt werden, dass das Notfallmanagement für Informationen und IT-Systeme bereits Bestandteil eines ISMS ist. Es ist daher wichtig, beim allgemeinen Notfallmanagement auch die Geschäftsprozesse zu betrachten, die nichts oder nur wenig mit Informationen und/oder IT-Systemen zu tun haben.
Es muss berücksichtigt werden, dass das Notfallmanagement für Informationen und IT-Systeme bereits Bestandteil eines ISMS ist. Es ist daher wichtig, beim allgemeinen Notfallmanagement auch die Geschäftsprozesse zu betrachten, die nichts oder nur wenig mit Informationen und/oder IT-Systemen zu tun haben.
Notfallszenarien
Zur Erleichterung dieser Betrachtung sollten einige Notfallszenarien durchgespielt werden. Dabei wird ermittelt, welche Szenarien sich wie auf die Fortführung des Geschäftsbetriebs auswirken. Betrachtet werden in der Regel die Szenarien
Zur Erleichterung dieser Betrachtung sollten einige Notfallszenarien durchgespielt werden. Dabei wird ermittelt, welche Szenarien sich wie auf die Fortführung des Geschäftsbetriebs auswirken. Betrachtet werden in der Regel die Szenarien
• | IT fällt aus, |
• | Standort fällt aus, |
• | Personal fällt aus, |
• | Dienstleister fällt aus und |
• | Hackerangriff (IT fällt nicht aus, ist aber kompromittiert). |
Je nach Geschäftsmodell kann es sinnvoll sein, weitere Szenarien in die Überlegungen einzubeziehen.
1.2.2 Kritische Geschäftsprozesse
Produkte und Dienstleistungen zur Wertschöpfung
Es ist sinnvoll, sich zunächst nur auf die wirklich kritischen Geschäftsprozesse zu beschränken und diese in den Geltungsbereich aufzunehmen. Dabei sollte von den Produkten und Dienstleistungen ausgegangen werden, mit denen die eigene Organisation ihre Wertschöpfung betreibt. Die damit zusammenhängenden Prozesse gehören in jedem Fall in den Geltungsbereich.
Es ist sinnvoll, sich zunächst nur auf die wirklich kritischen Geschäftsprozesse zu beschränken und diese in den Geltungsbereich aufzunehmen. Dabei sollte von den Produkten und Dienstleistungen ausgegangen werden, mit denen die eigene Organisation ihre Wertschöpfung betreibt. Die damit zusammenhängenden Prozesse gehören in jedem Fall in den Geltungsbereich.
Beispiel: Eine Onlinebank bietet als Produkt ein Girokonto an. Dieses lässt sich in drei Top-Level-Prozesse aufteilen:
• | Eröffnung des Kontos |
• | Nutzung des Kontos |
• | Schließen des Kontos |
In dieser frühen Phase der BCMS-Entwicklung sollten die Geschäftsprozesse nur ganz grob modelliert werden. Mehr ins Detail wird dann später in der BIA gegangen.
Die Fragestellung lautet dabei: Wenn ein Geschäftsprozess x ausfällt, welche Auswirkungen hat das auf die Funktionsfähigkeit unserer Organisation?
Folgen eines Prozessausfalls
Ein solcher Prozessausfall kann verschiedene Folgen haben:
Ein solcher Prozessausfall kann verschiedene Folgen haben:
• | Finanzielle Schäden: Das können etwa Strafzahlungen sein oder entgangene Gewinne. |
• | Reputationsverlust: Wie reagiert die Außenwelt auf den Ausfall? |
• | Kundennutzen: Können unsere Kunden unsere Produkte/Dienstleistungen trotz des Prozessausfalls noch nutzen? |
• | Verstoß gegen gesetzliche Vorgaben oder Compliance-Anforderungen wie etwa Datenschutzverstöße. |
Je nach dem Zweck der Organisation können noch andere Kategorien hinzukommen, etwa die körperliche Unversehrtheit von Mitarbeitern oder Kunden.
Einsatz der ISO 31000
Organisationen, die schon ein Risikomanagement (etwa nach ISO 31000) aufgebaut haben, können die dort definierten Risikokategorien auch für BCM übernehmen. Auch spezifische für die IT-Sicherheit nach ISO 27005 aufgesetzte Risikokategorien können berücksichtigt werden.
Organisationen, die schon ein Risikomanagement (etwa nach ISO 31000) aufgebaut haben, können die dort definierten Risikokategorien auch für BCM übernehmen. Auch spezifische für die IT-Sicherheit nach ISO 27005 aufgesetzte Risikokategorien können berücksichtigt werden.
1.3 Referenzdokumente
In dieser ersten Phase der Entwicklung eines BCMS fallen einige Referenzdokumente an, entsprechend dem Standard, nach dem gearbeitet wird. Ein Referenzdokument ist ein Dokument, das verpflichtend zu erstellen ist, um dem jeweils genutzten Standard zu genügen.
Einflussfaktoren
Jede Organisation ist Anforderungen ausgesetzt, die interner oder externer Natur sein können. Die für den Geschäftsbetrieb wesentlichen Einflussfaktoren werden in einem Referenzdokument schriftlich dokumentiert. Das umfasst
Jede Organisation ist Anforderungen ausgesetzt, die interner oder externer Natur sein können. Die für den Geschäftsbetrieb wesentlichen Einflussfaktoren werden in einem Referenzdokument schriftlich dokumentiert. Das umfasst
• | gesetzliche, regulatorische oder vertragliche Anforderungen, |
• | externe Einflussfaktoren wie Kunden, Aktionäre, die Öffentlichkeit; darunter fallen auch Aktivisten, die dem Zweck der Organisation feindlich gegenüberstehen, |
• | interne Einflussfaktoren wie Mitarbeiter, das Management Board, einzelne interne Abteilungen wie Governance, Legal & Compliance oder die Revision. |
Für diese „interested Parties” wird (z. B. in einer Word- oder Excel-Tabelle, vgl. Kap. 07475, Abschnitt 3.1) festgehalten, was deren Interessen in Bezug auf die eigene Organisation sind und welche Anforderungen sich daraus für das Notfallmanagement ergeben.[ 07475_b.docx]
BCMS-Leitlinie
Ein besonders wichtiges Referenzdokument ist die BCMS-Leitlinie, in der (in knapper Form, maximal 4–5 Seiten) einige grundlegende Aussagen zum Thema BCM getroffen werden:
Ein besonders wichtiges Referenzdokument ist die BCMS-Leitlinie, in der (in knapper Form, maximal 4–5 Seiten) einige grundlegende Aussagen zum Thema BCM getroffen werden:
• | Notwendigkeit von BCM, abgeleitet aus dem Geschäftszweck der Organisation |
• | Grundlegende Anforderungen an das BCMS |
• | Standard, nach dem gearbeitet wird (z. B. ISO 22301 oder BSI 200-4) |
• | Verpflichtung zur Implementierung des BCMS und dessen kontinuierlicher Verbesserung |
• | Leadership Commitment, in dem die Führungsebene (per Unterschrift) bestätigt, dass sie das BCMS unterstützt, die erforderlichen personellen und finanziellen Ressourcen bereitstellt sowie für den kontinuierlichen Verbesserungsprozess sorgt. |
Das Bundesamt für Sicherheit in der Informationstechnik (BSI) bietet eine geeignete Dokumentenvorlage zur Erstellung der Leitlinie auf der Basis des BSI-Standards 200-4 zum Download an [1] .
Im Lauf der Implementierung des BCMS fallen noch weitere Referenzdokumente an, die in späteren Abschnitten in diesem Beitrag beschrieben werden.
2 Analyse und BCM-Strategie
Risikoorientierter Ansatz
Ein BCMS arbeitet analog zu einem ISMS auf der Basis von Risiken. Die Risikoanalyse ist bei BCM etwas komplizierter als bei einem ISMS und umfasst mehrere Stufen:
Ein BCMS arbeitet analog zu einem ISMS auf der Basis von Risiken. Die Risikoanalyse ist bei BCM etwas komplizierter als bei einem ISMS und umfasst mehrere Stufen:
• | Modellierung der kritischen Geschäftsprozesse |
• | Bestimmung des Schadens als Funktion der Zeit bei Ausfall eines Prozesses, um die maximal zulässige Ausfallzeit zu bestimmen. Damit werden wichtige Parameter für die Notfallvorsorge festgelegt. |
• | Analyse, wie wahrscheinlich dieser Schaden ist, d. h., ob tatsächlich Maßnahmen zur Notfallvorsorge getroffen werden müssen oder das Risiko getragen werden kann. |
2.1 Modellierung der Geschäftsprozesse
Untergliederung in Teilprozesse
Nachdem bei der Festlegung des Geltungsbereichs die wichtigsten Top-Level-Prozesse identifiziert wurden, werden diese Prozesse in Teilprozesse aufgegliedert. Damit können die Notfallvorsorgemaßnahmen besser an die eigene Prozesslandschaft und die mit den Prozessen verbundenen Assets angepasst werden.
Nachdem bei der Festlegung des Geltungsbereichs die wichtigsten Top-Level-Prozesse identifiziert wurden, werden diese Prozesse in Teilprozesse aufgegliedert. Damit können die Notfallvorsorgemaßnahmen besser an die eigene Prozesslandschaft und die mit den Prozessen verbundenen Assets angepasst werden.
2.1.1 Detaillierungsgrad
Wie detailliert diese Modellierung sein muss, hängt von der Komplexität der Geschäftsprozesse ab. Als Faustformel gilt dabei, mit der Modellierung spätestens dann aufzuhören, wenn der betrachtete Teilprozess innerhalb einer einzelnen Anwendung oder in einem einzelnen IT-System abgebildet wird.
Beispiel
Als Beispiel soll wieder das Online-Girokonto dienen.
Als Beispiel soll wieder das Online-Girokonto dienen.
Der Prozess „Eröffnung des Kontos” lässt sich in fünf Teilprozesse aufteilen:
• | Ein Kunde beantragt die Einrichtung eines neuen Kontos über die Website der Bank. |
• | Eine Schufa-Abfrage zur Bonitätsprüfung wird automatisch angestoßen. |
• | Ein Sachbearbeiter prüft das Konto und schaltet es frei. |
• | Das Konto wird im Bankensystem mittels eines automatischen Workflows eingerichtet. |
• | Der Kunde wird über die Einrichtung des Kontos benachrichtigt. |
Diese Teilprozesse lassen sich prinzipiell noch weiter untergliedern. Das ist aber nur dann sinnvoll, wenn unterschiedliche Assets und/oder IT-Systeme innerhalb eines Teilprozesses involviert sind.
Im vorliegenden Beispiel endet die Modellierung bei den fünf Teilprozessen.
2.1.2 Synergieeffekte
Übernahmen aus anderen Managementsystemen
Falls vor der Einführung des BCMS schon andere Managementsysteme implementiert wurden, kann die dort gemachte Prozessmodellierung übernommen werden.
Falls vor der Einführung des BCMS schon andere Managementsysteme implementiert wurden, kann die dort gemachte Prozessmodellierung übernommen werden.
Es muss allerdings sorgfältig überprüft werden, ob die bei den anderen Managementsystemen vorgenommene Modellierung für das Notfallmanagement geeignet ist. Bei einer Prozessmodellierung für ein ISMS ist das in der Regel gegeben, da auch dort die Zuordnung von Teilprozessen zu Assets und IT-Systemen im Vordergrund steht. Bei einem Qualitätsmanagementsystem nach ISO 9001 ist das nicht automatisch gegeben.
2.2 Business-Impact-Analyse
Kenngrößen für kritische Teilprozesse
Die nun folgende Business-Impact-Analyse (BIA) hat das Ziel, Kenngrößen für die kritischen Teilprozesse zu ermitteln, mit denen Notfälle entweder verhindert werden oder aber im Ernstfall ein schnelles Wiederanlaufen der Geschäftsprozesse möglich wird. Diese Kenngrößen werden vom Asset Owner ermittelt.
Die nun folgende Business-Impact-Analyse (BIA) hat das Ziel, Kenngrößen für die kritischen Teilprozesse zu ermitteln, mit denen Notfälle entweder verhindert werden oder aber im Ernstfall ein schnelles Wiederanlaufen der Geschäftsprozesse möglich wird. Diese Kenngrößen werden vom Asset Owner ermittelt.
Referenzdokument
Die BIA und ihre Ergebnisse müssen dokumentiert werden, da die BIA ein Referenzdokument des BCMS ist.
Die BIA und ihre Ergebnisse müssen dokumentiert werden, da die BIA ein Referenzdokument des BCMS ist.
2.2.1 MTPD
Maximale Ausfallzeit eines Prozesses
Als Maximum Tolerable Period of Disruption (MTPD) wird die maximal tolerierbare Ausfallzeit eines Prozesses bezeichnet. Die MTPD wird für Produkte und/oder Geschäftsprozesse ermittelt. Wenn ein Prozess ausfällt und nicht nach Ablauf der MTPD wieder hochgefahren ist, erleidet das Unternehmen einen bestandsgefährdenden Schaden. Die MTPD wird über eine BIA ermittelt und/oder von der Geschäftsleitung vorgegeben.
Als Maximum Tolerable Period of Disruption (MTPD) wird die maximal tolerierbare Ausfallzeit eines Prozesses bezeichnet. Die MTPD wird für Produkte und/oder Geschäftsprozesse ermittelt. Wenn ein Prozess ausfällt und nicht nach Ablauf der MTPD wieder hochgefahren ist, erleidet das Unternehmen einen bestandsgefährdenden Schaden. Die MTPD wird über eine BIA ermittelt und/oder von der Geschäftsleitung vorgegeben.
2.2.2 RTO
Geforderte Wiederanlaufzeit
Als Recovery Time Objective (RTO) wird die zeitliche Anforderung für den Wiederanlauf von Prozessen und den mit diesen verbundenen Ressourcen bezeichnet (geforderte Wiederanlaufzeit). Das RTO wird immer im Rahmen einer BIA ermittelt.
Als Recovery Time Objective (RTO) wird die zeitliche Anforderung für den Wiederanlauf von Prozessen und den mit diesen verbundenen Ressourcen bezeichnet (geforderte Wiederanlaufzeit). Das RTO wird immer im Rahmen einer BIA ermittelt.
Es ist offensichtlich, dass RTO immer kleiner oder gleich MTPD sein muss. In der Regel ist RTO aber kleiner als MTPD, da
• | es sinnvoll ist, zwischen RTO und MTPD noch einen Reservepuffer einzuplanen, falls es bei der Wiederherstellung Pannen gibt, |
• | es sein kann, dass die Ressourcen eines Prozesses nicht gleichzeitig hochgefahren werden können. So kann etwa ein Windows-Anwendungsserver erst hochgefahren werden, wenn zuvor das Active Directory (Domänencontroller) und beispielsweise ein Datenbankserver hochgefahren wurden. |
Das erforderliche Feintuning kann erst nach Abschluss der BIA beim Aufstellen des Wiederanlaufplans vorgenommen werden. Dann werden die diversen Zeiten zum Hochfahren der Ressourcen berücksichtigt und kontrolliert, ob die MTPD überschritten wird.
2.2.3 RPO
Fällt ein Geschäftsprozess aus, gehen in der Regel Daten verloren, was am Beispiel von Onlinebanking verdeutlicht werden kann. Angenommen, es sind 200 Kunden aktuell im Onlinebanking angemeldet und der Onlinebankingprozess fällt aus. Damit sind die von den Kunden gerade bearbeiteten Transaktionen in einem unsauberen, nicht definierten Zustand. Wenn der Prozess wieder hochgefahren wird, muss auf einem sauberen Datenbestand aufgesetzt werden. In der Regel müssen die 200 Kunden ihre Transaktionen neu erfassen. Im Worst Case sind aber auch weiter zurückliegende Transaktionen betroffen, da auch deren Daten ganz oder teilweise verloren gegangen sind.
Maximal zulässiger Datenverlust
Als Recovery Point Objective (RPO) wird die Zeitspanne bezeichnet, in der der Verlust an Daten bei einem Prozessausfall noch tolerabel ist. RPO ist damit eine Vorgabe an die IT, wie häufig die Daten zu sichern sind.
Als Recovery Point Objective (RPO) wird die Zeitspanne bezeichnet, in der der Verlust an Daten bei einem Prozessausfall noch tolerabel ist. RPO ist damit eine Vorgabe an die IT, wie häufig die Daten zu sichern sind.
Wenn beim Beispiel des Onlinebankings die Daten z. B. jede Minute gesichert oder auf ein anderes System gespiegelt werden, dürften außer bei den 200 vom direkten Prozessausfall betroffenen Kunden keine weiteren Transaktionen betroffen sein.
Liegt die letzte Datensicherung aber eine Stunde zurück, sind mit Sicherheit Tausende andere Transaktionen betroffen, die im System zurückgesetzt und damit (von den Kunden) neu erfasst werden müssen.
RPO wird innerhalb der BIA ermittelt.
2.2.4 Unterstützung durch Tools
Nutzung einer CMDB sinnvoll
Die BIA muss für alle Prozesse und Assets nach einer identischen Vorgehensweise durchgeführt werden. In der Regel wird die Erstellung der BIA von einem Tool unterstützt. Im Idealfall steht eine Configuration Management Database (CMDB) zur Verfügung, in der alle Assets schon erfasst und die Bewertungskriterien hinterlegt sind. Dann kann sich der Asset Owner am hinterlegten Workflow orientieren, sodass wenige Fehler passieren und die BIA-Ergebnisse der einzelnen Ressourcen vergleichbar sind.
Die BIA muss für alle Prozesse und Assets nach einer identischen Vorgehensweise durchgeführt werden. In der Regel wird die Erstellung der BIA von einem Tool unterstützt. Im Idealfall steht eine Configuration Management Database (CMDB) zur Verfügung, in der alle Assets schon erfasst und die Bewertungskriterien hinterlegt sind. Dann kann sich der Asset Owner am hinterlegten Workflow orientieren, sodass wenige Fehler passieren und die BIA-Ergebnisse der einzelnen Ressourcen vergleichbar sind.
Zudem sollten in der CMDB hinterlegt sein:
• | Ressourcen (in der Regel IT-Systeme), die für den Betrieb des Assets benötigt werden, |
• | Upstream- und Downstream-Assets, d. h., von welchen Assets erhält das betrachtete Asset seine Daten, und an welche Assets werden Daten abgegeben. |
Natürlich kann eine BIA auch per Excel-Tabelle durchgeführt werden. In diesem Fall ist es empfehlenswert, über Makros den Asset Owner durch den BIA-Prozess zu leiten.
2.2.5 Bewertungskriterien
Folgende Bewertungskriterien sollten für die BIA definiert werden:
Schadenstypen | |
• | Die bei der BIA zu betrachtenden Typen von Schäden, also beispielsweise finanzielle Schäden, Reputationsverlust, Kundennutzen, Verstoß gegen gesetzliche Vorgaben oder Compliance-Anforderungen |
Schadenshöhe | |
• | Kriterien für die Schadenshöhe: Es ist eine sinnvolle Best-Practice-Vorgabe, dazu vier Kategorien zu wählen. Für jede Schadenskategorie muss dann festgelegt werden, wann ein niedriger, mittlerer, hoher oder sehr hoher Schaden vorliegt. Bei finanziellen Schäden kann das etwa der Anteil am Jahresumsatz sein, bei den anderen Kategorien müssen gegebenenfalls qualitative Kriterien festgelegt werden. |
• | Maximale tolerierbare Schadenshöhe: Ein Schaden bei Ausfall eines Prozesses steigt mit der Dauer des Ausfalls an. Erreicht der Schaden die maximale tolerierbare Schadenshöhe, muss der Prozess (spätestens) wieder laufen. In der Regel werden bei Notfällen Schäden unterhalb eines hohen Schadens toleriert. Das hängt aber stark vom Geschäftsmodell und eventuellen regulatorischen Vorgaben ab. |
Zeitparameter | |
• | Zeitintervalle, zu denen ein Schaden bei Ausfall eines Geschäftsprozesses betrachtet werden muss, also nach Ausfall von einer Stunde, von vier Stunden, von einem Tag etc. Welche und wie viele Zeitintervalle betrachtet werden müssen, hängt von den betrachteten Prozessen ab. Falls bereits ein ISMS implementiert ist, sollten die dort hinterlegten Zeitintervalle für die Verfügbarkeit als Ausgangspunkt für das BCMS genommen werden. |
2.2.6 Berechnung des RTO
Verlauf des Schadens über die Zeit
Für jeden Schadenstyp wird der Verlauf des Schadens bei Ausfall eines Prozesses für alle betroffenen Assets durchdacht. Zu einem bestimmten Zeitpunkt erreicht oder überschreitet der Schaden die maximal tolerierbare Schadenshöhe. Damit ist ein Teil-RTO für den jeweiligen Schadenstyp bestimmt.
Für jeden Schadenstyp wird der Verlauf des Schadens bei Ausfall eines Prozesses für alle betroffenen Assets durchdacht. Zu einem bestimmten Zeitpunkt erreicht oder überschreitet der Schaden die maximal tolerierbare Schadenshöhe. Damit ist ein Teil-RTO für den jeweiligen Schadenstyp bestimmt.
Zeitintervalle
Das soll mit einem Beispiel verdeutlich werden. Die Zeitintervalle in den folgenden Abbildungen sind zu
Das soll mit einem Beispiel verdeutlich werden. Die Zeitintervalle in den folgenden Abbildungen sind zu
P1: 0–4 Stunden
P2: 4–8 Stunden
P3: 8–24 Stunden
P4: > 24 Stunden
gewählt. Dann ermittelt der Asset Owner etwa
RTOfinanzAbb. 1: Finanzieller Schaden
RTOfinanz ergibt sich zu P4 = 24 Stunden (s. Abbildung 1).
RTOReputationAbb. 2: Reputationsverlust
RTOReputation ergibt sich zu P3 = 8 Stunden (s. Abbildung 2).
RTOKundeAbb. 3: Kundennutzen
RTOKunde ergibt sich zu P4 = 24 Stunden (s. Abbildung 3).
RTOComplianceAbb. 4: Compliance
Der RTOCompliance ist für diesen Prozess nicht relevant, da die maximal tolerierbare Schadenshöhe nie erreicht wird (s. Abbildung 4).
Berechnung des Gesamt-RTO
Der Gesamt-RTO für dieses Asset ergibt sich aus dem kleinsten Teil-RTO. Dieser ist der RTOReputation mit acht Stunden.
Der Gesamt-RTO für dieses Asset ergibt sich aus dem kleinsten Teil-RTO. Dieser ist der RTOReputation mit acht Stunden.
Nachdem die RTOs von allen Assets berechnet wurden, müssen die Abhängigkeiten der Teilprozesse untereinander betrachtet und die RTOs ggf. korrigiert werden. Dazu werden die Uptream- und Downstream-Assets innerhalb der Prozesskette betrachtet und auf Engpässe hin untersucht.
Wenn beispielsweise die Teilprozesse TP1, TP2 und TP3 mit ihren Assets nacheinander einen Geschäftsprozess abbilden und RTOTP1 und RTOTP3 jeweils eine Stunde ist, RTOTP2 jedoch zwei Stunden, muss RTOTP2 auf eine Stunde korrigiert werden.
2.2.8 Kritikalitätsstufen
Es gibt noch einen weitergehenden Ansatz zur Analyse von Prozessen, bei dem sogenannte Kritikalitätsstufen berechnet werden. Das Modell zur Berechnung der RTOs macht lediglich eine Aussage darüber, nach welcher Zeit der Prozess wieder laufen muss. Es wird kein Unterschied gemacht, ob dieses RTO lediglich von einem Schadensdtyp ausgelöst wurde oder ob nicht vielleicht alle Schadenstypen ihren kritischen Wert erreicht haben.
Schadenstypen zusammenfassen
Bei der Berechnung der Kritikalitätsstufen werden alle Schadenstypen zu einem Gesamtschaden zusammenfasst und der Verlauf des Gesamtschadens wird betrachtet.
Bei der Berechnung der Kritikalitätsstufen werden alle Schadenstypen zu einem Gesamtschaden zusammenfasst und der Verlauf des Gesamtschadens wird betrachtet.
Dazu werden Wichtungsfaktoren für die Schadensszenarien vergeben (je nach Priorität der Organisation) und die Schäden bei Ausfall des Prozesses direkt mit den Wichtungsfaktoren multipliziert und zu einem Gesamtschaden aufaddiert.
Wichtungsfaktoren
In unserem Beispiel werden folgende Wichtungsfaktoren vergeben:
In unserem Beispiel werden folgende Wichtungsfaktoren vergeben:
Finanzieller Schaden = 2
Reputationsverlust = 1
Kundennutzen = 3
Compliance = 3
Dann ergibt sich aus den Schadensverläufen in den Abbildungen 1 bis 4 ein gewichteter Gesamtschadensverlauf wie in Tabelle 1 angegeben.
Tabelle 1: Gesamtschaden
Finanz | Reputation | Kunde | Compliance | Gesamtschaden | |
Wichtung | 2 | 1 | 3 | 3 | |
P1 | 1 | 1 | 1 | 1 | 9 |
P2 | 1 | 2 | 1 | 2 | 13 |
P3 | 2 | 3 | 1 | 2 | 16 |
P4 | 3 | 3 | 4 | 2 | 27 |
Priorisierung des Wiederanlaufs
Dieser Schaden kann im Beispiel maximal einen Wert von 27 annehmen, die Kritikalität des Assets ist also 27. Die Kritikalität ist ein Hinweis darauf, welche Assets mit ihren Ressourcen bei einem Notfall zuerst anlaufen sollen und welche ggf. warten müssen.
Dieser Schaden kann im Beispiel maximal einen Wert von 27 annehmen, die Kritikalität des Assets ist also 27. Die Kritikalität ist ein Hinweis darauf, welche Assets mit ihren Ressourcen bei einem Notfall zuerst anlaufen sollen und welche ggf. warten müssen.
Anmerkung
Die Berechnung der Kritikalität ist optional, viele BCMS kommen ohne diese Kenngröße aus.
Die Berechnung der Kritikalität ist optional, viele BCMS kommen ohne diese Kenngröße aus.
2.2.9 Abschätzung des RPO
Die zweite wichtige Kenngröße, der maximal erlaubte Datenverlust, muss ebenfalls vom Asset Owner ermittelt werden. Das geschieht durch eine Abschätzung, eine mathematische Formel zur Berechnung des RPO gibt es nicht.
Auswirkungen eine Datenverlusts
Bei der Abschätzung wird überlegt, welche Auswirkungen ein Datenverlust auf den Neustart eines Prozesses hat. Dabei sollten folgende Fragen berücksichtigt werden:
Bei der Abschätzung wird überlegt, welche Auswirkungen ein Datenverlust auf den Neustart eines Prozesses hat. Dabei sollten folgende Fragen berücksichtigt werden:
• | Mit welchen Mechanismen wird dafür gesorgt, dass der Prozess nach Einspielen der letzten Datensicherung wieder sauber läuft? |
• | Wie wird mit den Daten umgegangen, die nach der letzten Datensicherung angefallen und somit verloren sind? |
• | Wer ist dafür verantwortlich, die fehlenden Daten neu zu erfassen (Kunden, eigene Mitarbeiter)? |
• | Wie groß ist der Aufwand, die fehlenden Daten zu erfassen? |
• | Welcher Schaden (z. B. Reputationsverlust) entsteht, wenn Daten nacherfasst werden müssen und der Datenbestand des Prozesses für diese Zeit nicht aktuell ist? |
RPO-Klassen
Es ist sinnvoll, für den RPO vordefinierte Klassen zu definieren, die der Asset Owner dann nutzen kann. Beispiel:
Es ist sinnvoll, für den RPO vordefinierte Klassen zu definieren, die der Asset Owner dann nutzen kann. Beispiel:
RPO1: 1 Stunde
RPO2: 4 Stunden
RPO3: 8 Stunden
RPO4: 24 Stunden
2.3 Risk Assessment
Bei der Einführung eines BCMS ist ebenfalls nicht einheitlich vorgesehen, ob nach der BIA noch eine Risikoanalyse im klassischen Sinne erfolgen soll. Einige BCM-Ansätze schreiben diese vor, andere lassen das Risk Assessment (RIA) aus.
Wahrscheinlichkeit des Prozessausfalls
Hintergrund der Risikoanalyse ist, dass bei der BIA davon ausgegangen wird, dass Geschäftsprozesse unterbrochen werden. Daraus werden alle weiteren Überlegungen abgeleitet. Die BIA sagt aber nichts darüber aus, wie groß das Risiko eines Prozessausfalls wirklich ist. Das Risk Assessment ermittelt dieses Risiko anhand Schadenshöhe und Eintrittswahrscheinlichkeit und kann zu einem Feinabgleich der BIA-Ergebnisse führen.
Hintergrund der Risikoanalyse ist, dass bei der BIA davon ausgegangen wird, dass Geschäftsprozesse unterbrochen werden. Daraus werden alle weiteren Überlegungen abgeleitet. Die BIA sagt aber nichts darüber aus, wie groß das Risiko eines Prozessausfalls wirklich ist. Das Risk Assessment ermittelt dieses Risiko anhand Schadenshöhe und Eintrittswahrscheinlichkeit und kann zu einem Feinabgleich der BIA-Ergebnisse führen.
So können Prozessausfälle, bei denen die Eintrittswahrscheinlichkeit extrem gering ist, in der Notfallplanung eine geringere Priorität bekommen. Die Führungsebene könnte sich sogar dazu entscheiden, das Risiko zu tragen und den Prozess aus dem Notfallmanagement hinauszunehmen. Auf der anderen Seite verlangen Ausfälle mit einer hohen Eintrittswahrscheinlichkeit nach ergänzenden Maßnahmen, die über die aus der BIA abgeleiteten Maßnahmen hinausgehen.
Achtung!
Die RIA sollte aber keinesfalls so weit gehen, dass Prozessausfälle, die das Unternehmen existenziell bedrohen, aber eine geringe Eintrittswahrscheinlichkeit haben, aus dem Notfallmanagement entfernt werden.
Die RIA sollte aber keinesfalls so weit gehen, dass Prozessausfälle, die das Unternehmen existenziell bedrohen, aber eine geringe Eintrittswahrscheinlichkeit haben, aus dem Notfallmanagement entfernt werden.
Zur Durchführung der RIA kann ein Großteil der bei der BIA gemachten Arbeiten wiederverwendet werden. Die Listen der Geschäftsprozesse, Teilprozesse und Assets wurden bei der BIA unter dem Aspekt beleuchtet, wie sich der Schaden im Verlauf der Zeit entwickelt. Jetzt wird untersucht, wie wahrscheinlich der Eintritt dieses Schadens ist.
Eintrittswahrscheinlichkeit bestimmen
Um die Eintrittswahrscheinlichkeit zu ermitteln, können eigene Erfahrungen mit Ausfällen, aber auch allgemeine Erkenntnisse über Prozessketten und Ausfallwahrscheinlichkeiten genutzt werden.
Um die Eintrittswahrscheinlichkeit zu ermitteln, können eigene Erfahrungen mit Ausfällen, aber auch allgemeine Erkenntnisse über Prozessketten und Ausfallwahrscheinlichkeiten genutzt werden.
Die Ergebnisse der RIA werden in eine übliche Risikomatrix eingetragen, wobei die Schadenshöhe die jeweils bei der BIA eingesetzte maximale tolerierbare Schadenshöhe ist. Die Eintrittswahrscheinlichkeit ist die einzige Größe, die bei RIA neu bestimmt bzw. abgeschätzt wird.
Abbildung 5 zeigt eine Riskomatrix, in die die Ergebnisse der RIA einzutragen sind.
RiskomatrixAbb. 5: Gesamtschaden
Die in der Risikomatrix rechts oben anzutreffenden Risiken sollten durch zusätzliche Maßnahmen abgesichert werden (z. B. redundante IT-Systeme zur Ausführung der Prozesse).
Referenzdokument
Ist vom gewählten BCM-Standard her eine RIA vorgesehen, muss diese dokumentiert werden.
Ist vom gewählten BCM-Standard her eine RIA vorgesehen, muss diese dokumentiert werden.
2.4 Wiederanlauf von Ressourcen
Mit der BIA und den ermittelten Werten RTO und RPO haben wir die Anforderungen ermittelt, die an den Prozess, seine Assets und letztlich auch an die betroffenen IT-Systeme gestellt werden. Jetzt stellt sich die Frage, ob diese Anforderungen erfüllt werden können oder ob zur Notfallvorsorge Maßnahmen zur schnelleren Wiederherstellung des Prozesses getroffen werden müssen.
2.4.1 Ermittlung der WAZ
Reale Wiederanlaufzeit
Dazu muss für jede am Prozess beteiligte Ressource eine reale Wiederanlaufzeit (WAZ) ermittelt werden. Das ist Aufgabe der Asset Owner, vor allem aber der System Owner der beteiligten IT-Systeme.
Dazu muss für jede am Prozess beteiligte Ressource eine reale Wiederanlaufzeit (WAZ) ermittelt werden. Das ist Aufgabe der Asset Owner, vor allem aber der System Owner der beteiligten IT-Systeme.
Zunächst wird für jede Ressource eine eigene Wiederanlaufzeit abgeschätzt. Diese ist die maximale Zeit, die für das Hochfahren dieser Ressource benötigt wird, sofern alle Voraussetzungen für das Hochfahren erfüllt sind.
Beispiel
Das soll am Beispiel einer Webanwendung erläutert werden. Die Anwendung benötigt einen Webserver, einen Applikationsserver, eine Datenbank, Netzwerkverbindungen sowie eine Stromversorgung (eine USV ist nicht vorhanden). Als WAZ für die Ressourcen wurde abgeschätzt:
Das soll am Beispiel einer Webanwendung erläutert werden. Die Anwendung benötigt einen Webserver, einen Applikationsserver, eine Datenbank, Netzwerkverbindungen sowie eine Stromversorgung (eine USV ist nicht vorhanden). Als WAZ für die Ressourcen wurde abgeschätzt:
• | Reaktionszeit: 15 Min. |
• | Webserver inkl. Betriebssystem (Zurückspielen vom Backup): eine Std. |
• | Applikationsserver inkl. Betriebssystem (Zurückspielen vom Backup): eine Std. |
• | Datenbank (Zurückspielen vom Backup laut RPO): 30 Min. |
• | Hardware für Server aufsetzen: zwei Std. |
• | Netzwerkverbindungen (Switches, Router): zwei Std. |
• | Stromversorgung (Stadtwerke): vier Std. |
Abhängigkeiten von Ressourcen
Da die Ressourcen teilweise voneinander abhängen, lässt sich die Gesamt-WAZ erst über einen (vorläufigen) Wiederanlaufplan ermitteln:
Da die Ressourcen teilweise voneinander abhängen, lässt sich die Gesamt-WAZ erst über einen (vorläufigen) Wiederanlaufplan ermitteln:
• | Reaktionszeit: 15 Min. |
• | Stromversorgung wird wiederhergestellt: vier Std. |
• | Netzwerkverbindungen & Server-Hardware parallel: zwei Std |
• | Zurückspielen aller Backups parallel: eine Std |
Insgesamt ergibt sich so eine WAZ von sieben Stunden und 15 Minuten.
2.4.2 Maßnahmen zur Notfallvorsorge
WAZ mit RTO und MPTD abgleichen
Die ermittelten realen Wiederanlaufzeigen (WAZ) müssen in einem weiteren Schritt mit den geforderten Wiederanlaufzeigen (RTO) und letztlich auch mit den MTPD abgeglichen werden. Wenn die WAZ kleiner als die RTO ist, ist alles in Ordnung.
Die ermittelten realen Wiederanlaufzeigen (WAZ) müssen in einem weiteren Schritt mit den geforderten Wiederanlaufzeigen (RTO) und letztlich auch mit den MTPD abgeglichen werden. Wenn die WAZ kleiner als die RTO ist, ist alles in Ordnung.
WAZ-Verkleinerung
Falls die WAZ aber größer als die RTO ist, müssen Maßnahmen getroffen werden. Ansonsten sind bei Prozessausfall Probleme vorprogrammiert. Im Fall der Webanwendung ist der Engpass die Stromversorgung, da keine USV vorhanden ist. Mit einer ausreichend dimensionierten USV ist die WAZ um volle vier Stunden kürzer, da Hard- und Software ohne Verzögerung neu aufgesetzt werden können.
Falls die WAZ aber größer als die RTO ist, müssen Maßnahmen getroffen werden. Ansonsten sind bei Prozessausfall Probleme vorprogrammiert. Im Fall der Webanwendung ist der Engpass die Stromversorgung, da keine USV vorhanden ist. Mit einer ausreichend dimensionierten USV ist die WAZ um volle vier Stunden kürzer, da Hard- und Software ohne Verzögerung neu aufgesetzt werden können.
Wenn aber die WAZ von drei Stunden noch immer zu groß ist, muss über weitergehende Maßnahmen nachgedacht werden. Das können etwa sein:
• | redundante Systeme an einem anderen Standort, |
• | Dienstleister, der im Fall des Ausfalls den Prozess übernimmt, |
• | vorkonfigurierte eigene Systeme, die schnell den Prozess übernehmen können. |
Restrisiken werden getragen
Die Vorsorgemaßnahmen müssen so ausgelegt sein, dass alle RTOs bzw. MTPDs unter Berücksichtigung eines verbleibenden, von der Führungsebene zu tragenden Restrisikos eingehalten werden.
Die Vorsorgemaßnahmen müssen so ausgelegt sein, dass alle RTOs bzw. MTPDs unter Berücksichtigung eines verbleibenden, von der Führungsebene zu tragenden Restrisikos eingehalten werden.
2.4.3 Wiederanlaufpläne
Aus den bei der Ermittlung der WAZ erstellten vorläufigen Wiederanlaufplänen sowie eventuellen Korrekturen durch Maßnahmen zur Notfallvorsorge werden nun für alle Ressourcen eines Geschäftsprozesses die finalen Wiederanlaufpläne erstellt.
Zeitliche Reihenfolge und Anleitungen
Diese enthalten neben der zeitlichen Reihenfolge des Hochfahrens von Ressourcen auch Anleitungen, wie die einzelnen Ressourcen wieder an den Start gebracht werden. Dabei müssen diese Anleitungen nicht zu detailliert sein. System Owner oder deren Vertretung kennen die betroffenen Ressourcen in der Regel gut, sodass in einer Anleitung nur die wesentlichen Schritte zur Wiederherstellung beschrieben werden müssen.
Diese enthalten neben der zeitlichen Reihenfolge des Hochfahrens von Ressourcen auch Anleitungen, wie die einzelnen Ressourcen wieder an den Start gebracht werden. Dabei müssen diese Anleitungen nicht zu detailliert sein. System Owner oder deren Vertretung kennen die betroffenen Ressourcen in der Regel gut, sodass in einer Anleitung nur die wesentlichen Schritte zur Wiederherstellung beschrieben werden müssen.
Referenzdokument
Die Wiederanlaufpläne müssen dokumentiert werden, da sie ein Referenzdokument des BCMS sind.
Die Wiederanlaufpläne müssen dokumentiert werden, da sie ein Referenzdokument des BCMS sind.
2.5 BCM-Strategie
Zusammenfassendes Dokument
Als BCM-Strategie oder auch Kontinuitätsstrategie wird die Zusammenfassung aller bisherigen Arbeiten zu einer Gesamtstrategie verstanden. Dabei wird für jedes BCM-Szenario:
Als BCM-Strategie oder auch Kontinuitätsstrategie wird die Zusammenfassung aller bisherigen Arbeiten zu einer Gesamtstrategie verstanden. Dabei wird für jedes BCM-Szenario:
• | IT fällt aus |
• | Standort fällt aus |
• | Personal fällt aus |
• | Dienstleister fällt aus |
• | Hackerangriff |
angegeben, welche Prozesse betroffen sind und wie diese wieder hochgefahren werden. Zudem werden die im Notfall aktivierten Maßnahmen bewertet.
Referenzdokument
Die BCM-Strategie muss dokumentiert werden, da sie ein Referenzdokument des BCMS ist.
Die BCM-Strategie muss dokumentiert werden, da sie ein Referenzdokument des BCMS ist.
2.5.1 Notbetrieb
Notbetrieb erforderlich?
Bei der Entwicklung der BCM-Strategie muss zunächst geklärt werden, für welche Prozesse ein Notbetrieb mit eingeschränkten Ressourcen möglich ist. Das ist beispielsweise bei Webservices denkbar. Beim Betrieb mit eingeschränkten Ressourcen ist die Verarbeitung dann langsamer als im Normalbetrieb.
Bei der Entwicklung der BCM-Strategie muss zunächst geklärt werden, für welche Prozesse ein Notbetrieb mit eingeschränkten Ressourcen möglich ist. Das ist beispielsweise bei Webservices denkbar. Beim Betrieb mit eingeschränkten Ressourcen ist die Verarbeitung dann langsamer als im Normalbetrieb.
Ist ein Notbetrieb vorgesehen, muss dessen Niveau definiert werden. Die im Folgenden beschriebenen Notfallmaßnahmen werden dann für den Notbetrieb und den später folgenden Normalbetrieb ermittelt.