Zum Inhalt springen

Services, Wiki-Artikel, Blog-Beiträge und Glossar-Einträge durchsuchen

↑↓NavigierenEnterÖffnenESCSchließen

Business Continuity Management (BCM): Unternehmen krisenfest machen

Business Continuity Management (BCM) ist der organisatorische Rahmen um kritische Geschäftsprozesse auch während und nach Krisen aufrechtzuerhalten. Dieser Artikel erklärt den BCM-Lifecycle nach ISO 22301, Business Impact Analysis (BIA), Recovery Strategies, Business Continuity Plans (BCP), Krisenmanagement-Strukturen und die Integration mit IT-Notfallmanagement und ISO 27001.

Inhaltsverzeichnis (5 Abschnitte)

Ransomware trifft. Rechenzentrum brennt. Schlüsselmitarbeiter fällt aus. Lieferant insolvent. In allen Fällen stellt sich die entscheidende Frage: Wie lange kann das Unternehmen noch funktionieren - und was ist der Plan? BCM gibt strukturierte Antworten auf diese Fragen, bevor die Krise eintritt.

BCM vs. Disaster Recovery vs. IT-Notfallmanagement

Abgrenzung der Konzepte:

BCM (Business Continuity Management):
  → Organisatorischer Rahmen für alle Arten von Geschäftsstörungen
  → Fokus: kritische Geschäftsprozesse aufrechterhalten
  → Scope: gesamte Organisation (nicht nur IT)
  → Standard: ISO 22301
  → Umfasst: BIA, BCP, Crisis Management, Kommunikation, Training

Disaster Recovery (DR):
  → Technische Wiederherstellung von IT-Systemen nach Ausfall
  → Teilmenge von BCM
  → Fokus: RTO/RPO für IT-Systeme
  → Standard: ISO 27031 (IT für BCM)

IT-Notfallmanagement (BSI):
  → BSI IT-Grundschutz: Sicherstellung der Informationsverarbeitung
  → Incident Response als Teilmenge
  → Integration in ISMS (ISO 27001 Klausel 8.4, 6.1)

Business Continuity Plan (BCP):
  → Dokument das beschreibt wie bei Störung weitergekämpft wird
  → Enthält: Notfallorganisation, Eskalation, Kommunikation, Recovery-Schritte

Crisis Management:
  → Führungs- und Entscheidungsstruktur während einer Krise
  → Crisis Management Team (CMT): Wer entscheidet was?

BCM-Lifecycle nach ISO 22301

ISO 22301:2019 - Business Continuity Management System (BCMS):

Klausel 4: Kontext
  → Stakeholder-Analyse: wer ist betroffen bei Ausfall?
  → Scope des BCMS: welche Standorte, Prozesse, Services?
  → Anforderungen: regulatorische (DORA, KRITIS), vertragliche (SLAs)

Klausel 6: Planung
  → Business Impact Analysis (BIA) durchführen
  → Risikoanalyse: welche Ereignisse können Störungen verursachen?
  → Objectives: Was sind RTO/RPO-Ziele?

Klausel 8: Betrieb (Kernstück!)
  8.2 Business Impact Analysis (BIA)
  8.3 Business Continuity Strategy
  8.4 Business Continuity Plans (BCPs)
  8.5 Business Continuity Tests und Übungen

Klausel 9: Leistungsbewertung
  → Interne Audits des BCMS
  → Management Review
  → Metriken: MTPD, RTO, RPO-Einhaltung

Klausel 10: Verbesserung
  → Lessons Learned aus Tests und realen Ereignissen
  → KVP (kontinuierlicher Verbesserungsprozess)

---

BCM-Implementierungs-Roadmap (6 Monate):

Monat 1-2: Grundlagen
  □ Scope des BCMS definieren
  □ BCM-Policy verabschieden
  □ BCM-Manager benennen
  □ Crisis Management Team (CMT) nominieren

Monat 3-4: BIA und Risiken
  □ Business Impact Analysis durchführen
  □ Kritische Prozesse identifizieren
  □ RTO/RPO-Ziele festlegen
  □ Risikoanalyse für BCM-Ereignisse

Monat 5-6: Pläne und Tests
  □ Business Continuity Plans schreiben
  □ Kommunikationsplan erstellen
  □ Tabletop Exercise durchführen
  □ BCMS-Dokumentation vervollständigen

Business Impact Analysis (BIA)

BIA - der Kern von BCM:

Ziel der BIA:
  → Welche Prozesse sind wie kritisch?
  → Wie lange können wir ohne sie auskommen?
  → Was sind die Konsequenzen eines Ausfalls (finanziell, rechtlich, reputational)?

BIA Datenerhebung (Workshop + Interviews mit Prozessverantwortlichen):
  Fragen pro Prozess:
  □ Beschreiben Sie den Prozess (Input → Verarbeitung → Output)
  □ Welche Ressourcen benötigt der Prozess? (Personal, IT, Gebäude)
  □ Welche Abhängigkeiten hat der Prozess? (Vorgelagerte Prozesse, Lieferanten)
  □ Was passiert wenn der Prozess 1h / 1 Tag / 1 Woche ausfällt?
  □ Gibt es regulatorische Fristen die eingehalten werden müssen?
  □ Wann ist der Prozess am kritischsten? (Monatsende, Jahresende?)

---

BIA-Ergebnisse:

MTPD (Maximum Tolerable Period of Disruption):
  → Wie lange kann der Prozess maximal ausfallen?
  → Nach MTPD: irreversible Schäden (Verlust von Kunden, Insolvenz)

RTO (Recovery Time Objective):
  → Wie schnell muss der Prozess wieder laufen?
  → MUSS kleiner als MTPD sein!

RPO (Recovery Point Objective):
  → Wie alt dürfen die Daten sein nach Wiederherstellung?
  → Direkt abhängig von Backup-Frequenz

Beispiel-BIA-Tabelle:
Prozess              | MTPD | RTO  | RPO  | Kritikalität
---------------------|------|------|------|-------------
Webshop/Online-Shop  | 4h   | 2h   | 1h   | KRITISCH
Lagerverwaltung      | 1 Tag| 4h   | 4h   | HOCH
Buchhaltung          | 1 WO | 2 Tg | 1 Tg | MITTEL
HR-System            | 2 WO | 1 WO | 1 Tg | NIEDRIG
Webseite (statisch)  | 1 WO | 4h   | 1 Tg | MITTEL

---

Recovery Strategies:

Basierend auf BIA-Ergebnissen werden Strategien festgelegt:

1. Ausweich-Arbeitsplätze:
   → Homeoffice-Fähigkeit (für Pandemie, Gebäudeverlust)
   → Ausweichstandort bei Partner/Schwestergesellschaft
   → Mobile Arbeitspakete (Laptops, VPN-Zugang)

2. Manuelle Fallback-Prozesse:
   → Was wenn IT komplett ausfällt?
   → Kritische Formulare und Checklisten auf Papier verfügbar!
   → "Wie haben wir das vor 20 Jahren gemacht?"

3. Alternativlieferanten:
   → Kritische Lieferanten: immer Alternativlieferant identifiziert
   → SLA mit Alternativlieferant vorab vereinbaren

4. IT-Recovery-Strategien:
   → Cold Standby: Backup-System existiert, muss noch aufgebaut werden (4-24h)
   → Warm Standby: System läuft, aber nicht aktuell (1-4h Syncing)
   → Hot Standby: System läuft synchron, sofortige Übernahme (< 1h)
   → Active-Active: beide Systeme laufen produktiv (< 15 Minuten, teuerste Option)

Business Continuity Plan (BCP)

BCP-Dokument-Struktur:

1. Geltungsbereich und Ziele
   → Für welche Szenarien gilt dieser Plan?
   → Activation Trigger: Wann wird der Plan aktiviert?
   → Wer aktiviert ihn? (Crisis Management Team)

2. Crisis Management Team (CMT)
   → Rollenverzeichnis: Krisenstab-Mitglieder
   → Primär- und Stellvertreterkontakte
   → Notfallkontaktliste (auch offline verfügbar!)

3. Kommunikationsplan
   → Intern: Wie werden Mitarbeiter informiert?
      (E-Mail, Teams, SMS-Kette, Notfallwebseite)
   → Extern: Kunden, Lieferanten, Behörden, Presse
   → Datenschutz: Keine voreiligen Mitteilungen über Cyberangriffe!
   → Pressekontakt: Wer spricht für das Unternehmen?

4. Prozess-spezifische Recovery-Prozeduren
   Pro kritischem Prozess:
   □ Ausfallszenario beschreiben
   □ Sofortmaßnahmen (erste 1 Stunde)
   □ Kurzfristmaßnahmen (erste 24 Stunden)
   □ Mittelfristige Wiederherstellung
   □ Verantwortlichkeiten (Wer macht was?)
   □ Ressourcen (Was wird benötigt?)

