We have been PWNED - Was CISOs und Unternehmen wirklich brauchen, wenn der Ernstfall eintritt

Was passiert in den ersten Minuten nach einem Cyberangriff?

In den ersten Minuten nach einem Cyberangriff braucht ein Unternehmen vor allem ein belastbares Lagebild. Jede relevante Meldung muss ernst genommen, eingeordnet und priorisiert werden – auch wenn noch nicht sofort klar ist, ob es sich um einen kritischen Incident handelt.

Der Ablauf ist im Kern einfach: Erst wird bewertet, was bekannt ist. Dann wird eingeschätzt, welche Systeme, Daten oder Geschäftsprozesse betroffen sein könnten. Daraus ergibt sich die Kritikalität. Erst danach wird entschieden, welche Reaktion angemessen ist.

Wichtige Fragen in dieser frühen Phase sind:

• Was ist tatsächlich bekannt?

• Welche Systeme oder Daten könnten betroffen sein?

• Wie hoch ist der mögliche Schaden?

• Welche Geschäftsprozesse hängen an den betroffenen Assets?

• Wer muss sofort informiert werden?

• Welche Entscheidungen dürfen nicht allein im Security-Team getroffen werden?

Die ersten Minuten verhindern den Angriff meist nicht mehr. Sie entscheiden aber darüber, ob ein Unternehmen strukturiert reagiert oder ob aus Unsicherheit, Druck und Aktionismus zusätzlicher Schaden entsteht.

‍

Warum ein öffentlicher Breach sofort zur Unternehmenskrise wird

Ein öffentlicher Breach wird zur Unternehmenskrise, sobald nicht mehr nur Systeme betroffen sind, sondern Vertrauen, Kommunikation, Verantwortung und Geschäftsrisiko. Dann reicht es nicht mehr, eine Schwachstelle zu schließen.

Sobald Medien berichten, Kund:innen Fragen stellen, Behörden involviert sind oder der Vorstand eine Einschätzung braucht, verschiebt sich die Lage. Im öffentlichen Breach treffen mehrere Perspektiven gleichzeitig aufeinander:

• Security muss verstehen, was technisch passiert ist.

• IT und Engineering müssen Systeme prüfen, stabilisieren oder abschalten.

• Legal muss regulatorische Pflichten, Haftungsfragen und Meldewege bewerten.

• Kommunikation muss interne und externe Aussagen vorbereiten.

• Finance muss mögliche wirtschaftliche Folgen einordnen.

• Management und Vorstand müssen Entscheidungen treffen, die über Technik hinausgehen.

Der CISO kann in dieser Situation Risiken erklären, Optionen aufzeigen und technische Konsequenzen bewerten. Aber der CISO kann nicht allein entscheiden, ob ein System abgeschaltet wird, wenn dadurch Produktion, Umsatz oder Kund:innen betroffen sind.

Ein öffentlicher Cyberangriff ist deshalb immer auch ein Test der Unternehmensführung. Er zeigt, ob Rollen, Kommunikationswege und Entscheidungsrechte wirklich geklärt sind.

‍

Warum Panik kein Incident-Response-Plan ist

Panik ist im Cyber-Krisenfall verständlich, aber kein Plan. Wer zu schnell handelt, ohne die Kritikalität zu verstehen, riskiert falsche Entscheidungen und zusätzlichen Schaden.

Ein System zu früh abzuschalten, kann wirtschaftlich massiv schaden. Ein System zu spät abzuschalten, kann den Angriff vergrößern. Eine unklare Kommunikation kann Vertrauen zerstören, obwohl die technische Lage vielleicht beherrschbar wäre.

Deshalb ist Benedikts Gedanke so wichtig: Erst durchatmen, dann entscheiden. Strukturierte Ruhe verhindert, dass aus einem Security Incident zusätzlich ein Führungsproblem wird.

Ein guter Incident-Response-Plan klärt vorab:

• Wer bewertet die Lage?

• Wer entscheidet über Eskalation?

• Wer informiert den Vorstand?

• Wer spricht mit Behörden?

• Wer gibt Kommunikation frei?

• Wer dokumentiert Entscheidungen?

• Wer schützt das Team vor Überlastung und Schuldzuweisungen?

Vorbereitung nimmt dem Ernstfall nicht die Schwere. Aber sie verhindert, dass jede Entscheidung neu verhandelt werden muss, während die Uhr läuft.

