NIS2-Anforderungen im IT-Betrieb prüfbar machen. Diese Nachweise zählen

NIS2 wird für den IT-Betrieb nicht erst bei der offiziellen Prüfung relevant. Die entscheidende Frage lautet früher: Welche Entscheidungen, Zuständigkeiten, Vorfälle und Wiederanlaufwege lassen sich im Alltag überhaupt belegen?

NIS2 Anforderungen IT Betrieb klingen nach einem großen Rechts- und Sicherheitsprogramm. In der Praxis landen viele Pflichten aber bei Menschen, die Services betreiben, Störungen führen, Dienstleister steuern, Risiken dokumentieren und Nachweise aus Tickets, Protokollen oder Betriebsunterlagen liefern müssen. Genau dort entscheidet sich, ob eine Organisation nur Regeln beschrieben hat oder ob sie zeigen kann, wie der Betrieb tatsächlich kontrolliert wird.

Die NIS2-Richtlinie ist eine EU-Vorgabe für ein höheres gemeinsames Cybersicherheitsniveau. Sie erweitert den Kreis betroffener Einrichtungen und betont Risikomanagement, Meldewege, Lieferketten, Leitungspflichten und Business Continuity. Für Nicht-Juristen ist wichtig: NIS2 verlangt nicht nur schöne Sicherheitskonzepte. Organisationen müssen im Ernstfall nachvollziehbar zeigen können, wer zuständig war, welche Risiken bekannt waren, welche Maßnahmen liefen und wie auf Vorfälle reagiert wurde.

Eine Richtlinie reicht nicht als Betriebsnachweis

Viele Organisationen starten mit einer Policy. Das ist verständlich, aber noch kein belastbarer Nachweis. Eine Richtlinie sagt, was gelten soll. Der IT-Betrieb muss zeigen, was tatsächlich passiert. Wer hat den Service verantwortet? Wann wurde ein Risiko bewertet? Welche Änderung wurde freigegeben? Wo ist dokumentiert, dass ein Wiederanlauf getestet wurde? Welche Eskalation lief, als ein Dienstleister nicht reagierte?

Prüfbar wird NIS2 erst, wenn diese Spuren auffindbar sind. Ein Ticket mit sauberer Entscheidung kann stärker sein als eine lange Präsentation. Ein aktueller Dienstleistersteckbrief kann wichtiger sein als eine generische Lieferantenstrategie. Ein getesteter Wiederanlaufplan sagt mehr als ein Notfallhandbuch, das niemand mit einem konkreten Service verbindet. Besonders wertvoll sind Nachweise, die ohnehin aus der täglichen Arbeit entstehen. Sie bleiben aktueller als Sonderlisten, weil Teams sie bei Störungen, Changes und Freigaben wirklich benutzen.

Zuständigkeiten brauchen Servicebezug

Der erste Nachweis ist selten technisch. Er lautet: Wer ist für welchen Service verantwortlich? Ohne Service Owner verschwimmen Sicherheitsrisiken, Kosten, Wiederherstellung, Lieferantensteuerung und Freigaben. NIS2 macht diese Lücke sichtbar, weil Verantwortung nicht nur im Organigramm stehen darf. Sie muss im Betrieb an Services, Systeme und Abhängigkeiten anschließen.

Ein brauchbarer Nachweis besteht aus einer aktuellen Serviceliste, einem Owner, Stellvertretung, kritischen Abhängigkeiten und einer klaren Eskalation. Das muss nicht in einem perfekten Configuration Management Database Projekt beginnen. Der Beitrag CMDB aufbauen aus IT-Inventar braucht klare Servicefragen zeigt, warum Bestandsdaten erst durch Servicefragen wirksam werden. Für NIS2 gilt dasselbe: Inventar ohne Verantwortlichkeit bleibt schwer prüfbar.

Vorfälle müssen eine Entscheidungsspur haben

NIS2 betont den Umgang mit Sicherheitsvorfällen. Für den IT-Betrieb reicht es deshalb nicht, einen Vorfall technisch zu lösen. Es muss nachvollziehbar sein, wann der Vorfall erkannt wurde, wer ihn bewertet hat, welche Services betroffen waren, welche Kommunikation lief und ob eine Meldepflicht geprüft wurde. Nicht jeder Vorfall wird meldepflichtig. Aber die Entscheidung, warum er es war oder nicht war, sollte später erklärbar sein.

Dafür braucht der Service Desk kein juristisches Gutachten im Ticket. Er braucht Pflichtfelder, Zeitpunkte und Rollen. Was wurde beobachtet? Welcher Service war betroffen? Wer hat Security, Datenschutz, Fachbereich oder Management eingebunden? Welche Übergabe gab es an den Notfall- oder Krisenprozess? Der Beitrag Eine schwere IT-Störung führen. So behält der Service Desk den Überblick zeigt, wie Lageführung und Zuständigkeiten im Ausfall zusammengehören.

Lieferanten werden zum prüfbaren Betriebsrisiko

Viele IT-Services hängen an Providern, Cloud-Plattformen, Softwareherstellern oder spezialisierten Dienstleistern. NIS2 verschiebt Lieferantensteuerung damit aus der reinen Einkaufsakte in den laufenden Betrieb. Entscheidend ist nicht nur, ob ein Vertrag existiert. Entscheidend ist, ob der Betrieb weiß, welcher externe Partner für welchen Service kritisch ist, welche Reaktionszeiten gelten, wie Sicherheitsmeldungen ankommen und wer im Störungsfall eskaliert.

