Bildquelle: Pexels / https://www.pexels.com/photo/3184418/
Kurz gesagt Externe IT-Dienste sind im Alltag oft unsichtbar, bis sie ausfallen. Dann zeigt sich, ob ein Anbieter nur vertraglich bekannt ist oder wirklich in die Störungsarbeit eingebunden wurde. Für ITSM heißt das: Lieferanten, Cloud-Dienste, Sicherheitswerkzeuge, Zahlungsdienste, Identitätsprovider und Spezialsoftware gehören nicht nur in Einkauf und Risikoliste. Sie müssen in Übungen, Meldewegen, Servicekatalogen und Entscheidungsrechten auftauchen.
Ein IT-Ausfall endet selten an der eigenen Systemgrenze. Ein Identitätsdienst reagiert verzögert, ein externer Monitoring-Dienst liefert keine Daten, ein Supportportal des Herstellers ist nicht erreichbar oder eine Schnittstelle zu einem Fachverfahren hängt. Im Statusbericht steht dann schnell „Anbieterproblem“. Operativ hilft diese Formulierung wenig, wenn niemand weiß, wer beim Anbieter eskaliert, welche Daten geteilt werden dürfen und welche Alternative kurzfristig tragfähig ist.
Genau deshalb reicht klassische Lieferantensteuerung nicht aus. Verträge, Ansprechpartner und Service Level sind wichtig, aber sie beantworten im Ernstfall nicht automatisch die praktische Frage: Was macht der Betrieb in den ersten 30, 60 und 120 Minuten, wenn ein kritischer Dienst außerhalb der eigenen Kontrolle wackelt?
Einordnung NIS2 ist eine europäische Richtlinie zur Stärkung der Cybersicherheit in wichtigen und wesentlichen Einrichtungen. Sie rückt auch Lieferketten, Dienstleister und Risikomanagement stärker in den Blick. NIST und ENISA beschreiben Supply-Chain-Risiken ebenfalls als Aufgabe, die über den Einkauf hinausgeht. Für ITSM ist daran entscheidend: Externe Abhängigkeiten müssen im Betrieb steuerbar werden, nicht nur in Dokumenten genannt sein.
Die Kritikalität entsteht im Service, nicht im Vertrag
Ein Anbieter kann vertraglich klein wirken und betrieblich kritisch sein. Das passiert zum Beispiel bei Identitätsdiensten, Zahlungsanbietern, DNS-Diensten, Monitoring-Plattformen, Sicherheitsfiltern, API-Gateways oder spezialisierten SaaS-Werkzeugen. Ihr Ausfall betrifft nicht immer den größten Kostenblock, aber oft einen wichtigen Arbeitsfluss. Wer nur nach Einkaufsvolumen priorisiert, übersieht solche Abhängigkeiten schnell.
Der bessere Ausgangspunkt ist der Servicekatalog. Welche externen Dienste hängen an welchem Geschäftsprozess? Welche Nutzergruppe merkt eine Störung zuerst? Welche interne Stelle kann den Effekt erklären? Gibt es einen technischen Ersatzweg oder nur eine Warteschleife beim Anbieter? Erst diese Sicht zeigt, welche Lieferanten in eine Störungsübung gehören.
Kontaktlisten sind noch keine Einsatzfähigkeit
In vielen Organisationen existieren Ansprechpartnerlisten für kritische Dienstleister. Sie werden aber selten unter realen Bedingungen geprüft. Funktioniert die Eskalationsnummer außerhalb der Bürozeiten? Darf der Service Desk dort selbst anrufen oder nur der Einkauf? Welche Kundennummer, Vertragskennung oder technische ID muss genannt werden? Wer entscheidet, ob ein Herstellerzugang geöffnet oder ein Logauszug geteilt wird?
Solche Fragen wirken klein, bis der erste Ausfall läuft. Dann kosten sie Zeit und erzeugen Unsicherheit. Eine Störungsübung mit Lieferantenbezug muss deshalb nicht immer den Anbieter selbst live einbinden. Schon ein internes Tabletop reicht, wenn es die tatsächlichen Hürden sichtbar macht: Zuständigkeit, Datenfreigabe, Kontaktweg, Kommunikationspflicht, Ersatzverfahren und Rückkehr in den Normalbetrieb.
Supply-Chain-Risiko braucht eine Betriebsübersetzung
CISA beschreibt die Absicherung von Informations- und Kommunikationstechnik-Lieferketten als Aufgabe, die Risiken über Produkte, Dienste und Anbieter hinweg betrachtet. NIST SP 800-161 ordnet Cybersecurity Supply Chain Risk Management als organisatorische Disziplin ein. ENISA betont in seinen Empfehlungen ebenfalls, dass Abhängigkeiten, Sicherheitsanforderungen und Verantwortlichkeiten über die Lieferkette hinweg betrachtet werden müssen.
Für den ITSM-Alltag heißt das nicht, jede Quelle als Compliance-Checkliste abzuschreiben. Entscheidend ist die Übersetzung in konkrete Betriebsfragen. Welche Dienste sind so wichtig, dass ihr Anbieter im Major-Incident-Prozess genannt wird? Welche Warnungen des Anbieters erreichen den Service Owner rechtzeitig? Welche Änderungen beim Anbieter müssen ins Change Management? Welche Notizen braucht der Service Desk, wenn Nutzer eine externe Störung melden?
Die erste Übung sollte klein und unbequem sein
Ein guter Einstieg ist ein begrenztes Szenario. Ein Identitätsprovider ist gestört, ein externer Sicherheitsdienst blockiert irrtümlich legitime Zugriffe oder ein SaaS-Anbieter meldet eine regionale Einschränkung. Das Ziel ist nicht Theater, sondern Klarheit. Wer erkennt die Lage? Wer spricht mit dem Anbieter? Wer informiert Fachbereiche? Welche Statusmeldung geht an Nutzer? Welche Workarounds sind erlaubt?
Die Übung wird wertvoll, wenn sie nicht bei Technikfragen stehen bleibt. Sie sollte auch prüfen, ob Verträge, Risikoakten, Servicekatalog, Kommunikationsvorlagen und Entscheidungsrechte zusammenpassen. Ein Anbieter kann im Einkauf sauber geführt sein und im Betrieb trotzdem keine klare Rolle haben. Genau diese Lücke muss sichtbar werden.
Service Desk und Kommunikation brauchen vorbereitete Sprache
Bei externen Störungen entsteht schnell ein Kommunikationsproblem. Nutzer erwarten eine Erklärung, der interne Betrieb hat aber nur begrenzte Kontrolle. Trotzdem darf die Antwort nicht ausweichen. Der Service Desk braucht einfache Formulierungen: welcher Dienst betroffen ist, welche Nutzergruppe Einschränkungen spürt, ob Daten gefährdet sind oder nicht, welche Alternativen gelten und wann die nächste Aktualisierung kommt.
Diese Sprache sollte nicht erst im Ausfall erfunden werden. Für besonders kritische Anbieter reichen wenige vorbereitete Bausteine. Sie verhindern, dass Teams zwischen juristischer Vorsicht, technischer Unsicherheit und Nutzerfrust stecken bleiben. Gleichzeitig helfen sie, Anbieterinformationen nüchtern weiterzugeben, ohne ungeprüfte Schuldzuweisungen oder falsche Entwarnungen zu verbreiten.
Was jetzt in die Prüfung gehört
- Die wichtigsten Services auf externe Abhängigkeiten prüfen, nicht nur auf interne Komponenten.
- Kritische Anbieter nach betrieblicher Wirkung priorisieren, nicht nur nach Vertragswert.
- Kontakt-, Eskalations- und Datenfreigabewege einmal praktisch durchspielen.
- Major-Incident-Prozess, Servicekatalog und Lieferantenliste miteinander abgleichen.
- Service-Desk-Bausteine für typische Anbieterstörungen vorbereiten.
- Nach der Übung klare Korrekturen festhalten, mit Besitzer und Termin.
Fazit
Lieferantenrisiken bleiben abstrakt, solange sie nur in Verträgen, Audits oder Risikoregistern stehen. Im Betrieb werden sie konkret, sobald ein externer Dienst eine interne Leistung ausbremst. Wer Anbieter in Störungsübungen einbezieht, gewinnt keine vollständige Kontrolle über fremde Systeme. Aber er gewinnt Klarheit darüber, wer handelt, wer entscheidet, wer kommuniziert und welche Alternative im ersten Moment wirklich trägt.
Für ITSM ist das der entscheidende Schritt: Aus dem Lieferanten als Akteneintrag wird ein sichtbarer Teil der Serviceführung. Genau dann kann ein externer Ausfall schneller eingeordnet werden, ohne dass das eigene Incident-Team erst die Organisation hinter dem Vertrag suchen muss.