‍

Welche Rollen im Ernstfall sofort klar sein müssen

Im Cyber-Krisenfall müssen technische Bewertung, geschäftliche Bewertung, rechtliche Einordnung und Kommunikation zusammenspielen. Der CISO ist dabei zentral, aber der Ernstfall ist kein Solo für Security.

1. Technische Lagebewertung: Security, SOC, IT und gegebenenfalls Engineering prüfen Alarme, Logs, betroffene Systeme, mögliche Angriffswege und kritische Assets.

2. Geschäftliche Bewertung: Fachbereiche, Finance und Management bewerten, welche Prozesse, Umsätze, Kund:innen oder Lieferketten betroffen sein könnten.

3. Rechtliche und regulatorische Bewertung: Legal, Datenschutz und Compliance prüfen Meldepflichten, Fristen, Haftungsfragen und Anforderungen aus NIS2 oder ISO 27001.

4. Kommunikation und Führung: Vorstand, Management und Kommunikation entscheiden, wie intern, extern, gegenüber Behörden und gegenüber der Öffentlichkeit gesprochen wird.

Je klarer diese Rollen vor dem Angriff definiert sind, desto schneller kann das Unternehmen im Ernstfall handeln. Nicht hektisch. Nicht perfekt. Aber strukturiert genug, um aus einem kritischen Moment keine unkontrollierte Krise zu machen.

‍

Takeaways

• Ein Cyberangriff im Ernstfall braucht zuerst ein belastbares Lagebild.

• Kritikalität muss bewertet werden, bevor Aktionismus entsteht.

• Betroffene Systeme, Daten und Geschäftsprozesse müssen schnell eingeordnet werden.

• Ein öffentlicher Breach ist immer auch ein Unternehmensrisiko.

• Vorstand, Legal, Kommunikation, Finance, IT und Fachbereiche müssen früh eingebunden werden.

• Rollen, Eskalationswege und Entscheidungsrechte müssen vor dem Ernstfall definiert sein.

• Security darf den Cyber-Krisenfall nicht allein lösen müssen.

‍

‍

‍

Was gehört zu einem funktionierenden Incident-Response-Prozess?

Ein funktionierender Incident-Response-Prozess legt fest, wie ein Unternehmen Sicherheitsvorfälle erkennt, bewertet, eskaliert, eindämmt, kommuniziert und nachbereitet. Er verhindert, dass Teams im Ernstfall improvisieren müssen.

Die wichtigsten Elemente sind:

• Erkennung: Welche Alarme, Hinweise oder externen Meldungen deuten auf einen Cyberangriff hin?

• Bewertung: Welche Systeme, Daten oder Geschäftsprozesse könnten betroffen sein?

• Priorisierung: Wie kritisch ist der Vorfall für das Unternehmen?

• Eskalation: Wer muss wann informiert werden?

• Eindämmung: Welche Maßnahmen begrenzen den Schaden?

• Kommunikation: Wer spricht intern, extern, mit Behörden oder mit Kund:innen?

• Dokumentation: Welche Entscheidungen wurden wann und warum getroffen?

• Nachbereitung: Was muss verbessert werden?

Entscheidend ist, dass diese Abläufe vor dem Angriff bekannt sind. Nur dann bleibt das Unternehmen unter Druck handlungsfähig und kann Entscheidungen nachvollziehbar treffen.

Warum Kritikalität wichtiger ist als blinder Aktionismus

Kritikalität entscheidet im Cyber-Krisenfall, wie schnell, wie hart und mit welchen Stakeholdern reagiert werden muss. Geschwindigkeit ist wichtig, aber ohne Einordnung kann sie zusätzlichen Schaden verursachen.

Ein Angriff auf ein Testsystem ist anders zu bewerten als ein Angriff auf Produktionssysteme, Kundendaten, Transaktionsdaten oder operative Technologie. Beides kann relevant sein. Aber nicht beides gefährdet das Unternehmen im gleichen Maß.

Deshalb braucht Incident Response klare Kriterien:

• Welche Assets sind geschäftskritisch?

• Welche Daten wären besonders sensibel?

• Welche Prozesse dürfen nicht ausfallen?

• Ab wann wird der Cyber-Krisenstab aktiviert?

• Welche Reaktionszeiten sind realistisch?

• Wer entscheidet über Abschaltung, Wiederanlauf oder externe Kommunikation?

