Die meisten Unternehmen reden über Resilienz, als wäre sie ein Gefühl: „Wir sind besser vorbereitet“, „Unsere Verteidigung ist gestärkt“, „Wir haben vieles verbessert“. Das klingt beruhigend – und ist doch häufig nur ein Echo aus Projektsitzungen. Resilienz ist kein Stimmungsbild, sondern ein Ergebnis. Und Ergebnisse lassen sich messen. Genau darin liegt die eigentliche Herausforderung: Cyber-Resilienz messbar zu machen, ohne sich in Zahlen zu verlieren, die zwar schön aussehen, aber nichts verändern. Wer mit Kennzahlen nur berichtet, statt zu steuern, betreibt Statistik – nicht Führung. Dieser Beitrag zeigt, wie messbare Resilienz wirklich funktioniert: mit wenigen, harten Kennzahlen, die Verhalten lenken; mit einer Zeitlogik, die Kosten sichtbar macht; mit Nachweisen aus dem Betrieb statt aus PowerPoint; mit Lieferkettenmetriken, die nicht beschwichtigen, sondern verlässlich machen; mit Übungen, die Zahlen erzeugen, auf die man bauen kann; und mit Governance, die Kennzahlen in Konsequenzen übersetzt.

Warum Resilienz Zahlen braucht – und zwar die richtigen

Cyber-Resilienz ist die Fähigkeit, trotz Vorfällen handlungsfähig zu bleiben, schnell zu erkennen, zügig zu entscheiden, gezielt zu isolieren und verlässlich wiederherzustellen. Dieses „trotz, schnell, zügig, gezielt, verlässlich“ ist keine Poesie, es ist eine Zeitkette. Solange Unternehmen Resilienz als Zustand beschreiben – „reif“, „fortgeschritten“, „gut unterwegs“ – bleibt sie angreifbar, weil niemand weiß, ob das Urteil hält, wenn Stress einsetzt. Zahlen zwingen zur Klarheit: Wie lange dauert Erkennung in kritischen Prozessen? Wieviel Zeit vergeht, bis eine Entscheidung getroffen ist? Wie fix gelingt die Isolation? Wie zuverlässig der Wiederanlauf? Wie verändert sich der erwartete Schaden, wenn eine dieser Zeiten um 30 Minuten länger wird? Antworten darauf beenden Bauchgefühl. Sie schaffen eine Führungssprache, die Technik, Recht, Betrieb, Finanzen und Kommunikation zusammenbringt: Zeit, Wirkung, Kosten.

Operational Resilience klingt wie ein großes Programm. In der Praxis entscheidet sich aber sehr vieles an einer erstaunlich einfachen Frage: Wie schnell wird aus einem technischen Problem eine klare Entscheidung – und wie schnell wird aus dieser Entscheidung ein koordinierter Ablauf? Genau an dieser Stelle sind Incident-Prozesse in vielen Organisationen zu langsam. Nicht, weil Menschen nicht reagieren. Sondern weil sie im entscheidenden Moment zu viel klären müssen, was eigentlich längst geklärt sein sollte.

Wenn DORA ernst genommen wird, verschiebt sich der Blick vom „Incident als IT-Aufgabe“ hin zu „Incident als Betriebsfähigkeit“. Das ist kein kosmetischer Unterschied. Ein IT-Team kann einen Fehler beheben und trotzdem kann das Unternehmen als Ganzes langsam sein: weil Auswirkung und Priorisierung unklar bleiben, weil Kommunikation zögert, weil Dienstleister nicht sauber eingebunden werden, weil Freigaben fehlen oder weil das Thema Wiederherstellung erst dann strukturiert wird, wenn bereits wertvolle Zeit verloren ist. In Audits zeigt sich das häufig in einem typischen Muster: Prozesse sind beschrieben, Tickets existieren, aber die End-to-end-Kette ist brüchig. Und wenn die Kette brüchig ist, wird Geschwindigkeit zur Glückssache.

