Vom Sicherheitsvorfall zur Betriebsunterbrechung: CISO und BCM verzahnen

Lesezeit
4 Minuten
Bis jetzt gelesen

Vom Sicherheitsvorfall zur Betriebsunterbrechung: CISO und BCM verzahnen

17.08.2026 - 08:00
Veröffentlicht in:

Montagmorgen, 7.20 Uhr: Mehrere Fileserver sind nicht erreichbar, auf den ersten Clients erscheint ein Erpresserschreiben. Für das Security-Team beginnt die Analyse. Im Betrieb stellt sich zur selben Zeit die Frage, welche Leistungen noch erbracht werden können. Hier treffen die Aufgaben des CISO und des Business Continuity Managements aufeinander.

Ihr Zusammenspiel ist organisatorisch sinnvoll und regulatorisch relevant. Durch sinnvolle Strukturen sind die wichtigsten Fragen bereits vor dem eigentlichen Vorfall geklärt, so dass im Ernstfall keine wertvolle Zeit verloren geht.

Ein Vorfall, zwei Arbeitsaufträge

Wenn beim Angriff Ransomware eingesetzt wird, beginnt das häufig als klassischer Sicherheitsfall. Dabei zeigt beispielsweise ein Konto ungewöhnliche Anmeldungen, Daten fließen an einen unbekannten Empfänger oder ein Endpoint schlägt Alarm.

Der technische Blick reicht nicht mehr aus, wenn zentrale Systeme ausfallen. Aufgabe des CISOs ist es nun, den Angriff einzugrenzen, Beweise zu sichern und zu verhindern, dass sich die Schadsoftware weiterbewegt. Parallel dazu fragt das BCM, welche Geschäftsleistungen betroffen sind und in welcher Reihenfolge Systeme zurückkehren müssen. Ist etwa der zentrale Identitätsdienst verdächtig, kann ein vorschneller Neustart die Lage verschärfen, obwohl der Betrieb ohne Anmeldung teilweise stillsteht.

Eine solche Abstimmung kann im Fall eines Alarms kaum sinnvoll improvisiert werden. Der Zertifikats-Lehrgang Resilience Officer (CISO und BCM) ist eine sinnvolle Weiterbildungsmöglichkeit, bei der die Teilnehmer dafür geschult werden, technische Sicherheitsfragen und betriebliche Auswirkungen gemeinsam zu betrachten.

NIS-2 verschiebt die Zuständigkeiten

Seit dem 6. Dezember 2025 gilt in Deutschland das NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetz. Darin wird die Richtlinie (EU) 2022/2555 umgesetzt. Das BSI-Gesetz wird dadurch deutlich erweitert. Laut Gesetzgeber wird mit rund 29.500 Einrichtungen im erweiterten Anwendungsbereich gerechnet. Ob eine Organisation dazugehört, muss sie selbst klären. Ist das der Fall, muss sie sich beim BSI registrieren. Kontakt-, Sektor- und Zuständigkeitsdaten sind anschließend aktuell zu halten.

Ein Blick in § 30 BSIG zeigt, dass es nicht allein um Schutztechnik geht. Genannt werden nämlich auch explizit die Behandlung von Sicherheitsvorfällen, die Fortführung des Betriebs sowie Backup und Wiederherstellung. Krisenmanagement und Lieferkettenrisiken zählen ebenfalls zu den wichtigen Punkten.

Werden Security und Notfallvorsorge in getrennten Registern geführt, führt das dazu, dass dieselben Abhängigkeiten oft zweimal und auch noch vollkommen unterschiedlich bewertet werden, was Zeit kostet und im Ernstfall die Priorisierung erheblich erschwert.

24 Stunden sind schnell vorbei

Für eine frühe Erstmeldung bleiben nur 24 Stunden. Nach 72 Stunden verlangt § 32 BSIG eine ausführlichere Meldung mit einer ersten Bewertung, Angaben zu den Auswirkungen und gegebenenfalls Kompromittierungsindikatoren. Ein Abschlussbericht ist grundsätzlich einen Monat nach der Meldung fällig. Wenn der Vorfall noch weiterläuft, ist zuerst ein Fortschrittsbericht einzureichen. Die ersten Angaben werden fast zwangsläufig Lücken haben. Deshalb sollte klar erkennbar sein, was bestätigt ist, was nur vermutet wird und welche Fragen noch offen sind.

In der Praxis darf es dafür nicht zwei Zeitachsen geben. Incident-Response-Plan und Krisenhandbuch brauchen dieselben Eskalationsstufen und Ansprechpartner. Security liefert technische Indikatoren und Erkenntnisse zum Angriffspfad. Das BCM beschreibt, welche Produkte, Dienste und Standorte ausfallen und welche Zeitziele gefährdet sind.

Die Geschäftsleitung braucht ein Lagebild, kein Berichtspaar

Die Geschäftsleitung muss die vorgesehenen Risikomanagementmaßnahmen billigen. § 38 BSIG macht Informationssicherheit damit explizit zur Leitungsaufgabe und verknüpft sie mit klaren Governance‑Pflichten und einer persönlichen Verantwortlichkeit der Geschäftsleitung.