Blinder Aktionismus entsteht oft aus Unsicherheit. Strukturierte Priorisierung schafft Orientierung: Was ist laut? Was ist dringend? Und was gefährdet wirklich das Unternehmen?

‍

Wer gehört in den Cyber-Krisenstab?

Ein Cyber-Krisenstab bringt alle Rollen zusammen, die im Ernstfall technische, rechtliche, kommunikative und geschäftliche Folgen bewerten müssen. Er darf nicht nur aus Security bestehen, weil ein Cyberangriff fast immer mehrere Unternehmensbereiche betrifft.

Je nach Vorfall gehören dazu:

• CISO oder Security-Verantwortliche für die Risikoeinschätzung

• SOC und IT für Analyse, Eindämmung und Systemmaßnahmen

• Engineering oder Fachbereiche für betroffene Produkte, Plattformen oder Prozesse

• Legal und Datenschutz für Meldepflichten, Haftung und regulatorische Fragen

• Kommunikation oder PR für interne und externe Aussagen

• Finance oder Controlling für wirtschaftliche Auswirkungen

• Risk Management und Compliance für Dokumentation und Unternehmensrisiken

• Vorstand oder Management für geschäftskritische Entscheidungen

Der technische Befund beantwortet nicht automatisch, was das Unternehmen tun sollte. Erst das gemeinsame Lagebild macht eine belastbare Entscheidung möglich.

‍

Warum der CISO nicht allein entscheiden sollte

Der CISO sollte im Cyber-Krisenfall Risiken erklären und Entscheidungsvorlagen liefern, aber keine umfassenden Business-Entscheidungen allein treffen. Viele Maßnahmen haben Folgen, die weit über Security hinausgehen.

Wenn ein System abgeschaltet wird, kann das Produktion, Umsatz, Lieferfähigkeit, Kund:innen oder regulatorische Pflichten betreffen. Deshalb braucht es neben Security auch Management, Legal, Finance, Kommunikation und betroffene Fachbereiche.

Die zentrale Aufgabe des CISO ist die Übersetzung: Was ist passiert? Was wissen wir sicher? Was ist noch unklar? Welche Optionen gibt es? Welche Risiken entstehen durch Handeln oder Nicht-Handeln?

So wird aus technischer Analyse eine entscheidungsfähige Lageeinschätzung. Genau diese Übersetzung braucht der Vorstand, um schnell und verantwortlich handeln zu können.

‍

Wie Unternehmen Kommunikationschaos im Ernstfall vermeiden

Kommunikationschaos entsteht, wenn viele Zielgruppen gleichzeitig Informationen brauchen und niemand weiß, welche Aussage belastbar ist. Deshalb muss Krisenkommunikation vor dem Ernstfall vorbereitet werden.

Im Cyber-Krisenfall laufen mehrere Kommunikationswege parallel:

• Security und IT brauchen operative Klarheit.

• Vorstand und Management brauchen ein entscheidungsfähiges Lagebild.

• Mitarbeitende brauchen Orientierung.

• Kund:innen, Partner und Lieferanten brauchen verlässliche Informationen.

• Behörden brauchen korrekte Meldungen.

• Medien brauchen abgestimmte Aussagen.

Unternehmen brauchen dafür Freigabeprozesse, vorbereitete Sprachregelungen und eine gemeinsame Quelle der Wahrheit. Niemand sollte im Ernstfall eigenständig Aussagen treffen, die später korrigiert werden müssen.

Gute Krisenkommunikation bedeutet nicht, sofort alles zu wissen. Sie bedeutet, klar zu sagen, was bekannt ist, was geprüft wird und welche nächsten Schritte laufen.

‍

SOC intern oder extern? Entscheidend ist nur eine Frage.

Ein Security Operations Center wirkt für viele Unternehmen wie der Beweis, dass Cybersecurity professionell aufgestellt ist. Doch ein SOC schafft nur dann Sicherheit, wenn Erwartungen, Zuständigkeiten, kritische Assets und Eskalationswege klar sind.

Die wichtigste Frage lautet deshalb nicht zuerst: SOC intern oder extern? Entscheidend ist: Erkennt das SOC relevante Angriffe rechtzeitig und kann das Unternehmen danach handlungsfähig reagieren?

Benedikt d'Oleire-Oltmanns macht in CISO unscripted deutlich: Ein SOC ist kein Tool, das man kauft und dann „hat“. Es ist ein Betriebsmodell aus Datenquellen, Use Cases, Menschen, Prozessen, Playbooks und Verantwortung.

