Die meisten Organisationen machen denselben Fehler, wenn mehrere Regelwerke gleichzeitig relevant werden: Sie bauen drei Programme. DORA bekommt ein Projekt, NIS2 bekommt ein Projekt, der EU AI Act bekommt ein Projekt. Jedes Projekt erstellt Anforderungen, Maßnahmenlisten, Richtlinien, Reportings. Und jedes Projekt hat gute Gründe, weil jede Anforderung „irgendwie“ stimmt. Das Ergebnis ist trotzdem oft enttäuschend: viel Arbeit, viel Dokumentation, aber die Betriebsfähigkeit wird nicht proportional besser. Noch schlimmer: Teams beginnen zu „optimieren“, indem sie das jeweils nächste Audit bedienen, statt das System als Ganzes stabiler zu machen.

Die Abkürzungen sind unterschiedlich, aber die Realität dahinter ist erstaunlich ähnlich. Alle drei Rahmenwerke wollen im Kern, dass Sie Entscheidungen nicht dem Zufall überlassen. Sie wollen Verantwortlichkeiten, die im Alltag funktionieren. Sie wollen, dass Störungen beherrscht werden können. Sie wollen, dass kritische Abhängigkeiten gesteuert werden. Und sie wollen, dass Sie das belegen können – nicht durch schöne Texte, sondern durch eine nachvollziehbare Spur.

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.

D ie Zeiten, in denen IT-Sicherheit als rein technisches Thema in einem abgegrenzten Bereich „passierte“, sind vorbei. Mit NIS2 ist Cybersicherheit keine Frage von Tools und Firewalls mehr, sondern eine Frage der Führung: Prioritäten setzen, Risiken akzeptieren oder vermeiden, Budgets lenken, Lieferketten führen, Meldeketten beherrschen, Beweise liefern. NIS2 rückt damit eine unbequeme Wahrheit in den Mittelpunkt: Sicherheit ist Governance. Und Governance ist Chefsache. Wer Cybersicherheit weiterhin als Spezialdisziplin delegiert und im Jahresbericht mit ein paar Schlagworten abräumt, wird in der neuen Aufsichtswelt scheitern – nicht an einer fehlenden Lösung, sondern an der fehlenden Fähigkeit, wirksam zu steuern und nachweisbar zu handeln.

Dieser Beitrag zeigt, was „live“ unter NIS2 praktisch bedeutet: welche Pflichten wirken, wo Organisationen typischerweise stolpern, wie Verantwortlichkeiten aussehen, welche Metriken zählen, wie Lieferketten wirklich geführt werden, wie Incident-Management unter Zeitdruck funktioniert – und wie man das Thema aus der Ecke holt, ohne die gesamte Organisation zu lähmen. Kurz: Wie man Chefsache gestaltet.

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.