Regelmäßige Schulungen sollen die Leitung in die Lage versetzen, IT-Risiken und deren Folgen für die erbrachten Dienste zu beurteilen. IT-Risiken sind damit Leitungsaufgabe. Die Verantwortung lässt sich weder vollständig an den CISO noch an die IT-Leitung oder einen externen Dienstleister abgeben.

Zwei Berichte, zwei Ampeln, zwei Prioritäten: Für die Geschäftsleitung ist das kaum brauchbar. Besser ist ein gemeinsames Lagebild mit den wenigen Punkten, die eine Entscheidung verändern. Dazu zählen: 

  • offene Hochrisiken
  • kritische Lieferanten
  • erreichbare Wiederanlaufzeiten
  • Restore-Ergebnisse
  • überfällige Maßnahmen
  • ungeklärte Zuständigkeiten

Bei bestimmten Verstößen drohen besonders wichtigen Einrichtungen Bußgelder bis zu zehn Millionen Euro. Akuter als das Sanktionsrisiko ist im Vorfall jedoch die Frage, ob Eindämmung, Betriebsfortführung und Kommunikation dieselbe Reihenfolge verfolgen. Dafür braucht es einheitliche Schwellenwerte.

ISMS und BCMS teilen Daten, nicht jeden Zweck

Ein ISMS nach ISO/IEC 27001:2022 ordnet Informationssicherheitsrisiken, Verantwortlichkeiten und Kontrollen. ISO 22301 richtet den Blick dagegen auf Unterbrechungen, kritische Leistungen und die Wiederherstellung einer akzeptablen Betriebsfähigkeit. Beide Systeme arbeiten risikobasiert, beantworten aber nicht dieselben Fragen. Ein vorhandenes ISMS deckt daher viele NIS-2-Punkte ab, jedoch nicht automatisch alle.

Fünf Punkte sollten separat geprüft werden:

  1. Melde- und Eskalationswege einschließlich der gesetzlichen Fristen
  2. Lieferkettenrisiken und Nachweise kritischer Dienstleister
  3. Business-Impact-Analysen mit plausiblen RTO- und RPO-Werten
  4. Notfall-, Wiederanlauf- und Krisenkommunikationskonzepte
  5. Übungen sowie dokumentierte Verfahren zur Wirksamkeitskontrolle

Sinnvoll ist ein gemeinsames Maßnahmenregister. Jede Maßnahme erhält einen Eigentümer, eine Frist, einen Nachweis und eine Zuordnung zu den betroffenen Geschäftsleistungen. So wird sichtbar, wo eine Kontrolle technisch vorhanden ist, der Wiederanlauf aber noch an fehlenden Abhängigkeiten, Zugängen oder Ersatzverfahren scheitert.

Resilience Officer braucht Mandat statt Zusatzrolle

Ein Resilience Officer kann die Schnittstelle bündeln, ohne bestehende Verantwortlichkeiten einzusammeln. Zu den Aufgaben gehören Risikoanalysen, Business-Impact-Analysen, Notfall- und Wiederanlaufkonzepte, Krisenkommunikation sowie die Planung von Übungen. Die Rolle übersetzt technische Szenarien in betriebliche Folgen und führt Erkenntnisse aus ISMS und BCM in einem Lagebild zusammen. Ein typischer Fall: Das Backup ist intakt, aber ohne Verzeichnisdienst bleibt die wiederhergestellte Anwendung unzugänglich.

Der Titel allein hilft wenig. Die Rolle benötigt Zugang zu Prozessverantwortlichen, Architekturinformationen, Lieferantenbewertungen und zur Geschäftsleitung. Gleichzeitig müssen die Grenzen klar bleiben: Der CISO steuert die Informationssicherheit, Fachbereiche definieren ihre Wiederanlaufanforderungen, und Risikoakzeptanzen liegen bei den zuständigen Entscheidern. Der Resilience Officer verfolgt Maßnahmen, bereitet Entscheidungen vor und moderiert Konflikte. Ohne Mandat entsteht dagegen nur eine weitere Berichtsstelle.

Übungen müssen unbequeme Entscheidungen erzwingen

Im Übungsraum reicht es nicht, den Angriffsweg auf einem Whiteboard nachzuzeichnen. Der Krisenstab muss entscheiden: Identitätsdienst abschalten? Produktion manuell fortführen? Kunden informieren? Eine gute Tabletop-Übung bringt genau diese Fragen zusammen und setzt dafür ein knappes Zeitfenster. Danach folgen praktische Restore-Tests mit Identitätsdiensten, Netzwerk, Anwendungen, Daten und externen Dienstleistern. Auch ein Ausfall von E-Mail und Kollaboration gehört ins Drehbuch. Nur dann zeigt sich, ob der Krisenstab seine Ersatzkanäle kennt.

Vier Messwerte reichen meist: 

  1. Zeit bis zum gemeinsamen Lagebild
  2. Dauer bis zur ersten Leitungsentscheidung
  3. Vollständigkeit der Meldeinformationen
  4. Abweichung zwischen geplantem und tatsächlichem Wiederanlauf. 

Die Auswertung darf sich nicht auf Dokumente beschränken. Auch Annahmen, Vertretungen und Freigabewege gehören auf den Prüfstand. Erst wenn Security und BCM unter Zeitdruck dieselben Prioritäten anwenden, funktioniert die Verzahnung außerhalb des Organigramms.