Zertifizierung

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.

Audit

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

Alarmierung

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

Störfall

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.

KPI

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

Notfallplan

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

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

BCM-Tool

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.

Krise

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.

Notfall

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.

Operative BIA

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