‍

Was ist ein Security Operations Center?

Ein Security Operations Center, kurz SOC, ist die zentrale Funktion zur Überwachung, Erkennung, Bewertung und Reaktion auf Sicherheitsereignisse. Es sammelt Signale aus IT-Systemen, Cloud-Umgebungen, Netzwerken, Endpoints und Identitätsdiensten und macht daraus bewertbare Alarme.

Das Ziel eines SOC ist nicht, möglichst viele Meldungen zu erzeugen. Das Ziel ist, relevante Angriffe früh genug zu erkennen, richtig einzuordnen und eine Reaktion auszulösen, bevor großer Schaden entsteht.

Ein wirksames SOC klärt vor allem:

• Welche Systeme müssen überwacht werden?

• Welche Datenquellen sind wirklich relevant?

• Welche Alarme sind kritisch und welche nur Rauschen?

• Wer bewertet einen Alarm fachlich?

• Wer eskaliert wann an IT, Security, Management oder Krisenstab?

• Welche Reaktionszeiten und Maßnahmen sind realistisch?

Damit ist ein SOC nicht nur technische Überwachung. Es ist ein Zusammenspiel aus Technologie, Prozessen, Verantwortlichkeiten und Erfahrung.

Warum ein SOC kein Tool, sondern ein Betriebsmodell ist

Ein SOC ist kein einzelnes Security-Tool, sondern ein dauerhaftes Betriebsmodell für Erkennung, Analyse, Eskalation und Reaktion. SIEM, EDR, XDR, Cloud Monitoring oder Threat Intelligence können wichtig sein, ersetzen aber keine klare Steuerung.

Ein Tool kann einen Alarm erzeugen. Es weiß aber nicht automatisch, ob dieser Alarm für das Unternehmen kritisch ist. Es kennt nicht immer den Business-Kontext, die wichtigsten Assets oder die Folgen eines Ausfalls.

Deshalb braucht ein SOC definierte Use Cases, angebundene Datenquellen, abgestimmte Playbooks und Rollen, die auch unter Druck funktionieren. Benedikts Punkt ist hier zentral: In sechs Monaten kann ein Unternehmen ein realistisches Grundgerüst aufbauen. Aber dieses Grundgerüst muss zuerst dort schützen, wo es wirklich weh tut.

Die Kernfrage lautet also nicht: Welche Plattform kaufen wir? Sondern: Wie betreiben wir Erkennung und Reaktion so, dass sie zu unserem Risiko passt?

‍

Internes SOC: Wann lohnt sich der eigene Aufbau?

Ein internes SOC lohnt sich, wenn ein Unternehmen viel Kontextwissen, hohe Datenhoheit, schnelle interne Abstimmung oder besonders komplexe Umgebungen braucht. Das betrifft zum Beispiel stark regulierte Unternehmen, Konzerne, kritische Infrastruktur, Banken oder Organisationen mit komplexer OT.

Der größte Vorteil ist Nähe zum Geschäft. Interne Teams kennen Systeme, Abhängigkeiten, Prozesse und Besonderheiten oft besser als externe Dienstleister. Dadurch können sie schneller einschätzen, ob ein Alarm harmlos, relevant oder kritisch ist.

Ein internes SOC ist besonders sinnvoll, wenn:

• Budget und langfristige Management-Unterstützung vorhanden sind

• qualifizierte Security-Fachkräfte aufgebaut und gehalten werden können

• kritische Assets und Geschäftsprozesse gut dokumentiert sind

• komplexe oder sensible Umgebungen betrieben werden

• schnelle interne Abstimmung entscheidend ist

Der Nachteil: Ein internes SOC ist kein Projekt, sondern ein dauerhafter Betrieb. Es braucht Menschen, Prozesse, Schichtmodelle, Qualitätssicherung und laufende Weiterentwicklung.

‍

Externes SOC: Wann ist Outsourcing sinnvoll?

Ein externes SOC ist sinnvoll, wenn Unternehmen schnell eine Grundversorgung aufbauen wollen oder intern nicht genügend Fachkräfte, Erfahrung oder 24/7-Kapazitäten haben. Gerade auf der grünen Wiese kann ein Dienstleister helfen, schneller handlungsfähig zu werden.

