Cybersecurity & Informationssicherheit

NIS2 ist kein IT-Projekt. Es ist ein Realitätscheck für Unternehmensführung.

NIS2 ist kein IT-Projekt: Entscheidend sind Managementverantwortung, klare Risikosteuerung und belastbare Governance im Unternehmen.

Kategorie
Cybersecurity & Informationssicherheit
Veröffentlicht
02. Mai 2026
Lesedauer
6 Minuten
  • NIS2
  • ISO 27001
  • Security Governance
Artikel-Link öffnen
NIS2 ist kein IT-Projekt. Es ist ein Realitätscheck für Unternehmensführung. | Andreas WöhrmannN°04 · Cybersecurity & Informationssicherheit

Viele Unternehmen behandeln NIS2 zunächst wie eine Aufgabenliste für die IT. Backups verbessern, Patches sauberer einspielen, Incident Response aktualisieren, vielleicht noch ein Audit vorbereiten.

Das ist alles sinnvoll. Es ist nur nicht der Kern.

Während unserer ISO-27001-Einführung wurde mir das sehr klar. Informationssicherheit scheitert selten daran, dass niemand weiß, welche Technik helfen würde. Sie scheitert dort, wo Verantwortung unklar bleibt. Dort, wo niemand entschieden hat, wer im Ernstfall führt. Und dort, wo die Geschäftsleitung unausgesprochen davon ausgeht, dass die IT das schon irgendwie regelt.

Die wichtigste Erkenntnis aus dieser Arbeit war für mich deshalb nicht, dass Dokumentation wichtig ist. Auch nicht, dass Maßnahmen sauber beschrieben sein müssen.

Die eigentliche Erkenntnis war einfacher und unbequemer: Informationssicherheit funktioniert nur dauerhaft, wenn sie als Führungsaufgabe verstanden wird. Genau deshalb wird NIS2 in vielen Unternehmen noch falsch eingeordnet.

NIS2 ist kein Härtungsprogramm für die IT. Es ist ein Realitätscheck für Unternehmensführung im digitalen Betrieb.

Die Richtlinie betrifft deutlich mehr Unternehmen und Sektoren als frühere KRITIS-Regelungen. Sie verlangt nicht nur technische Schutzmaßnahmen, sondern auch Risikomanagement, Meldewege, organisatorische Verantwortung und nachvollziehbare Steuerung.

Es geht also nicht nur darum, ob die IT ihre Hausaufgaben gemacht hat. Entscheidend ist, ob das Unternehmen digitale Risiken verstehen, priorisieren und führen kann.

Die IT spielt eine zentrale Rolle. Die Verantwortung ist breiter.

Natürlich wird ein großer Teil der Umsetzung in der IT landen. Identitätsmanagement, Schwachstellenmanagement, Netzwerksicherheit, Logging, Backup, Notfallprozesse und Lieferantenbewertungen liegen technisch oder organisatorisch nahe an der IT.

Viele Unternehmen schließen daraus, dass NIS2 automatisch ein IT-Thema ist. Genau hier beginnt der Denkfehler. Die IT kann viel vorbereiten, bewerten und umsetzen. Die Steuerungsverantwortung liegt trotzdem breiter.

Die IT kann Risiken sichtbar machen. Akzeptieren muss sie jemand anders.

Eine IT-Abteilung kann Risiken identifizieren, Schwachstellen analysieren, Maßnahmen empfehlen und technische Konzepte entwickeln. Sie kann aber nicht entscheiden, welches Restrisiko ein Unternehmen bewusst trägt.

Diese Entscheidung ist keine technische Entscheidung. Sie gehört ins Management.

Ein geschäftskritisches Altsystem mit bekannten Schwachstellen ist ein typisches Beispiel. Die IT benennt das Risiko, beschreibt Handlungsoptionen und liefert eine Bewertung. Ob investiert wird, ob das Risiko für eine Übergangszeit akzeptiert wird oder ob andere Prioritäten höher wiegen, entscheidet nicht die IT.

An dieser Stelle beginnt Unternehmensführung. Oder sie bleibt aus.

