Wenn ein IT-Dienstleister plötzlich nicht mehr leisten kann, genügt ein vertraglicher Exit-Plan allein nicht. Die Organisation muss wissen, welche Zugänge sie selbst kontrolliert, wo die Wiederherstellungsschlüssel liegen, ob ein Datenexport außerhalb des Dienstes lesbar ist und welche weiteren Dienste vom Anbieter abhängen. Insolvenz ist ein möglicher Auslöser eines solchen Ausfalls, aber diese Anleitung trifft keine insolvenzrechtlichen Aussagen zu Eigentum, Herausgabe oder Rang von Ansprüchen. Sie liefert eine technische und organisatorische Notfallliste, die vor einer Krise geprüft werden sollte. Der DORA-Beitrag zum IKT-Drittparteirisiko und Exit behandelt einen regulierten Rahmen; hier geht es um den abrupten Ausfall des Betriebswegs.
Der NIST SP 1305 bietet Orientierung zur Steuerung von Risiken in der Cyber-Lieferkette. Die NIST SP 800-53A unterstützt bei der Frage, wie ein behaupteter Kontrollzustand beobachtet und getestet werden kann. Weder Quelle garantiert Zugriff auf Daten eines insolventen Dienstleisters. Verträge und einschlägiges Recht müssen gesondert geprüft werden. Der praktische Maßstab dieser Seite ist enger: Können die verantwortlichen Personen die notwendige Leistung oder Datenverfügbarkeit ohne die normale Unterstützung des Anbieters tatsächlich wiederherstellen?
Abhängigkeit und Ausfallmodus genau beschreiben
Erfassen Sie zunächst den gekauften Dienst und seine Rolle: Hosting, Identität, Backup, Schlüsselverwaltung, Entwicklung, DNS, Zahlungsabwicklung oder Fachanwendung. Welche Geschäftsprozesse stoppen, wenn die Leistung endet? Welche Daten werden ausschließlich dort gehalten? Welche Rechte besitzt nur der Anbieter? Ein Provider kann austauschbar erscheinen, während eine einzige von ihm verwaltete Domain, ein Zertifikat oder ein Verschlüsselungsschlüssel den Wechsel blockiert. Die BSI-C5-Cloud-Kriterien können bei der Sicherheitsbewertung eines Cloud-Dienstes helfen; ein Prüfbericht ersetzt aber keinen kundeneigenen Wiederanlaufversuch.
Unterscheiden Sie mehrere Szenarien. Der Anbieter ist technisch erreichbar, aber Support und Vertragsverwaltung fallen aus. Oder die Anwendung läuft noch, lässt jedoch keine neuen Benutzer und Exporte zu. Oder Rechenzentrum und Personal sind gleichzeitig nicht verfügbar. Jede Lage hat andere kurzfristige Optionen. Ein Plan, der vom freundlichen Support des ausfallenden Unternehmens abhängt, deckt gerade den harten Fall nicht ab. Benennen Sie deshalb für jeden wichtigen Schritt, ob er vollständig in Ihrer Hand liegt oder von einer externen Person abhängt.
Priorisieren Sie nach Folgen und Zeitfenster. Ein täglicher Bericht kann warten; die Möglichkeit, eine kritische Produktionsanlage zu verwalten, vielleicht nicht. Die Fachverantwortlichen legen fest, wie lange ein manueller Betrieb möglich ist und welche Mindestdaten dafür nötig sind. Das Sicherheitsteam prüft, ob der Ersatzweg neue Risiken schafft. Der Plan muss nicht versprechen, sofort alle Funktionen wiederherzustellen. Er muss nachvollziehbar zeigen, welcher Mindestbetrieb mit vorhandenen Mitteln erreichbar ist.
Kundenseitige Zugänge sichern
Erstellen Sie ein Inventar der Administrationskonten, Rollen, Domain-Zugänge, DNS-Zonen, Zertifikate, Repository-Rechte, Backup-Portale und API-Konten, die für einen Wechsel gebraucht werden. Vermerken Sie für jeden Zugang, wer ihn kontrolliert und wie er ohne den Anbieter genutzt werden kann. Ein Konto, das nur über die Identität des Dienstleisters wiederhergestellt werden kann, ist keine unabhängige Rückfallebene. Prüfen Sie mindestens einen Zugriff mit einer dafür autorisierten Person unter sicheren Bedingungen.
Vermeiden Sie ein Passwortverzeichnis in der Notfallliste. Die Liste enthält Verweise auf einen geschützten Tresor, berechtigte Rollen, Zugriffsvoraussetzungen und ein Testdatum. Die eigentlichen Geheimnisse werden dort aufbewahrt, wo die Organisation sie sicher verwalten kann. Zwei Personen sollten nicht denselben privaten Account teilen, nur weil die Krise eilt. Falls der Anbieter bisher alleinige Administrationsrechte hatte, dokumentieren Sie die Lücke und verhandeln Sie einen technisch nutzbaren Notfallweg, solange die Beziehung noch funktioniert.
Prüfen Sie Rechte auch auf Zeit. Eine Domain kann zwar der Kundengesellschaft gehören, aber die Zugangsdaten können an eine ausgeschiedene Person gebunden sein. Ein Zertifikat kann vor der geplanten Migration auslaufen. Eine API kann nur aus dem Netz des Dienstleisters aufgerufen werden. Ein unabhängiger Zugang muss nicht nur vorhanden, sondern unter den angenommenen Ausfallbedingungen benutzbar sein. Die Auftragsverarbeitung nach DSGVO betrifft zusätzlich Rollen und Datenpflichten, beantwortet aber die technische Zugangskontrolle nicht automatisch.
Schlüssel, Zertifikate und Wiederherstellung testen
Verschlüsselung schützt Daten im Normalbetrieb. Wenn nur der Anbieter den Entschlüsselungsschlüssel kontrolliert, kann dieselbe Architektur die Wiederherstellung bei Ausfall verhindern. Erfassen Sie Schlüsseltypen, Verwahrstellen, Berechtigungen, Rotation und Abhängigkeiten. Bei kundenseitig verwalteten Schlüsseln muss ein berechtigtes Team zeigen können, dass eine gesicherte Kopie tatsächlich zu einem verschlüsselten Testdatensatz passt. Bewahren Sie keine Schlüssel in einem öffentlich zugänglichen Notfalldokument auf.
Testen Sie einen Restore auf einem isolierten System. Kann ein Backup außerhalb der Anbieterplattform gelesen werden? Werden Datenbank, Anhänge, Konfiguration und Beziehungen zwischen Objekten vollständig rekonstruiert? Wie lange dauert es? Ein erfolgreicher Download ist noch keine Wiederherstellung. Protokollieren Sie Datenstand, Werkzeug, Person, Ergebnis und Fehler. Falls ein proprietäres Format benötigt wird, klären Sie vorab, ob dessen Lesesoftware und Lizenz im Ausfall verfügbar sind.
Zertifikate und Secrets für Integrationen sind Teil derselben Kette. Der Ersatzanbieter kann eine Anwendung vielleicht starten, aber eine abgelaufene Client-Zertifikatskette verhindert den Datenaustausch. Halten Sie fest, welche Geheimnisse neu ausgestellt werden müssen, welche alten Zugänge zu widerrufen sind und wer diesen Wechsel autorisiert. Ein Notfallweg, der alle alten Schlüssel unverändert übernimmt, kann einen Angriff oder eine unkontrollierte Restzugänglichkeit mitnehmen.
Datenexport als nutzbaren Bestand prüfen
Listen Sie pro Datentyp Menge, Format, Änderungsrate, Speicherort und Exportverantwortlichen auf. Unterscheiden Sie laufende Exporte von einem auf Anfrage versprochenen Komplett-Export. Wenn die Plattform nicht mehr antwortet, ist eine vertragliche Zusage technisch möglicherweise nicht sofort erfüllbar. Ein regelmäßiger, sicher gespeicherter Export kann den maximalen Datenverlust reduzieren; seine Häufigkeit muss zum Geschäftsbedarf passen und seine Integrität überprüft werden.
Öffnen Sie den Export außerhalb der Produktoberfläche. Sind Identifikatoren, Beziehungen, Anhänge, Zeitstempel und Löschkennzeichen verständlich? Eine CSV-Datei mit Kundennamen ohne Bestellungen kann für den Betrieb wertlos sein. Rechnen Sie Datensätze und Stichproben gegen den Quellbestand ab. Dokumentieren Sie nicht auflösbare Referenzen und fachliche Prüfungen. Der Export sollte in einer geschützten Umgebung liegen, mit klarer Zugriffskontrolle und einer Aufbewahrungsdauer, die zum Zweck und zu geltenden Pflichten passt.
Ein Beispiel: Ein fiktiver Ticketdienst bietet einen nächtlichen CSV-Export. Beim Test stellt das Team fest, dass nur aktuelle Tickets enthalten sind, nicht jedoch Anhänge und interne Kommentare. Für den Notbetrieb reicht das zur Bearbeitung offener Fälle, nicht zur vollständigen Rekonstruktion früherer Entscheidungen. Der Plan bezeichnet diesen Unterschied ausdrücklich. Das Team verhandelt einen zusätzlichen Anhangexport und richtet bis dahin eine begrenzte Ersatzdokumentation ein. Es meldet keine „vollständige Datenportabilität“, solange der Retest fehlt.
Ersatzbetrieb und versteckte Abhängigkeiten
Ein Ersatzanbieter oder eine interne Übergangslösung benötigt mehr als Rohdaten. Er benötigt Zugang zu Domain, Schnittstellen, Identität, Supportkanälen, Konfiguration und geschulten Personen. Zeichnen Sie die Abfolge: Wer stoppt Schreibzugriffe, wer bestimmt den letzten konsistenten Datenstand, wer richtet den Ersatz ein, wer prüft die Ergebnisse und wer informiert Nutzer? Wenn der alte Dienst noch teilweise läuft, muss ein kontrollierter Schnitt verhindern, dass zwei Systeme widersprüchliche Änderungen annehmen.
Prüfen Sie Lieferketten hinter dem ersten Anbieter. Ein SaaS kann denselben Identitätsanbieter oder dieselbe Cloud-Infrastruktur nutzen wie die geplante Alternative. Die Alternative ist dann für einige Ausfallursachen nicht unabhängig. Fragen Sie nach der konkreten gemeinsamen Komponente, ohne aus einem gleichen Markennamen automatisch eine identische Ausfallzone abzuleiten. Der DORA-Risikomanagementrahmen liefert für betroffene Finanzunternehmen den breiteren Rahmen; die Notfallliste muss trotzdem die realen technischen Kanten nachzeichnen.
Führen Sie einen begrenzten Probelauf aus, solange der Anbieter gesund ist. Exportieren Sie Testdaten, starten Sie sie in einer isolierten Ersatzumgebung, prüfen Sie Anmeldung, einen kritischen Arbeitsablauf und die Datenqualität. Messen Sie die tatsächliche Zeit. Das Ergebnis kann lauten, dass nur ein manueller Minimalbetrieb möglich ist. Diese Erkenntnis ist wertvoller als eine unbelegte Zusicherung, der Wechsel gelinge binnen eines Tages. Wiederholen Sie den Test nach größeren Architektur- oder Vertragsänderungen.
Entscheidungsblatt für die ersten Stunden
Ein abrupter Ausfall erfordert klare Zuständigkeiten. Das Blatt nennt Auslöser, erreichbare Personen, technische Zugänge, Datenstand, Kommunikationswege und Entscheidungsrechte. Trennen Sie bestätigte Fakten von Gerüchten über die wirtschaftliche Lage des Lieferanten. Eine Insolvenzmeldung kann rechtliche Schritte erfordern, aber das Sicherheitsteam sollte keine Eigentums- oder Herausgabeansprüche improvisieren. Es kann jedoch die eigenen Systeme schützen, vorhandene Datenkopien prüfen und den minimalen Betrieb vorbereiten.
| Zeitpunkt | Praktische Frage | Möglicher Nachweis |
|---|---|---|
| Erkennung | Welche Leistung ist tatsächlich ausgefallen? | Monitoring und Fachmeldung |
| Sicherung | Welche eigenen Konten und Kopien sind erreichbar? | Kontrollierter Zugangstest |
| Datenstand | Welche Version ist konsistent und lesbar? | Export- und Restoreprotokoll |
| Ersatz | Welche Funktion kann wo gestartet werden? | Abnahme eines Testvorgangs |
| Kommunikation | Welche Teams und Nutzer sind betroffen? | Freigegebene Statusmeldung |
| Nacharbeit | Welche alten Zugänge werden widerrufen? | Widerruf und Protokollprüfung |
Benennen Sie für jeden Schritt einen Stellvertreter. Ein Plan, der nur beim Hauptadministrator liegt, kann bei dessen Abwesenheit wertlos sein. Verteilen Sie Zugriff auf die Notfalldokumente kontrolliert und testen Sie die Erreichbarkeit. Der Inhalt sollte sicherheitsrelevante Details nicht an einen breiten Verteiler senden. Für die Kommunikation genügt zunächst der bestätigte technische Sachverhalt und das nächste Update; spekulative rechtliche Bewertungen gehören nicht in eine IT-Statusmeldung.
Vertragslage und Datenschutz gesondert klären
Verträge können Regelungen zu Exit, Datenrückgabe, Unterstützung, Unterauftragnehmern und Löschung enthalten. Ob und wie sie im konkreten Insolvenzfall durchsetzbar sind, ist eine eigene Rechtsfrage. Diese Seite ersetzt keine Prüfung des Vertrags und des einschlägigen Rechts. Technisch sollten Sie dennoch vorher wissen, welche Daten Sie schon selbst besitzen und welche Leistungen Sie erst vom Anbieter anfordern müssten. Eine vertragliche Option ohne geübten technischen Weg kann für eine unmittelbare Wiederherstellung zu langsam sein.
Werden personenbezogene Daten verarbeitet, prüfen Sie mit Datenschutzverantwortlichen die Rechtsgrundlagen und Pflichten des konkreten Auftragsverhältnisses. Ein Wechsel zu einem neuen Dienstleister kann neue Vereinbarungen, Informationen und Sicherheitsprüfungen erfordern. Das Ziel des schnellen Ersatzbetriebs hebt diese Anforderungen nicht pauschal auf. Umgekehrt sollte eine rechtliche Prüfung mit den tatsächlichen Datenflüssen arbeiten, nicht mit einer veralteten Anbieterfolie. Notieren Sie im Krisenblatt, wer solche Fragen entscheidet und welche Fakten er benötigt.
Wird die Leistung von einem Finanzunternehmen im DORA-Anwendungsbereich genutzt, muss dessen Exit- und Drittparteiprogramm einbezogen werden. Bei anderen Organisationen kann dieselbe technische Liste sinnvoll sein, ohne die DORA-Vorgaben als allgemein verbindlich auszugeben. Die Abgrenzung DORA und NIS2 kann helfen, Regelungsbereiche zu unterscheiden. Für den einzelnen Dienst bleibt entscheidend, welche Funktion er unterstützt und welche Aufsichts- und Vertragsanforderungen tatsächlich gelten.
Nach dem Test Lücken schließen
Ein Probelauf sollte Mängel erzeugen dürfen: fehlender Schlüssel, unlesbares Format, zu alte Kopie, keine Berechtigung zum Domainwechsel oder unbekannter Ansprechpartner. Tragen Sie für jeden Mangel Eigentümer, Maßnahme, Frist und Wiederholungstest ein. „Exit-Plan vorhanden“ ist kein Abschluss, wenn die kritische Datenbank im Test nicht startet. Priorisieren Sie Hindernisse, die bei einem abrupten Ausfall nicht mehr korrigierbar wären.
Bewahren Sie die Version des Plans und die Testergebnisse getrennt auf. Nach einem Wechsel des Anbieters oder einer neuen Architektur aktualisieren Sie die Zugänge, den Export und die Ersatzreihenfolge. Entfernen Sie nicht die Historie, aus der hervorgeht, welche Annahme falsch war. Ein belastbarer Plan beweist nicht, dass eine Insolvenz eintreten wird; er zeigt, dass die Organisation ihre eigenen Zugangsmittel, Schlüssel und Daten unter einem konkreten Ausfallszenario nutzbar halten kann.
Frühwarnzeichen nicht mit Rechtsfolgen verwechseln
Verspätete Supportantworten, ausbleibende Updates oder eine angekündigte Restrukturierung können Anlass für eine engere technische Prüfung sein. Sie beweisen jedoch keine Insolvenz und erlauben keine pauschale Aussage über die Rechte an Daten. Das Team kann sachlich nachfragen, bestehende Exporte testen und interne Alternativen vorbereiten. Es sollte keine vertraulichen Informationen über den Dienstleister als feststehende Tatsache verbreiten. Die Entscheidung, einen Dienst vorzeitig zu verlassen, benötigt neben Technik auch Vertrag, Geschäftsauswirkung und gegebenenfalls Rechtsberatung.
Ein risikoorientierter Vorlauf ist besonders wichtig, wenn ein vollständiger Export nur mit Unterstützung des Anbieters möglich ist. Fragen Sie während des normalen Betriebs nach einem regelmäßigen Datenabzug oder einem geprüften Notfallweg. Dokumentieren Sie, was technisch machbar und vertraglich vereinbart ist. Wenn ein kritischer Schlüssel ausschließlich bei einer Person des Lieferanten liegt, ist das eine konkrete Abhängigkeit, die behoben oder bewusst akzeptiert werden muss. Ein allgemeiner Hinweis „Lieferant finanziell beobachten“ ersetzt diese technische Maßnahme nicht.
Den Datenstand bei einem abrupten Wechsel schützen
Im Störfall können Nutzer weiter im alten System arbeiten, während ein Export oder Restore vorbereitet wird. Definieren Sie einen klaren Umschaltpunkt: Wann werden Schreibvorgänge gestoppt, welcher Datenstand ist maßgeblich, und wer entscheidet über nachträglich eingegangene Änderungen? Falls das alte System nur zeitweise erreichbar ist, können mehrere Exporte unterschiedliche Stände enthalten. Ein Abgleich anhand von IDs und Zeitstempeln verhindert, dass eine scheinbar neuere Datei ältere, aber wichtige Einträge verdrängt.
Testen Sie auch den Rückweg. Wenn die Ersatzumgebung nur provisorisch ist, muss später entschieden werden, ob Daten zurückgeführt oder dauerhaft migriert werden. Eine improvisierte Rückmigration kann die ursprünglichen Zuordnungen und Löschfristen beschädigen. Protokollieren Sie deshalb Transformationen und manuelle Korrekturen bereits beim ersten Wechsel. Ein Notfallbetrieb ist nicht erfolgreich, wenn er kurzfristig erreichbar ist, aber anschließend keine verlässliche Datenbasis mehr liefert.
Ein verantwortlicher Fachbereich sollte Stichproben abnehmen: Kann eine Bestellung geöffnet, ein Fall bearbeitet oder ein Bericht erzeugt werden? Die IT kann die Datenbank wiederherstellen, ohne zu wissen, ob die fachlichen Beziehungen richtig sind. Legen Sie die Mindestfunktionen vorab fest, damit unter Zeitdruck nicht „Server läuft“ mit „Geschäft läuft“ verwechselt wird.
Übungen in zwei Schwierigkeitsstufen
Beginnen Sie mit einem dokumentierten Schreibtischszenario: Der Anbieter antwortet nicht mehr, aber Ihre vorhandenen Datenkopien und Tresore sind erreichbar. Lassen Sie die vorgesehenen Personen die Schritte ohne Eingriff in die Produktion erklären und benötigte Zugänge finden. Notieren Sie jede Stelle, an der eine Telefonnummer, ein Schlüssel oder eine Entscheidung fehlt. Anschließend folgt ein begrenzter technischer Test mit Testdaten und isolierter Ersatzumgebung.
Eine zweite Übung kann zusätzliche Einschränkungen annehmen: Das normale Identitätssystem ist ebenfalls gestört, und die letzte vollständige Kopie ist älter als erwartet. Jetzt zeigt sich, ob Notfallzugänge und Datenstand unabhängig genug sind. Verwechseln Sie die Übung nicht mit dem Beweis, dass jedes reale Ausfallszenario bewältigt wird. Sie belegt nur die getesteten Schritte und macht Lücken sichtbar. Wiederholen Sie gezielt die zuvor gescheiterten Schritte, anstatt beim nächsten Mal lediglich dieselbe Präsentation zu zeigen.