Benedikt beschreibt genau diesen Punkt: Wenn noch keine Strukturen vorhanden sind, kann externe Unterstützung Geschwindigkeit bringen und verhindern, dass ein Unternehmen monatelang konzipiert, aber noch nichts überwacht.

Ein externes SOC passt besonders, wenn:

• interne Security-Ressourcen begrenzt sind

• schnell erstes Monitoring aufgebaut werden muss

• Standard-Use-Cases professionell betrieben werden sollen

• 24/7-Abdeckung intern nicht realistisch ist

• externe Erfahrung aus vielen Umgebungen wertvoll ist

Aber Outsourcing ist keine Abkürzung aus der Verantwortung. Ein Dienstleister kann überwachen, analysieren und eskalieren. Er kann aber nicht allein entscheiden, welche Systeme geschäftskritisch sind oder welche Business-Folgen eine Maßnahme hat.

‍

Warum Outsourcing ohne internes Verständnis nicht funktioniert

Ein ausgelagertes SOC funktioniert nur, wenn das Unternehmen intern weiß, was geschützt werden muss und wie Alarme bewertet werden sollen. Ohne diese Steuerung entsteht schnell falsche Sicherheit.

Das größte Risiko ist nicht der externe Anbieter. Das größte Risiko ist fehlender Business-Kontext. Wenn kritische Assets unbekannt sind, Eskalationswege fehlen oder intern niemand Alarme einordnen kann, bleibt das SOC technisch aktiv, aber strategisch blind.

Ein externer Anbieter braucht klare Antworten:

• Welche Systeme sind kritisch?

• Welche Daten dürfen auf keinen Fall kompromittiert werden?

• Welche Geschäftsprozesse haben Priorität?

• Wer ist intern erreichbar, wenn ein kritischer Alarm entsteht?

• Welche Maßnahmen darf der Anbieter selbst auslösen?

• Ab wann müssen Management oder Krisenstab eingebunden werden?

Ohne diese Antworten wird aus Outsourcing Verantwortungsdiffusion: Der Dienstleister sieht Signale, das Unternehmen erwartet Schutz, aber dazwischen fehlt die Übersetzung.

‍

‍

‍

Warum Security im Ernstfall oft den schwarzen Peter bekommt

Wenn ein Cyberangriff öffentlich wird, suchen Unternehmen schnell nach Ursachen. Das ist notwendig. Gefährlich wird es, wenn aus Ursachenanalyse Schuldzuweisung wird und der Druck automatisch beim CISO oder Security-Team landet.

Genau hier zeigt sich, ob Cybersecurity im Unternehmen als Führungsaufgabe verstanden wird. Security kann Risiken sichtbar machen, Maßnahmen empfehlen und Vorfälle einordnen. Aber ob ein Unternehmen wirklich sicherer wird, hängt auch von IT, Engineering, Einkauf, Management, Budget, Prozessen und Vorstand ab.

Benedikt d'Oleire-Oltmanns macht in CISO unscripted deutlich: Informationssicherheit lässt sich nicht vollständig an eine einzelne Person delegieren. Im Ernstfall braucht Security Rückendeckung, klare Governance und Entscheidungen, die vom Business mitgetragen werden.

‍

Warum Security-Teams nach einem Breach schnell zum Sündenbock werden

Security-Teams werden nach einem Breach schnell zum Sündenbock, weil sie am sichtbarsten mit Cybersecurity verbunden sind. Vorstand, Kund:innen, Medien und Behörden wollen Antworten – und der naheliegende Adressat ist oft der CISO.

Diese Sicht greift zu kurz. Viele Sicherheitsrisiken entstehen nicht allein im Security-Team, sondern in IT-Architekturen, Produktentscheidungen, Einkaufsprozessen, Legacy-Systemen, fehlenden Ressourcen oder Business-Prioritäten.

Wenn Risiken über Jahre akzeptiert, verschoben oder nicht ausreichend finanziert wurden, darf der Ernstfall nicht so behandelt werden, als hätte Security allein versagt. Ein Breach zeigt deshalb nicht nur technische Schwächen. Er zeigt auch, wie ein Unternehmen Verantwortung verteilt.

Was bedeutet „Don’t shoot the messenger“ im Cybersecurity-Kontext?

„Don’t shoot the messenger“ bedeutet im Cybersecurity-Kontext: Wer Risiken sichtbar macht, darf dafür nicht bestraft werden. Security-Teams sprechen oft die unangenehmen Wahrheiten aus, bevor ein Vorfall passiert.