Ich habe Situationen erlebt, in denen die technische Lösung klar war. Die Umsetzung passierte trotzdem nicht. Nicht, weil niemand das Problem verstanden hätte. Es fehlte die Entscheidung. Das Risiko blieb offen, weil niemand es formal übernommen hat.

Leerer Besprechungsraum mit offenem Dokument — eine Entscheidung die aussteht

Genau dieses Muster macht NIS2 sichtbar.

Viele Risiken liegen außerhalb der IT

Ein großer Teil der Sicherheitsdiskussion dreht sich um Technik: Firewall, Endpoint Protection, MFA, Backup und Logging. Das sind wichtige Themen. Ohne sie wird es nicht funktionieren.

Die tatsächliche Angriffsfläche eines Unternehmens endet aber nicht an der eigenen Infrastruktur. Sie verläuft durch Fachbereiche, Lieferanten, Dienstleister, Cloud-Plattformen, Produktionsumgebungen und Geschäftsprozesse.

Viele Unternehmen kennen ihre kritischen Lieferanten dem Namen nach. Deutlich weniger wissen, wie abhängig sie wirklich von ihnen sind. In Sicherheitsprogrammen habe ich erlebt, dass der kritischste Dienstleister nicht der größte Vertragspartner war, sondern ein kleiner Spezialist mit tiefem Systemzugriff.

Wer betreibt das ERP-System? Wer administriert die Firewall? Wer kennt die Produktionsschnittstellen? Wer verwaltet die wichtigsten Cloud-Dienste? Wer könnte im Ernstfall kurzfristig ersetzt werden und wer nicht?

Genau solche Fragen werden unter NIS2 plötzlich sehr praktisch.

Wo Risiken im Mittelstand tatsächlich entstehen

  • Das ERP-System wird seit Jahren von einer einzelnen Person betreut.
  • Ein externer Dienstleister besitzt weitreichende Zugänge zu kritischen Systemen.
  • Berechtigungen wurden über Jahre vererbt und nie grundlegend überprüft.
  • Fachbereiche nutzen Cloud-Dienste ohne zentrale Risikobewertung.
  • Notfallpläne existieren, wurden aber nie praktisch getestet.
  • Kritische Schnittstellen sind dokumentiert, ihre tatsächlichen Abhängigkeiten jedoch kaum bekannt.

Das ist keine Ausnahme. Das ist Unternehmensrealität.

Vernetzungskarte mit Abhängigkeiten — kritische Lieferantenrisiken außerhalb der IT

Von Maßnahmenlisten zu Governance

Einzelne Kontrollen reichen nicht. Entscheidend ist, ob das Unternehmen seine Risiken versteht und wirksam steuert.

Klassischer AnsatzGovernance-Ansatz
Haben wir MFA?Wissen wir, welche Risiken wir reduzieren wollen?
Haben wir Backups?Können wir kritische Prozesse tatsächlich wiederherstellen?
Haben wir Policies?Werden Entscheidungen daran ausgerichtet?
Haben wir Audits bestanden?Verbessern wir unsere Sicherheitsfähigkeit kontinuierlich?
Haben wir Tools eingeführt?Können wir deren Wirksamkeit belegen?

Was mir ISO 27001 über Informationssicherheit beigebracht hat

Informationssicherheit ist weder ein Dokumentationsprojekt noch ein Technologieprojekt. Sie ist ein Managementsystem.

Die schwierigsten Fragen sind selten technischer Natur:

  • Wer entscheidet?
  • Wer trägt welches Risiko?
  • Wer überprüft die Wirksamkeit?
  • Wer finanziert notwendige Maßnahmen?
  • Wer akzeptiert Restrisiken?
  • Wer eskaliert kritische Abweichungen?

Das sind keine IT-Fragen. Das sind Managementfragen. Im Tagesgeschäft werden sie trotzdem gerne vermieden, weil sie unbequem sind und Verantwortung sichtbar machen.

Angemessenheit ist anspruchsvoller als Maximalforderung

Angemessenheit bedeutet nicht Minimalismus. Es bedeutet, Maßnahmen an Risiko, Unternehmensgröße, Kritikalität und tatsächlicher Belastbarkeit auszurichten.

Entscheidend ist nicht die Größe des Sicherheitsapparats. Entscheidend ist, ob Risiken nachvollziehbar gesteuert werden.

