Bildquelle: extern
Neue Cyberregeln klingen zuerst nach Firewalls, Meldestellen und Pflichtenkatalog. Im IT-Alltag stellen sie aber eine einfachere und unbequemere Frage: Welche Services betreibt die Organisation wirklich, wer trägt Verantwortung dafür und welche Abhängigkeiten dürfen im Ernstfall nicht im Nebel bleiben?
NIS2 ist die zweite europäische Richtlinie zur Sicherheit von Netz- und Informationssystemen. Sie soll kritische und wichtige Einrichtungen widerstandsfähiger gegen Cybervorfälle machen und schreibt unter anderem Risikomanagement, Meldepflichten und Verantwortung auf Leitungsebene vor. Für ITSM-Generalisten ist daran wichtig: Die Richtlinie prüft nicht nur einzelne Technikmaßnahmen, sondern die Fähigkeit einer Organisation, Risiken in ihren echten Betriebszusammenhängen zu steuern. Deshalb wird aus einem Security-Thema schnell ein Service-Management-Thema.
Die Europäische Kommission beschreibt NIS2 als Rahmen, der mehr Sektoren erfasst und höhere Sicherheitsanforderungen setzt. Das Bundesamt für Sicherheit in der Informationstechnik ordnet für Deutschland ein, welche Unternehmen und Einrichtungen voraussichtlich betroffen sein können. Die EU-Richtlinie selbst nennt unter anderem Risikomanagementmaßnahmen, Lieferketten, Vorfallbehandlung, Geschäftskontinuität und Meldewege. Genau dort beginnt die Brücke zum IT-Betrieb: Wer diese Punkte nur als Checkliste liest, übersieht, dass jeder Punkt an konkreten Services hängt.
Der erste Prüfpunkt ist kein Tool, sondern die Servicegrenze
Ein IT-Service ist mehr als eine Anwendung. Er umfasst Nutzer, Prozesse, Daten, Schnittstellen, Dienstleister, technische Plattformen, Betriebszeiten, Supportwege und Wiederanlaufannahmen. Sobald NIS2 nach Risiken, Störungen oder Lieferketten fragt, reicht eine reine Systemliste nicht mehr aus. Ein Servername erklärt nicht, welcher Fachprozess betroffen ist. Eine Cloud-Anwendung erklärt nicht, welche Datenflüsse, Berechtigungen und externen Abhängigkeiten daran hängen.
Darum wird die Servicegrenze zum praktischen Startpunkt. Sie beantwortet, wo ein Service beginnt, wo er endet und welche Teile wirklich nötig sind, damit er im Alltag funktioniert. Ohne diese Grenze entstehen typische Lücken. Ein Dienstleister wird als Vertrag geführt, aber nicht als Betriebsabhängigkeit. Eine Schnittstelle steht in der Technikdokumentation, aber nicht im Notfallplan. Ein Fachbereich kennt die Kritikalität, aber der Service Desk kennt nur den Anwendungstitel.
NIS2 verschärft diese Unschärfe, weil Verantwortung nicht mehr bequem bei einem einzelnen Sicherheitsteam abgeladen werden kann. Risikomanagement braucht Entscheidungen, Prioritäten und Nachweise. Diese Nachweise entstehen nicht allein im Security-Dashboard. Sie entstehen dort, wo Betrieb, Fachbereich, Einkauf, Rechtsabteilung und Dienstleister dieselbe Servicelogik teilen.
Lieferketten werden erst auf Serviceebene verständlich
Ein häufiger Fehler liegt in der Lieferantenliste. Sie zeigt, wer vertraglich beteiligt ist, aber nicht zwingend, welcher Anbieter welchen Service im Ernstfall wirklich beeinflusst. Für ITSM zählt die Betriebsfrage: Welcher externe Dienst kann einen Geschäftsprozess stoppen, welche Reaktionszeit ist vereinbart, welche Daten liegen dort, welcher Ersatzweg ist vorbereitet und wer darf im Vorfall entscheiden?
Gerade digitale Services bestehen oft aus mehreren Bausteinen. Eine Anwendung nutzt Identitätsdienste, Zahlungsanbieter, Monitoring, E-Mail-Versand, Schnittstellen, Hosting, Backups und Supportkanäle. Fällt ein Baustein aus oder wird er kompromittiert, wirkt die Störung für Nutzer trotzdem wie ein Problem des gesamten Services. Wer NIS2 ernst nimmt, sollte solche Abhängigkeiten deshalb nicht als Randnotiz führen, sondern in der Servicebeschreibung sichtbar machen.
Das hilft auch bei Prioritäten. Nicht jeder Anbieter ist gleich kritisch. Ein Newsletter-Tool, ein Identitätsanbieter und eine zentrale Fachanwendung haben unterschiedliche Folgen. Erst die Verbindung zum Service zeigt, welche Maßnahmen zuerst geklärt werden müssen. Dazu gehören Mindestanforderungen, Meldewege, Kontaktketten, Wiederanlaufannahmen und die Frage, welche Leistung auch ohne den Anbieter noch möglich ist.
Der Service Desk braucht frühere Antworten
Regulatorische Anforderungen wirken oft weit weg von der ersten Supportlinie. Im Vorfall ist der Service Desk aber einer der ersten Orte, an denen Unsicherheit sichtbar wird. Nutzer fragen, ob sie weiterarbeiten dürfen, ob Daten betroffen sind, ob eine Störung bekannt ist oder ob eine Meldung echt ist. Wenn der Service Desk dann nur allgemeine Sicherheitshinweise hat, verliert die Organisation wertvolle Zeit.
Eine gute NIS2-Vorbereitung übersetzt deshalb zentrale Serviceinformationen in alltagstaugliche Antworten. Welche Symptome gehören zu welchem Service? Welche Meldungen dürfen bestätigt werden? Wann wird an Security, Datenschutz, Fachbereich oder Management eskaliert? Welche Formulierungen sind erlaubt, solange Fakten noch geprüft werden? Solche Punkte sind keine juristische Detailarbeit, sondern Betriebsfähigkeit.
Wichtig ist dabei die Trennung von Verdacht, bestätigter Störung und meldepflichtigem Ereignis. Der Service Desk muss nicht rechtlich bewerten, ob eine formale Meldung nötig ist. Er muss aber wissen, welche Beobachtungen schnell weitergegeben werden müssen und welche Kommunikationsspur danach genutzt wird. Diese Klarheit verhindert stille Verzögerungen und widersprüchliche Aussagen.
Geschäftskontinuität braucht konkrete Wiederanlaufannahmen
NIS2 spricht auch über Maßnahmen zur Aufrechterhaltung des Betriebs. In der Praxis reicht dafür ein allgemeiner Notfallplan selten aus. Entscheidend ist, welche Services zuerst wiederkommen müssen, welche Datenstände akzeptabel sind, welche manuellen Ersatzwege funktionieren und wer eine reduzierte Leistung freigibt. Diese Fragen gehören in die Serviceplanung, nicht nur in ein Krisenhandbuch.
Ein Service kann technisch wieder verfügbar sein und trotzdem fachlich nicht nutzbar bleiben. Vielleicht fehlen aktuelle Daten, eine Schnittstelle läuft noch nicht, ein externer Freigabeprozess ist blockiert oder die Nutzer wissen nicht, welche Arbeitsweise vorübergehend gilt. Deshalb sollte Wiederanlauf immer aus Nutzersicht geprüft werden. Kann der betroffene Prozess wieder arbeiten, oder ist nur ein System grün?
Für ITSM entsteht daraus ein pragmatischer Arbeitsauftrag. Kritische Services brauchen eine kurze Betriebskarte: Zweck, Nutzergruppen, fachlicher Owner, technischer Owner, wichtigste Abhängigkeiten, Meldeweg, Wiederanlaufziel, bekannte Ersatzwege und Kommunikationsverantwortung. Diese Karte ersetzt keine vollständige Risikoanalyse. Sie sorgt aber dafür, dass die Analyse nicht losgelöst vom Betrieb bleibt.
Was ITSM jetzt vorbereiten sollte
Der erste sinnvolle Schritt ist eine kleine Serviceauswahl. Statt sofort das ganze Unternehmen zu kartieren, sollten ITSM, Security und Fachbereiche gemeinsam die Services wählen, deren Ausfall den größten Schaden verursachen würde. Für diese Services wird geprüft, ob Grenzen, Owner, Lieferanten, Datenflüsse, Supportwege und Wiederanlaufannahmen verständlich dokumentiert sind.
Der zweite Schritt ist ein Abgleich mit echten Vorfällen und Übungen. Wo gab es zuletzt Verzögerungen? Welche Zuständigkeit war unklar? Welcher Anbieterkontakt fehlte? Welche Nutzerkommunikation musste improvisiert werden? Solche Befunde sind oft wertvoller als abstrakte Reifegradfragen, weil sie zeigen, wo die Organisation im Ernstfall tatsächlich stolpert.
Der dritte Schritt ist eine klare Sprache. NIS2 darf nicht als Spezialprojekt verschwinden, das nur Security versteht. Der Betrieb braucht Begriffe, die Fachbereiche und Support nutzen können: Service, Abhängigkeit, Ausfallfolge, Meldeweg, Rückfallbetrieb und Verantwortlicher. Je verständlicher diese Begriffe im Alltag sind, desto besser lassen sich die formalen Anforderungen später mit Leben füllen.
Die Pointe ist einfach: Neue Cyberregeln machen Sicherheit sichtbarer, aber sie lösen keine alten Betriebsunklarheiten. Wer nicht weiß, welche Services wirklich kritisch sind, kann Risiken nicht sauber priorisieren. Wer keine Owner kennt, kann Verantwortung nicht belastbar zuweisen. Und wer Abhängigkeiten erst im Vorfall entdeckt, ist für Meldepflichten, Krisenkommunikation und Wiederanlauf zu spät dran.
Quellen und Einordnung: Europäische Kommission zur NIS2-Richtlinie, BSI-Informationen zu NIS2 in Deutschland und Richtlinie (EU) 2022/2555 im Amtsblatt der Europäischen Union. Stand der Quellenprüfung 24.06.2026. Der Beitrag enthält keine Preise, Gebühren oder Leistungssätze.