5. IT-Wiederherstellungsprozeduren (Verweis auf DR-Plan)
   → DR-Plan ist technisches Pendant zum BCP
   → BCP beschreibt "was" - DR-Plan beschreibt "wie" technisch

6. Tests und Übungen

---

Crisis Management Team Aktivierung:

Eskalations-Schwellen:
  Level 1 (Incident):
    → IT-Störung, begrenzte Auswirkung
    → IT-Leiter + betroffene Abteilung lösen intern
    → Kein CMT notwendig

  Level 2 (Business-Continuity-Ereignis):
    → Mehrere Stunden Ausfall kritischer Prozesse
    → CMT informiert, evtl. aktiviert
    → CISO + COO in Entscheidung einbezogen

  Level 3 (Krise):
    → > 1 Tag Ausfall, externen Schaden, Datenpanne
    → CMT vollständig aktiviert
    → Geschäftsführung einbezogen
    → Krisenstab: täglich 2x Lagebesprechung

CMT Erste Maßnahmen (Aktivierung):
  1. Lagebild herstellen: Was ist passiert?
  2. Schadensausmaß einschätzen: was ist betroffen?
  3. Sofortmaßnahmen entscheiden: Notbetrieb aktivieren?
  4. Kommunikation intern: alle Betroffenen informieren
  5. Logbuch führen: alle Entscheidungen dokumentieren!
     (Für Versicherung, Behörden, Nachweis nachher)

BCM-Tests und Übungen

Testtypen (von einfach zu komplex):

1. Dokumentenreview (quartalsweise):
   → BCP auf Aktualität prüfen
   → Kontaktdaten aktuell?
   → Prozesse noch korrekt beschrieben?
   → Organisationsveränderungen eingearbeitet?

2. Tabletop Exercise (halbjährlich):
   → CMT trifft sich, spielt Szenario durch
   → Moderator gibt Szenario vor: "Es ist Montag, 08:00, Ransomware schlägt zu..."
   → Team diskutiert: Was tun wir jetzt? Wer ruft wen an?
   → Keine echte IT involviert - nur Entscheidungsprozesse testen
   → Dauer: 2-4 Stunden

3. Functional Exercise (jährlich):
   → Einzelne Prozeduren wirklich testen
   → DR-Plan: Failover auf Backup-Systeme testen
   → Kommunikationsplan: Notfall-SMS-Kette testen
   → Ergebnis: Prozeduren validieren

4. Full Simulation Exercise (alle 2-3 Jahre):
   → Vollständige Krisensimulation, ggf. ohne Vorankündigung
   → CMT wird aktiviert, alle Pläne werden ausgeführt
   → Realistischstes Testszenario
   → Aufwändig, teuer, aber wertvollstes Testergebnis

Übungsszenarien für Cyberangriff-BCM:
  "Ransomware trifft Produktionssystem. 09:00 Uhr Montagmorgen."
  → Wer wird wann informiert?
  → Wie kommunizieren wir mit Kunden?
  → Welcher Notbetrieb wird aktiviert?
  → Ab wann sprechen wir mit der Presse?
  → Wann melden wir bei BSI/LfDI?

Fragen zu diesem Thema?

Unsere Experten beraten Sie kostenlos und unverbindlich.

Erstberatung

Über den Autor

Oskar Braun
Oskar Braun

Abteilungsleiter Information Security Consulting

Dipl.-Math. (WWU Münster) und Promovend am Promotionskolleg NRW (Hochschule Rhein-Waal) mit Forschungsschwerpunkt Phishing-Awareness, Behavioral Security und Nudging in der IT-Sicherheit. Verantwortet den Aufbau und die Pflege von ISMS, leitet interne Audits nach ISO/IEC 27001:2022 und berät als externer ISB in KRITIS-Branchen. Lehrbeauftragter für Communication Security an der Hochschule Rhein-Waal und NIS2-Schulungsleiter bei der isits AG.

6 Publikationen
ISO 27001 Lead Auditor (IRCA) ISB (TÜV)
Dieser Artikel wurde zuletzt am 04.03.2026 bearbeitet. Verantwortlich: Oskar Braun, Abteilungsleiter Information Security Consulting bei AWARE7 GmbH. Lizenz: CC BY 4.0 — freie Nutzung mit Namensnennung: „AWARE7 GmbH, https://a7.de

Cookielose Analyse via Matomo (selbst gehostet, kein Tracking-Cookie). Datenschutzerklärung