

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.
NIS2 ist kein technologischer Produktkatalog; NIS2 ist ein Führungsauftrag mit Nachweispflicht. Es verlangt Risiko-basierte Sicherheitsmaßnahmen, Meldepflichten mit engen Fristen, Aufsicht mit Zähnen, persönliche Verantwortung in der Leitung und Sorgfalt in der Lieferkette. Der normative Kern ist einfach und scharf: Zeige, dass du kannst, was du behauptest – im Betrieb, nicht auf Papier.
Das betrifft nicht mehr nur klassische „kritische Infrastrukturen“, sondern eine viel größere Bandbreite von Unternehmen: Energie, Transport, Gesundheit, Wasser, digitale Infrastruktur und Dienste, Finanzmarktakteure, Post- und Abfallwirtschaft, chemische Industrie, Nahrungsmittel, Raumfahrt, Forschung, öffentliche Verwaltung – und zahlreiche wichtige Einrichtungen der Realwirtschaft, die als „wichtig“ gelten, weil ein Ausfall große Auswirkungen hätte. Viele Unternehmen sind heute „drin“, die sich gestern für „nicht relevant“ hielten.
Die zentrale Verschiebung unter NIS2 ist nicht „mehr Pflichten“, sondern andere Adressaten: Die Leitungsebene trägt Verantwortung für das Sicherheitsniveau, für die Risikopriorisierung, für Meldeentscheidungen, für Lieferkettenaufsicht – und sie muss nachweislich geschult, eingebunden und entscheidungsfähig sein. Das hat vier Konsequenzen:
Chefsache bedeutet also wirksames Entscheiden unter Zeitdruck – mit Ketten, die geübt und mit Daten unterlegt sind.
NIS2 nennt keine exotischen Silberkugeln. Es fordert Dinge, die jede reife Organisation ohnehin haben sollte – nur verbindlicher und messbarer. Die Pflichtfelder lassen sich in sechs Blöcke ordnen:
Die Maßnahmen sind bekannt. Neu ist die Ernsthaftigkeit und die Pflicht zum Vorzeigen – „live“ und nicht retrospektiv.
Sicherheit wird delegiert; Leitung sieht Berichte statt Entscheidungen. Ergebnis: Lähmung im Vorfall. Lösung: Rollen im RACI namentlich besetzen (Incident Decision Lead, Regulator Liaison, Third-Party Command, Forensic Lead), Entscheidungsbefugnis formell geben, Übungen mit dem Vorstand durchführen.
Ohne Grenzen kann niemand entscheiden. Alles erscheint kritisch – oder nichts. Lösung: Appetit, Toleranzen, Kapazität je Prozess definieren und auf Cockpits sichtbar machen.
Schöne Farben, keine Steuerung. Lösung: Metriken, die handeln lassen – Mean Time to Detect/Decide/Contain/Recover, Patch-Lag für Kritikalität X, PSIRT-Signal-Lag, Backup-Restore-Erfolgsquote, Anteil rote Ampeln ohne Reaktion > Schwelle.
Freigaben dauern, Fakten fehlen, Fristen reißen. Lösung: Dreistufiges Reporting (Frühwarnung, Zwischenstand, Abschluss) mit festen Pflichtfeldern, Entscheidungsleitfaden und geübter Kette.
Audits auf Papier, keine operativen Rechte. Lösung: vier harte Klauseln (PSIRT/SBOM+VEX, Forensikfeeds, Interconnect-Tests, Exit-Probe) und Lebenszyklusführung (Onboarding → Betrieb → Änderungen → Offboarding).
Backups werden gemacht; Restores scheitern. Lösung: Restore-Drills mit klaren RTO/RPO-Zielen, Offline-Kopien, getrennten Berechtigungen, Notfall-Runbooks.
Berichtslast steigt, aber Messwerte fehlen. Lösung: CCM zuerst: wenige Kontrollen in die Echtzeitüberwachung, Alerts mit Eskalation, Audit-fähige Speicherung.
Inhalte generisch, Führung außen vor. Lösung: rollen- und szenariobasierte Schulungen, Vorstand mit Tabletop-Erfahrung, Messung von Wirkung (z. B. Phishing-Click-Rates, Zeit bis Meldung).
NIS2 lebt von Zeit. „Live“ bedeutet, Entscheidungen unter Unsicherheit zu treffen – methodisch:
Wichtig ist der Mechanismus: Vorlagen, Kanäle, Rollen, Metriken – und regelmäßige Drills. Tempo entsteht aus Übung, nicht aus Hektik.
Unter NIS2 sind Drittparteien der Hebel – im Guten wie im Schlechten. Führen heißt:
Das Ziel: Operative Beherrschbarkeit statt blanker Vertragsgläubigkeit.
NIS2 kollidiert nicht mit Datenschutz – es verlangt beides: Sicherheit und Rechtmäßigkeit. Praktisch heißt das:
Sicherheit ohne Datenkompetenz wird schnell zur Falle – und umgekehrt.
Wenige, durchsetzungsfähige Kennzahlen genügen:
Diese Zahlen gehören nicht in einen Audit-Anhang, sondern in Führungssitzungen – mit Konsequenzen, wenn Schwellen reißen.
Die effektivste Transformation unter NIS2 bringt Policy-as-Code: Regeln werden maschinenlesbar und getestet. Beispiele:
Parallel wird CCM auf die wichtigsten Kontrollen gelegt – wenig, aber tief: Zugriff, Backup, Patch, Segmentierung, Admin-Events, jeweils mit Alarm und Eskalationsplan. So wird aus Governance eine Betriebsdisziplin.
NIS2 wird da schwierig, wo die Kultur auf Schweigen, Verschönern, Verschieben baut. Drei Sätze verändern mehr als jede Technik:
Kultur zeigt sich, wenn es brennt. Man kann sie nicht in PowerPoints beschließen, aber man kann sie in Routinen einüben.
Tage 1–30: Klarheit & Rollen
Tage 31–90: Messen & Melden operationalisieren
Tage 91–120: Resilienz & Exit
Tage 121–180: Skalieren & Verstetigen
Ergebnis nach 180 Tagen: Entscheidungsfähigkeit, Evidenzbereitschaft, geübte Meldeketten, führbare Lieferkette – ohne Big-Bang-Programm, aber mit spürbarer Wirkung.
Energie: Leitsysteme mit langer Lebensdauer, hohe OT-Anteile. Fokus auf Segmentierung zwischen IT/OT, Notbetrieb (manuelle Verfahren), Ersatzteil- und Dienstleister-Verfügbarkeit, Offline-Backups, OT-Forensikpfade. Leitung entscheidet, wo Ausfälle keine Option sind – und finanziert Redundanz, statt sie zu wünschen.
Gesundheit: Viele Hersteller, verteilte Verantwortung. SBOM/VEX, PSIRT-Feeds, Forensikrechte sind überlebenswichtig. Vorstände müssen Lieferketten führen, sonst bleiben Kliniken im Blindflug. Üben von Downtime-Prozessen ist Pflicht.
Transport/Logistik: Echtzeit-Abhängigkeiten, Multi-Partner-Ketten. Interconnect-Tests, Exit-Fähigkeit für zentrale Plattformen, Slicing-Resilienz (wo private Netze), Kommunikationspläne in der Fläche. Meldeketten mit Behörden eingelaufen, nicht improvisiert.
Digitale Dienste: Skalierende Plattformen, viel Open Source. Policy-as-Code, Metrikdisziplin, SBOM-Sauberkeit, PSIRT-Tempo. Führung sorgt dafür, dass Entwicklung und Sicherheit nicht konkurrieren, sondern denselben Takt fahren.
NIS2 wird oft als Bürde wahrgenommen. In Wahrheit ist es ein Effizienzprogramm – wenn man es als Chefsache begreift. Eine Organisation, die unter Unsicherheit entscheidet, Evidenzen produziert, Lieferketten führt, Meldeketten geübt hat und Backup/Restore wirklich beherrscht, ist schneller als eine, die Checklisten pflegt. Kunden spüren das. Aufsichten spüren das. Mitarbeitende spüren das.
Sicherheit ist nicht die Bremse; sie ist die Lenkung. Und Lenkung gehört an die Spitze. NIS2 live heißt deshalb: nicht neue Schlagwörter, sondern neue Routinen. Nicht mehr Fachvokabular, sondern mehr Entscheidung. Nicht höhere Mauern, sondern bessere Führung.
Wer das verstanden hat, hat NIS2 nicht nur erfüllt, sondern genutzt – als Hebel für Widerstandsfähigkeit, Vertrauen und Tempo. Genau das ist Chefsache.
| Hinweis: Teile dieses Beitrags könnten unter Einsatz von KI-gestützten Tools erstellt oder überarbeitet worden sein. Weitere Informationen finden Sie im Impressum/Disclaimer. | Marken- und Bildrechte: Dargestellte Logos und genannten Marken liegen ausschließlich bei den jeweiligen Rechteinhabern. Nutzung erfolgt ausschließlich zu illustrativen Zwecken. |
Wenn Sie den Blog-Beitrag abonnieren, senden wir Ihnen eine E-Mail, sobald es Updates auf dieser Website gibt.