Eine einfache Lieferantenübersicht sollte deshalb mindestens Servicebezug, Kontaktweg, Eskalationsstufe, vereinbarte Reaktionszeit, Sicherheitskontakt, relevante Nachweise und Vertragsgrenzen enthalten. Der Beitrag Gib Provider-Aufgaben nur mit Rückmeldefrist ab beschreibt den operativen Kern: Eine externe Aufgabe ist erst steuerbar, wenn Rückmeldefrist, Zuständigkeit und nächster Schritt sichtbar sind.

Wiederanlauf braucht Testprotokolle statt Hoffnung

Business Continuity und Wiederherstellung sind klassische Stellen, an denen Papier und Betrieb auseinanderlaufen. Ein Wiederanlaufplan ist nur dann belastbar, wenn er mit einem konkreten Service verbunden ist, regelmäßig getestet wird und offene Punkte nachverfolgt werden. NIS2 erhöht den Druck, solche Spuren sauber zu führen, weil Ausfallsicherheit nicht nur behauptet werden kann.

Ein guter Nachweis ist knapp: Datum des Tests, betroffener Service, Szenario, beteiligte Rollen, Ergebnis, Abweichungen, offene Maßnahmen und nächster Testtermin. Wenn Backup, Identitätssystem, Netzwerk, Dienstleister oder Cloud-Konsole für den Wiederanlauf nötig sind, müssen diese Abhängigkeiten im Test auftauchen. Sonst bleibt der Plan eine Annahme.

Änderungen und Ausnahmen brauchen Begründungen

NIS2 verlangt nicht, dass jede Organisation jedes Risiko sofort beseitigt. Aber akzeptierte Risiken, verschobene Maßnahmen und Ausnahmen müssen begründet sein. Für den IT-Betrieb heißt das: Eine Änderung an einem produktiven Service, eine spätere Patchfolge, ein temporärer Admin-Zugang oder eine abweichende Schutzmaßnahme braucht eine Entscheidungsspur. Wer hat entschieden, auf welcher Grundlage, mit welcher Laufzeit und welchem Rückweg?

Hier hilft eine saubere Change- und Freigabelogik. Der Beitrag Standardänderungen brauchen einen Freigabeplan statt Bauchgefühl zeigt, warum Vorabregeln besser sind als Einzelentscheidungen aus dem Bauch. Für NIS2 ist das besonders wichtig, weil eine Prüfung später nicht nur die technische Maßnahme sieht, sondern auch die Governance dahinter.

Eine praktische NIS2-Nachweisliste für den IT-Betrieb

• Serviceverantwortung: Liste kritischer Services mit Owner, Stellvertretung und Eskalation.
• Risikobewertung: dokumentierte Risiken, akzeptierte Ausnahmen, offene Maßnahmen und Wiedervorlage.
• Vorfallprotokolle: Erkennung, Bewertung, betroffene Services, Rollen, Zeiten und Meldeentscheidung.
• Lieferantenübersicht: Servicebezug, Kontakte, Sicherheitsmeldungen, Reaktionszeiten und Eskalation.
• Wiederanlaufnachweise: Testdatum, Szenario, Ergebnis, Abweichungen und nächste Probe.
• Änderungsentscheidungen: Freigabe, Risiko, Rückweg, betroffene Systeme und Umsetzungskontrolle.
• Zugriffsprüfung: privilegierte Rechte, Ablaufdaten, Rezertifizierung und Entzug bei Rollenwechsel.
• Managementspur: Berichte an Leitung, offene Entscheidungen, Budgetfolgen und akzeptierte Restrisiken.

Der beste Start ist eine Lückenprüfung an echten Services

Der IT-Betrieb sollte NIS2 nicht zuerst als vollständiges Dokumentationsprojekt behandeln. Besser ist eine Stichprobe an drei bis fünf wichtigen Services. Für jeden Service wird geprüft: Gibt es einen Owner? Sind kritische Lieferanten bekannt? Liegt ein Wiederanlaufnachweis vor? Ist der letzte schwere Vorfall nachvollziehbar dokumentiert? Gibt es offene Risiken mit Entscheidung und Termin? Sind privilegierte Zugänge aktuell?

Diese Stichprobe zeigt schnell, ob die Organisation prüfbar arbeitet. Fehlende Punkte werden nicht als Schuldfrage behandelt, sondern als Arbeitsliste. Genau darin liegt der Nutzen für ITSM-Generalisten: NIS2 wird von einer abstrakten Pflicht zu einer konkreten Steuerungsfrage. Der Betrieb sieht, welche Nachweise fehlen, welche Tickets angepasst werden müssen und welche Owner Entscheidungen liefern müssen.

So wird NIS2 im Alltag führbar

Prüfbereitschaft entsteht nicht am Abend vor einem Audit. Sie entsteht, wenn Tickets, Changes, Lieferantenübersichten, Wiederanlaufprotokolle und Managemententscheidungen denselben Servicekontext nutzen. Dann muss niemand nachträglich erklären, was im Betrieb eigentlich passiert ist. Die Nachweise liegen bereits in den Arbeitsabläufen.

Der nächste sinnvolle Schritt ist deshalb klein und konkret: Wählen Sie einen kritischen Service, öffnen Sie die letzten relevanten Tickets, Changes und Lieferantenkontakte und prüfen Sie die Nachweisliste. Wenn Zuständigkeit, Vorfallspur, Lieferantenweg, Wiederanlauf und Risikoentscheidung auffindbar sind, ist NIS2 nicht erledigt. Aber der IT-Betrieb hat eine belastbare Grundlage. Fehlen diese Spuren, ist genau dort die erste Verbesserung fällig.

Quellen und Stand: Quellenprüfung am 19.08.2026 anhand der EU-Richtlinie 2022/2555, der BSI-Informationen zur NIS-2-Richtlinie und des EU-Kommission zur NIS2-Richtlinie. Es werden keine Preise, Tarife oder Beträge behandelt. Bildquelle: Pexels / Foto-ID 590022 / CC0-Lizenz