NIS2 wird im Betrieb erst belastbar, wenn Assets, Lieferanten und Meldewege zusammenlaufen

Viele Unternehmen diskutieren NIS2 noch immer vor allem als Rechts- oder Compliance-Thema. Operativ hilft das nur begrenzt. Sobald ein Sicherheitsvorfall mehrere Dienstleister, alte Systembestände und unklare Zuständigkeiten berührt, zeigt sich sehr schnell, ob die Organisation ihre kritischen Services wirklich kennt – oder ob sie nur Listen, Policies und Vertragsordner pflegt. Genau an dieser Stelle kippt NIS2 aus der Präsentation in den Regelbetrieb.

Das Problem ist selten ein völliger Mangel an Sicherheitsmaßnahmen. Häufiger fehlt die Verbindung zwischen drei Dingen, die in der Praxis getrennt verwaltet werden: belastbare Asset-Verantwortung, aktive Lieferantensteuerung und einsatzfähige Meldewege. Wenn diese Ketten nicht zusammenlaufen, lassen sich Vorfälle zwar technisch erkennen, aber weder sauber bewerten noch fristgerecht eskalieren oder gegenüber Aufsicht und Management belastbar erklären.

Betroffenheitsprüfung ist nur der Anfang

Das BSI stellt inzwischen eine NIS-2-Betroffenheitsprüfung bereit, die Unternehmen eine erste, an der Gesetzgebung orientierte Einschätzung geben soll. Genau diese Formulierung ist wichtig: Es geht um Orientierung, nicht um einen Freifahrtschein. Das BSI betont selbst, dass die Prüfung rechtlich nicht bindend ist und die Selbst-Identifizierung nicht ersetzt. Für die Praxis heißt das: Wer nur einmal einen Fragebogen ausfüllt und das Ergebnis ablegt, hat die eigentliche Managementaufgabe noch gar nicht begonnen.

Gerade in größeren Gruppenstrukturen oder bei ausgelagerten Betriebsmodellen entstehen die heiklen Lücken. Ein Service mag fachlich klein wirken, hängt aber an gemeinsam genutzten Identitätsdiensten, Netzwerksegmenten, SaaS-Plattformen oder Managed-Security-Dienstleistern. Das BSI verweist in seinen FAQ außerdem darauf, dass verbundene Unternehmen und bestimmte Schwellenwerte nicht isoliert pro Team oder Niederlassung betrachtet werden dürfen. Damit wird aus der Betroffenheitsprüfung schnell eine Aufgabe für Architektur, Governance und Einkauf – nicht nur für Legal oder Informationssicherheit.

Ohne saubere Asset-Verantwortung bleibt NIS2 blind

Viele Organisationen besitzen heute irgendeine Form von Asset-Inventar. Doch NIS2 braucht mehr als eine Liste aus Geräten, Verträgen oder CMDB-Einträgen. Im Ernstfall muss klar sein, welche Systeme und Services für die betroffene Leistung relevant sind, wer Änderungen freigibt, welche Abhängigkeiten zu Identität, Netzwerk, Cloud oder Fachverfahren bestehen und welche Lieferanten an dieser Kette mitwirken. Ein Asset ohne eindeutige fachliche und technische Verantwortung ist für NIS2 nur begrenzt hilfreich.

Die Europäische Kommission beschreibt NIS2 als Regelwerk, das Risikomanagementmaßnahmen und Meldepflichten in 18 kritischen Sektoren auf eine einheitlichere Grundlage stellen soll. Genau deshalb reicht es nicht, Sicherheitskontrollen nur punktuell an Tools zu hängen. Unternehmen brauchen einen Blick auf kritische Services, auf ihre unterstützenden Assets und auf die Personen, die deren Zustand erklären können. Wer bei einem Vorfall zuerst herausfinden muss, welches Team für einen betroffenen VPN-Dienst, eine Identity-Komponente oder ein altes Fachverfahren zuständig ist, verliert Zeit an der falschen Stelle.

Praktisch sinnvoll ist deshalb ein servicebezogener Zuschnitt: Welche geschäftskritischen Leistungen fallen unter den NIS2-relevanten Betrieb? Welche Kern-Assets tragen diese Leistungen? Welche Ersatz- oder Notfallpfade existieren? Und wer darf verbindlich sagen, ob ein Vorfall nur lokal bleibt oder den eigentlichen Service beeinträchtigt? Diese Fragen klingen banal, sind aber oft der Unterschied zwischen früher Lageklarheit und hektischer Sucharbeit.

Auslagerung entbindet nicht von Verantwortung

Ein besonders häufiger Irrtum lautet, dass ein weitgehend ausgelagerter IT-Betrieb die NIS2-Last automatisch an Dienstleister verschiebt. Das BSI widerspricht diesem Reflex ausdrücklich: Auch wenn die IT komplett ausgelagert ist, bleiben betroffene Einrichtungen selbst verantwortlich. Sie müssen sicherstellen, dass Dienstleister die nötigen Vorgaben umsetzen, regelmäßig überprüft werden und Vorfälle ordnungsgemäß gemeldet werden. Verträge allein genügen nicht.

Damit wird Lieferantensteuerung zu einer operativen Kernaufgabe. Wer Managed Services, Hosting, SOC-Leistungen, Cloud-Plattformen oder spezialisierte Kommunikationsdienste einkauft, braucht nicht nur saubere Vertragsklauseln, sondern belastbare Nachweise und Eskalationsroutinen. Welche Security-Maßnahmen wurden tatsächlich umgesetzt? Wer meldet einen sicherheitsrelevanten Ausfall zuerst? Welche Daten liefert der Provider für die eigene Bewertung? Wie schnell lassen sich gemeinsame Ursachenanalysen starten? Wenn diese Fragen offenbleiben, wird NIS2 in der Praxis zur Blackbox zwischen Einkauf, Provider-Management und Security-Team.

