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.

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.

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 beginnt oft mit einem Formular: zweihundert Fragen, die jeder Lieferant ausfüllen soll; Häkchen bei „ja/nein“, Freitextfelder für „bitte beschreiben“, angeheftet ein PDF mit Zertifikaten. Man schickt es an zehn, fünfzig, hundert Drittparteien – und spürt Erleichterung, wenn die Antwort im Posteingang landet. Doch die Erleichterung ist trügerisch. Spätestens beim ersten Lieferkettenvorfall zeigt sich: Fragebögen sind keine Feuerlöschanlage. Third-Party Risk Management (TPRM), das vor allem aus Kontrolle, Formalitäten und verspäteter Dokumentation besteht, liefert die Illusion von Sicherheit – aber nicht die Fähigkeit, Risiken zu verhindern, zu erkennen und gemeinsam zu bewältigen.

2026 markiert in vielen Häusern einen Wendepunkt. Die Schlagzahl von NIS2-Pflichten, DORA-Anforderungen, Branchennormen, Audit-Nachweisen, SBOM-Erwartungen und KI-Integrationen hat TPRM aus der Compliance-Ecke geholt und in die operative Führung geschoben. Aus „kontrollieren“ wird „kooperieren“. Aus „prüfen“ wird „prüfen und beweisen“. Aus „Dienstleister“ wird „Mitgestalter“. Diese Verlagerung ist kein weicher Kulturwunsch, sondern harte Ökonomie: Nur wer Lieferanten zur Partnerschaft befähigt, erhält die Geschwindigkeit, Transparenz und Resilienz, die moderne Geschäftsmodelle benötigen.

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?