Sie zeigen, wo Systeme verwundbar sind, Budgets fehlen, Prozesse nicht funktionieren oder Entscheidungen zu riskant werden. Das macht sie nicht automatisch verantwortlich für jedes Risiko. Im Gegenteil: Ein CISO, der Risiken klar benennt, erfüllt eine zentrale Führungsaufgabe.

Reife Security-Kultur braucht deshalb:

• offene Risiko-Kommunikation

• klare Entscheidungswege

• dokumentierte Risikoakzeptanz

• Business-Verantwortliche, die Entscheidungen mittragen

• Schutz für Teams, die Risiken transparent machen

Der Satz ist also mehr als ein Spruch. Er beschreibt eine Voraussetzung für Cyber-Resilienz: Unternehmen müssen diejenigen schützen, die Risiken früh sichtbar machen.

‍

Warum Cybersecurity nicht einfach an den CISO delegiert werden kann

Cybersecurity kann nicht vollständig an den CISO delegiert werden, weil viele Risikoentscheidungen außerhalb des Security-Teams entstehen. Der CISO kann Strategien entwickeln, Risiken bewerten und Entscheidungsvorlagen liefern. Die eigentlichen Business-Entscheidungen liegen aber oft bei Management, Vorstand, IT, Einkauf oder Fachbereichen.

Wenn ein veraltetes System weiterbetrieben wird, ist das nicht nur ein Security-Thema. Wenn ein Budget nicht freigegeben wird, ist das eine Managemententscheidung. Wenn ein Risiko bewusst akzeptiert wird, muss diese Akzeptanz auf der richtigen Ebene getragen werden.

Benedikt beschreibt den CISO deshalb als Übersetzer. Aus „kritische Schwachstelle“ wird die Business-Frage: Welche Prozesse sind gefährdet? Welche Kosten entstehen bei Ausfall? Welche regulatorischen Folgen drohen? Welche Entscheidung brauchen wir jetzt?

So wird Cybersecurity zur Führungsaufgabe. Nicht, weil der Vorstand jedes technische Detail verstehen muss. Sondern weil der Vorstand wissen muss, welche Risiken das Unternehmen trägt.

‍

Welche Rolle spielen NIS2 und ISO 27001 für Vorstände?

NIS2 und ISO 27001 verstärken, dass Informationssicherheit auf Leitungsebene verankert werden muss. Cybersecurity ist damit nicht mehr nur eine operative Spezialaufgabe, sondern Teil der Unternehmensverantwortung.

ISO 27001 macht deutlich, dass Informationssicherheit Managementverantwortung braucht. Führung muss Rahmenbedingungen schaffen, Ressourcen ermöglichen, Risiken bewerten und wirksame Steuerung sicherstellen.

NIS2 erhöht zusätzlich den Druck auf Unternehmen und Leitungsorgane. Kritische Incidents, Meldepflichten, Nachweispflichten und persönliche Verantwortlichkeit rücken stärker in den Fokus. Vorstände müssen deshalb wissen, welche kritischen Systeme betroffen sein könnten, wie eskaliert wird und wer im Ernstfall entscheidet.

Das Ziel ist nicht, Vorstände zu Security-Analyst:innen zu machen. Das Ziel ist, Cyberrisiken genauso ernst zu behandeln wie Finanzrisiken, Lieferkettenrisiken oder Produktionsausfälle.

‍

Wie CISOs Cyberrisiken in Business-Sprache übersetzen

CISOs schaffen Wirkung, wenn sie technische Risiken in entscheidungsfähige Business-Sprache übersetzen. Ein Vorstand braucht meist nicht die vollständige technische Tiefe, sondern Klarheit über Tragweite, Optionen und Konsequenzen.

Statt abstrakt von einem kritischen Risiko zu sprechen, sollte die Übersetzung lauten: Was bedeutet dieses Risiko für Umsatz, Betrieb, Kund:innen, Reputation, Regulierung oder Lieferfähigkeit? Welche Systeme wären betroffen? Wie lange könnten Prozesse ausfallen? Welche Investition senkt das Risiko?

Hilfreiche Leitfragen sind:

• Welche Kernprozesse wären betroffen?

• Welche Assets sind besonders kritisch?

• Welche Ausfallzeit wäre wirtschaftlich relevant?

