Viele Unternehmen behandeln NIS2 als Maßnahmenpaket für die IT-Abteilung. Bessere Backups. Sauberere Patches. Ein aktualisierter Incident-Response-Plan. Vielleicht ein externes Audit.
Das ist nicht falsch. Es ist nur das falsche Verständnis des Problems.
NIS2 ist kein Härtungsprogramm. Es ist ein Realitätscheck für Unternehmensführung im digitalen Betrieb. Wer das Thema an die IT delegiert, kann einzelne Maßnahmen umsetzen. Aber er baut keine echte Widerstandsfähigkeit auf. Und er unterschätzt, welche Verantwortung NIS2 explizit auf Managementebene verschiebt.
Das ist nicht falsch. Aber es ist zu klein gedacht.
NIS2 ist nicht einfach die nächste regulatorische Anforderung, die man an die IT delegieren kann. Die Richtlinie zielt auf ein höheres gemeinsames Cybersicherheitsniveau in der EU und betrifft deutlich mehr Unternehmen und Sektoren als frühere KRITIS-Logiken. Die Europäische Kommission ordnet NIS2 als einheitlichen Rechtsrahmen für 18 kritische Sektoren ein. Das BSI macht zugleich sehr klar, dass es für betroffene Einrichtungen nicht nur um technische Schutzmaßnahmen geht, sondern um Risikomanagement, Meldepflichten, Registrierung und organisatorische Verantwortung.
Die unbequemere Frage lautet deshalb: Wer übernimmt eigentlich Verantwortung für die digitale Widerstandsfähigkeit des Unternehmens?
Nicht auf dem Papier. Nicht in einer Rollenbeschreibung. Sondern im Führungsalltag.
Ich habe in den letzten Monaten sehr intensiv erlebt, was es bedeutet, ein Informationssicherheitsmanagementsystem aufzubauen, zu strukturieren und erfolgreich durch eine ISO-27001-Zertifizierung zu führen. Die wichtigste Erkenntnis daraus war für mich nicht, dass Dokumentation wichtig ist. Auch nicht, dass technische Maßnahmen sauber beschrieben sein müssen. Das stimmt alles.
Die eigentliche Erkenntnis war eine andere: Informationssicherheit funktioniert nur dann dauerhaft, wenn sie als Steuerungsaufgabe verstanden wird.
Genau deshalb ist NIS2 kein IT-Projekt.
Wer NIS2 an die IT delegiert, hat das Problem nicht verstanden
Natürlich spielt die IT eine zentrale Rolle. Viele Maßnahmen liegen technisch oder organisatorisch nah an der IT: Identitätsmanagement, Logging, Schwachstellenmanagement, Backup, Netzwerksicherheit, Berechtigungen, Notfallprozesse, Lieferantenbewertung, Incident Handling.
Aber die Verantwortung dafür, dass diese Themen angemessen gesteuert, finanziert, priorisiert und kontrolliert werden, liegt nicht allein bei der IT.
Das ist der entscheidende Unterschied.
Eine IT-Abteilung kann Risiken sichtbar machen. Sie kann keine Risikobereitschaft beschließen. Das ist Aufgabe der Unternehmensführung — und genau diese Verantwortung macht NIS2 schwerer wegdelegierbar als jede Vorgängerrichtlinie.
Eine IT-Abteilung kann Risiken sichtbar machen. Sie kann Maßnahmen vorschlagen. Sie kann technische Konzepte liefern. Sie kann Prozesse aufbauen und betreiben. Aber sie kann nicht alleine entscheiden, welches Risiko ein Unternehmen akzeptiert. Sie kann nicht alleine durchsetzen, dass Fachbereiche ihre Verantwortung ernst nehmen. Sie kann nicht alleine Lieferantenrisiken bewerten, wenn Einkauf, Legal und Fachbereich nicht mitziehen. Und sie kann auch nicht alleine eine Sicherheitskultur erzeugen, wenn das Management Informationssicherheit nur dann wahrnimmt, wenn ein Audit bevorsteht.
Das BSI beschreibt NIS2 ausdrücklich als Thema, bei dem Verantwortlichkeiten festgelegt, Risikomanagementmaßnahmen umgesetzt und Informationssicherheit kontinuierlich verbessert werden müssen. Das ist mehr als technische Abarbeitung. Es ist ein Führungs- und Steuerungssystem. Siehe dazu die BSI-Seite NIS-2 – Was tun?.
NIS2 verschiebt den Schwerpunkt. Weg von „Hat die IT ihre Hausaufgaben gemacht?“ hin zu „Ist das Unternehmen in der Lage, Cyberrisiken wirksam zu steuern?“
Das klingt ähnlich. Ist es aber nicht.
Die erste Frage führt zu Maßnahmenlisten. Die zweite Frage führt zu Governance.
ISO 27001 zeigt sehr klar, wo die Organisation wirklich steht
Eine ISO-27001-Zertifizierung ist in diesem Zusammenhang ein guter Spiegel. Nicht weil ISO 27001 automatisch bedeutet, dass man NIS2 vollständig erfüllt. Das wäre zu einfach. Aber weil ein ernsthaft aufgebautes ISMS viele Fähigkeiten erzeugt, die für NIS2 entscheidend sind.
Man lernt, Risiken strukturiert zu betrachten. Man lernt, Verantwortlichkeiten zu definieren. Man lernt, Maßnahmen nicht nur umzusetzen, sondern auch zu begründen. Man lernt, Nachweise zu führen. Man lernt, interne Audits nicht als Formalität zu sehen, sondern als Instrument zur Verbesserung. Und man lernt, dass Informationssicherheit nicht aus Einzeldokumenten besteht, sondern aus einem System.
Genau das ist der Punkt.
Viele Unternehmen unterschätzen, wie groß der Unterschied zwischen vorhandenen Sicherheitsmaßnahmen und einem gesteuerten Sicherheitsmanagement ist.
Ein Unternehmen kann technisch solide aufgestellt sein und trotzdem kein reifes Sicherheitsmanagement haben. Es kann gute Administratoren haben, moderne Tools einsetzen und trotzdem nicht sauber erklären können, warum bestimmte Risiken akzeptiert, reduziert oder priorisiert wurden. Es kann Backups haben, aber keinen ausreichend getesteten Wiederanlauf. Es kann Policies haben, aber keine echte Verankerung im Alltag. Es kann Lieferantenlisten haben, aber keine belastbare Risikosicht auf kritische Abhängigkeiten.
In der ISO-27001-Praxis merkt man sehr schnell: Nicht die Technik ist der schwierigste Teil. Die schwierigen Fragen liegen oft in der Organisation.
- Wer entscheidet?
- Wer trägt welches Risiko?
- Wer prüft Wirksamkeit?
- Wer eskaliert?
- Wer finanziert?
- Wer akzeptiert Restrisiken?
- Wer stellt sicher, dass Prozesse nicht nur beschrieben, sondern gelebt werden?
Das sind keine IT-Fragen. Das sind Managementfragen.
Angemessenheit ist anspruchsvoller als Maximalforderung
Ein verbreiteter Fehler bei NIS2 ist die Flucht in Maximalforderungen. Alles muss sofort härter, strenger, vollständiger, dokumentierter und kontrollierter werden.
Das klingt nach Sicherheit. In der Praxis führt es oft zu Überforderung.
Gerade im Mittelstand muss Informationssicherheit wirksam sein, ohne die Organisation zu lähmen. Das bedeutet nicht, Anforderungen kleinzureden. Es bedeutet, sie richtig zu übersetzen.
Angemessenheit ist kein Freifahrtschein für Minimalismus. Angemessenheit heißt, dass Maßnahmen zum Risiko, zur Unternehmensgröße, zur Kritikalität der Prozesse, zur vorhandenen Reife und zur operativen Belastbarkeit passen müssen.
Das ist anspruchsvoller als eine pauschale Best-Practice-Liste.
Eine Konzernorganisation kann bestimmte Sicherheitsprozesse mit spezialisierten Teams, dedizierten Rollen und zentralen Governance-Funktionen betreiben. Ein mittelständisches Unternehmen hat diese Ressourcen oft nicht in gleicher Tiefe. Trotzdem kann es sich nicht hinter seiner Größe verstecken. Es muss einen Weg finden, Sicherheit so zu organisieren, dass sie belastbar ist.
Das heißt zum Beispiel: klare Verantwortlichkeiten statt komplexer Gremienlogik. Saubere Risikobewertung statt endloser Tool-Debatten. Priorisierte Maßnahmen statt vollständiger Kontrollillusion. Regelmäßige Managementbefassung statt einmaliger Audit-Aktion. Lieferantensteuerung dort, wo echte Abhängigkeiten bestehen, statt pauschaler Fragebogen-Bürokratie für jeden Dienstleister.
NIS2 verlangt nicht, dass jedes Unternehmen wie ein Großkonzern funktioniert. Aber es verlangt, dass jedes betroffene Unternehmen seine Risiken ernsthaft steuert.
Das ist ein großer Unterschied.
Die Geschäftsführung muss Informationssicherheit führen, nicht nur genehmigen
Ein zentrales Missverständnis besteht darin, Managementbeteiligung mit formaler Freigabe zu verwechseln.
Ein Management-Review einmal im Jahr reicht nicht, wenn Informationssicherheit im Rest des Jahres keine Rolle spielt. Eine unterschriebene Policy reicht nicht, wenn Entscheidungen weiterhin ausschließlich nach Kosten, Geschwindigkeit oder operativer Bequemlichkeit getroffen werden. Ein Budgetbeschluss reicht nicht, wenn niemand nachfragt, ob die Maßnahmen wirken.
Führung bedeutet hier nicht, dass Geschäftsführung oder Vorstand technische Details bewerten müssen. Das wäre unrealistisch und auch nicht sinnvoll.
Aber Führung bedeutet, die richtigen Fragen zu stellen.
- Welche Geschäftsprozesse sind besonders kritisch?
- Welche digitalen Abhängigkeiten gefährden unsere Lieferfähigkeit?
- Welche Risiken akzeptieren wir bewusst, und welche nicht?
- Wo sind wir organisatorisch zu schwach aufgestellt?
- Welche Sicherheitsmaßnahmen scheitern nicht an Technik, sondern an fehlender Priorität?
- Welche Lieferanten wären im Ernstfall ein echtes Problem?
- Wie schnell wären wir nach einem schwerwiegenden Vorfall wieder handlungsfähig?
- Und wer würde im Krisenfall tatsächlich entscheiden?
Solche Fragen gehören nicht allein in die IT. Sie gehören in die Unternehmenssteuerung.
Das ist für viele Organisationen unbequem, weil damit Verantwortung sichtbar wird. NIS2 macht genau diese Verantwortung schwerer wegdelegierbar.
Lieferanten, Fachbereiche und Prozesse sind Teil des Risikos
Viele Sicherheitsdiskussionen bleiben zu lange im technischen Kern hängen. Endpoint Protection, Firewall, Backup, MFA, Logging. Alles wichtig. Aber die reale Angriffsfläche eines Unternehmens endet nicht an der eigenen Infrastruktur.
Sie läuft durch Fachbereiche, Dienstleister, Cloud-Plattformen, Softwareanbieter, Produktionsumgebungen, Integrationspartner, externe Administratoren, Wartungszugänge und Geschäftsprozesse.
Gerade im Mittelstand entstehen Risiken oft nicht aus Ignoranz, sondern aus historisch gewachsenen Strukturen. Ein System wurde vor Jahren eingeführt. Ein Dienstleister betreut eine kritische Anwendung. Eine Schnittstelle wurde pragmatisch gebaut. Ein Fachbereich nutzt eine Plattform, weil sie operativ hilft. Ein Standort hat Sonderlösungen, weil es irgendwann notwendig war.
Das ist normale Unternehmensrealität. Aber unter NIS2 reicht es nicht mehr, diese Realität nur zu kennen. Man muss sie steuern.
Das bedeutet: Kritikalität verstehen. Abhängigkeiten sichtbar machen. Verantwortlichkeiten zuordnen. Mindestanforderungen definieren. Notfallfähigkeit bewerten. Und bei wesentlichen Risiken auch unangenehme Entscheidungen treffen.
Nicht jede Altlast lässt sich sofort beseitigen. Aber jede wesentliche Altlast muss bewusst bewertet werden.
Das ist ein Reifegradthema. Und genau hier trennt sich operative IT-Verwaltung von echter IT-Governance.
Dokumentation ist kein Selbstzweck, sondern Führungsnachweis
Bei regulatorischen Themen entsteht schnell eine Abwehrreaktion gegen Dokumentation. Zu viel Papier. Zu viel Auditlogik. Zu viel Formalismus.
Ich verstehe diese Reaktion. Schlechte Dokumentation hilft niemandem. Dokumente, die nur für Auditoren geschrieben werden, erzeugen keinen Sicherheitsgewinn. Sie erzeugen Pflegeaufwand und Zynismus.
Aber daraus folgt nicht, dass Dokumentation unwichtig ist.
Gute Dokumentation ist kein Selbstzweck. Sie ist der Nachweis, dass eine Organisation ihre Risiken verstanden, Entscheidungen getroffen und Maßnahmen nachvollziehbar gesteuert hat.
Auch das BSI verweist darauf, dass betroffene Unternehmen die Umsetzung ihrer Risikomanagementmaßnahmen nachvollziehbar dokumentieren müssen. Der entscheidende Punkt ist aber nicht die Existenz eines Dokuments. Entscheidend ist, ob daraus Führung, Steuerung und Verbesserung entstehen. Auch hier ist die BSI-Seite NIS-2 – Was tun? der passende Referenzrahmen.
Eine Risikoanalyse ist nicht wertvoll, weil sie existiert. Sie ist wertvoll, wenn sie Entscheidungen besser macht. Eine Policy ist nicht wertvoll, weil sie formal freigegeben wurde. Sie ist wertvoll, wenn sie Orientierung gibt und Verhalten prägt. Ein Maßnahmenplan ist nicht wertvoll, weil er vollständig aussieht. Er ist wertvoll, wenn er Prioritäten setzt und Fortschritt steuerbar macht.
Aus meiner Sicht ist das eine der wichtigsten Lehren aus einem ernsthaften ISMS-Aufbau: Man schreibt nicht auf, um etwas zu beweisen, das in Wirklichkeit nicht gelebt wird. Man dokumentiert, damit Steuerung belastbar wird.
Für NIS2 gilt das genauso.
Der CIO muss übersetzen, nicht nur umsetzen
Für CIOs und IT-Leiter entsteht durch NIS2 eine besondere Rolle. Sie dürfen sich nicht in die Position drängen lassen, alleiniger Umsetzer einer Managementverantwortung zu sein. Gleichzeitig können sie sich auch nicht darauf zurückziehen, dass Governance Aufgabe der Geschäftsführung ist.
Die Rolle des CIO ist die Übersetzung.
Wer NIS2 als Compliance-Projekt verkauft, hat bereits verloren. Compliance ist kein überzeugender Führungsanker — weder für das Management noch für die eigene Glaubwürdigkeit. Resilienz schon. Steuerbarkeit noch mehr.
Zwischen regulatorischer Anforderung und Unternehmensrealität. Zwischen technischem Risiko und Managemententscheidung. Zwischen Sicherheitsnotwendigkeit und operativer Belastbarkeit. Zwischen Auditfähigkeit und Alltagstauglichkeit.
Das ist anspruchsvoll, aber auch eine Chance.
NIS2 kann helfen, Themen auf die richtige Ebene zu bringen, die in vielen Unternehmen seit Jahren bekannt sind: unklare Verantwortlichkeiten, schwache Lieferantensteuerung, historisch gewachsene Berechtigungen, fehlende Notfallübungen, zu wenig Transparenz über kritische Systeme, zu geringe Priorität für Security-Themen im Tagesgeschäft.
Aber diese Chance entsteht nur, wenn CIOs NIS2 nicht als Compliance-Projekt verkaufen. Compliance ist kein überzeugender Führungsanker. Resilienz schon eher. Steuerbarkeit noch mehr.
Die bessere Botschaft lautet nicht: „Wir müssen NIS2 erfüllen.“
Die bessere Botschaft lautet: „Wir müssen wissen, welche digitalen Risiken unsere Geschäftsfähigkeit gefährden, und wir müssen sie wirksam steuern.“
Das ist der Kern.
NIS2 wird dort scheitern, wo es als Projekt behandelt wird
Projekte haben einen Anfang und ein Ende. Governance nicht.
Genau deshalb ist der Projektbegriff bei NIS2 gefährlich. Natürlich braucht es ein Programm, einen Plan, Verantwortlichkeiten, Meilensteine und Umsetzungslogik. Aber wenn das Ziel nur lautet, eine Anforderung abzuarbeiten, wird das Thema zu kurz springen.
NIS2 verlangt dauerhafte Fähigkeit.
Risiken verändern sich. Systeme verändern sich. Lieferanten verändern sich. Geschäftsmodelle verändern sich. Angriffe verändern sich. Und Organisationen verändern sich ebenfalls.
Was heute angemessen ist, kann in zwei Jahren zu schwach sein. Was heute ausreichend dokumentiert ist, kann nach einer Akquisition, einem neuen Standort, einer Cloud-Migration oder einer neuen Produktionsplattform unvollständig sein.
Deshalb muss NIS2 in Regelkreise übersetzt werden: Risikomanagement, Management-Review, interne Audits, Maßnahmenverfolgung, Incident Lessons Learned, Lieferantenbewertung, Schulung, Notfallübungen, Wirksamkeitsprüfung.
Das klingt weniger spektakulär als ein neues Security-Tool. Aber genau dort entsteht Reife.
Informationssicherheit wird nicht dadurch besser, dass man sie einmal groß aufsetzt. Sie wird besser, wenn sie regelmäßig geführt wird.
Die eigentliche Frage ist nicht, ob man NIS2 erfüllt
Natürlich müssen betroffene Unternehmen ihre Pflichten erfüllen. Das ist keine Option. Nach aktueller BSI-Information gelten in Deutschland seit dem Inkrafttreten des NIS-2-Umsetzungsgesetzes am 6. Dezember 2025 die dort aufgeführten Registrierungs- und Meldepflichten; die Registrierung erfolgt dafür über das BSI-Portal.
Aber aus Managementsicht greift die Frage zu kurz.
Die eigentliche Frage lautet: Hat das Unternehmen ein belastbares System, mit dem es digitale Risiken erkennt, bewertet, priorisiert, behandelt und überprüft?
Wenn die Antwort darauf ehrlich „ja“ lautet, ist NIS2 beherrschbar.
Wenn die Antwort „nein“ lautet, hilft auch kein hektisches Maßnahmenpaket kurz vor einer Prüfung. Dann wird NIS2 nur sichtbar machen, was vorher schon gefehlt hat: klare Steuerung.
Für mich ist genau das der Punkt.
NIS2 ist kein IT-Projekt. Es ist ein Realitätscheck für Unternehmensführung im digitalen Betrieb.
Wer das Thema an die IT delegiert, kann Maßnahmen abhaken. Aber er schafft keine Widerstandsfähigkeit. Und er übersieht, dass am Ende nicht die vollständigste Policy entscheidend sein wird — sondern ob das Unternehmen im Ernstfall weiß, was kritisch ist, wer entscheidet, was zu tun ist, und wie schnell es wieder handlungsfähig wird.
Das ist der eigentliche Test. Und kein IT-Projekt besteht ihn stellvertretend für die Unternehmensführung.
