Was beim Providerwechsel vor der Kündigung sichtbar sein muss

Ein Providerwechsel wirkt oft wie eine Einkaufs- oder Vertragsfrage. Im Betrieb entscheidet aber schon vor der Kündigung, ob Zugänge, Wissen, Eskalationen und Verantwortlichkeiten am Stichtag wirklich übergeben werden können.

Providerwechsel meint hier den geplanten Wechsel eines externen IT-Dienstleisters, etwa für Betrieb, Support, Cloud, Netzwerk, Security oder Fachanwendungen. Für ITSM-Generalisten ist das mehr als ein neuer Vertrag. Es ist eine kontrollierte Übergabe von Abhängigkeiten, die im Alltag oft nur in Tickets, Admin-Konten, Bereitschaftslisten oder persönlichen Absprachen sichtbar sind.

Wer erst nach der Kündigung nach diesen Details sucht, verliert Zeit. Der alte Dienstleister arbeitet bereits auf den Ausstieg hin, der neue Dienstleister kennt die Umgebung noch nicht und interne Teams müssen plötzlich erklären, welche Leistungen tatsächlich kritisch sind. Deshalb braucht ein Providerwechsel vor der formalen Kündigung eine Betriebslandkarte.

Die Leistungsliste reicht nicht für den Betrieb

Verträge beschreiben meist Leistungen, Servicezeiten und Preise. Für den Wechsel reicht das selten. Entscheidend ist, welche konkreten Dienste vom Provider abhängen, welche Systeme er berührt, welche Tickets er regelmäßig löst und welche technischen Ausnahmen nur ihm bekannt sind. Ohne diese Sicht entsteht eine gefährliche Lücke zwischen Einkaufsdokument und Betriebswirklichkeit.

Eine gute Vorprüfung beginnt deshalb mit einfachen Fragen. Welche Anwendungen, Standorte, Schnittstellen und Benutzergruppen hängen am Provider? Wo hat er administrative Rechte? Welche Skripte, Monitoring-Regeln, Zertifikate, Schlüssel, Firewall-Freigaben oder Cloud-Rollen liegen in seiner Verantwortung? Welche Störungen würden sofort beim Service Desk aufschlagen, wenn die Übergabe nicht funktioniert?

Zugänge müssen vor der Kündigung sortiert werden

Bei einem Dienstleisterwechsel werden Zugänge schnell zum Engpass. Manche Konten sind persönlich, manche rollenbasiert, manche liegen in Kundenumgebungen und manche wurden für Notfälle eingerichtet. Wenn diese Übersicht fehlt, kann der neue Provider nicht sauber starten. Noch problematischer ist der umgekehrte Fall: Der alte Provider behält Rechte, die nach Vertragsende nicht mehr begründet sind.

Vor der Kündigung sollte deshalb feststehen, welche Konten übernommen, neu angelegt, gesperrt oder entzogen werden. Dazu gehören Admin-Zugänge, VPN- oder Zero-Trust-Zugänge, Cloud-Rollen, API-Schlüssel, Monitoring-Konten, Tickettool-Berechtigungen und Notfallwege. Die Übergabe muss nicht jedes Passwort kopieren. Sie muss aber klären, welcher Zugang durch welchen kontrollierten Nachfolger ersetzt wird.

Wissen steckt oft in den falschen Orten

Ein Providerwechsel scheitert selten nur an fehlenden Dokumenten. Häufig fehlt das Wissen darüber, wo die entscheidende Information tatsächlich liegt. Ein alter Ticketverlauf erklärt die Ursache einer wiederkehrenden Störung. Ein Kommentar im Monitoring beschreibt eine bewusst tolerierte Ausnahme. Eine persönliche Mail enthält die einzige Begründung für eine Firewall-Regel. Solche Spuren sind für den neuen Dienstleister schwer zu finden.

Darum sollte die Übergabe nicht als großer Dokumentenexport geplant werden. Besser ist eine gezielte Wissensliste: bekannte Dauerprobleme, kritische Betriebsroutinen, wiederkehrende Eskalationen, Sonderfreigaben, offene technische Schulden und nicht dokumentierte Workarounds. Jede Position braucht einen Besitzer, einen Ort und eine Entscheidung, ob sie übernommen, bereinigt oder bewusst beendet wird.

Der Wechsel braucht einen Probebetrieb statt nur einen Stichtag

Ein sauberer Providerwechsel hat nicht nur ein Vertragsende, sondern eine Probe der Betriebsfähigkeit. Der neue Dienstleister sollte vor dem Stichtag ausgewählte Tickets, Bereitschaftswege, Monitoring-Alarme und Eskalationen testweise durchlaufen. Dabei geht es nicht um Misstrauen, sondern um einen realistischen Blick auf Übergaben, Reaktionszeiten und fehlende Rechte.

Für den Service Desk ist diese Probe besonders wichtig. Er muss wissen, wohin Meldungen laufen, welche Prioritäten gelten, welcher Provider bei gemischten Zuständigkeiten führt und welche Antwort Kunden oder Fachbereiche bekommen. Ohne diese klare Rolle wird der Wechsel nach außen als Supportproblem sichtbar, obwohl die Ursache in der Providersteuerung liegt.

Lieferkettenregeln geben den Rahmen, die Übergabe bleibt Handarbeit

NIST SP 800-161 beschreibt Cybersecurity-Risikomanagement in Lieferketten als Aufgabe über den gesamten Lebenszyklus von Lieferantenbeziehungen. Die CISA Cybersecurity Performance Goals betonen grundlegende Schutzmaßnahmen, unter anderem kontrollierte Zugänge, Protokollierung und belastbare Wiederherstellung. Für itsm.news heißt das praktisch: Providerwechsel sind keine reine Beschaffung. Sie sind ein Betriebsrisiko, das früh sichtbar gemacht werden muss.

Die wichtigste Kontrollfrage lautet deshalb nicht, ob die Kündigung formal sauber ist. Wichtiger ist, ob der Betrieb vor der Kündigung zeigen kann, welche Abhängigkeiten übergeben, ersetzt oder beendet werden müssen. Erst dann wird aus einem Anbieterwechsel kein Blindflug, sondern ein geplanter Übergang mit weniger Störungspotenzial.

Quellen und Einordnung: NIST SP 800-161 Rev. 1 zum Cybersecurity Supply Chain Risk Management, CISA Cybersecurity Performance Goals. Stand der Quellenprüfung: 20.07.2026. Bildquelle: Pexels, Foto-ID 8297478, C00 Lizenz.