NIS2 verlangt keine Konzernorganisation. NIS2 verlangt verantwortungsvolle Steuerung. Das ist ein Unterschied, der in der Umsetzung enorm viel ausmacht.

Die Geschäftsführung muss Informationssicherheit führen

Eine unterschriebene Policy ersetzt keine Führung. Ein Budgetbeschluss ersetzt keine Steuerung. Ein jährliches Management-Review ersetzt keine kontinuierliche Befassung.

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?
  • Wo bestehen organisatorische Schwächen?
  • Welche Lieferanten stellen ein wesentliches Risiko dar?
  • Wie schnell wären wir nach einem schwerwiegenden Vorfall wieder handlungsfähig?
  • Wer entscheidet im Krisenfall tatsächlich?

Diese Fragen klingen selbstverständlich. In der Praxis werden sie erstaunlich selten gestellt und noch seltener ehrlich beantwortet.

Dokumentation ist Führungsnachweis

Gute Dokumentation zeigt, dass Risiken verstanden, Entscheidungen getroffen und Maßnahmen nachvollziehbar gesteuert wurden. Sie ist kein Verwaltungsakt. Sie ist der Nachweis, dass Führung stattgefunden hat.

Das ist nüchternes Handwerk. Wer einmal ein ISMS aufgebaut hat, weiß aber, wie direkt Dokumentation die Realität sichtbar macht. Man sieht sehr schnell, wo Zuständigkeiten fehlen, wo Entscheidungen nie getroffen wurden und wo Prozesse nur auf dem Papier existieren.

Dokumentenstapel mit Checklisten und Markierungen — Dokumentation als Nachweis gelebter Führung

Die Rolle des CIO in diesem Prozess

Für CIOs und IT-Leiter entsteht durch NIS2 eine besondere Situation. Sie kennen die technische Realität. Sie verstehen die regulatorischen Anforderungen. Sie sehen die Lücken.

Ihre wichtigste Aufgabe liegt deshalb in der Übersetzung: von technischem Risiko zu Unternehmensrisiko, von regulatorischer Anforderung zu operativer Umsetzbarkeit, von IT-Sicht zu Managemententscheidung.

Compliance erzeugt selten Begeisterung. Resilienz und Steuerbarkeit können das sehr wohl, wenn man sie richtig erklärt.

NIS2 wird dort scheitern, wo es als Projekt behandelt wird

Projekte haben einen Anfang und ein Ende. Governance nicht.

Risiken, Systeme, Lieferanten und Geschäftsmodelle verändern sich. Organisationen tun das ebenfalls. Was heute angemessen ist, kann in zwei Jahren überholt sein. Deshalb muss NIS2 in dauerhafte Regelkreise übersetzt werden: Risikomanagement, Management-Reviews, interne Audits, Maßnahmenverfolgung, Lieferantenbewertungen, Schulungen, Notfallübungen, Lessons Learned und Wirksamkeitsprüfungen.

Informationssicherheit wird nicht besser, weil man sie einmal groß aufsetzt. Sie wird besser, weil man sie regelmäßig führt.

Worauf es hinausläuft

Natürlich müssen betroffene Unternehmen ihre regulatorischen Pflichten erfüllen. Dahinter steht aber die Managementfrage, ob sie ihre digitalen Risiken verstehen und wirksam steuern können.

Wenn die Antwort ehrlich Ja lautet, wird NIS2 beherrschbar. Wenn die Antwort Nein lautet, macht die Richtlinie vor allem sichtbar, was vorher schon gefehlt hat: klare Verantwortung.

Wer jetzt wartet, bis sich das von selbst klärt, bekommt seinen Realitätscheck. Nur dann nicht mehr ganz freiwillig.

NIS2 ist kein IT-Projekt. Es ist eine Führungsaufgabe.

Portrait von Andreas Wöhrmann.

Autor

Andreas Wöhrmann

Andreas Wöhrmann ist IT-Führungskraft mit Schwerpunkt auf IT-Transformation, Governance, Cybersecurity, ERP/SAP und Operational Excellence im industriellen Mittelstand. Er schreibt über IT-Strukturen, die strategisch sinnvoll, operativ belastbar und organisatorisch wirksam sind.

Weiterführende Artikel