Kommentare 47
Mich interessiert besonders, wie sich die Anforderung in einen belastbaren Arbeitsablauf übersetzen lässt. Welches erste Signal wäre dafür im Alltag wirklich aussagekräftig?
Entscheidend wäre für mich, nicht nur die Durchführung zu dokumentieren. Auch die Wirkung und eine mögliche Abweichung sollten später nachvollziehbar sein.
Den Pilotgedanken finde ich gut. Ergänzen würde ich eine klare Schwelle: Ab wann führt das Ergebnis zu einer Entscheidung und wann bleibt es nur eine Beobachtung?
Genau diese Verbindung ist entscheidend: klein beginnen, aber Wirkung und Entscheidungsfolge vorher festlegen. So bleibt der Aufwand vertretbar und das Ergebnis trotzdem belastbar.
Damit wird es für mich deutlich greifbarer. Vor allem die vorher festgelegte Entscheidungsfolge verhindert, dass der Pilot nur als zusätzlicher Bericht endet.
Eine Frage zur Umsetzung: Wie würdest du die im Beitrag angesprochenen Anforderungen in überschaubare erste Schritte übersetzen?
Ich würde mit klaren Verantwortlichkeiten und einem begrenzten Anwendungsfall beginnen. So lässt sich prüfen, ob die Vorgehensweise im Alltag tatsächlich hilft.
Ich würde wirksame Sicherheitsmaßnahmen und klare Verantwortung zunächst an einem kritischen, aber überschaubaren Fall testen. Dann lassen sich Aufwand und Nutzen vergleichen.
Welche Entscheidung müsste zu Zuordnung von Verantwortung für Sicherheitsmaßnahmen zuerst fallen, wenn ein Dienstleister einen Teil der Umsetzung übernimmt?
Ich würde die erwarteten Ergebnisse und Übergaben konkret vereinbaren; ein Vertrag allein belegt noch keine Umsetzung. Entscheidend wäre für mich, ob das Ergebnis für den konkreten Fall nachprüfbar bleibt. Bei Zuordnung von Verantwortung für Sicherheitsmaßnahmen sollte die Prüfung aus meiner Sicht auf den im Beitrag beschriebenen Zusammenhang begrenzt werden.
Welcher konkrete Nachweis wäre bei Nachweis der Wirksamkeit im laufenden Betrieb für euch aussagekräftiger als eine reine Statusmeldung?
Für mich wäre eine überprüfbare Stichprobe stärker als eine Zusammenfassung. Die Auswahl sollte begründet sein und auch einen Fall enthalten, in dem die Umsetzung Schwierigkeiten machen könnte. Mit Blick auf Nachweis der Wirksamkeit im laufenden Betrieb würde ich den Umfang der Prüfung bewusst auf diese Entscheidung begrenzen.
Wie trennt man die rechtliche Betroffenheitsprüfung von der eigentlichen Sicherheitsverbesserung? Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Mein Vorschlag wäre: Für mich wären das verbundene, aber getrennte Arbeitsschritte. Eine dokumentierte Einordnung beantwortet noch nicht, wie belastbar die vorhandenen Maßnahmen sind. Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.
Ich finde den Ansatz plausibel, aber noch sehr grundsätzlich. An welchem konkreten Entscheidungspunkt würde er einen Unterschied machen? Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Als ersten Schritt würde ich einen klar begrenzten Fall nehmen und den tatsächlichen Ablauf gemeinsam durchgehen. An diesem Fall lassen sich die offenen Zuständigkeiten meist konkreter besprechen. Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig.
Welche Lücke wird am ehesten übersehen, wenn die Umsetzung vor allem als IT-Projekt behandelt wird? Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.
Ich würde es so einordnen: Ich würde besonders auf Entscheidungen und Übergaben zwischen den Funktionen schauen. Sicherheit betrifft für mich auch Führung, Einkauf und den normalen Betrieb. Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Hier würde ich widersprechen: Ein zusätzlicher Prozess kann auch neue Reibung schaffen. Welche vorhandene Aufgabe könnte man damit zusammenführen? Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig.
Welche Kennzahl würde eine Führungskraft tatsächlich zu einer anderen Entscheidung bewegen? Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig.
Für mich liegt der Schwerpunkt hier: Für mich müsste die Kennzahl ein Risiko oder einen Handlungsbedarf erklären. Eine reine Anzahl abgeschlossener Kontrollen wäre dafür nicht immer ausreichend. Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.
Das ist mir als Maßstab noch etwas zu weich. Welches Ergebnis müsste sich nach der Änderung nachweisbar verbessern?
Ich würde das Ergebnis vorher festlegen: Was soll danach klarer, schneller oder belastbarer sein? Ohne diesen Bezug ist der Erfolg einer Änderung schwer zu beurteilen. Auf die Ausgangsfrage bezogen: Für mich müsste die Kennzahl ein Risiko oder einen Handlungsbedarf erklären. Eine reine Anzahl abgeschlossener Kontrollen wäre dafür nicht immer ausreichend.
Wie vermeidet man doppelte Nachweise, wenn bereits ein ISMS besteht? Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Ich würde es so einordnen: Ich würde vorhandene Kontrollen und Belege zunächst den konkreten Anforderungen zuordnen. Erst erkennbare Lücken wären für mich ein Grund für neue Dokumente.
Dazu eine Rückfrage: Was müsste die Geschäftsleitung tatsächlich entscheiden, statt nur eine Richtlinie zu unterschreiben? Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.
Mein Vorschlag wäre: Ich würde Prioritäten, Ressourcen und akzeptierte Restrisiken ausdrücklich vorlegen. Sonst bleibt die Verantwortung auf einer sehr abstrakten Ebene. Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.
Ich würde das nicht allein anhand einer Beschreibung beurteilen. Was wäre ein überzeugender praktischer Nachweis?
Wo würdet ihr bei Verbindung von Vorfallmanagement und Meldeprozessen anfangen, wenn die Zuständigkeit beim Übergang in den Betrieb unklar bleibt?
Mein Vorschlag wäre, die Übergabe erst mit benanntem Verantwortlichen und nachvollziehbaren Abnahmekriterien abschließen. Anschließend sollte klar sein, wer die Wirkung prüft und wann erneut entschieden wird. Bei Verbindung von Vorfallmanagement und Meldeprozessen sollte die Prüfung aus meiner Sicht auf den im Beitrag beschriebenen Zusammenhang begrenzt werden.
Dazu eine Rückfrage: Wie verhindert man, dass die Sicherung dieselben Schwachstellen wie das Produktivsystem hat?
Daran würde ich anknüpfen. Ich würde Zugriffe und Abhängigkeiten gesondert betrachten. Eine zusätzliche Kopie ist für mich noch kein unabhängiger Wiederherstellungsweg. Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig.
Guter Punkt. Ich würde zusätzlich fragen, was passieren soll, wenn sich die Voraussetzungen während des Betriebs ändern. Meine Ausgangsfrage bleibt: Wie verhindert man, dass die Sicherung dieselben Schwachstellen wie das Produktivsystem hat?
Die Grenze sehe ich dort, wo zusätzlicher Aufwand keine bessere Entscheidung mehr unterstützt. Das müsste man an einem konkreten Fall prüfen und nicht pauschal behaupten. Auf die Ausgangsfrage bezogen: Ich würde Zugriffe und Abhängigkeiten gesondert betrachten. Eine zusätzliche Kopie ist für mich noch kein unabhängiger Wiederherstellungsweg.
Dazu eine Rückfrage: Wie prüft man, ob ein Wiederanlauf auch ohne die üblichen Personen und Zugänge gelingt? Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Mein Vorschlag wäre: Ich würde Vertretungen und alternative Zugangswege in die Übung aufnehmen. Gerade diese Voraussetzungen können im Ausfall fehlen. Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig.
Woran erkennt man, dass die Maßnahmen dem eigenen Risiko angemessen sind? Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Ich würde die Auswahl mit den tatsächlichen Leistungen, Abhängigkeiten und möglichen Schäden begründen. Eine pauschale Maßnahmenliste wäre mir zu wenig.
Beim Prinzip bin ich dabei. Bei der Umsetzung könnte aber gerade die Übergabe zwischen zwei Zuständigen schwierig werden. Meine Ausgangsfrage bleibt: Woran erkennt man, dass die Maßnahmen dem eigenen Risiko angemessen sind?
Welche Grenze sollte bei Zuordnung von Verantwortung für Sicherheitsmaßnahmen ausdrücklich festgelegt werden, damit der Umfang handhabbar bleibt?
Zunächst würde ich den konkreten Anwendungsfall und seine Grenzen festhalten. Ausnahmen sollten anschließend bewusst entschieden werden, damit der Umfang nicht unbemerkt wächst. Für Zuordnung von Verantwortung für Sicherheitsmaßnahmen würde ich den ersten Prüfschritt bewusst klein halten.
Ein weiterer Punkt: Wie viel Kontext gehört zu einem Nachweis, damit Rückfragen nicht unvermeidlich werden? Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.
Ich würde Zweck, Zuordnung und zeitliche Gültigkeit mitgeben. Zu viele unstrukturierte Anlagen können die Prüfung eher erschweren. Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.
Der Grundgedanke passt für mich. Trotzdem: Wie verhindert man, dass die Verantwortung zwischen mehreren Beteiligten hängen bleibt? Ich würde das am konkreten Anwendungsfall dieses Artikels festmachen.
Eine überprüfbare Zuständigkeit wäre für mich die Basis. Dazu gehört auch, wer die notwendige Information liefert und wer handelt, wenn sie fehlt. Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Ich bleibe beim Aufwand etwas skeptisch. Eine kleine, überprüfbare Lösung könnte hier zunächst mehr bringen als ein umfassendes Konzept. Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig.
Das ist mir als Maßstab noch etwas zu weich. Welches Ergebnis müsste sich nach der Änderung nachweisbar verbessern? Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.