Hier ist die ENISA-Guidance nützlich. Sie versucht, die regulatorischen Anforderungen für digitale Infrastrukturen, ICT-Service-Management und digitale Anbieter in konkrete Evidenz, Beispiele und technische Umsetzungsbausteine zu übersetzen. Das ist ein wichtiger Hinweis für den Betrieb: NIS2 verlangt nicht nur gute Absichten, sondern prüfbare Belege. Unternehmen sollten deshalb früh entscheiden, welche Lieferantenberichte, Auditnachweise, Kontaktketten und Incident-Schnittstellen sie standardisiert einfordern.

Meldewege müssen vor dem Vorfall geübt sein

NIS2 macht aus Sicherheitsvorfällen kein reines Fachthema des SOC. Sobald ein erheblicher Incident möglich ist, müssen technische Bewertung, Management-Information, Kommunikation und gegebenenfalls Aufsichtskontakt ineinandergreifen. Genau das scheitert oft an getrennten Meldeketten. Das Security-Team erkennt ein Problem, der Provider untersucht noch, der Service Owner versteht die geschäftliche Tragweite nicht sofort, und die Kommunikationslinie wartet auf belastbare Formulierungen. In dieser Gemengelage hilft keine generische Incident-Policy.

Die bessere Vorbereitung besteht aus klaren Übergaben: Wer bewertet die technische Signifikanz? Wer bestätigt die Auswirkung auf den Service? Wer kennt die Meldepflichten und hält den Kontakt zu Aufsicht oder BSI? Welche Informationen müssen aus dem Providervertrag sofort verfügbar sein? Und wer entscheidet, wann aus einem operativen Störfall ein berichtspflichtiger Sicherheitsvorfall wird? Wenn diese Rollen nur auf Organigrammen existieren, ist die Organisation zu langsam.

Hilfreich ist ein schlankes Incident-Playbook pro kritischem Serviceverbund. Darin sollten nicht Hunderte Seiten Prozessbeschreibung stehen, sondern die wenigen wirklich entscheidenden Dinge: Verantwortliche, Vertreter, Kontaktwege, Mindestdaten für Erstbewertungen, Eskalationsschwellen, Provider-Abfragen und Kommunikationsschnittstellen. NIS2 belohnt nicht die schönste Dokumentation, sondern die Fähigkeit, unter Zeitdruck mit denselben Fakten zu arbeiten.

Geschäftsleitung und Betrieb müssen dieselbe Lage sehen

Die Kommission hebt hervor, dass NIS2 die Verantwortung des Top-Managements deutlich sichtbarer macht. Das BSI präzisiert in seinen FAQ, dass Geschäftsleitungen die Risikomanagementmaßnahmen umsetzen und ihre Umsetzung überwachen müssen; außerdem sind regelmäßige Schulungen vorgesehen. Das ist mehr als ein Governance-Signal. Es bedeutet, dass operative Sicherheitslagen nicht erst im Krisenfall nach oben erklärt werden dürfen.

Für den Alltag heißt das: Management und Betrieb brauchen ein gemeinsames Lagebild. Dazu gehören verständliche Übersichten über kritische Services, Abhängigkeiten zu Kernlieferanten, offene Risikoentscheidungen, wiederkehrende Schwachstellen in Altbeständen und der Reifegrad der Incident-Wege. Wenn die Geschäftsleitung nur Quartalsfolien mit Ampelfarben sieht, während Betriebsteams mit unvollständigen Kontaktketten und schlecht gepflegten Systemgrenzen kämpfen, erfüllt die Organisation den Geist von NIS2 nicht.

Womit Unternehmen jetzt sinnvoll anfangen

Wer NIS2 pragmatisch in den Betrieb übersetzen will, sollte nicht mit einer riesigen Compliance-Matrix starten. Nützlicher sind drei direkte Arbeitsstränge. Erstens: kritische Services auflisten und pro Service die wirklich relevanten Assets, Identitäts- und Provider-Abhängigkeiten benennen. Zweitens: für ausgelagerte Leistungen konkrete Sicherheits- und Incident-Nachweise standardisieren, statt nur Verträge zu archivieren. Drittens: Melde- und Eskalationswege so verdichten, dass bei einem Incident in Minuten klar wird, wer welche Lageaussage treffen darf.

Damit entsteht noch kein perfektes NIS2-Programm. Aber es entsteht das, was in vielen Häusern bislang fehlt: ein verbindlicher Zusammenhang zwischen Technik, Lieferkette und Entscheidungsfähigkeit. Genau dieser Zusammenhang entscheidet darüber, ob NIS2 im Betrieb trägt oder bei der ersten größeren Störung in Silos zerfällt.

Fazit

NIS2 ist operativ keine Frage schöner Policies, sondern eine Disziplin der Verbindung. Erst wenn Asset-Verantwortung, Lieferantensteuerung und Meldewege gemeinsam geführt werden, kann eine Organisation Vorfälle belastbar einschätzen, sauber eskalieren und regulatorische Pflichten ohne Blindflug erfüllen. Wer diese Ketten getrennt lässt, hat vielleicht Dokumentation – aber noch kein belastbares Betriebsmodell für Cyber-Resilienz.

Quellen und weiterführende Hinweise

• European Commission: NIS2 Directive: securing network and information systems
• BSI: NIS-2-Betroffenheitsprüfung
• BSI: Allgemeine FAQ zu NIS-2
• ENISA: NIS2 Technical Implementation Guidance

Quelle: Beitragsbild folgt aus Pexels und wird nach dem Live-Publish als Featured Image gesetzt.