Übernimmt der neue Provider auch im Probeausfall?

Ein Dienstleisterwechsel sieht auf dem Papier oft sauber aus. Der Vertrag ist unterschrieben, die Kontakte sind benannt, die Servicezeiten stehen fest. Kritisch wird es erst, wenn eine Störung simuliert wird und der neue Provider zeigen muss, ob er den Betrieb wirklich übernehmen kann.

Provider Management meint die Steuerung externer IT-Dienstleister über Leistung, Verantwortung, Risiken und Zusammenarbeit. Für ITSM-Generalisten ist dabei nicht nur wichtig, was im Vertrag steht. Entscheidend ist, ob der Dienstleister im Alltag handlungsfähig ist: mit den richtigen Zugängen, klaren Eskalationswegen, aktueller Dokumentation und einem gemeinsamen Verständnis, wer bei einer Störung welche Entscheidung trifft.

Der Vertrag beweist noch keine Betriebsfähigkeit

Ein neuer Provider kann fachlich geeignet sein und trotzdem im ersten echten Ausfall stolpern. Häufig liegt das nicht an fehlendem Willen, sondern an Lücken zwischen Vertrag, Übergabe und Betrieb. Kontaktlisten sind vorhanden, aber nicht erreichbar. Zugänge wurden beantragt, aber nicht getestet. Monitoring-Alarme laufen an das alte Team. Runbooks wurden übergeben, aber nicht im neuen Werkzeug gepflegt. Die Eskalationskette existiert, aber niemand hat geprüft, ob sie am Wochenende funktioniert.

Genau deshalb ist ein Probeausfall mehr als eine technische Übung. Er ist ein Realitätscheck für Verantwortlichkeit. Das Betriebsteam sieht, ob der neue Dienstleister die Lage erkennt, den richtigen Kommunikationsweg nutzt, Entscheidungen sauber vorbereitet und den Wiederanlauf nachvollziehbar dokumentiert. Der Kunde sieht, ob die vereinbarte Leistung im Stress trägt und nicht nur in Übergabeprotokollen gut aussieht.

Ein Probeausfall darf nicht zur Theaterprobe werden

Der Wert der Übung hängt davon ab, wie ehrlich sie angelegt ist. Ein rein angekündigter Test mit perfekter Vorbereitung zeigt nur, dass alle Beteiligten den Termin kennen. Für einen belastbaren Betriebstest braucht es ein realistisches Szenario: ein nicht erreichbarer Service, ein falscher Alarmweg, eine fehlende Berechtigung oder eine Abhängigkeit zu einem Drittsystem. Das Ziel ist nicht, den Provider bloßzustellen. Das Ziel ist, die Lücken zu finden, solange noch Zeit für Korrektur bleibt.

Wichtig ist eine klare Grenze. Der Test darf keine produktiven Kundenprozesse unnötig gefährden. Er muss abgestimmt, rückholbar und dokumentiert sein. Aber innerhalb dieser sicheren Leitplanken sollte er echte Fragen stellen: Wer nimmt den ersten Alarm an? Wer bewertet die Auswirkung auf Nutzer? Wer entscheidet über Workaround oder Wiederanlauf? Wer informiert den Service Desk? Wer dokumentiert die Ursache und wer schließt die Maßnahme nach?

Zugänge sind oft der erste Schwachpunkt

Viele Übergaben wirken vollständig, bis der neue Provider tatsächlich handeln soll. Dann zeigt sich, ob privilegierte Zugänge funktionieren, ob Notfallkonten erlaubt sind, ob Passwörter oder Schlüssel aktuell sind und ob die Berechtigungen zum vereinbarten Betriebsmodell passen. Ein fehlender Admin-Zugang kann im Normalbetrieb unsichtbar bleiben. Im Ausfall entscheidet er darüber, ob der Dienstleister nur beraten oder wirklich eingreifen kann.

