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.

GRC-KPIs sind in vielen Unternehmen ein Dauerbrenner – und trotzdem bleibt ein unangenehmes Gefühl: Wir messen viel, aber es verändert zu wenig. Es gibt Dashboards, Ampeln, Kontrollquoten, Reifegradwerte, Audit-Feststellungen, Maßnahmenlisten. Und dennoch fragen Führungskräfte irgendwann (zu Recht): „Was soll ich damit konkret entscheiden?“ Spätestens an diesem Punkt wird sichtbar, ob KPI-Reporting eine reine „Pflichtlage“ ist oder ein echtes Steuerungsinstrument.

Der Kern des Problems liegt selten in fehlenden Daten. Er liegt in der Logik dahinter. Viele GRC-KPIs sind so gebaut, dass sie zeigen, ob etwas existiert oder ob etwas erledigt wurde. Das ist nicht wertlos – aber es ist nur die erste Stufe. Führung braucht nicht primär ein Bild davon, dass Kontrollen „irgendwie laufen“. Führung braucht ein Bild davon, wo das Unternehmen gerade verwundbar ist, was die wahrscheinlichsten Ausfall- oder Schadensszenarien sind und welche Entscheidungen die Situation spürbar verbessern. Genau an dieser Stelle kippt das Reporting häufig: Es ist entweder zu technisch, zu detailliert oder zu sehr auf „Kontroll-Abarbeitung“ fokussiert. Dann wird es zwar geliefert, aber nicht genutzt.

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.

Auf dem Papier wirkt die Risikologik des EU AI Act zunächst wie eine saubere Sortierung: Einordnen, Pflichten ableiten, fertig. In der Praxis ist genau dieser Schritt einer der größten Stolpersteine. Nicht, weil Teams das Thema „nicht verstehen“, sondern weil Klassifizierung im Alltag selten an einem klaren, stabilen Entscheidungsprozess hängt. Stattdessen passiert sie oft nebenbei: im Projekt, im Einkauf, in der IT, manchmal in der Fachabteilung – je nachdem, wer gerade am schnellsten ist. Das Ergebnis ist dann eine Mischung aus gut gemeinten Annahmen und unvollständigen Informationen. Und genau dort entstehen Fehlklassifizierungen.

Warum ist das so kritisch? Weil die Risikoklasse im EU AI Act nicht nur ein Label ist. Sie steuert, wie streng Sie Anforderungen erfüllen müssen, welche Nachweise Sie brauchen, wie viel Governance-Takt sinnvoll ist – und welche Risiken Sie eingehen, wenn Sie zu locker oder zu streng einsortieren. Eine Fehlklassifizierung ist daher selten nur ein „Formfehler“. Sie führt typischerweise zu einem von zwei Problemen: Entweder Sie unterschätzen Pflichten und stehen später mit Lücken da. Oder Sie überziehen unnötig und bauen eine Governance, die Projekte bremst und dann umgangen wird. Beides ist gefährlich – nur auf unterschiedliche Weise.

NIS2 und ISO 27001 begegnen sich in vielen Unternehmen gerade auf eine Weise, die erst einmal „logisch“ wirkt – und dann erstaunlich schnell anstrengend wird: Man hat ein etabliertes ISMS, dazu ein Set an Kontrollen, Richtlinien und Nachweisen. Dann kommt NIS2, und plötzlich entstehen neue Listen, neue Workstreams, neue Maßnahmenpläne, neue Reportings. Alles mit gutem Grund. Und trotzdem bleibt bei vielen Teams am Ende ein Gefühl: Wir machen vieles doppelt, und trotzdem sind wir nicht sicher, ob es wirklich besser geworden ist.

Genau hier lohnt sich ein Perspektivwechsel. Denn NIS2 ist kein Ersatz für ISO 27001, aber es zwingt dazu, den Blick zu erweitern: weg von „Sicherheitsmanagement als System“ hin zu „Sicherheits- und Resilienzfähigkeit als Betriebsrealität“. ISO 27001 liefert Ihnen die Struktur, um Informationssicherheit systematisch zu managen. NIS2 setzt stärker auf die Frage, ob diese Struktur in der Praxis spürbar wirkt – besonders dort, wo es unangenehm wird: bei Incidents, bei Lieferkettenabhängigkeiten, bei Managementverantwortung, bei operativer Steuerung. Das ist keine Kritik an ISO 27001. Es ist eine Erinnerung daran, dass ein Managementsystem erst dann seine Stärke zeigt, wenn es den Betrieb stabilisiert, nicht nur Dokumente erzeugt.