NIS2 wird in vielen Unternehmen zunächst als „Security-Thema“ einsortiert: IT und Informationssicherheit klären Maßnahmen, Compliance koordiniert, und irgendwann bekommt die Geschäftsleitung ein Update mit Ampeln. Das wirkt vertraut, weil viele Regulierungs- und Auditwellen so gelaufen sind. Der Unterschied bei NIS2 ist jedoch, dass sich die Erwartung an die Geschäftsleitung deutlich verändert – nicht nur als Empfänger von Berichten, sondern als sichtbarer Teil der Verantwortungskette. In der Praxis ist das weniger dramatisch, als es manchmal klingt, aber es ist konkreter: Es geht um Organisationsentscheidungen, um Priorisierung, um nachvollziehbare Steuerung – und darum, dass diese Steuerung im Ernstfall und in der Prüfung belegbar ist.

Genau hier entstehen typische Reibungen. Auf der einen Seite will die Geschäftsleitung keine zusätzlichen „Programme“, die den Betrieb lähmen. Auf der anderen Seite will sie nicht in einer Situation stehen, in der ein Vorfall eskaliert, die Aufsicht Fragen stellt oder ein Kunde Nachweise fordert – und man dann feststellt, dass vieles zwar „gemacht“ wurde, aber nicht sauber als Verantwortung, Entscheidung und Evidenz zusammenläuft. Das ist der eigentliche Kern: NIS2 verlangt nicht, dass Vorstände plötzlich technische Spezialisten werden. NIS2 verlangt, dass Verantwortung so organisiert ist, dass sie im Betrieb funktioniert und im Zweifel auch nachweisbar ist.

Einordnung zum Veröffentlichungszeitpunkt: NIS2 gilt bereits im deutschen Umsetzungsrecht: Das NIS-2-Umsetzungsgesetz ist am 6. Dezember 2025 in Kraft getreten. Der Schwerpunkt dieses Beitrags liegt deshalb auf der laufenden Wirksamkeit der Sicherheitsorganisation, nicht auf der Vorbereitung eines noch ausstehenden Gesetzes. Quelle

NIS2 bringt viele Organisationen in eine vertraute Komfortzone: Anforderungen lesen, Maßnahmen ableiten, Dokumente erstellen, Checklisten abhaken. Das fühlt sich nach Fortschritt an – und ein Teil davon ist auch wirklich notwendig. Trotzdem gibt es ein Problem, das in der Praxis häufig erst dann sichtbar wird, wenn es ernst wird: „Compliant“ heißt nicht automatisch „resilient“.

Policy-Sprawl ist eines dieser Probleme, die selten als „Problem“ gestartet sind. Es entsteht fast immer aus guten Gründen. Ein Audit bringt neue Anforderungen, ein Incident erzeugt Druck, ein neuer Dienstleister will klare Regeln, eine Revision fordert Nachweise, eine Aufsicht setzt Schwerpunkte, oder ein interner Standard soll harmonisiert werden. Also schreibt man eine Richtlinie. Und noch eine. Und irgendwann sind es nicht zehn, sondern vierzig, sechzig, achtzig. Das Ergebnis wirkt zunächst professionell – bis der Alltag zeigt, was sich heimlich aufgebaut hat: Niemand weiß mehr sicher, welche Regel in welchem Fall gilt, welche Version verbindlich ist, wo Ausnahmen stehen, welche Vorgaben sich widersprechen und welche davon wirklich gelebt werden. Im schlimmsten Fall entsteht eine Parallelrealität: Auf dem Papier ist alles geregelt, im Betrieb entscheidet Erfahrung, Gewohnheit und der schnellste Weg.

Das Gefährliche an Policy-Sprawl ist nicht die Anzahl der Dokumente. Das Gefährliche ist die verlorene Steuerbarkeit. Je mehr Richtlinien existieren, desto stärker steigt die Wahrscheinlichkeit, dass sie sich gegenseitig überlagern, dass Zuständigkeiten unklar werden und dass Teams anfangen, Richtlinien zu umgehen, weil sie zu schwer, zu unübersichtlich oder zu weit weg vom Betrieb sind. Dann kippt das Ganze in ein Muster, das man im Audit häufig sofort erkennt: Es gibt viele Dokumente, aber wenig belastbare Evidenz dafür, dass die Regeln im Alltag wirklich wirken. Und genau das ist der Punkt, an dem aus „guter Governance“ plötzlich „Dokumentationslast“ wird – ohne dass das Risiko sinkt.

GRC wird in vielen Organisationen immer noch wie ein Sammelbegriff behandelt: ein bisschen Risiko hier, ein paar Kontrollen dort, dazu Richtlinien, Audits und eine Handvoll Reports. Und dann – ganz am Ende – eine Excel, die alles „zusammenführt“. Das Problem daran ist nicht Excel. Das Problem ist die Erwartung, dass man Führung, Steuerung und Nachweisführung über Listen „nachrüsten“ kann, während der Betrieb längst mit eigener Logik läuft.

Wenn Sie GRC wirklich wirksam machen wollen, hilft ein anderes Bild: GRC als Betriebssystem. Nicht als Tool, nicht als Abteilung und nicht als Papierlage – sondern als die Logik, nach der Entscheidungen vorbereitet, umgesetzt und überprüfbar gemacht werden. Ein Betriebssystem ist unsichtbar, solange es funktioniert. Es macht Abläufe zuverlässig, reduziert Reibung und sorgt dafür, dass ein System unter Last stabil bleibt. Genau das ist auch die Aufgabe eines guten GRC-Ansatzes: Er muss das Unternehmen im Alltag stabiler machen – und nebenbei auditfest.

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.