Gute Providersteuerung trennt deshalb zwischen Besitz, Nutzung und Nachweis. Wer darf zugreifen? Wofür? Mit welcher Freigabe? Wie wird der Zugriff protokolliert? Was passiert nach Ende einer Maßnahme? Diese Fragen gehören nicht erst in die Sicherheitsprüfung nach dem Vorfall. Sie gehören in den Übergabetest, weil sie den Unterschied zwischen vereinbarter und gelebter Verantwortung sichtbar machen.

Kommunikation ist Teil der Leistung

Ein Providerwechsel betrifft nicht nur Technik. Der Service Desk, Fachbereiche, interne IT, Informationssicherheit und Management brauchen im Störungsfall ein gemeinsames Bild. Wenn der neue Dienstleister eine technische Ursache findet, aber der Service Desk keine nutzbare Meldung bekommt, entsteht trotzdem Kontrollverlust. Wenn Statusupdates unklar bleiben, beginnen parallele Nachfragen. Wenn niemand weiß, ob ein Workaround freigegeben ist, verzögert sich der Wiederanlauf.

Darum sollte der Probeausfall auch Kommunikationsqualität prüfen. Eine gute Meldung erklärt kurz, was betroffen ist, welche Nutzerwirkung bekannt ist, was gerade getan wird, wann das nächste Update kommt und welche Entscheidung offen ist. Für ITSM-Generalisten ist das oft wertvoller als eine lange technische Ursachenbeschreibung. Betriebssicherheit entsteht nicht nur durch Lösungskompetenz, sondern durch steuerbare Information.

Aus dem Test muss ein Nachweis werden

Nach dem Probeausfall reicht ein kurzes Fazit nicht aus. Die Ergebnisse gehören in eine überprüfbare Maßnahmenliste. Dazu zählen fehlende Rechte, falsche Kontakte, unklare Rollen, alte Dokumentation, fehlende Monitoring-Zuordnung, Lücken im Wiederanlaufplan und Kommunikationsprobleme. Jede Lücke braucht einen Besitzer, einen Termin und einen erneuten Nachweis.

Externe Regelwerke zur digitalen Betriebsstabilität und Lieferkettensicherheit betonen seit Jahren, dass Dienstleisterrisiken nicht nur vertraglich betrachtet werden dürfen. DORA legt für Finanzunternehmen einen starken Fokus auf digitale operationale Resilienz und Risiken durch IKT-Drittdienstleister. ENISA beschreibt Lieferkettenrisiken als Zusammenspiel aus Technik, Organisation und Abhängigkeiten. Auch außerhalb regulierter Branchen ist die praktische Konsequenz ähnlich: Wer einen kritischen Provider steuert, braucht Belege aus dem Betrieb, nicht nur Zusagen.

Was ITSM-Teams konkret verlangen sollten

Ein pragmatischer Providerwechsel bekommt deshalb einen festen Betriebstest vor der endgültigen Abnahme. Die Checkliste ist überschaubar: Alarmweg auslösen, Servicewirkung bewerten, Zugänge testen, Eskalation anstoßen, Statusmeldung schreiben, Wiederanlauf durchführen, Nachweis sichern und offene Punkte nachverfolgen. Erst wenn diese Kette einmal sichtbar funktioniert hat, ist der Übergang mehr als eine formale Übergabe.

Der Nutzen liegt nicht nur in weniger Risiko beim ersten echten Ausfall. Ein Probeausfall schafft gemeinsame Sprache zwischen Kunde und Dienstleister. Er zeigt, welche Zusagen wirklich tragfähig sind, welche Annahmen korrigiert werden müssen und wo der Vertrag für den Betrieb zu ungenau bleibt. Wer den neuen Provider erst im Ernstfall prüft, verschenkt die wichtigste Lernchance des Wechsels.

Quellen und Einordnung: EIOPA zu DORA und digitaler operationaler Resilienz, BaFin zu DORA, ENISA zu Cybersecurity in Lieferketten. Stand der Quellenprüfung: 05.07.2026. Bildquelle: Pexels, Foto-ID 236705.