Einleitung

Beschreibung

Business Continuity Management System

Business Continuity Management System in Institutionen aufbauen und etablieren

Praxisnahe Anleitung
Leichter Einstieg
Normativer Anforderungskatalog für erfahrene AnwenderInnen

Resilienz

Zielsetzung

Herausforderung

Leistungen erbringen

immer effizienter
möglichst zu jeder Zeit

Entwicklungen und Trends

Steigende Anforderungen

Globalen Wettbewerb
Fortschreitende Digitalisierung
Interessengruppen (Aufsichtsbehörden, Kunden, Öffentlichkeit, ...)

Abhängigkeiten

Steigende Abhängigkeiten

Die Verfügbarkeit der Geschäftsprozesse oder Fachaufgaben ist eine Existenzfrage für Institution

Existenzbedrohenden Schäden

Gleichzeitig nehmen Risiken zu

die den Geschäftsbetrieb oder die Aufgabenerfüllung einer Institution in hohem Maße beeinträchtigen und sogar zu einem existenzbedrohenden Schaden führen können
gegen die sich Institutionen nicht komplett schützen können
Cyber-Angriffe
Naturereignisse

Ausfall kritischer Geschäftsprozesse

Obwohl

Institutionen sich mit Informationssicherheit bzw. Cybersicherheit
sowie mit IT-Service Continuity Management (ITSCM)
zu schützen versuchen
führten Cyber-Angriffe immer wieder zu Ausfällen kritischer Geschäftsprozesse
Insbesondere Ransomware-Angriffe haben sich zu einer allgegenwärtigen Bedrohung entwickelt

Effizienzsteigerung von Geschäftsprozessen

Zudem sorgt die fortschreitende Effizienzsteigerung von Geschäftsprozessen dafür

dass Leerlauf- und Pufferzeiten auf ein Minimum reduziert werden
Darüber hinaus werden auch in der Logistik und der Produktion benötigte Ressourcen auf ein Mindestmaß reduziert, um Lagerflächen einzusparen

Zeitfenster

Dadurch verkleinern sich in der Praxis die Zeitfenster innerhalb derer auf Ausfälle der Geschäftsprozesse angemessen reagiert und unmittelbare Folgewirkungen eingedämmt werden können

Notwendigkeit der Vorsorge

Entsprechend steigt die Notwendigkeit, gegen Ausfälle des Geschäftsbetriebs umfassend vorzusorgen sowie für den Schadensfall angemessene Möglichkeiten zur Geschäftsfortführung vorzubereiten (engl. Business Continuity oder BC)

Business-Continuity-Management

Angemessenes Business-Continuity-Management

Mit Hilfe eines angemessenen Business-Continuity-Managements ([BCM]) können sich Institutionen vor den Auswirkungen solcher Schadensereignisse schützen, die den Geschäftsbetrieb in nicht akzeptablem bis hin zu existenzbedrohendem Maße beeinträchtigen können

Ziel des BCM ist es sicherzustellen, dass der Geschäftsbetrieb selbst bei massiven Schadensereignissen nicht unterbrochen wird oder nach einer Unterbrechung in angemessener Zeit auf einem definierten Mindestniveau fortgeführt werden kann
Das BCM umfasst organisatorische, technische, bauliche und personelle Maßnahmen

Synergien

Institutionen können dabei teilweise auf vorhandene Sicherheitsmaßnahmen weiterer Managementsysteme zurückgreifen und diese gegebenenfalls erweitern
Synergien ergeben sich beispielsweise mit dem Managementsystem für Informationssicherheit (ISMS)

BSI-Standard 200-4

Erleichtert den Einstieg in ein BCM

indem ein Stufenmodell mit Einstiegsstufen angeboten wird

Anleitung, ein vollständiges, zur Norm ISO 22301 konformes BCM

einzuführen
aufrechtzuerhalten
zu verbessern

Anforderungskatalog

Für erfahrene Anwendende

Existierendes BCM
Schnell und effektiv nach BSI-Standard 200-4 ausrichten

Business Continuity Management System

Business Continuity Management System (BCMS)

BCM ist kein einmaliges Projekt

Bedarf eines zielgerichteten Business Continuity Management Systems (BCMS)
das fortlaufend weiterentwickelt wird

Aufbau und Verbesserung

Ein BCMS muss

kontinuierlich verbessert werden
an sich verändernde Rahmenbedingungen der Institution angepasst werden

Dauerhafter Prozess

So wird ein dauerhafter Prozess geschaffen

um organisatorische Resilienz (Widerstandsfähigkeit) aufzubauen

Organisatorische Resilienz

Auf Veränderungen reagieren und anzupassen

Organisatorische Resilienz ist die Fähigkeit, auf Veränderungen zu reagieren und sich diesen Veränderungen anzupassen

Resilienz

Je „resilienter“ eine Institution ist

umso besser kann sie
Risiken und Chancen durch Veränderungen
- erkennen
- flexibel darauf reagieren
Dies gilt für Veränderungen
- plötzliche und allmähliche
- interne und externe

Managementsysteme

Organisatorische Resilienz

wird nicht durch ein einzelnes Managementsystem aufgebaut
sondern entsteht erst durch das Zusammenspiel verschiedener Management-Disziplinen

Eckpfeiler, die gemeinsam Resilienz schaffen können

Einführung in das BCM

BSI/200-4/Einführung

Initiierung des BCMS durch die Institutionsleitung

BSI/200-4/Initiierung

Konzeption und Planung des BCMS

BSI/200-4/Konzeption und Planung

Aufbau und Befähigung der BAO

BSI/200-4/Aufbau und Befähigung

Voranalyse

BSI/200-4/Voranalyse

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 zudem

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

Geschäftsprozesse

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

Hilfsmittel

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 Schadenspotenzials

MTPD festlegen

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 rechnen?“

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 Kundenmanagement

Recovery Point Objective

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

Beispiel

Informationsbasierte Ressourcenabhängigkeiten verschiedener Geschäftsprozesse

Single Points of Failure

Identifizierung von Single Points of Failure

Viele Geschäftsprozesse benötigen einzelne Ressourcen

erhöhtes Risiko für eine Unterbrechung

Arten

	Name	Bereich	Beschreibung
SPoF	Single Point of Failure	Technik/Dienstleistung	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
SPoK	Single Point of Knowledge	Wissen	Person, die als einzige über alle Fähigkeiten und spezifische Kenntnisse eines Prozesses oder Verfahrens verfügt
SPoC	Single Point of Contact	Kontakte	Person, die die alleinige Kontaktperson ist, oder eine Schnittstelle, die die alleinige Kommunikationsstelle für einen bestimmten Sachverhalt ist
Kumulationseffekt			Ressourcen, welche von vielen Geschäftsprozessen benötigt werden