Das Business Continuity Management System BCMS kann nach ISO 22301:2012 durch eine Zertifizierungsorganisation (Bsp. BSI, TÜV, DQS) im Rahmen eines Audits zertifiziert werden. Das nach erfolgreichem Audit erteilte Zertifikat hat eine Gültigkeit von ist drei Jahren. Durch jährliche Überwachungsaudits wird die Einhaltung der Norm überprüft.

Durch eine Zertifizierung des BCMS nach ISO 22310:2013 kann Kunden und Geschäftspartnern ein funktionsfähiges Business Continuity Management System nachgewiesen werden.

Bei der Einsichtnahme in das Zertifikat eines Dienstleisters ist neben der zeitlichen Gültigkeit insbesondere auf den Scope der Zertifizierung zu achten. Der Scope kann die Zertifizierung auf Standorte oder Geschäftsbereiche beschränken.

Die Zertifizierung trifft keine Aussage darüber, ob und in welchem Umfang die individuell benötigten Produkte, Services und Dienstleistungen durch das zertifizierte Unternehmen mit Notfallvorsorgemaßnahmen abgesichert sind und diese Notfallvorsorge des Ansprüchen des Kunden genügt.

Bei wesentlichen / kritischen Dienstleistern sind daher in regelmäßigen Abständen Dienstleister-Audits durchzuführen, die Notfallkonzepte aufeinander abzustimmen und gemeinsame Tests und Übungen durchzuführen.

Unabhängige Überprüfung der BCM-Pläne, -Verfahren und -Dokumentationen, um die Compliance mit gesetzlichen, regulatorischen, normativen sowie internen Anforderungen festzustellen.

Audit-Feststellungen weisen auf Abweichungen gegenüber den Audit-Kriterien hin. Für die Feststellungen sind Nachweise zu führen. Audit-Feststellungen werden durch die Auditoren bewertet. Die Ergebnisse werden in einem Audit-Bericht dokumentiert. Für die Behebung der Feststellungen sind Audit-Folgemaßnahmen aufzusetzen. Diese sind nicht Bestandteil eines Audits.

Relevante Normen:

DIN EN ISO 19011 Leitfaden zur Auditierung von Managementsystemen

DIN EN ISO 17021:2011 Anforderungen an Zertifizierungsstellen, die Managementsysteme auditieren und zertifizieren

Weitergabe einer Nachricht über eine Störung oder ein Schadensereignis an die zuständige Stelle(n) (Bsp. Leitstelle) oder anonyme Öffentlichkeit. Eine Alarmierung kann manuell (Telefon, Funk) oder automatisiert bei Überschreiten einer Warnschwelle (beispielsweise durch eine Gefahrenmeldeanlage GMA) mittels Alarmierungssysteme erfolgen.

Relevante Normen:

VdS 2300: 2001 Akustische Signalgeber für Externalarm

