Zum Inhalt springen

BSI/200-4/07 Business Impact Analyse: Unterschied zwischen den Versionen

Aus Foxwiki
Versionsgeschichte interaktiv durchsuchen
← Zum vorherigen Versionsunterschied
Dirkwagner (Diskussion | Beiträge)
Bürokraten, Oberflächenadministratoren, Administratoren
145.338 Bearbeitungen
VisuellWikitext
 
(48 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 2: Zeile 2:


== Beschreibung ==
== Beschreibung ==
; In der BIA wird untersucht
; In der [[BIA]] wird untersucht
* welche Geschäftsprozesse zeitkritisch sind
* welche Geschäftsprozesse zeitkritisch sind
*ab wann deren Ausfälle nicht tolerierbare Auswirkungen haben.
*ab wann deren Ausfälle nicht tolerierbare Auswirkungen haben


; Daraus werden die Wiederanlaufanforderungen abgeleitet
; Daraus werden die Wiederanlaufanforderungen abgeleitet
Zeile 10: Zeile 10:
* welche Ressourcen dafür benötigt werden
* welche Ressourcen dafür benötigt werden


Falls die BAO schon aufgebaut wurde, helfen diese Informationen der BAO zu­dem
Falls die [[BAO]] schon aufgebaut wurde, helfen diese Informationen der [[BAO]] zu­dem
* die zeitkritischen Geschäftsprozesse und Ressourcen in einem Notfall zu priorisieren
* die zeitkritischen Geschäftsprozesse und Ressourcen in einem Notfall zu priorisieren
* früh zu erkennen, ob ein Schadensereignis eskaliert werden muss sowie
* früh zu erkennen, ob ein Schadensereignis eskaliert werden muss sowie
* den Geschäftsbetrieb aufrechtzuerhalten
* den Geschäftsbetrieb aufrechtzuerhalten


; Prozessschritte der Business-Impact-Analyse
; Prozessschritte der Business-Impact-Analyse
[[File:img-159-278.png|800px]]
[[File:img-159-278.png|800px]]


=== Kenngrößen ===
== Kenngrößen ==
[[File:img-157-276.png|700px]]
[[File:img-157-276.png|700px]]


{| class="wikitable options big"
{| class="wikitable options big gnu"
! Kenngröße !!Beschreibung
! !! Kenngröße !! Beschreibung
|-
|-
| Maximum Tolerable Period of Disruption (MTPD) </br>Maximal Tolerierbare Ausfallzeit, MTA || legt fest, wie lange ein Geschäftsprozess maximal ausfallen darf, bevor nicht tolerierbare Auswirkungen für die Institution auftreten
| [[MTPD]] || Maximum Tolerable Period of Disruption </br>Maximal Tolerierbare Ausfallzeit, MTA || legt fest, wie lange ein Geschäftsprozess maximal ausfallen darf, bevor nicht tolerierbare Auswirkungen für die Institution auftreten
* Die MTPD wird anhand einer Bewertung des Schadenspotenzials je Geschäftsprozess ermittelt.
* Die [[MTPD]] wird anhand einer Bewertung des Schadenspotenzials je Geschäftsprozess ermittelt.
|-
|-
| Recovery Time Objective (RTO) </br> Geforderte Wiederanlaufzeit (WAZ) || wird aus der MTPD abgeleitet und sowohl den zeitkritischen Geschäftsprozessen als auch den Ressourcen zugeordnet, die relevant sind für die Aufrechterhaltung der zeitkritischen Geschäftsprozesse
| [[RTO]]</br>[[WAZ]] || Recovery Time Objective</br> Geforderte Wiederanlaufzeit || wird aus der [[MTPD]] abgeleitet und sowohl den zeitkritischen Geschäftsprozessen als auch den Ressourcen zugeordnet, die relevant sind für die Aufrechterhaltung der zeitkritischen Geschäftsprozesse
* Die RTO umfasst den Zeitraum vom Ausrufen des Notfalls bis zum Zeitpunkt der geforderten Inbetriebnahme der BC-Lösung
* Die [[RTO]] umfasst den Zeitraum vom Ausrufen des Notfalls bis zum Zeitpunkt der geforderten Inbetriebnahme der BC-Lösung
* Im Falle von IT-Ressourcen wäre das z.&nbsp;B.&nbsp;der Schwenk auf eine Ausweich- oder Ersatzressource oder das Zurücksetzen eines IT-Systems auf den letzten gesicherten Zustand
* Im Falle von IT-Ressourcen wäre das beispielsweise&nbsp;der Schwenk auf eine Ausweich- oder Ersatzressource oder das Zurücksetzen eines IT-Systems auf den letzten gesicherten Zustand
*  
*  
Die RTO muss zwingend kürzer sein als die MTPD des relevanten Geschäftsprozesses, denn die Reaktionszeit wird von der MTPD abgezogen, um mit der RTO die MTPD noch erreichen zu können
Die [[RTO]] muss zwingend kürzer sein als die [[MTPD]] des relevanten Geschäftsprozesses, denn die Reaktionszeit wird von der [[MTPD]] abgezogen, um mit der [[RTO]] die [[MTPD]] noch erreichen zu können
* Zusätzlich ist es empfehlenswert, einen weiteren zeitlichen Puffer einzuplanen, da insbesondere die Detektion mit Unsicherheiten hinsichtlich des genauen zeitlichen Ablaufs einhergeht.
* Zusätzlich ist es empfehlenswert, einen weiteren zeitlichen Puffer einzuplanen, da insbesondere die Detektion mit Unsicherheiten hinsichtlich des genauen zeitlichen Ablaufs einhergeht.
|-
|-
| Recovery Point Objective (RPO) </br> Maximal zulässiger Datenverlust || legt fest, welcher Datenverlust akzeptiert wird, d.&nbsp;h.&nbsp;wie alt verfügbare Daten maximal sein dürfen, um im Notbetrieb sinnvoll damit arbeiten zu können
| [[RPO]] || Recovery Point Objective </br> Maximal zulässiger Datenverlust || legt fest, welcher Datenverlust akzeptiert wird, d.&nbsp;h.&nbsp;wie alt verfügbare Daten maximal sein dürfen, um im Notbetrieb sinnvoll damit arbeiten zu können
* Diese Kenngröße dient auch dazu, um den notwendigen Datensicherungszyklus daraus abzuleiten.
* Diese Kenngröße dient auch dazu, um den notwendigen Datensicherungszyklus daraus abzuleiten.
Theoretisch kann die RPO auch für analoge Informationen erhoben werden
Theoretisch kann die [[RPO]] auch für analoge Informationen erhoben werden
* Da diese analogen Informationen in der Praxis aber nicht in sinnvoller Art und Weise versioniert werden können, ist es in der Regel zielführender, benötigte analoge Informationen allein über die Ressourcenkategorie Informationen zu erheben, ohne RPO zu erheben und immer vom aktuellen Stand auszugehen.
* Da diese analogen Informationen in der Praxis aber nicht in sinnvoller Art und Weise versioniert werden können, ist es in der Regel zielführender, benötigte analoge Informationen allein über die Ressourcenkategorie Informationen zu erheben, ohne [[RPO]] zu erheben und immer vom aktuellen Stand auszugehen.
|-
|-
| Minimum Business Continuity Objective (MBCO) </br> Notbetriebsniveau || definiert, wie leistungsfähig der Notbetrieb sein soll, um einen sinnvollen Geschäftsbetrieb gewährleisten zu können
| [[MBCO]] || Minimum Business Continuity Objective</br>Notbetriebsniveau || definiert, wie leistungsfähig der Notbetrieb sein soll, um einen sinnvollen Geschäftsbetrieb gewährleisten zu können
* Das Notbetriebsniveau wird je Geschäftsprozess individuell festgelegt
* Das Notbetriebsniveau wird je Geschäftsprozess individuell festgelegt
* Hierzu kann die Leistungsfähigkeit des Notbetriebs z.&nbsp;B.&nbsp;prozentual angegeben werden oder alternativ können Aktivitäten priorisiert werden
* Hierzu kann die Leistungsfähigkeit des Notbetriebs beispielsweise&nbsp;prozentual angegeben werden oder alternativ können Aktivitäten priorisiert werden
* In obiger Abbildung wird das Notbetriebsniveau nur schematisch dargestellt
* In obiger Abbildung wird das Notbetriebsniveau nur schematisch dargestellt
|}
|}


== Vorbereitung der BIA ==
== Vorbereitung ==


=== Erhebung der Geschäftsprozesse ===
=== Erhebung der Geschäftsprozesse ===
Zeile 51: Zeile 51:
[[File:img-162-286.png|500px]]
[[File:img-162-286.png|500px]]


=== Festlegung der BIA-Parameter und betrachteten ===
=== Parameter und Zeithorizonte ===
; BIA-Parameter und Zeithorizonte
; Beispiel einer Bewertung des Schadenspotenzials je Zeithorizont
; Beispiel einer Bewertung des Schadenspotenzials je Zeithorizont
[[File:img-163-292.png|500px]]
[[File:img-163-292.png|700px]]


; Definition von Zeithorizonten
; Definition von Zeithorizonten
Zeile 65: Zeile 66:


; Beispiele für Zeithorizonte
; Beispiele für Zeithorizonte
[[File:img-165-298.png|600px]]
[[File:img-165-298.png|800px]]


; Schadensszenarien
; Schadensszenarien
; Innerhalb der BIA sollten mindestens die folgenden Schadensszenarien berücksichtigt werden
; Innerhalb der [[BIA]] sollten mindestens die folgenden Schadensszenarien berücksichtigt werden
* Beeinträchtigung der persönlichen Unversehrtheit
* Beeinträchtigung der persönlichen Unversehrtheit
* Beeinträchtigung der Aufgabenerfüllung
* Beeinträchtigung der Aufgabenerfüllung
Zeile 79: Zeile 80:
* ab welcher Schadenskategorie die Auswirkungen eines Ausfalls durch die Institution nicht länger toleriert werden (siehe Abbildung). Die Entscheidung darüber
* ab welcher Schadenskategorie die Auswirkungen eines Ausfalls durch die Institution nicht länger toleriert werden (siehe Abbildung). Die Entscheidung darüber
* ab welcher Höhe Schäden nicht länger toleriert werden
* ab welcher Höhe Schäden nicht länger toleriert werden
* sollte aufgrund der Tragweite für die weitere BC-Planung die Institutionsleitung treffen. Anhand des festgelegten Untragbarkeitsniveaus kann in der BIA identifiziert werden
* sollte aufgrund der Tragweite für die weitere BC-Planung die Institutionsleitung treffen. Anhand des festgelegten Untragbarkeitsniveaus kann in der [[BIA]] identifiziert werden
* zu welchem Zeitpunkt die erwarteten Schäden so hoch werden
* zu welchem Zeitpunkt die erwarteten Schäden so hoch werden
* dass diese nicht länger akzeptiert werden. Dies ist dann die MTPD des Geschäftsprozesses.
* dass diese nicht länger akzeptiert werden. Dies ist dann die [[MTPD]] des Geschäftsprozesses.


; Schadenskategorien
; Schadenskategorien
Zeile 88: Zeile 89:
[[File:bcmTab16-2.png|600px]]
[[File:bcmTab16-2.png|600px]]


=== Festlegung der Ressourcenkategorien und -cluster ===
=== Ressourcenkategorien und -cluster ===
Festlegung der Ressourcenkategorien und -cluster
; Ressourcenkategorien
; Ressourcenkategorien
Beispiele verschiedener Ressourcenkategorien
Beispiele verschiedener Ressourcenkategorien
Zeile 95: Zeile 97:


; Ressourcencluster
; Ressourcencluster
; Innerhalb bestimmter Ressourcenkategorien, z.&nbsp;B.&nbsp; der IT, können mitunter sehr viele einzelne Ressourcen vorhanden sein, die für die BIA relevant sind
; Innerhalb bestimmter Ressourcenkategorien, beispielsweise&nbsp; der IT, können mitunter sehr viele einzelne Ressourcen vorhanden sein, die für die [[BIA]] relevant sind
* Wenn alle Ressourcen einzeln erfasst werden, besteht jedoch die Gefahr, dass diese aufgrund der Menge und der Komplexität nicht handhabbar sind
* Wenn alle Ressourcen einzeln erfasst werden, besteht jedoch die Gefahr, dass diese aufgrund der Menge und der Komplexität nicht handhabbar sind
* Es ist daher sinnvoll, Ressourcen sinnvoll zu Clustern zusammenzufassen
* Es ist daher sinnvoll, Ressourcen sinnvoll zu Clustern zusammenzufassen
Zeile 104: Zeile 106:
* Ein Arbeitsplatz kann Teil einer größeren Infrastruktur sein und wiederum aus einer Menge an Maschinen, Geräten, Anlagen oder Betriebsmitteln zusammengesetzt sein.
* Ein Arbeitsplatz kann Teil einer größeren Infrastruktur sein und wiederum aus einer Menge an Maschinen, Geräten, Anlagen oder Betriebsmitteln zusammengesetzt sein.


=== Planung der BIA-Erhebung ===
=== Planung der Erhebung ===
Vor Beginn der BIA sollte festgelegt werden, wie die Informationen zur BIA erhoben werden sollen.  
; Planung der BIA-Erhebung
Vor Beginn der [[BIA]] sollte festgelegt werden, wie die Informationen zur [[BIA]] erhoben werden sollen.  


; Formate
; Formate
Zeile 117: Zeile 120:
* Hilfsmittel zur Erhebung und Auswertung der BIA
* Hilfsmittel zur Erhebung und Auswertung der BIA


== Durchführung der BIA ==
== Durchführung ==
=== Identifizierung zeitkritischer Geschäftsprozesse ===
=== Zeitkritische Geschäftsprozesse ===
; Identifizierung zeitkritischer Geschäftsprozesse
; Bewertung des Schadenspotenzials von Geschäftsprozessen
; Bewertung des Schadenspotenzials von Geschäftsprozessen
[[File:bcmTab18.png|600px]]
[[File:bcmTab18.png|600px]]
Zeile 128: Zeile 132:
[[File:bcmTab20.png|600px]]
[[File:bcmTab20.png|600px]]


=== Festlegung der MTPD ===
=== Festlegung der [[MTPD]] ===
; Leitfrage
; Leitfrage
<blockquote>
<blockquote>
Zeile 139: Zeile 143:


; Gründe
; Gründe
* Wenn die BIA in einem neuen BCMS-Zyklus aktualisiert wird, kann auf die bestehenden Informationen zurückgegriffen werden. Damit die Bewertung des Schadenspotenzials auch zu einem späteren Zeitpunkt nachvollziehbar ist, sollte diese begründet werden.
* Wenn die [[BIA]] in einem neuen BCMS-Zyklus aktualisiert wird, kann auf die bestehenden Informationen zurückgegriffen werden. Damit die Bewertung des Schadenspotenzials auch zu einem späteren Zeitpunkt nachvollziehbar ist, sollte diese begründet werden.
* Regulatoren setzen eine Begründung voraus, um auch als außenstehende Dritte die Schadensanalyse dahingehend überprüfen zu können, ob diese plausibel ist.
* Regulatoren setzen eine Begründung voraus, um auch als außenstehende Dritte die Schadensanalyse dahingehend überprüfen zu können, ob diese plausibel ist.
Die Begründung dient als Entscheidungshilfe, um geeignete Maßnahmen für die Geschäftsfortführung auszuwählen.  
Die Begründung dient als Entscheidungshilfe, um geeignete Maßnahmen für die Geschäftsfortführung auszuwählen.  
* Wenn die einzusetzenden finanziellen oder personellen Ressourcen für diese Maßnahmen zu hoch erscheinen, dann hilft eine Begründung aus der BIA mehr als die reine Angabe einer zu erreichenden MTPD.
* Wenn die einzusetzenden finanziellen oder personellen Ressourcen für diese Maßnahmen zu hoch erscheinen, dann hilft eine Begründung aus der [[BIA]] mehr als die reine Angabe einer zu erreichenden [[MTPD]] .


; Beispielhafte Begründung eines Schadenspotenzials
; Beispielhafte Begründung eines Schadenspotenzials
[[File:bcmTab22.png|600px]]
[[File:bcmTab22.png|600px]]


=== Festlegung der RTO für zeitkritische Geschäftsprozesse ===
=== [[RTO]] für zeitkritische Geschäftsprozesse ===
; Für die zeitkritischen Geschäftsprozesse muss zusätzlich die geforderte Wiederanlaufzeit RTO festgelegt werden
; Festlegung der [[RTO]] für zeitkritische Geschäftsprozesse
; Für die zeitkritischen Geschäftsprozesse muss zusätzlich die geforderte Wiederanlaufzeit [[RTO]] festgelegt werden
* Sie beschreibt, wie lange der reine Wiederanlauf dauern darf, bevor es zu nicht tolerablen Schäden kommt
* Sie beschreibt, wie lange der reine Wiederanlauf dauern darf, bevor es zu nicht tolerablen Schäden kommt
* Daher wird von der MTPD die BAO-Reak-tionszeit abgezogen
* Daher wird von der [[MTPD]] die BAO-Reak-tionszeit abgezogen
* Die BAO-Reaktionszeit verstreicht in der Regel unabhängig von einzelnen Geschäftsprozessen, bis der Notfall ausgerufen und die relevanten BC-Pläne gestartet werden.
* Die BAO-Reaktionszeit verstreicht in der Regel unabhängig von einzelnen Geschäftsprozessen, bis der Notfall ausgerufen und die relevanten BC-Pläne gestartet werden.


; Die RTO nimmt eine zentrale Rolle in der Notfallplanung und -behandlung ein
; Die [[RTO]] nimmt eine zentrale Rolle in der Notfallplanung und -behandlung ein
* Sie wird in Übungen verifiziert, sodass ein realistischeres Bild für die Notfallbehandlung entsteht.
* Sie wird in Übungen verifiziert, sodass ein realistischeres Bild für die Notfallbehandlung entsteht.
Für die BAO ist dann sichtbar, wie lange der Wiederanlauf vermutlich dauern wird, sodass dort bei dem Auftrag zum Wiederanlauf gut abgeschätzt werden kann, ob die MTPD noch eingehalten werden kann
Für die [[BAO]] ist dann sichtbar, wie lange der Wiederanlauf vermutlich dauern wird, sodass dort bei dem Auftrag zum Wiederanlauf gut abgeschätzt werden kann, ob die [[MTPD]] noch eingehalten werden kann
* Auch für die Notfallteams ist die RTO eine klare Zielvorgabe.
* Auch für die Notfallteams ist die [[RTO]] eine klare Zielvorgabe.


; Zwischen der Bestimmung der RTO und der BAO-Reaktionszeit besteht eine Wechselwirkung:  
; Zwischen der Bestimmung der [[RTO]] und der BAO-Reaktionszeit besteht eine Wechselwirkung:  
Einerseits bietet es sich an, diese Reaktionszeit einfach von der MTPD abzuziehen, um an die RTO zu gelangen
Einerseits bietet es sich an, diese Reaktionszeit einfach von der [[MTPD]] abzuziehen, um an die [[RTO]] zu gelangen
* Hierbei kann ein zusätzlicher Puffer berücksichtigt werden, z.&nbsp;B.&nbsp;für den Fall, dass beim Wiederanlauf Schwierigkeiten auftreten.
* Hierbei kann ein zusätzlicher Puffer berücksichtigt werden, beispielsweise&nbsp;für den Fall, dass beim Wiederanlauf Schwierigkeiten auftreten.
Andererseits wird hier sehr deutlich, dass längere Reaktionszeiten z.&nbsp;B.&nbsp;bei der Detektion oder Alarmierung alle Zeiträume für RTOs verkürzen
Andererseits wird hier sehr deutlich, dass längere Reaktionszeiten beispielsweise&nbsp;bei der Detektion oder Alarmierung alle Zeiträume für RTOs verkürzen
* Dadurch können sich auch die Kosten erhöhen, um diese RTOs einzuhalten
* Dadurch können sich auch die Kosten erhöhen, um diese RTOs einzuhalten
* Letzten Endes ist auch die BAO-Reaktionszeit eine Sollvorgabe, die sich aus den Anforderungen der Institution an die MTPDs ergibt.
* Letzten Endes ist auch die BAO-Reaktionszeit eine Sollvorgabe, die sich aus den Anforderungen der Institution an die [[MTPD]] s ergibt.


Zudem ist es bei der Festlegung der RTO hilfreich, schon Teile der BC-Planung, z.&nbsp;B.&nbsp;das angestrebte Notbetriebsniveau, konzeptionell vorzubereiten, sodass die RTO konkretisiert werden kann.
Zudem ist es bei der Festlegung der [[RTO]] hilfreich, schon Teile der BC-Planung, beispielsweise&nbsp;das angestrebte Notbetriebsniveau, konzeptionell vorzubereiten, sodass die [[RTO]] konkretisiert werden kann.


Für nicht zeitkritische Geschäftsprozesse entfallen die nachfolgenden Schritte, da diese im Rahmen des BCM nicht weiter betrachtet werden.
Für nicht zeitkritische Geschäftsprozesse entfallen die nachfolgenden Schritte, da diese im Rahmen des [[BCM]] nicht weiter betrachtet werden.


=== Festlegung des Notbetriebsniveaus (MBCO) ===
=== Notbetriebsniveaus ===
; Beispiel eines dokumentierten Notbetriebsniveaus
; Festlegung des Notbetriebsniveaus ([[MBCO]])
Beispiel eines dokumentierten Notbetriebsniveaus
[[File:bcmTab23.png|600px]]
[[File:bcmTab23.png|600px]]


; Dieser Prozessschritt der BIA ist abgeschlossen, wenn
; Abschluss
* die Geschäftsprozesse im GP-Umfang hinsichtlich ihres Schadenspotenzials bewertet wurden
Dieser Prozessschritt der [[BIA]] ist abgeschlossen
* die Geschäftsprozesse im GP-Umfang anhand der Kriterien mit einer MTPD versehen sind
* Geschäftsprozesse im GP-Umfang hinsichtlich ihres Schadenspotenzials bewertet
* die MTPD je zeitkritischem Geschäftsprozess begründet wurde
* Geschäftsprozesse im GP-Umfang anhand der Kriterien mit einer [[MTPD]] versehen
* für zeitkritische Geschäftsprozesse die jeweilige RTO definiert ist sowie
* [[MTPD]] je zeitkritischem Geschäftsprozess begründet
* für zeitkritische Geschäftsprozesse das erforderliche Notbetriebsniveau definiert wurde
* für zeitkritische Geschäftsprozesse  
** die jeweilige [[RTO]] definiert
**  das erforderliche Notbetriebsniveau definiert


== Identifizierung der Prozessabhängigkeiten (AS) ==
== Prozessabhängigkeiten ==
; Identifizierung der Prozessabhängigkeiten (AS)
; Beispiel Antragsbearbeitung
; Beispiel Antragsbearbeitung
[[File:img-184-338.png|mini|400px]]
[[File:img-184-338.png|mini|400px]]


Der Geschäftsprozess „Antragsbearbeitung“, mit einer RTO von 3 Tagen, ist vom Geschäftsprozess „Antragsprüfung“ abhängig
Der Geschäftsprozess „Antragsbearbeitung“, mit einer [[RTO]] von 3 Tagen, ist vom Geschäftsprozess „Antragsprüfung“ abhängig
* Die Antragsprüfung hat eine geringere Prozessausführungszeit
* Die Antragsprüfung hat eine geringere Prozessausführungszeit
* Zudem sind erfahrungsgemäß immer mehr Anträge bereits geprüft als in Bearbeitung (Arbeitsvorrat von einigen Tagen)
* Zudem sind erfahrungsgemäß immer mehr Anträge bereits geprüft als in Bearbeitung (Arbeitsvorrat von einigen Tagen)
* Obwohl eine zeitkritische Abhängigkeit zwischen beiden Geschäftsprozessen besteht, kann der abhängige Geschäftsprozess „Antragsbearbeitung“ wiederaufgenommen werden, ohne dass der benötigte Geschäftsprozess „Antragsprüfung“ bereits läuft
* Obwohl eine zeitkritische Abhängigkeit zwischen beiden Geschäftsprozessen besteht, kann der abhängige Geschäftsprozess „Antragsbearbeitung“ wiederaufgenommen werden, ohne dass der benötigte Geschäftsprozess „Antragsprüfung“ bereits läuft
* Daher wird zwischen den Prozesszuständigen vereinbart, dass die RTO des benötigten Geschäftsprozesses „Antragsprüfung“ mit 7 Tagen deutlich größer sein kann als die RTO des abhängigen Geschäftsprozesses „Antragsbearbeitung“
* Daher wird zwischen den Prozesszuständigen vereinbart, dass die [[RTO]] des benötigten Geschäftsprozesses „Antragsprüfung“ mit 7 Tagen deutlich größer sein kann als die [[RTO]] des abhängigen Geschäftsprozesses „Antragsbearbeitung“


; Beispiel Kundschaftsbetreuung
; Beispiel Kundschaftsbetreuung
[[File:img-184-338.png|mini|400px]]
[[File:img-184-338.png|mini|400px]]
Der Geschäftsprozess „Kundschaftsbetreuung“ mit einer RTO von 3 Tagen ist von einem ausgelagerten Geschäftsprozess „Telefon-Hotline-Dienst“ abhängig
Der Geschäftsprozess „Kundschaftsbetreuung“ mit einer [[RTO]] von 3 Tagen ist von einem ausgelagerten Geschäftsprozess „Telefon-Hotline-Dienst“ abhängig
* Dieser stellt sicher, dass Anrufe angenommen, die Anfragen geprüft und an das richtige Team in der „Kundschaftsbetreuung“ weitergeleitet werden
* Dieser stellt sicher, dass Anrufe angenommen, die Anfragen geprüft und an das richtige Team in der „Kundschaftsbetreuung“ weitergeleitet werden
* Da der benötigte Geschäftsprozess „Telefon-Hotline-Dienst“ parallel zum abhängigen Geschäftsprozess „Kundschaftsbetreuung“ ausgeführt werden muss, wird entschieden, dass die RTO des abhängigen Geschäftsprozesses übernommen wird.
* Da der benötigte Geschäftsprozess „Telefon-Hotline-Dienst“ parallel zum abhängigen Geschäftsprozess „Kundschaftsbetreuung“ ausgeführt werden muss, wird entschieden, dass die [[RTO]] des abhängigen Geschäftsprozesses übernommen wird.


; Beispiel Produktion
; Beispiel Produktion
[[File:img-185-342.png|mini|400px]]
[[File:img-185-342.png|mini|400px]]
Der Geschäftsprozess „Produktion“ in einer Milchfabrik, mit einer RTO von drei Tagen, ist vom nachgelagerten Geschäftsprozess „Distribution“ abhängig
Der Geschäftsprozess „Produktion“ in einer Milchfabrik, mit einer [[RTO]] von drei Tagen, ist vom nachgelagerten Geschäftsprozess „Distribution“ abhängig
* Da nur begrenzte Lagermöglichkeiten für die produzierten Güter bestehen, können diese maximal zwei weitere Tage aufbewahrt werden, bevor das Lagervolumen ausgeschöpft ist
* Da nur begrenzte Lagermöglichkeiten für die produzierten Güter bestehen, können diese maximal zwei weitere Tage aufbewahrt werden, bevor das Lagervolumen ausgeschöpft ist
* Um einen kontinuierlichen Produktionsfluss zu gewährleisten, wird beschlossen, die RTO des benötigten Geschäftsprozesses „Distribution“ auf fünf Tage festzulegen.
* Um einen kontinuierlichen Produktionsfluss zu gewährleisten, wird beschlossen, die [[RTO]] des benötigten Geschäftsprozesses „Distribution“ auf fünf Tage festzulegen.


== Identifizierung der Ressourcenabhängigkeiten ==
== Ressourcenabhängigkeiten ==
; Identifizierung der Ressourcenabhängigkeiten
Relevant für die weiteren Schritte in der BC-Planung der Ressourcen sind die folgenden BIA-Kenngrößen für Ressourcen:
Relevant für die weiteren Schritte in der BC-Planung der Ressourcen sind die folgenden BIA-Kenngrößen für Ressourcen:
* Geforderte Wiederanlaufzeit (RTO)
* Geforderte Wiederanlaufzeit ([[RTO]])
* Ressourcenbedarf in Abhängigkeit zur Dauer des Notbetriebs
* Ressourcenbedarf in Abhängigkeit zur Dauer des Notbetriebs
* Im Falle von Daten und IT-Ressourcen: maximal zulässiger Datenverlust (RPO)
* Im Falle von Daten und IT-Ressourcen: maximal zulässiger Datenverlust ([[RPO]])


=== RTO der benötigten Ressourcen ===
=== [[RTO]] der Ressourcen ===
; [[RTO]] der benötigten Ressourcen
; Beispiele für Ressourcenabhängigkeiten verschiedener Geschäftsprozesse
; Beispiele für Ressourcenabhängigkeiten verschiedener Geschäftsprozesse
[[File:bcmTab24.png|600px]]
[[File:bcmTab24.png|600px]]


Ressourcen, deren RTO aufgrund des Minimalprinzips ermittelt wurden, sind hervor­ gehoben.
Ressourcen, deren [[RTO]] aufgrund des Minimalprinzips ermittelt wurden, sind hervor­ gehoben.


=== Ressourcenbedarf in Abhängigkeit zur Dauer des Notbetriebs ===
=== Ressourcenbedarf im Notbetrieb ===
Ressourcenbedarf in Abhängigkeit zur Dauer des Notbetriebs
; Beispiel für Arbeitsplatz- und Personalabhängigkeiten
; Beispiel für Arbeitsplatz- und Personalabhängigkeiten
Benötigte Anzahl Arbeitsplätze oder Personal im Notbetrieb der OE Kun­denmanagement
Benötigte Anzahl Arbeitsplätze oder Personal im Notbetrieb der OE Kun­denmanagement
[[File:bcmTab25.png|600px]]
[[File:bcmTab25.png|600px]]


=== RPO ===
=== Recovery Point Objective ===
; Beispiele für informationsbasierte Ressourcenabhängigkeiten verschiede­ner Geschäftsprozesse
[[RPO]] - Recovery Point Objective (maximal zulässiger Datenverlust)
 
; Beispiel
Informationsbasierte Ressourcenabhängigkeiten verschiede­ner Geschäftsprozesse
[[File:bcmTab26.png|600px]]
[[File:bcmTab26.png|600px]]


== Identifizierung vorhandener Single Points of Failure ==
== Single Points of Failure ==
; Identifizierung vorhandener Single Points of Failure
Wenn viele (sehr) zeitkritische Geschäftsprozesse eine einzelne Ressource benötigen, stellt diese ein erhöhtes Risiko für eine Geschäftsunterbrechung dar. Üblicherweise werden solche Ressourcen als ''Single Point of Failure'' bezeichnet.  
Wenn viele (sehr) zeitkritische Geschäftsprozesse eine einzelne Ressource benötigen, stellt diese ein erhöhtes Risiko für eine Geschäftsunterbrechung dar. Üblicherweise werden solche Ressourcen als ''Single Point of Failure'' bezeichnet.  


Es gibt verschiedene Arten von Single Points of Failure:
;  Arten
{| class="wikitable options big"
{| class="wikitable options big gnu"
! SPoF !! Beschreibung
! !! Name !! Beschreibung
|-
|-
| Wissen </br>(Single Point of Knowledge, SPoK) || Person, die als einzige über alle Fähigkeiten und spezifische Kenntnisse eines Prozesses oder Verfahrens verfügt
| SPoK || Wissen </br>(Single Point of Knowledge) || Person, die als einzige über alle Fähigkeiten und spezifische Kenntnisse eines Prozesses oder Verfahrens verfügt
|-
|-
| Technik oder Dienstleistung </br>(Single Point of Failure, SPoF) || Anlage, eine Komponente, ein IT-System, ein Dienstleistungsunternehmen etc., durch deren Ausfall ein Gesamtsystem nicht mehr betriebsbereit ist  
| SPoF || Technik oder Dienstleistung </br>(Single Point of Failure) || Anlage, eine Komponente, ein IT-System, ein Dienstleistungsunternehmen etc., durch deren Ausfall ein Gesamtsystem nicht mehr betriebsbereit ist  
* Das trifft immer dann zu, wenn eine Komponente eine zentrale Funktion im Gesamtsystem übernimmt und beim Ausfall die Funktionen der anderen Komponenten beeinträchtigt
* Das trifft immer dann zu, wenn eine Komponente eine zentrale Funktion im Gesamtsystem übernimmt und beim Ausfall die Funktionen der anderen Komponenten beeinträchtigt
|-
|-
| Kontakte </br>(Single Point of Contact, SPoC) || Person, die die alleinige Kontaktperson ist, oder eine Schnittstelle, die die alleinige Kommunikationsstelle für einen bestimmten Sachverhalt ist
| SPoC || Kontakte </br>(Single Point of Contact) || Person, die die alleinige Kontaktperson ist, oder eine Schnittstelle, die die alleinige Kommunikationsstelle für einen bestimmten Sachverhalt ist
|-  
|-  
| Kumulationseffekt || Ressourcen, welche von relativ vielen zeitkritischen Geschäftsprozessen benötigt werden
| Kumulationseffekt || || Ressourcen, welche von relativ vielen zeitkritischen Geschäftsprozessen benötigt werden
|}
|}


== Auswertung ==
== Auswertung ==
Die Gesamtübersicht sollte mindestens die folgenden Inhalte umfassen:
; Gesamtübersicht
* Übersicht der zeitkritischen Geschäftsprozesse und zugehörigen Kontaktpersonen
* Übersicht der zeitkritischen Geschäftsprozesse und zugehörigen Kontaktpersonen
* Übersicht der Prozessabhängigkeiten  
* Übersicht der Prozessabhängigkeiten  
* Übersicht der abhängigen Ressourcen und SpoFs sowie deren RTO bzw. RPO
* Übersicht der abhängigen Ressourcen und [[SpoF]]s sowie deren [[RTO]] bzw. [[RPO]]


<noinclude>
<noinclude>
----
{{Navigation|BSI/200-4/06 BIA-Vorfilter|BSI/200-4/08 Soll-Ist-Vergleich}}
----


== Anhang ==
== Anhang ==

Aktuelle Version vom 16. Juni 2026, 20:42 Uhr

BSI/200-4/07 Business Impact Analyse

Beschreibung

In der BIA wird untersucht
  • welche Geschäftsprozesse zeitkritisch sind
  • ab wann deren Ausfälle nicht tolerierbare Auswirkungen haben
Daraus werden die Wiederanlaufanforderungen abgeleitet
  • ob und ab wann für diese Geschäftsprozesse ein Notbetrieb zur Verfügung stehen sollte
  • welche Ressourcen dafür benötigt werden

Falls die BAO schon aufgebaut wurde, helfen diese Informationen der BAO zu­dem

  • die zeitkritischen Geschäftsprozesse und Ressourcen in einem Notfall zu priorisieren
  • früh zu erkennen, ob ein Schadensereignis eskaliert werden muss sowie
  • den Geschäftsbetrieb aufrechtzuerhalten
Prozessschritte der Business-Impact-Analyse

Kenngrößen

Kenngröße Beschreibung
MTPD Maximum Tolerable Period of Disruption
Maximal Tolerierbare Ausfallzeit, MTA		 legt fest, wie lange ein Geschäftsprozess maximal ausfallen darf, bevor nicht tolerierbare Auswirkungen für die Institution auftreten
  • Die MTPD wird anhand einer Bewertung des Schadenspotenzials je Geschäftsprozess ermittelt.
RTO
WAZ		 Recovery Time Objective
Geforderte Wiederanlaufzeit		 wird aus der MTPD abgeleitet und sowohl den zeitkritischen Geschäftsprozessen als auch den Ressourcen zugeordnet, die relevant sind für die Aufrechterhaltung der zeitkritischen Geschäftsprozesse
  • Die RTO umfasst den Zeitraum vom Ausrufen des Notfalls bis zum Zeitpunkt der geforderten Inbetriebnahme der BC-Lösung
  • Im Falle von IT-Ressourcen wäre das beispielsweise der Schwenk auf eine Ausweich- oder Ersatzressource oder das Zurücksetzen eines IT-Systems auf den letzten gesicherten Zustand

Die RTO muss zwingend kürzer sein als die MTPD des relevanten Geschäftsprozesses, denn die Reaktionszeit wird von der MTPD abgezogen, um mit der RTO die MTPD noch erreichen zu können

  • Zusätzlich ist es empfehlenswert, einen weiteren zeitlichen Puffer einzuplanen, da insbesondere die Detektion mit Unsicherheiten hinsichtlich des genauen zeitlichen Ablaufs einhergeht.
RPO Recovery Point Objective
Maximal zulässiger Datenverlust		 legt fest, welcher Datenverlust akzeptiert wird, d. h. wie alt verfügbare Daten maximal sein dürfen, um im Notbetrieb sinnvoll damit arbeiten zu können
  • Diese Kenngröße dient auch dazu, um den notwendigen Datensicherungszyklus daraus abzuleiten.

Theoretisch kann die RPO auch für analoge Informationen erhoben werden

  • Da diese analogen Informationen in der Praxis aber nicht in sinnvoller Art und Weise versioniert werden können, ist es in der Regel zielführender, benötigte analoge Informationen allein über die Ressourcenkategorie Informationen zu erheben, ohne RPO zu erheben und immer vom aktuellen Stand auszugehen.
MBCO Minimum Business Continuity Objective
Notbetriebsniveau		 definiert, wie leistungsfähig der Notbetrieb sein soll, um einen sinnvollen Geschäftsbetrieb gewährleisten zu können
  • Das Notbetriebsniveau wird je Geschäftsprozess individuell festgelegt
  • Hierzu kann die Leistungsfähigkeit des Notbetriebs beispielsweise prozentual angegeben werden oder alternativ können Aktivitäten priorisiert werden
  • In obiger Abbildung wird das Notbetriebsniveau nur schematisch dargestellt

Vorbereitung

Erhebung der Geschäftsprozesse

Beispiele hierarchisch angeordneter Geschäftsprozesse

Parameter und Zeithorizonte

BIA-Parameter und Zeithorizonte
Beispiel einer Bewertung des Schadenspotenzials je Zeithorizont

Definition von Zeithorizonten

Die Wahl der Zeithorizonte wird unter anderem beeinflusst durch

  • die Zyklen, in denen Produkte hergestellt, Prozesse durchgeführt oder Services bereitgestellt werden,
  • die Erwartungshaltung an Ausfallzeiten (unter anderem von Interessengruppen)
  • interne Vorgaben und Geschäftsziele
  • branchenübliche Standards
  • gesetzliche Vorgaben
  • Risikobereitschaft der Institution
Beispiele für Zeithorizonte

Schadensszenarien
Innerhalb der BIA sollten mindestens die folgenden Schadensszenarien berücksichtigt werden
  • Beeinträchtigung der persönlichen Unversehrtheit
  • Beeinträchtigung der Aufgabenerfüllung
  • Verstoß gegen Gesetze, Vorschriften und Verträge
  • negative Innen- und Außenwirkung (Imageschaden)
  • finanzielle Auswirkungen
Untragbarkeitsniveau

Das Untragbarkeitsniveau definiert

  • ab welcher Schadenskategorie die Auswirkungen eines Ausfalls durch die Institution nicht länger toleriert werden (siehe Abbildung). Die Entscheidung darüber
  • ab welcher Höhe Schäden nicht länger toleriert werden
  • sollte aufgrund der Tragweite für die weitere BC-Planung die Institutionsleitung treffen. Anhand des festgelegten Untragbarkeitsniveaus kann in der BIA identifiziert werden
  • zu welchem Zeitpunkt die erwarteten Schäden so hoch werden
  • dass diese nicht länger akzeptiert werden. Dies ist dann die MTPD des Geschäftsprozesses.
Schadenskategorien
Schadenskategorien und Erläuterung je Schadensszenario

Ressourcenkategorien und -cluster

Festlegung der Ressourcenkategorien und -cluster

Ressourcenkategorien

Beispiele verschiedener Ressourcenkategorien

Ressourcencluster
Innerhalb bestimmter Ressourcenkategorien, beispielsweise  der IT, können mitunter sehr viele einzelne Ressourcen vorhanden sein, die für die BIA relevant sind
  • Wenn alle Ressourcen einzeln erfasst werden, besteht jedoch die Gefahr, dass diese aufgrund der Menge und der Komplexität nicht handhabbar sind
  • Es ist daher sinnvoll, Ressourcen sinnvoll zu Clustern zusammenzufassen
Das gängigste Beispiel für ein Cluster ist der Arbeitsplatz
  • Ein Arbeitsplatz fasst alle Arbeitsmittel und Geräte zusammen, die für eine spezifische Aufgabenstellung innerhalb eines Geschäftsprozesses benötigt werden
  • Hierbei kann allgemein zwischen einem Standardarbeitsplatz und Spezialarbeitsplätzen unterschieden werden
  • Ein Arbeitsplatz kann Teil einer größeren Infrastruktur sein und wiederum aus einer Menge an Maschinen, Geräten, Anlagen oder Betriebsmitteln zusammengesetzt sein.

Planung der Erhebung

Planung der BIA-Erhebung

Vor Beginn der BIA sollte festgelegt werden, wie die Informationen zur BIA erhoben werden sollen.

Formate
  • Selbstauskunft durch den Prozesseigentümer oder die -eigentümerin anhand eines papierbasierten, elektronischen oder toolgestützten Fragebogens,
  • Einzelinterviews mit verschiedenen Personen (z. B. Leitenden der Organisationseinheiten, Prozesszuständigen oder sonstigen Prozessfachleuten, die Auskunft geben können)
  • Workshops, mit mehreren Personen

Vorbereitung der BIA-Hilfsmittel

  • Präsentation zur Erläuterung der BIA
  • Liste der Geschäftsprozesse
  • Hilfsmittel zur Erhebung und Auswertung der BIA

Durchführung

Zeitkritische Geschäftsprozesse

Identifizierung zeitkritischer Geschäftsprozesse
Bewertung des Schadenspotenzials von Geschäftsprozessen

Worst-Case-Bewertung des Schadenspotenzials des Geschäftsprozesses „Kundschaftsanfragen bearbeiten“

Korrekte und fehlerhafte Bewertung des Schadenspo­tenzials

Festlegung der MTPD

Leitfrage

„Wenn der Geschäftsprozess ausfällt, mit welchem Schadenspotenzial [1 (gering), 2 (mittel), 3 (hoch), 4 (sehr hoch)] ist bei einem Ausfall bis zu … zu rech­nen?“

Begründung zur Bewertung des Schadenspotenzials

Die Bewertung des Schadenspotenzials muss je Geschäftsprozess begründet und dokumentiert werden.

Gründe
  • Wenn die BIA in einem neuen BCMS-Zyklus aktualisiert wird, kann auf die bestehenden Informationen zurückgegriffen werden. Damit die Bewertung des Schadenspotenzials auch zu einem späteren Zeitpunkt nachvollziehbar ist, sollte diese begründet werden.
  • Regulatoren setzen eine Begründung voraus, um auch als außenstehende Dritte die Schadensanalyse dahingehend überprüfen zu können, ob diese plausibel ist.

Die Begründung dient als Entscheidungshilfe, um geeignete Maßnahmen für die Geschäftsfortführung auszuwählen.

  • Wenn die einzusetzenden finanziellen oder personellen Ressourcen für diese Maßnahmen zu hoch erscheinen, dann hilft eine Begründung aus der BIA mehr als die reine Angabe einer zu erreichenden MTPD .
Beispielhafte Begründung eines Schadenspotenzials

RTO für zeitkritische Geschäftsprozesse

Festlegung der RTO für zeitkritische Geschäftsprozesse
Für die zeitkritischen Geschäftsprozesse muss zusätzlich die geforderte Wiederanlaufzeit RTO festgelegt werden
  • Sie beschreibt, wie lange der reine Wiederanlauf dauern darf, bevor es zu nicht tolerablen Schäden kommt
  • Daher wird von der MTPD die BAO-Reak-tionszeit abgezogen
  • Die BAO-Reaktionszeit verstreicht in der Regel unabhängig von einzelnen Geschäftsprozessen, bis der Notfall ausgerufen und die relevanten BC-Pläne gestartet werden.
Die RTO nimmt eine zentrale Rolle in der Notfallplanung und -behandlung ein
  • Sie wird in Übungen verifiziert, sodass ein realistischeres Bild für die Notfallbehandlung entsteht.

Für die BAO ist dann sichtbar, wie lange der Wiederanlauf vermutlich dauern wird, sodass dort bei dem Auftrag zum Wiederanlauf gut abgeschätzt werden kann, ob die MTPD noch eingehalten werden kann

  • Auch für die Notfallteams ist die RTO eine klare Zielvorgabe.
Zwischen der Bestimmung der RTO und der BAO-Reaktionszeit besteht eine Wechselwirkung

Einerseits bietet es sich an, diese Reaktionszeit einfach von der MTPD abzuziehen, um an die RTO zu gelangen

  • Hierbei kann ein zusätzlicher Puffer berücksichtigt werden, beispielsweise für den Fall, dass beim Wiederanlauf Schwierigkeiten auftreten.

Andererseits wird hier sehr deutlich, dass längere Reaktionszeiten beispielsweise bei der Detektion oder Alarmierung alle Zeiträume für RTOs verkürzen

  • Dadurch können sich auch die Kosten erhöhen, um diese RTOs einzuhalten
  • Letzten Endes ist auch die BAO-Reaktionszeit eine Sollvorgabe, die sich aus den Anforderungen der Institution an die MTPD s ergibt.

Zudem ist es bei der Festlegung der RTO hilfreich, schon Teile der BC-Planung, beispielsweise das angestrebte Notbetriebsniveau, konzeptionell vorzubereiten, sodass die RTO konkretisiert werden kann.

Für nicht zeitkritische Geschäftsprozesse entfallen die nachfolgenden Schritte, da diese im Rahmen des BCM nicht weiter betrachtet werden.

Notbetriebsniveaus

Festlegung des Notbetriebsniveaus (MBCO)

Beispiel eines dokumentierten Notbetriebsniveaus

Abschluss

Dieser Prozessschritt der BIA ist abgeschlossen

  • Geschäftsprozesse im GP-Umfang hinsichtlich ihres Schadenspotenzials bewertet
  • Geschäftsprozesse im GP-Umfang anhand der Kriterien mit einer MTPD versehen
  • MTPD je zeitkritischem Geschäftsprozess begründet
  • für zeitkritische Geschäftsprozesse
    • die jeweilige RTO definiert
    • das erforderliche Notbetriebsniveau definiert

Prozessabhängigkeiten

Identifizierung der Prozessabhängigkeiten (AS)
Beispiel Antragsbearbeitung

Der Geschäftsprozess „Antragsbearbeitung“, mit einer RTO von 3 Tagen, ist vom Geschäftsprozess „Antragsprüfung“ abhängig

  • Die Antragsprüfung hat eine geringere Prozessausführungszeit
  • Zudem sind erfahrungsgemäß immer mehr Anträge bereits geprüft als in Bearbeitung (Arbeitsvorrat von einigen Tagen)
  • Obwohl eine zeitkritische Abhängigkeit zwischen beiden Geschäftsprozessen besteht, kann der abhängige Geschäftsprozess „Antragsbearbeitung“ wiederaufgenommen werden, ohne dass der benötigte Geschäftsprozess „Antragsprüfung“ bereits läuft
  • Daher wird zwischen den Prozesszuständigen vereinbart, dass die RTO des benötigten Geschäftsprozesses „Antragsprüfung“ mit 7 Tagen deutlich größer sein kann als die RTO des abhängigen Geschäftsprozesses „Antragsbearbeitung“
Beispiel Kundschaftsbetreuung

Der Geschäftsprozess „Kundschaftsbetreuung“ mit einer RTO von 3 Tagen ist von einem ausgelagerten Geschäftsprozess „Telefon-Hotline-Dienst“ abhängig

  • Dieser stellt sicher, dass Anrufe angenommen, die Anfragen geprüft und an das richtige Team in der „Kundschaftsbetreuung“ weitergeleitet werden
  • Da der benötigte Geschäftsprozess „Telefon-Hotline-Dienst“ parallel zum abhängigen Geschäftsprozess „Kundschaftsbetreuung“ ausgeführt werden muss, wird entschieden, dass die RTO des abhängigen Geschäftsprozesses übernommen wird.
Beispiel Produktion

Der Geschäftsprozess „Produktion“ in einer Milchfabrik, mit einer RTO von drei Tagen, ist vom nachgelagerten Geschäftsprozess „Distribution“ abhängig

  • Da nur begrenzte Lagermöglichkeiten für die produzierten Güter bestehen, können diese maximal zwei weitere Tage aufbewahrt werden, bevor das Lagervolumen ausgeschöpft ist
  • Um einen kontinuierlichen Produktionsfluss zu gewährleisten, wird beschlossen, die RTO des benötigten Geschäftsprozesses „Distribution“ auf fünf Tage festzulegen.

Ressourcenabhängigkeiten

Identifizierung der Ressourcenabhängigkeiten

Relevant für die weiteren Schritte in der BC-Planung der Ressourcen sind die folgenden BIA-Kenngrößen für Ressourcen:

  • Geforderte Wiederanlaufzeit (RTO)
  • Ressourcenbedarf in Abhängigkeit zur Dauer des Notbetriebs
  • Im Falle von Daten und IT-Ressourcen: maximal zulässiger Datenverlust (RPO)

RTO der Ressourcen

RTO der benötigten Ressourcen
Beispiele für Ressourcenabhängigkeiten verschiedener Geschäftsprozesse

Ressourcen, deren RTO aufgrund des Minimalprinzips ermittelt wurden, sind hervor­ gehoben.

Ressourcenbedarf im Notbetrieb

Ressourcenbedarf in Abhängigkeit zur Dauer des Notbetriebs

Beispiel für Arbeitsplatz- und Personalabhängigkeiten

Benötigte Anzahl Arbeitsplätze oder Personal im Notbetrieb der OE Kun­denmanagement

Recovery Point Objective

RPO - Recovery Point Objective (maximal zulässiger Datenverlust)

Beispiel

Informationsbasierte Ressourcenabhängigkeiten verschiede­ner Geschäftsprozesse

Single Points of Failure

Identifizierung vorhandener Single Points of Failure

Wenn viele (sehr) zeitkritische Geschäftsprozesse eine einzelne Ressource benötigen, stellt diese ein erhöhtes Risiko für eine Geschäftsunterbrechung dar. Üblicherweise werden solche Ressourcen als Single Point of Failure bezeichnet.

Arten
Name Beschreibung
SPoK Wissen
(Single Point of Knowledge)		 Person, die als einzige über alle Fähigkeiten und spezifische Kenntnisse eines Prozesses oder Verfahrens verfügt
SPoF Technik oder Dienstleistung
(Single Point of Failure)		 Anlage, eine Komponente, ein IT-System, ein Dienstleistungsunternehmen etc., durch deren Ausfall ein Gesamtsystem nicht mehr betriebsbereit ist
  • Das trifft immer dann zu, wenn eine Komponente eine zentrale Funktion im Gesamtsystem übernimmt und beim Ausfall die Funktionen der anderen Komponenten beeinträchtigt
SPoC Kontakte
(Single Point of Contact)		 Person, die die alleinige Kontaktperson ist, oder eine Schnittstelle, die die alleinige Kommunikationsstelle für einen bestimmten Sachverhalt ist
Kumulationseffekt Ressourcen, welche von relativ vielen zeitkritischen Geschäftsprozessen benötigt werden

Auswertung

Gesamtübersicht
  • Übersicht der zeitkritischen Geschäftsprozesse und zugehörigen Kontaktpersonen
  • Übersicht der Prozessabhängigkeiten
  • Übersicht der abhängigen Ressourcen und SpoFs sowie deren RTO bzw. RPO


← Zurück
Weiter →

Anhang

Siehe auch

  1. https://de.wikipedia.org/wiki/Business-Impact-Analyse
  2. Vermeidung von operationellen Prozessausfällen mit Hilfe der Business Impact-Methodik (deutsch) (PDF; 493 kB)
  3. Exemplarische Vorgehensweise für die Durchführung einer Business Impact Analyse (deutsch) (PDF-Datei; 439 kB)
Abgerufen von „https://wiki.foxtom.de/index.php?title=BSI/200-4/07_Business_Impact_Analyse&oldid=167349“