• Welche regulatorischen Fristen gelten?

• Welche Entscheidung muss der Vorstand treffen?

Gute Security-Kommunikation vereinfacht nicht aus Bequemlichkeit. Sie macht technische Risiken entscheidungsfähig.

‍

Wie Unternehmen ihre Security-Teams im Ernstfall schützen

Unternehmen schützen ihre Security-Teams, indem sie Verantwortung vor dem Ernstfall klären. Wer entscheidet? Wer kommuniziert? Wer trägt Business-Risiken? Wer gibt Budgets frei? Wer steht intern und extern für Entscheidungen ein?

Wenn diese Fragen offen bleiben, landet der Druck fast automatisch bei Security. Krisenfeste Unternehmen vermeiden genau das durch Governance, Übungen und klare Eskalationswege.

Konkret hilft:

• Risikoentscheidungen sauber dokumentieren

• Eskalationswege klar definieren

• Security früh in Geschäfts- und Technologieentscheidungen einbinden

• Tabletop Exercises mit Management und Vorstand durchführen

• realistische Budgets und Ressourcen bereitstellen

• Kommunikationsfreigaben vorab klären

• nach einem Vorfall lernen, statt nur Schuldige zu suchen

Ein Cyberangriff ist belastend genug. Wenn Teams zusätzlich Angst haben müssen, als Sündenbock zu enden, leidet die Reaktionsfähigkeit. Gute Führung schützt deshalb nicht nur Systeme, sondern auch die Menschen, die den Ernstfall bewältigen müssen.

‍

Takeaways

• Security wird im Ernstfall schnell sichtbar und dadurch schnell zum Ziel von Schuldzuweisungen.

• Ein Breach zeigt technische Schwächen, aber auch Governance- und Führungsfragen.

• „Don’t shoot the messenger“ bedeutet, dass Risiko-Transparenz geschützt werden muss.

• Der CISO kann Risiken übersetzen und Entscheidungen vorbereiten, aber nicht alle Business-Risiken allein tragen.

• Vorstand und Management bleiben für Informationssicherheit mitverantwortlich.

• NIS2 und ISO 27001 machen Cybersecurity stärker zur Führungsaufgabe.

• Cyberrisiken müssen in Business-Sprache übersetzt werden, damit sie entscheidungsfähig werden.

• Unternehmen schützen Security-Teams durch klare Rollen, dokumentierte Risikoentscheidungen und Rückendeckung im Ernstfall.

‍

‍

Fazit

Ein Cyberangriff entscheidet sich nicht erst, wenn der Alarm aufleuchtet oder ein Breach öffentlich wird. Der Ernstfall zeigt vor allem, was vorher vorbereitet wurde – und was nicht. Genau darin liegt die zentrale Botschaft aus dem Gespräch mit Benedikt d'Oleire-Oltmanns in CISO unscripted: Cybersecurity ist keine reine Frage von Tools oder einzelnen Expert:innen, sondern eine Frage von Führung, Struktur und gemeinsamer Verantwortung.

Wenn der Breach sichtbar wird, braucht ein Unternehmen ein belastbares Lagebild, klare Rollen, einen vorbereiteten Cyber-Krisenstab, funktionierende Incident-Response-Prozesse und verständliche Kommunikation. Der CISO spielt dabei eine zentrale Rolle, aber nicht als alleiniger Entscheider. Entscheidend ist, dass Security Risiken so übersetzt, dass Vorstand, Management, Legal, Kommunikation, IT und Fachbereiche handlungsfähig werden.

Auch beim SOC zeigt sich: Sicherheit entsteht nicht durch ein eingekauftes Tool oder ausgelagerte Verantwortung. Ein wirksames Security Operations Center braucht kritische Assets, klare Use Cases, saubere Eskalationswege und internes Verständnis dafür, was wirklich geschützt werden muss.

Für CISOs, Vorstände und Unternehmen bedeutet das: Krisenfestigkeit entsteht vor dem Angriff. Sie entsteht durch Übungen, klare Entscheidungswege, dokumentierte Risikoakzeptanz, realistische SOC-Modelle und eine Führung, die Cybersecurity als Teil der Unternehmensverantwortung begreift. Wer das vorbereitet, kann einen Cyberangriff nicht immer verhindern. Aber das Unternehmen kann verhindern, im entscheidenden Moment orientierungslos zu werden.

‍