In einem Krisenworkshop habe ich einmal eine einfache Frage gestellt:
„Welche Cyber-Szenarien haben Sie wirklich durchgerechnet?“
Nicht: Welche Risiken stehen im Risikoregister? Nicht: Welche Szenarien hat die IT schon einmal diskutiert? Nicht: Gibt es einen Incident-Response-Plan?
Sondern wirklich durchgerechnet. Was kostet die erste Stunde? Was kostet der erste Tag? Welche Kunden sind betroffen? Welche Verträge reißen? Welche Meldepflichten laufen? Welche Systeme müssen zuerst zurückkommen? Wer entscheidet, wenn IT, Recht, Kommunikation und Vertrieb unterschiedliche Prioritäten haben?
Der Raum wurde still.
Nicht, weil das Unternehmen Cybersecurity nicht ernst nahm. Im Gegenteil: Es gab Firewalls, EDR, Backups, Policies, Awareness-Trainings und ein Risikoregister. Aber in diesem Moment wurde klar: Die Organisation hatte Cyberrisiken beschrieben, aber nicht geschäftlich zu Ende gedacht.
Genau diese Lücke sehe ich immer wieder. Viele Cyberprogramme sind technisch besser geworden. Aber die entscheidende Frage bleibt oft unbeantwortet:
Was passiert mit unserem Geschäft, wenn ein konkretes Cyber-Szenario morgen früh eintritt?
NIST beschreibt Cybersecurity im Cybersecurity Framework 2.0 (final veröffentlicht im Februar 2024) ausdrücklich nicht nur als technische Schutzdisziplin, sondern als Managementsystem über die Funktionen Govern, Identify, Protect, Detect, Respond und Recover. Genau diese Logik ist entscheidend: Gute Vorbereitung endet nicht beim Schutz. Sie umfasst Governance, Erkennung, Reaktion und Wiederherstellung.
Was „durchgerechnet“ wirklich bedeutet
Ein Szenario ist erst dann durchgerechnet, wenn die Geschäftsleitung fünf Dinge kennt:
Operativer Impact: Welche Prozesse, Standorte, Kunden, Produkte oder Services sind betroffen?
Finanzieller Impact: Was kostet eine Stunde, ein Tag, eine Woche Ausfall?
Entscheidungsbedarf: Welche Entscheidungen müssen in den ersten 2, 8, 24 und 72 Stunden getroffen werden?
Abhängigkeiten: Welche Systeme, Dienstleister, Personen, Daten und Kommunikationswege sind kritisch?
Grenzwerte: Ab wann wird aus einem IT-Vorfall eine Unternehmenskrise?
Das klingt einfach. Ist es aber selten. Viele Unternehmen rechnen Cyberrisiken noch immer in technischen Kategorien: Anzahl kritischer Schwachstellen, Patch-Quote, Backup-Status, offene Findings. Diese Kennzahlen sind nicht wertlos. Aber sie sagen wenig darüber aus, ob das Unternehmen unter Druck handlungsfähig bleibt.
Der BSI-Standard 200-4 zum Business Continuity Management (final seit Juni 2023) macht genau diesen Punkt deutlich: Notbetrieb, Wiederanlauf und Geschäftsfortführung müssen geplant werden — inklusive Maßnahmen, um zeitkritische Ressourcen wieder anlaufen zu lassen.
Szenario 1: Der Betrieb steht still
Das erste Szenario ist der Klassiker: Ransomware, zerstörte Systeme, großflächiger Ausfall oder gezielte Sabotage. Plötzlich sind zentrale Systeme nicht mehr erreichbar — ERP, E-Mail, Produktionssteuerung, Lagerverwaltung, Kundenservice, Fakturierung, Domain Controller, Cloud-Management-Zugänge.
Die erste Reaktion lautet oft: „Können wir die Systeme wiederherstellen?“ Die bessere Managementfrage lautet:
Wie lange können wir unser Geschäft ohne diese Systeme weiterführen?
Konkretes Beispiel
Ein mittelständischer Industriebetrieb verliert durch Ransomware Zugriff auf ERP und Produktionsplanung. Die Maschinen laufen noch, aber niemand weiß zuverlässig, welche Aufträge priorisiert sind, welche Materialbestände verfügbar sind, welche Lieferzusagen kritisch sind oder welche Kundenstrafen drohen. Technisch ist „nur“ das ERP betroffen. Geschäftlich steht nach wenigen Stunden die Lieferfähigkeit auf dem Spiel.
Was durchgerechnet werden muss
Was kostet eine Stunde Stillstand pro kritischem Geschäftsprozess?
Welche Prozesse müssen nach 4, 24, 48 und 72 Stunden wieder laufen?
Gibt es manuelle Notprozesse — und sind diese getestet oder nur dokumentiert?
Welche Systeme müssen zuerst wiederhergestellt werden? Wer entscheidet die Reihenfolge?
Welche Abhängigkeiten bestehen zu Active Directory, DNS, IAM, Netzwerk und Cloud?
Sind Backups offline, unveränderbar oder logisch getrennt? Wann wurde der Restore zuletzt realistisch getestet?
Best Practices
Die beste Vorbereitung besteht nicht darin, „alle Systeme gleich wichtig“ zu behandeln. Das ist einer der häufigsten Fehler. Stattdessen braucht es eine Business Recovery Map:
Priorität 1: Prozesse, ohne die Umsatz, Sicherheit oder regulatorische Pflichten unmittelbar gefährdet sind.
Priorität 2: Prozesse, die innerhalb von 24 bis 72 Stunden wieder benötigt werden.
Priorität 3: Systeme, die wichtig sind, aber den Notbetrieb nicht sofort verhindern.
Für jedes kritische System sollten RTO (wie schnell muss es wieder verfügbar sein?) und RPO (wie viel Datenverlust ist tolerierbar?) nicht von der IT allein definiert werden. Das sind Geschäftsentscheidungen, keine rein technischen Parameter. CISA empfiehlt im #StopRansomware Guide (gemeinsam mit FBI, NSA und MS-ISAC) ausdrücklich vorbereitende Maßnahmen für Risikoreduktion, Erkennung, Reaktion und Wiederherstellung. Wer die fünf zentralen Vorstandsentscheidungen in den ersten zwei Stunden nicht vorbereitet hat, verliert hier wertvolle Zeit.
Leitfrage für die Geschäftsleitung:
Wenn morgen früh ERP, E-Mail und Fileserver gleichzeitig weg sind — welche drei Geschäftsprozesse stellen wir zuerst wieder her, und warum?
Szenario 2: Vertrauliche Daten sind draußen
Das zweite Szenario ist oft gefährlicher, weil es sich nicht einfach „zurückspielen“ lässt. Datenabfluss betrifft nicht nur IT. Er betrifft Vertrauen, Regulierung, Kundenkommunikation, Verhandlungsposition und Reputation.
Mögliche betroffene Daten: Kundendaten, Mitarbeiterdaten, Vertragsdokumente, M&A-Unterlagen, technische Zeichnungen, Quellcode, Preislisten, interne E-Mails, Rechtsgutachten, Strategieunterlagen, Zugangsdaten oder Secrets.
Konkretes Beispiel
Ein Unternehmen entdeckt, dass Angreifer Zugriff auf ein Fileshare mit Kundenverträgen, Preislisten und Projektunterlagen hatten. Noch ist unklar, welche Dateien tatsächlich kopiert wurden. Gleichzeitig kündigt die Angreifergruppe an, Daten auf einer Leak-Site zu veröffentlichen. Die Forensik braucht Zeit. Aber Kunden, Geschäftsleitung, Datenschutz, Rechtsabteilung und Kommunikation brauchen Antworten sofort.
Was durchgerechnet werden muss
Welche Datenklassen wären für uns besonders kritisch — und welche Veröffentlichungen würden das Kundenvertrauen massiv beschädigen?
Welche Datenabflüsse wären meldepflichtig (DSGVO, NIS2, sektorale Aufsicht)?
Welche Kunden oder Partner müssten aktiv informiert werden? Welche vertraglichen Informationspflichten bestehen?
Welche Kommunikationslinie nutzen wir, solange die Faktenlage unvollständig ist?
Wer darf Aussagen nach außen freigeben? Wie verhindern wir widersprüchliche Kommunikation?
Welche Datenbestände sind so sensibel, dass sie stärker segmentiert oder verschlüsselt werden müssen?
Best Practices
Ein gutes Unternehmen hat nicht nur ein technisches Klassifizierungsschema, sondern eine Krisenmatrix für Datenabfluss. Diese Matrix beantwortet pro Datenklasse: Kritikalität, Eigentümer, regulatorische Relevanz, Kommunikationspflicht, mögliche Betroffene, maximale Eskalationszeit, interne Entscheidungsgruppe.
Wichtig ist auch: Nicht alle Daten sind gleich kritisch. Ein öffentliches Marketing-PDF ist etwas anderes als ein M&A-Dokument, eine Kundenpreisliste oder ein Exportkontroll-Datensatz.
NIST SP 800-61 Revision 3 (veröffentlicht im April 2025) betont Incident Response als Zusammenspiel von Vorbereitung, Erkennung, Priorisierung, Eindämmung, Beseitigung, Wiederherstellung, Kommunikation und Lessons Learned — eingebettet in die sechs Funktionen des CSF 2.0. Genau bei Datenabfluss ist diese koordinierte Sicht entscheidend, weil technische Analyse und externe Kommunikation parallel laufen müssen.
Leitfrage für die Geschäftsleitung:
Welche drei Datenbestände würden uns am meisten schaden, wenn sie morgen öffentlich wären?
Szenario 3: Identitäten und Cloud-Zugänge sind kompromittiert
Dieses Szenario wird oft unterschätzt, weil es nicht sofort dramatisch aussieht. Keine Maschinen stehen still. Keine Ransomware-Note erscheint. Kein System ist sichtbar verschlüsselt.
Aber ein Angreifer hat Zugriff auf ein privilegiertes Administratorkonto, einen Cloud-Tenant, ein SaaS-System, eine CI/CD-Pipeline, ein E-Mail-Postfach der Geschäftsleitung, ein Helpdesk-Konto oder ein Identity-Provider-System. Das ist gefährlich, weil Identität heute häufig der eigentliche Perimeter ist.
Konkretes Beispiel
Ein Angreifer kompromittiert ein Konto mit erweiterten Rechten in der Cloud-Umgebung. Über OAuth-Apps, API-Tokens und Service Accounts bewegt er sich unauffällig weiter. Wochen später stellt sich heraus, dass nicht nur Daten eingesehen, sondern auch Berechtigungen verändert wurden. Die schwierigste Frage lautet jetzt nicht: „Wie setzen wir ein Passwort zurück?“ Sondern: Können wir unserer eigenen Identitäts- und Protokollierungsumgebung noch trauen?
Was durchgerechnet werden muss
Welche Konten haben privilegierten Zugriff — menschlich und technisch? Gibt es Break-Glass-Konten, und wie werden sie überwacht?
Welche SaaS-Systeme hängen am zentralen Identity Provider?
Welche Tokens, Secrets und Zertifikate müssten im Ernstfall rotiert werden?
Wie schnell können wir privilegierte Rechte entziehen? Können wir Cloud-Logs unveränderbar sichern?
Wie stellen wir sicher, dass Angreifer keine Persistenz behalten?
Wer entscheidet über temporäre Sperrungen, wenn der Geschäftsbetrieb betroffen ist?
Best Practices
Dieses Szenario braucht einen Identity Recovery Plan. Viele Organisationen haben Wiederanlaufpläne für Server, aber keine für Identität. Ein solcher Plan sollte enthalten:
Vollständige Liste privilegierter Rollen und definierte Break-Glass-Konten
Notfallverfahren für Identitätsplattformen inkl. Rotation von Secrets und Tokens
Priorisierung kritischer SaaS-Integrationen
Logging- und Beweissicherung — idealerweise unveränderbar
Entscheidungsregeln für Massen-Resets
Wiederherstellung vertrauenswürdiger Admin-Kontrolle
Besonders wichtig: Privilegierte Identitäten gehören in eine andere Schutzklasse als normale Benutzerkonten. Dazu gehören phishing-resistente MFA, minimale Rechte, Just-in-Time-Privilegierung, getrennte Admin-Konten und enges Monitoring.
Leitfrage für die Geschäftsleitung:
Was tun wir, wenn wir unserem Identity Provider morgen nicht mehr vertrauen können?
Szenario 4: Ein kritischer Dienstleister fällt aus oder wird kompromittiert
Viele Cyberkrisen beginnen heute nicht im eigenen Unternehmen. Sie beginnen beim Dienstleister: Cloud-Anbieter, Managed Service Provider, Zahlungsdienstleister, Logistikpartner, HR-Software, ERP-Betreiber, externer IT-Support, Softwarelieferant, Telekommunikationsanbieter, Rechenzentrum.
Third-Party-Risk wird oft als Compliance-Prozess behandelt: Fragebogen, Zertifikat, Vertragsanlage. Im Ernstfall reicht das nicht.
Konkretes Beispiel
Ein Unternehmen nutzt einen externen Dienstleister für Remote-Wartung und Monitoring. Dieser Dienstleister wird kompromittiert. Plötzlich ist unklar, ob der Angreifer Zugriff auf Kundennetze hatte. Das Unternehmen muss entscheiden, ob es Verbindungen trennt, Services abschaltet oder weiterarbeitet. Das Problem: Niemand im Unternehmen hat eine aktuelle Übersicht, welche Systeme der Dienstleister tatsächlich erreicht.
Was durchgerechnet werden muss
Welche fünf Drittparteien könnten unser Geschäft innerhalb von 48 Stunden ernsthaft beeinträchtigen?
Welche Dienstleister haben privilegierten Zugriff oder speichern kritische Daten?
Welche Dienstleister sind Single Points of Failure? Welche Alternativen gibt es — und wie schnell könnten wir umschalten?
Wer hat die operativen und vertraglichen Kontakte? Welche Exit- oder Notfallklauseln existieren?
Welche Kommunikationspflichten bestehen bei einem Vorfall des Dienstleisters?
Welche technischen Verbindungen müssen im Notfall sofort getrennt werden?
Best Practices
Unternehmen brauchen ein Critical Supplier Incident Playbook. Es sollte sich nicht auf alle Lieferanten beziehen, sondern auf die wirklich kritischen Drittparteien. Für jeden kritischen Dienstleister sollte dokumentiert sein:
Pro kritischen Dienstleister festhalten
Genutzter Service · geschäftlicher Impact bei Ausfall · technischer und Datenzugriff · Ansprechpartner 24/7 · vertragliche Meldepflichten · Notfallmaßnahmen · mögliche Workarounds · Exit-Optionen · interne Entscheidungsverantwortung.
Der ENISA Threat Landscape 2025 (veröffentlicht im Oktober 2025, 4.875 ausgewertete Vorfälle zwischen Juli 2024 und Juni 2025) zeigt die Schärfe des Themas deutlich: Phishing ist mit rund 60 % der wichtigste Erstvektor, OT-Angriffe stiegen auf 18,2 % aller Bedrohungen, und KI-gestützte Social-Engineering-Kampagnen machten Anfang 2025 weltweit über 80 % der beobachteten Aktivität aus. Lieferketten- und sektorübergreifende Risiken bleiben damit ein zentrales Managementthema — ebenso wie geopolitisch motivierte Angriffe staatsnaher Akteure.
Leitfrage für die Geschäftsleitung:
Welche fünf externen Abhängigkeiten könnten unser Geschäft schneller stoppen als ein Angriff auf uns selbst?
Szenario 5: Die Geschäftsleitung wird selbst manipuliert
Das fünfte Szenario ist besonders kritisch, weil nicht Systeme, sondern Entscheidungen angegriffen werden. Beispiele: Deepfake-Anruf des CFO, gefälschte CEO-Anweisung, kompromittiertes Assistenzpostfach, manipulierte E-Mail-Kette, dringende Zahlungsfreigabe, angeblicher M&A-Kontext, „Bitte nicht eskalieren, das ist vertraulich“, Freigabe eines Notfallzugangs, Änderung von Lieferantenstammdaten.
Hier geht es nicht um Malware. Hier geht es um Management-Manipulation.
Konkretes Beispiel
Eine Finanzabteilung erhält einen Anruf, der exakt wie der CFO klingt. Die Stimme bestätigt eine dringende Zahlung im Rahmen eines vertraulichen Projekts. Parallel kommt eine E-Mail aus einem scheinbar legitimen Thread. Zwei Personen prüfen den Vorgang — aber beide prüfen denselben manipulierten Kontext. Formal existiert ein Vier-Augen-Prinzip. Praktisch fehlt unabhängige Verifikation.
Was durchgerechnet werden muss
Welche Zahlungen können unter Zeitdruck ausgelöst werden? Welche Prozesse erlauben Ausnahmen?
Welche Rollen können Freigaben beschleunigen? Welche Kommunikationskanäle sind verbindlich?
Wie wird eine ungewöhnliche Anweisung unabhängig bestätigt?
Wer darf auch gegenüber Vorstand oder Geschäftsführung „Nein“ sagen?
Gibt es Out-of-band-Verifikation und definierte Rückrufnummern?
Gibt es Sperrfristen für neue Empfängerkonten? Werden Stammdatenänderungen getrennt von Zahlungsfreigaben geprüft?
Best Practices
Das klassische Vier-Augen-Prinzip reicht hier nicht mehr aus, wenn beide Personen derselben Täuschung glauben. Besser ist ein Vier-Augen-plus-zwei-Kanäle-Prinzip:
Auftrag wird über Kanal A entgegengenommen (z. B. E-Mail, Telefon, Chat).
Verifikation erfolgt über Kanal B — ausschließlich über vorher definierte Kontaktdaten.
Keine Verifikation über Links, Telefonnummern oder Kontakte aus der ursprünglichen Nachricht.
Ausnahmen werden dokumentiert — keine Umgehung wegen Hierarchie oder Dringlichkeit.
Wenn Geld, Zugänge oder vertrauliche Daten bewegt werden, gilt der definierte Prozess — nicht der Wunsch des Anrufers.
Leitfrage für die Geschäftsleitung:
Kann eine Stimme, ein Titel oder eine dringende Nachricht bei uns einen Sicherheitsprozess aushebeln?
Wie man die fünf Szenarien sauber durchrechnet
Viele Unternehmen bleiben bei Szenario-Workshops zu abstrakt. Dann entstehen schöne Folien, aber keine bessere Krisenfähigkeit. Ich empfehle ein anderes Vorgehen.
Szenario konkret formulieren. Nicht „Ransomware-Angriff“. Sondern: „Montag, 07:30 Uhr: ERP, E-Mail und Fileshares sind nicht erreichbar. Der Angreifer behauptet, 2 TB Daten kopiert zu haben. Produktion Standort A steht. Kundenservice ist offline.“ Je konkreter das Szenario, desto besser die Entscheidungen.
Die ersten 72 Stunden simulieren. 0–4 Stunden: Lagebild, Krisenmodus, Sofortmaßnahmen. 4–12 Stunden: Stabilisierung, Kommunikation, forensische Sicherung. 12–24 Stunden: Managemententscheidungen, Kunden- und Behördenfragen. 24–72 Stunden: Wiederanlauf, Priorisierung, externe Kommunikation, Board-Update.
Business Impact quantifizieren. Mindestens grob bekannt sein sollten: Umsatzverlust pro Stunde/Tag, Vertragsstrafen, Wiederanlaufkosten, externe Incident-Kosten, Kommunikations- und Rechtskosten, Kundenabwanderungsrisiko, Reputationswirkung, regulatorische Folgen. Es geht nicht um Scheingenauigkeit. Es geht um Entscheidungsfähigkeit.
Entscheidungsrechte klären. Wer aktiviert den Krisenstab? Wer darf Systeme abschalten? Wer entscheidet über Wiederanlaufprioritäten? Wer spricht mit Kunden, Behörden, Versicherern? Wer entscheidet über Lösegeldfragen und Zielkonflikte zwischen Produktion, Recht, IT und Kommunikation?
Ergebnisse in Playbooks überführen. Ein Workshop ohne Playbook ist nur eine Diskussion. Pro Szenario sollten entstehen: Entscheidungsbaum, Kontaktliste, Prioritätenliste, Kommunikationsvorlagen, Eskalationsmatrix, technische Sofortmaßnahmen, externe Partner, rechtliche Prüfpunkte, Wiederanlaufreihenfolge und offene Maßnahmen mit Verantwortlichen.
Die häufigsten Fehler
Alles wird technisch betrachtet. Cyberkrisen sind technische Auslöser mit geschäftlichen Folgen. Wer nur technische Wiederherstellung plant, übersieht Kommunikation, Verträge, Kunden, Lieferketten und Managemententscheidungen.
Es gibt keine echte Priorisierung. Wenn alles kritisch ist, ist nichts kritisch. Unternehmen brauchen eine klare Rangfolge ihrer Kronjuwelen.
Backups werden mit Resilienz verwechselt. Backups sind wichtig. Aber Resilienz entsteht erst, wenn Wiederherstellung, Priorisierung, Notbetrieb und Kommunikation zusammenspielen — ein häufiger Grund, warum Krisenhandbücher im Ernstfall versagen.
Dienstleister werden zu spät einbezogen. Viele Organisationen wissen nicht, welche externen Partner sie im Ernstfall wirklich brauchen — und ob diese überhaupt 24/7 verfügbar sind.
Die Geschäftsleitung übt nicht mit. Ein Incident-Response-Test nur mit IT ist kein Krisentest. Wenn Geschäftsleitung, Recht, Kommunikation, HR, Datenschutz und Fachbereiche nicht teilnehmen, bleibt die Übung unvollständig.
Best Practice: Der jährliche Cyber-Szenario-Tag
Jedes Unternehmen sollte mindestens einmal pro Jahr einen Cyber-Szenario-Tag mit der Geschäftsleitung durchführen — idealerweise als Tabletop Exercise oder Cyberkrisensimulation. Nicht als Technikübung. Sondern als Führungsübung.
09:00–10:00 · Top-5-Szenarien und geschäftliche Annahmen
10:00–11:30 · Szenario 1: Betriebsstillstand
11:30–12:30 · Szenario 2: Datenabfluss
13:30–14:30 · Szenario 3: Identität und Cloud kompromittiert
14:30–15:30 · Szenario 4: Kritischer Dienstleister fällt aus
15:30–16:30 · Szenario 5: Management-Manipulation
16:30–17:00 · Entscheidungen, Lücken, Verantwortlichkeiten
Am Ende sollten nicht 40 neue Ideen stehen, sondern maximal zehn priorisierte Maßnahmen. Beispiele:
RTO/RPO für Top-10-Geschäftsprozesse bestätigen · Wiederanlaufreihenfolge beschließen
Out-of-band-Verifikation verpflichtend machen · kritische Dienstleister neu klassifizieren
Restore-Test für Kronjuwelen durchführen · Kommunikationsvorlagen vorbereiten
Incident-Retainer abschließen · privilegierte Identitäten härten
Cyber-Krisenstab aktualisieren · Board-Reporting auf Szenarien umstellen
Fazit: Resilienz entsteht vor dem Vorfall
Viele Unternehmen glauben, sie seien vorbereitet, weil sie Dokumente haben. Ein Incident-Response-Plan ist gut. Ein Risikoregister ist gut. Backups sind gut. Security-Tools sind gut. Aber nichts davon ersetzt die zentrale Führungsfrage: Haben wir die wichtigsten Cyber-Szenarien geschäftlich durchgerechnet?
Für mich gehören diese fünf Szenarien mindestens einmal im Jahr auf die Agenda der Geschäftsleitung: Der Betrieb steht still · Vertrauliche Daten sind draußen · Identitäten und Cloud-Zugänge sind kompromittiert · Ein kritischer Dienstleister fällt aus · Die Geschäftsleitung wird selbst manipuliert.
Wer diese Szenarien vorher durchgerechnet hat, wird im Ernstfall nicht automatisch ruhig bleiben. Aber er wird besser führen. Und genau darum geht es bei Cyber-Resilienz: nicht um perfekte Verhinderung jedes Angriffs, sondern um die Fähigkeit, unter Druck die richtigen Entscheidungen zu treffen.
Häufige Fragen
Was bedeutet es, ein Cyber-Szenario „durchzurechnen“?
Ein Szenario ist erst dann durchgerechnet, wenn die Geschäftsleitung den operativen und finanziellen Impact, den Entscheidungsbedarf in den ersten 72 Stunden, kritische Abhängigkeiten und die Schwellen kennt, ab denen ein IT-Vorfall zur Unternehmenskrise wird.
Welche fünf Szenarien gehören auf jede Vorstandsagenda?
Betriebsstillstand durch Ransomware, Abfluss vertraulicher Daten, kompromittierte Identitäten und Cloud-Zugänge, Ausfall oder Kompromittierung eines kritischen Dienstleisters und gezielte Manipulation der Geschäftsleitung etwa per Deepfake oder CEO-Fraud.
Wie oft sollten Cyber-Szenarien mit der Geschäftsleitung durchgespielt werden?
Mindestens einmal pro Jahr im Rahmen eines Cyber-Szenario-Tags mit allen relevanten Funktionen — IT, Recht, Kommunikation, HR, Datenschutz und Geschäftsbereiche. Bei größeren Veränderungen wie M&A, Cloud-Transformationen oder neuer Regulatorik zusätzlich ad hoc.
Quellen und weiterführende Standards
ENISA Threat Landscape 2025 · European Union Agency for Cybersecurity, Oktober 2025 · enisa.europa.eu/publications/enisa-threat-landscape-2025
NIST Cybersecurity Framework 2.0 · National Institute of Standards and Technology, Februar 2024 · nist.gov/cyberframework
NIST SP 800-61 Revision 3 — Incident Response Recommendations and Considerations for Cybersecurity Risk Management · NIST, April 2025 · csrc.nist.gov/pubs/sp/800/61/r3/final
BSI-Standard 200-4 — Business Continuity Management · Bundesamt für Sicherheit in der Informationstechnik, Juni 2023 · bsi.bund.de
#StopRansomware Guide · CISA, FBI, NSA, MS-ISAC — Update Mai 2023, fortlaufend ergänzt durch Akira- und Play-Advisories 2025 · cisa.gov/resources-tools/resources/stopransomware-guide
Sie wollen diese fünf Szenarien unter realistischen Bedingungen mit Ihrem Führungsteam durchrechnen?
In der Cycademy Krisensimulation durchläuft Ihr Team genau diese Szenarien — mit dem Incident Simulator, dynamischen Injects und echtem Zeitdruck. 3–4 Stunden, die zeigen, wo Sie wirklich stehen. Mehr Hintergrund finden Sie im Buch Cybersecurity für Executives.