NIS2 bringt viele Organisationen dazu, Sicherheitsmaßnahmen zu „listen“: man schaut auf Kataloge, orientiert sich an Standards, erstellt Maßnahmenpläne. Das ist grundsätzlich sinnvoll. Die unangenehme Wahrheit ist aber: Nicht jede Maßnahme, die auf dem Papier gut aussieht, trägt im Ernstfall wirklich. Und umgekehrt sind es oft ein paar Basics, die darüber entscheiden, ob ein Vorfall kontrollierbar bleibt – oder ob er sich in Chaos, Stillstand und Nacharbeit übersetzt.

Wenn man über „Basics“ spricht, klingt das schnell nach Allgemeinplätzen. In der Praxis ist es deutlich konkreter. „Basics, die tragen“ sind Maßnahmen, die in kritischen Momenten zwei Dinge gleichzeitig ermöglichen: schnelle Entscheidungen und stabile Abläufe. Genau das erwartet NIS2 im Kern: nicht Perfektion, sondern Betriebsfähigkeit.

KRITIS, NIS2, DORA – drei Kürzel, die in vielen Unternehmen gerade gleichzeitig aufschlagen. Und fast immer passiert dabei dasselbe: Es wird erst mal gesammelt. Anforderungen, Pflichten, Leitfäden, Listen, Zuständigkeiten. Dann entstehen Workstreams. Dann entstehen Überschneidungen. Und irgendwann stellt jemand die richtige Frage: „Moment – was davon betrifft uns wirklich, und wie vermeiden wir Doppelarbeit?“

Dieser Beitrag ist eine Landkarte. Nicht im Sinne eines juristischen Kommentars, sondern als Orientierung für Praktiker: Welche Themen liegen wo, was ist ähnlich, was ist wirklich anders – und welche Entscheidungen sollten Sie früh treffen, damit Sie nicht ein Jahr lang parallel aneinander vorbeiarbeiten. Ich vermeide bewusst Nebelbegriffe. Stattdessen arbeite ich mit einem einfachen Prinzip: Pflichten sind nur dann hilfreich, wenn sie sich in einen betrieblichen Ablauf übersetzen lassen.

Es gibt Jahre, in denen Governance wie ein gepflegter Maschinenraum wirkt: saubere Schaltbilder, klare Zuständigkeiten, geölte Prozesse, Prüfzeichen am richtigen Ort. Und es gibt Jahre, in denen das gleiche Bild plötzlich alt aussieht. 2026 ist so ein Jahr. Die Architektur der Kontrolle – Regeln, Freigaben, Checklisten – bewährt sich weiterhin, aber sie reicht nicht mehr aus, um Organisationen durch eine Welt zu steuern, in der digitale Abhängigkeiten unübersichtlich, Lieferketten fragil, regulatorische Erwartungen dynamisch und Technologien wie KI, Cloud und vernetzte Produkte zum Taktgeber geworden sind. Der Satz „Kontrolle allein reicht nicht“ klingt wie eine Plattitüde. In Wahrheit markiert er einen Wendepunkt: Governance verschiebt sich von der Frage „Ist es freigegeben?“ zu „Hält es unter Last – und können wir das beweisen, während wir uns anpassen?“

Der Bruch mit der Kontrolllogik

Die Klassik der Governance wurde von zwei Grundgedanken getragen: Erstens lässt sich Risiko durch Regeln und Rollen beherrschen. Zweitens genügt es, die Einhaltung in Zyklen zu prüfen – Jahresabschluss, Auditplan, Projektgate. Das funktionierte, solange Veränderung langsam und Abhängigkeiten überschaubar waren. Heute kollidieren beide Annahmen mit der Praxis. Veränderungen passieren kontinuierlich (Feature-Rollouts, Infrastruktur-Drifts, Datenströme), und Abhängigkeiten ziehen systemische Effekte nach sich (ein Ausfall in der Lieferkette, ein Software-Bug, eine kompromittierte Identität). Kontrolle bleibt nötig – aber sie ist nicht mehr die Königsdisziplin. Die neue Frage lautet: Wie bleibt die Organisation handlungsfähig, obwohl Kontrolle versagen kann – und wie lernt sie schneller als die Welt sich ändert?