Immer wieder begegnet mir in Unternehmen die Bezeichnung “Störfall” für Störungen oder Notfälle. In nahezu allen Fällen bin ich nicht glücklich über diese Begriffswahl. Denn der Begriff “Störfall” ist eigentlich durch die Störfallverordnung (Zwölfte Verordnung zur Durchführung des Bundes-Immissionsschutzgesetzes (StörfallVerordnung – 12. BImSchV) geregelt. Betroffen von der Störfallverordnung sind Unternehmen, die gefährliche Stoffe im Betriebsbereich in definierten Mengen lagern. Die Mengen sind in Anhang I der Störfallverordnung definiert. Unternehmen, die dieser Verordnung unterliegen, haben besondere Pflichten hinsichtlich Sicherheitsmaßnahmen, Alarm- und Gefahrenabwehrplänen sowie Informations- und Mitteilungspflichten. Im Kontakt mit Behörden und Organisationen mit Sicherheitsaufgaben (BOS) kann dies zu Mißverständissen führen. Daher sollte der Begriff “Störfall” nur bei entsprechenden Unternehmen Anwendung finden. In den anderen Unternehmen und Organisationen sollte von “Störung” oder “Notfall” gesprochen werden.

Key Performance Indicators (KPI) für das BCM. Wie misst man den Reifegrad und die Funktionsfähigkeit des Business Continuity Managements?

Der Reifegrad eines Business Continuity Management Systems lässt sich gut anhand der einzelnen Phasen des BCM Lifecycle messen. Für jede Phase kann der Reifegrad mittels Prüffragen erhoben und zum Beisiel in Form des Capability Maturity Model (CMM) in fünf Reifegraden abgebildet werden (1- initial; incomplete; 2 – managed; 3 – defined; 4- quantitatively managed; 5- Optimizing).

Beispiele für Fragen zum Reifegrad:

• Policy und Programm-Management
  • gibt es eine vom Vorstand unterschriebene Policy?
  • gibt es definierte Verantwortlichkeiten für das BCM?
  • sind ausreichend Budget und Ressourcen für das BCM verfügbar?
  • Werden Gesetze, Normen, Standards, vertragliche Anforderungen berücksichtigt?
  • …
• Einbettung in das Unternehmen
  • werden die Anforderungen des BCM bei Entscheidungen berücksichtigt?
  • Ist den Mitarbeitern mit einer Rolle  im BCM diese bekannt?
  • …
• Analyse
  • Werden die kritischen Geschäftsprozesse in Form einer BIA ermittelt?
  • Wird die BIA regelmäßig aktualisiert?
  • Werden die kritischen Prozess-Ressourcen erhoben?
  • …
• Design
  • Gibt es Notfallkonzepte für die BCM-Szenarien?
  • Gibt es Notfallplanungen für die kritischen Prozesse und deren Ressourcen?
  • …
• Implementierung
  • Sind die Maßnahmen zur Notfallvorsorge umgesetzt und funktionsfähig?
  • …
• Validierung
  • Finden regelmäßig Tests und Übungen statt?
  • Werden die Erkenntnisse aus Test und Übungen für korrigierende Maßnahmen verwendet?
  • …

Die Funktionsfähigkeit der Notfallvorsorgemaßnahmen im BCM lassen sich nur durch Ernstfälle (nicht angestrebt) und ersatzweise durch Tests und Übungen validieren. Hierfür steht die Phase “Validierung” im BCM Lifecycle.

Bei Tests und Übungen wird ermittelt

• ob die Notfallkonzepte geeignet sind (Bsp. Erreichbarkeit Ausweich-Arbeitsplätze)
• angestrebte Wiederanlaufzeiten erreicht werden (Vergleich RTO gegen Ist-Zeiten für Prozesse und Ressourcen, isb. IT)
• die Notfallpläne richtig und ausreichend und zweckmäßig sind
• die Erreichbarkeit im Rahmen der Alarmierung funktioniert
• …

Der  Notfallplan dokumentiert den Notbetrieb eines Prozesses mit den Ersatzlösungen und Workarounds für die kritischen Ressourcen, die Schritte zur Einleitung des Notbetriebs sowie zum Wiederanlauf in den Normalbetrieb. Ergänzt wird der Notfallplan um Kontaktlisten, Wegbeschreibungen, Hersteller-, Lieferanten und Dienstleisterverzeichnisse.

Nach der zeitlichen Phase können Notfallpläne unterscheiden werden in

• Geschäftsfortführungsplan
• Wiederanlaufplan.

Dies müssen nicht zwingendermaßen zwei getrennte Planungsdokumente sein.

In einem Notfall bleibt keine Zeit, umfangreiche Planungsdokumente zu lesen. Auch Piloten arbeiten im Notfall stringent die jeweiligen Checklisten ab. Ich teile daher die Notfallplanung in zwei Teile auf:

1. Notfallkonzepte:
   Notfallstrategien und -taktiken für die Prozesse und Ressourcen. Diese beinhalten die Beschreibung der Ausweich- und Ersatzlösungen für Prozesse und Ressourcen
2. Notfallchecklisten:
   Checklisten für Sofortmaßnahmen für die wichtigen Szenarien, Schritte zur Einleitung des Notbetriebs und Inbetriebnahme von Ausweich- und Ersatzlösungen, Kommunikation intern und extern. Nach dem Prinzip: wer – macht was – mit welcher Priorität – womit und mit wem. Ergänzt um Kontaktlisten. Notfallchecklisten können neben der klassischen Papierform auch elektronisch als App abgebildet werden.

“Plans are worthless, but planning is everything.” hat Dwight D. Eisenhower in einer Rede bei der National Defense Executive Reserve Conference in Washington DC, 14. November 1957 gesagt.

Die Aktivitäten zur Erstellung der Pläne, sind elementar, d.h. die inhaltliche Konzeption und Formulierung der Inhalte. Wer einen Plan geschrieben hat, benötigt den Plan selbst nicht mehr, da die Inhalte des Plans “internalisiert” sind. Was fehlt ist das Wissen, ob der Plan auch im Notfall funktioniert.

Die Validierung und Einübung der Pläne (“Drills” wie die Amerikaner sagen)ist daher der zweite wesentliche Baustein ein der Notfallvorsorge.

FORDEC ist eine strukturierte Methode zur Entscheidungsfindung, die u.a. in der Luftfahrt angewendet wird. Für Krisenstäbe ist FORDEC eine sehr geeignete Methode, um Entscheidungen unter Unsicherheit treffen zu können.

FORDEC steht für

F – Facts: welche Situation liegt vor, wie ist die Lage

O – Options: welche Handlungsalternativen gibt es

R – Risks&Benefits: welche Risiken und Vorteile sind mit den einzelnen Handlungsoptionen verbunden

D – Decision: Auswahl der Handlungsoption

E – Execution: Ausführen der Handlungsoption, Erteilung von Aufrägen

C – Check: Überprüfen des Erfolgs, ggf. Korrektur der Maßnahmen

Bei der Implementierung, Wartung und Pflege des BCM entstehen viele Daten und vor allem viele Relationen zwischen diesen Datenobjekten (Bsp. Prozesse -> IT-Services -> IT-Systeme), die erfasst und gepflegt werden wollen. Excel & Co stehen da an ihre Grenzen. BCM-Tools im engeren Sinne unterstützen die Phasen des BCM-Lifecycle. Darüber hinaus gibt es Tools für die Alarmierung (Alarmierungssysteme) sowie Tools für das Krisenmanagement sowie für Tests und Übungen. In den BCM-News gibt es eine Datenbank mit einer ganzen Reihe gängiger Tools. Aktuell geht die Entwicklung zu einer Verzahnung der Themengebiete Informationssicherheit, Risikomanagement, Compliance-Management und BCM. Dies spiegelt sich auch bei den Tools wieder. GRC-Tools (Governance, Risk & Compliance) und ISM-Tools (Informationssicherheitsmanagement) erhalten BCM-Funktionalitäten, so dass eine gemeinsame Datenbasis genutzt werden kann, da die Informationsobjekte ja die gleichen sind.

Ich tue mich schwer mit dem Begriff “Krise” im BCM-Kontext. Der Begriff “Krise” für Unternehmenskrisen wird inflationär verwendet- außerhalb von Unternehmen noch viel inflationärer. Nur die wenigsten Unternehmenskrisen sind jedoch Geschäftsunterbrechungen und daher Thema des BCM. Das Krisenmanagement stellt einen organisatorischen Rahmen her, um Unternehmenskrisen bewältigen zu können. An dieser Stelle kann man diskutieren, ob Krisenmanagement eine Teil-Disziplin von BCM oder eine eigenständige Disziplin ist. Meine persönliche Meinung: die fachlichen und vor allem persönlichen Skills, die im Krisenmanagement benötigt werden, sind ganz andere als im BCM. Für mich ist daher Krisenmanagement eine eigene Disziplin, wenn auch das BCM oftmals das Krisenmanagement im Unternehmen erst initiiert.

Die Good Practice Guidelines (GPG) sind eine sehr gute Guideline zur Implementierung eines Business Continuity Management auf Basis des BCM-Lebenszyklus.

Die Good Practice Guidelines sind in mehreren Sprachen (auch deutsch) bei dem BCI (Business Continuity Institute) zu beziehen.

Leider gibt es keine einheitliche Begriffswelt im Business Continuity Management für die Bezeichnung von Geschäftsunterbrechungen. Gängige Bezeichnungen hierfür sind “Notfall”, “Krise”, “Katastrophe”. Der deutsche Standard BSI 100-4 verwendet diese Begriffe. In der Praxis werden jedoch auch auch Begriffe wie “Störfall” verwendet, die irreführend sind, da es eine Störfallverordnung gibt, die  Störfälle für die betroffenen Unternehmen regelt. Innerhalb eines Unternehmens führen unterschiedliche Begriffsverwendungen zu Missverständnissen. Zum Beispiel zwischen dem BCM und der IT. Die IT verwendet Begrifflichkeiten aus der ITIL-Welt und versteht unter einem IT-Notfall etwas anderes als das BCM. In der Zusammenarbeit mit anderen Unternehmen werden unterschiedliche Begriffsverwendungen ebenfalls zum Problem: was bedeutet es konkret, wenn ein Unternehmen den Notfall erklärt. Ist es schon die höchste Eskalationsstufe oder gibt es noch ein oder mehrere Eskalationsstufen zum Beispiel zur Krise und Katastrophe. Eine interne und externe Abstimmung der Begrifflichkeiten und der dahinter liegenden Bedeutung im Unternehmen ist daher zwingend. Ein Glossar bildet die Grundlage hierfür.

Good Practice Guidelines (GPG) des Business Continuity Institute (BCI) wie auch der ISO Standard für die BIA ISO 22317:215 unterscheiden zwischen strategischer, taktischer und operativer Business Impact Analyse (BIA).

Im Rahmen der strategischen BIA erfolgt die Priorisierung der Produkte und Prozesse durch das Top Management unter Berücksichtigung der betriebswirtschaftlichen Anforderungen des Unternehmens sowie der Anforderungen der interested parties. Für die Produkte und Prozesse wird die maximal tolerierbare Ausfallzeit festgelegt.

Im Rahmen der taktischen BIA werden die kritischen Prozesse identifiziert, deren Prozessabhängigkeiten, erforderliche Aktivitäten und Wiederanlaufanforderungen.

Im Rahmen der operativen BIA werden die erforderlichen Ressourcen für jede Aktivität erhoben:

• Personen, Skills, Rollen
• Gebäude
• Ausrüstung
• Dokumente
• Finanzierung
• IKT
• Dienstleister
• Andere Prozesse
• Spezielle Anforderungen