Bildquelle: Pexels / Foto-ID 5668858 / https://www.pexels.com/photo/5668858/
Cybervorgaben wirken zuerst wie ein Thema für Security und Recht. Im Alltag entscheiden sie aber oft an einer viel praktischeren Stelle: im Dienstleistervertrag, in der Übergabe und in der Frage, ob der Provider im Störfall wirklich steuerbar bleibt.
NIS2 ist die europäische Richtlinie für ein höheres gemeinsames Cybersicherheitsniveau in wichtigen und wesentlichen Einrichtungen. Sie verlangt unter anderem Risikomanagement, Vorfallbehandlung, Lieferkettenblick und klare Verantwortung. Für ITSM-Generalisten ist daran vor allem wichtig: Cyberpflichten enden nicht am eigenen Netzwerk. Sie reichen in ausgelagerte Dienste, Cloud-Leistungen, Wartungsverträge und Supportprozesse hinein.
Der Vertrag muss den Betrieb erklären können
Ein Dienstleistervertrag wird in vielen Organisationen noch immer vor allem über Preis, Laufzeit, Service Level und Kündigungsfristen gelesen. Das reicht nicht mehr, wenn ein externer Dienst produktive Abläufe, Kundenzugänge oder kritische Daten berührt. Dann muss der Vertrag auch beantworten, wie Sicherheit, Meldewege, Nachweise und Entscheidungsrechte im laufenden Betrieb funktionieren.
Die eigentliche Frage lautet nicht, ob irgendwo ein Abschnitt zu Informationssicherheit steht. Entscheidend ist, ob der Text im Ernstfall hilft. Wer meldet einen Vorfall an wen? Welche Frist gilt intern, bevor externe Meldepflichten geprüft werden müssen? Welche technischen Informationen liefert der Provider? Wer darf Logs, Berichte oder Wiederherstellungsnachweise anfordern? Und wer entscheidet, ob ein Dienst vorübergehend getrennt, gedrosselt oder umgestellt wird?
NIS2 verschiebt den Blick auf die Lieferkette
Die NIS2-Richtlinie benennt ausdrücklich das Risikomanagement in der Lieferkette und die Sicherheit der Beziehungen zu unmittelbaren Anbietern und Dienstleistern. Das ist für ITSM kein abstrakter Compliance-Satz. Es bedeutet, dass ausgelagerte Dienste nicht nur bestellt, sondern betrieblich geführt werden müssen. Ein Provider kann technisch gut arbeiten und trotzdem ein Risiko bleiben, wenn Zuständigkeiten, Eskalationswege und Nachweise unklar sind.
Für den Servicebetrieb entsteht daraus eine neue Prüffrage. Lässt sich der ausgelagerte Teil eines Dienstes genauso erklären wie der interne Teil? Wenn eine Störung auftritt, muss das Team wissen, welche Kontaktstelle trägt, welche Informationen erwartet werden, welche Reaktionszeit realistisch ist und wie die Kommunikation mit Fachbereich, Management und Kunden abgestimmt wird. Ohne diese Klarheit wird der Dienstleistervertrag zur Ablage, nicht zum Steuerungsinstrument.
Service Level sind nicht automatisch Cybernachweise
Ein Service Level Agreement sagt meist, wie schnell reagiert oder wiederhergestellt werden soll. Das ist wichtig, aber es ersetzt keine Cybersteuerung. Ein Anbieter kann eine Reaktionszeit einhalten und trotzdem zu wenig über Ursache, Umfang, betroffene Daten oder getroffene Gegenmaßnahmen liefern. Genau diese Informationen können aber für interne Bewertung, Meldeprüfung und Managementkommunikation entscheidend sein.
Darum sollten ITSM-Teams Service Level und Sicherheitsnachweise getrennt betrachten. Reaktionszeit, Verfügbarkeit und Supportkanal gehören zur operativen Leistung. Zusätzlich braucht es Anforderungen an Vorfallinformationen, Protokolle, Statusupdates, Lessons Learned, Schwachstellenkommunikation, Subdienstleister und Nachweise zu Wiederherstellung oder Schutzmaßnahmen. Erst zusammen entsteht ein belastbares Bild.
Subdienstleister dürfen nicht im Nebel bleiben
Viele digitale Dienste hängen an weiteren Anbietern. Ein SaaS-Provider nutzt Cloud-Infrastruktur, Monitoring, E-Mail-Dienste, Identitätsdienste oder externe Supportpartner. Für den Kunden ist das nicht immer sichtbar. Trotzdem kann genau diese Kette im Störfall relevant werden. Wenn ein Subdienstleister ausfällt oder kompromittiert wird, muss klar sein, wer informiert, wer bewertet und welche Auswirkung auf den eigenen Dienst entsteht.
Der Vertrag muss deshalb nicht jede technische Abhängigkeit im Detail ausbreiten. Er sollte aber regeln, wann wesentliche Unterauftragnehmer gemeldet werden, welche Sicherheitsanforderungen weitergegeben werden und wie Änderungen an kritischen Abhängigkeiten kommuniziert werden. Für ITSM ist das besonders wichtig bei Diensten mit Kundenwirkung, administrativen Zugriffen, Datenübertragung oder Betriebsüberwachung.
Der Provider braucht eine Rolle im Notfallplan
Ein Notfallplan, der externe Anbieter nur als Telefonnummer aufführt, ist zu schwach. Der Provider braucht eine konkrete Rolle. Welche Szenarien betreffen ihn? Wann wird er eingebunden? Welche Mindestinformationen muss das interne Team bereithalten? Welche Entscheidungen darf der Anbieter selbst treffen und welche nur nach Freigabe? Welche Kommunikationslinie gilt außerhalb der Bürozeiten?
Diese Fragen gehören nicht nur in eine Sicherheitsrichtlinie. Sie gehören in den praktischen Ablauf für Incident Management, Major Incident Management und Wiederanlauf. Wenn der Provider erst im Ernstfall versteht, welche Erwartung besteht, ist wertvolle Zeit verloren. Wenn das interne Team erst dann herausfinden muss, wer beim Anbieter entscheiden darf, entsteht ein Steuerungsloch.
Audits brauchen prüfbare Spuren statt guter Absichten
Cyberpflichten erzeugen auch eine Nachweisfrage. Es reicht selten, intern zu sagen, dass man den Dienstleister kennt und ihm vertraut. Prüfer, Management oder Kunden wollen sehen, welche Anforderungen vereinbart wurden, wann sie überprüft wurden und wie Abweichungen behandelt werden. Dazu gehören Vertragsklauseln, Sicherheitsanhänge, Risikoakzeptanzen, Protokolle von Service-Reviews und Belege aus Übungen oder echten Vorfällen.
Der beste Start ist eine einfache Lieferantenakte für kritische IT-Dienste. Sie muss nicht bürokratisch sein. Sie sollte aber zeigen, welche Dienste betroffen sind, welche Cyberanforderungen gelten, welche Ansprechpartner und Eskalationswege existieren, welche Nachweise vorliegen und welche offenen Punkte beim nächsten Review geprüft werden. So wird aus Compliance eine laufende Steuerung.
Was ITSM jetzt konkret prüfen sollte
Für bestehende Verträge hilft eine kurze Betriebsprüfung. Erstens: Welche ausgelagerten Dienste sind für Kunden, Produktion, Identität, Daten oder Service Desk besonders wichtig? Zweitens: Welche Anbieter haben administrativen Zugriff oder verarbeiten sensible Informationen? Drittens: Wo fehlen klare Meldewege, Nachweise oder Subdienstleisterregeln? Viertens: Welche Provider müssen in Notfallübungen einbezogen werden?
Diese Prüfung muss nicht auf den nächsten großen Vertragszyklus warten. Viele Lücken lassen sich über Sicherheitsanhänge, Betriebshandbücher, Review-Termine oder aktualisierte Eskalationslisten schließen. Wichtig ist, dass ITSM, Security, Einkauf und Fachbereich dieselbe Sicht auf den Dienst bekommen. Cyberpflichten werden erst handhabbar, wenn der Vertrag nicht nur juristisch existiert, sondern im Betrieb eine Rolle spielt.
Quellen und Einordnung: Europäische Kommission zur NIS2-Richtlinie, BSI-Informationen zu NIS2-regulierten Unternehmen, Richtlinie (EU) 2022/2555 im Amtsblatt der Europäischen Union. Stand der Quellenprüfung: 15.07.2026. Bildquelle: Pexels, Foto-ID 5668858.
