NIS2 wird in vielen Unternehmen gerade mit hohem Tempo umgesetzt. Das ist verständlich: Die Erwartungshaltung ist groß, der Druck ist real, und niemand möchte in eine Situation kommen, in der man im Ernstfall oder in einer Prüfung erklären muss, warum etwas „noch nicht fertig“ ist. Genau hier entsteht aber ein typisches Nebenproblem, das ich in der Praxis immer wieder sehe: Nachweise werden zu früh als „Dokumentationsprojekt“ verstanden. Dann wächst die Menge an Artefakten schnell – aber die Prüfbarkeit wird nicht automatisch besser. Im Gegenteil: Wenn zu viele Dinge als Nachweis gelten sollen, wird es unklar, was wirklich zählt. Und Unklarheit ist im Audit der schnellste Weg zu Nachforderungen.

Dieser Artikel hilft Ihnen, die NIS2-Nachweispflichten pragmatisch zu sortieren. Nicht nach dem Motto „möglichst viel sammeln“, sondern nach dem Prinzip: Welche Artefakte belegen im Zweifel wirklich, dass Ihr Betrieb sicher und handlungsfähig ist? Und welche Artefakte sehen zwar ordentlich aus, bringen Ihnen aber wenig, weil sie weder Entscheidungen stützen noch die Umsetzung im Alltag nachvollziehbar machen?

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 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“.

Compliance beantwortet primär die Frage: „Haben wir Anforderungen umgesetzt?“ Resilienz beantwortet eine andere Frage: „Können wir Störungen aushalten, schnell reagieren und den Betrieb stabil wiederherstellen – und zwar unter Stress, mit echten Abhängigkeiten und begrenzten Ressourcen?“ Zwischen beiden liegt eine Lücke, die Sie nicht mit noch mehr Papier schließen, sondern nur mit funktionierenden Abläufen.

Vorstände lieben Ampeln. Rot, Gelb, Grün versprechen Ordnung in einer Welt, die selten geordnet ist. Chief Risk Officers lieben Heatmaps. Quadranten vermitteln das Gefühl, man habe Komplexität in den Griff bekommen. Compliance liebt PDF-Berichte. Viele Seiten geben den Eindruck von Vollständigkeit. Und doch passiert in unzähligen Unternehmen dasselbe Ritual: Die Präsentation läuft, die Ampeln leuchten, die Quadranten flimmern, die PDFs stapeln sich – und am Tag danach trifft die Organisation Entscheidungen anhand von Einzelmeinungen, E-Mail-Threads und Ad-hoc-Calls. Aus schönen Berichten wird selten Führung. Genau an dieser Bruchkante setzt der radikale Gedanke eines modernen GRC-Dashboards an: Transparenz ist kein dekoratives Element, sondern eine Führungsdisziplin. Sie wird nicht an Folien gemessen, sondern an der Fähigkeit, Handlungen auszulösen, die sich nachweisen lassen. Ein GRC-Dashboard, das diesen Namen verdient, ist nicht eine weitere Sicht auf Daten. Es ist ein Betriebsinstrument, das Governance, Risk und Compliance in den Takt der Organisation übersetzt.

Vom Bericht zum Betrieb: Was ein Dashboard heute leisten muss

Das klassische Verständnis sah im Dashboard eine Verdichtung. Zahlen aus Security, Datenschutz, Legal, Audit, Betrieb und Einkauf wurden gesammelt, grafisch aufbereitet und regelmäßig vorgelegt. Die Annahme dahinter: Wenn Entscheidungsträger die wichtigsten Informationen auf einen Blick vor sich sehen, treffen sie bessere Entscheidungen. Diese Annahme ist nicht völlig falsch – aber unvollständig. Ein Dashboard, das allein informiert, erzeugt häufig Unverbindlichkeit. Die Inhalte werden zur Kulisse; die eigentliche Arbeit verlagert sich zurück in die Linien, wo Stimmenstärke und Verfügbarkeit mehr zählen als Evidenz.