Damit ein Dienstleisterausfall nicht zum Geschäftsausfall wird

Cyberangriffe, geopolitische Spannungen oder die Insolvenz eines zentralen IKT-Drittdienstleisters: Die letzten Jahre haben gezeigt, wie verletzlich auch robuste Finanzinstitute in ihrem Geschäftsbetrieb sein können. Der Digital Operational Resilience Act (DORA) reagiert darauf mit einer klaren Botschaft: Digitale Belastbarkeit muss planbar sein, auch wenn ein IKT-Drittdienstleister ausfällt.

Die europäische Finanzaufsicht hat auf diesen Zusammenhang auch mit einer Liste der als kritisch einzustufenden IKT-Drittanbieter reagiert. Die Institute müssen aber selbst im Blick haben, welche Funktionen und Prozesse im Betrieb gemäß DORA als kritisch oder wichtig einzustufen sind.

Doch zwischen regulatorischem Anspruch und praktischer Umsetzung klafft oft eine Lücke. Das Auslagerungsmanagement ist einer der Knackpunkte bei der Umsetzung von DORA , so die Erfahrungen aus dem ersten Jahr der DORA-Umsetzung. Seit Anfang 2025 verlangt DORA von Finanzinstituten, sogenannte Ausstiegspläne (auch Exit-Pläne genannt) vorzuhalten – und das nicht nur für wesentliche Auslagerungen, sondern auch für IKT-Dienstleistungen zur Unterstützung kritischer oder wichtiger Funktionen.

Ein Ausstiegsplan gewinnt dabei nicht nur in klassischen Krisensituationen an Bedeutung. Auch regulatorische Gründe können einen Anbieterwechsel erforderlich machen – etwa dann, wenn ein IKT-Drittdienstleister regulatorische Anforderungen nicht erfüllt oder deren Umsetzung verweigert. In solchen Fällen entsteht für das auslagernde Institut ein unmittelbares Compliance-Risiko, selbst wenn der Dienstleister operativ weiterhin Leistungen erbringt.

Viele Finanzinstitute merken erst jetzt, dass ein funktionierender Ausstiegsplan nicht nur eine formale Pflicht ist – er ist ein wichtiger Baustein dafür, auch im Ernstfall die Geschäfte weiterführen zu können.

Ob geplanter Ausstieg oder Krisenfall: Professionelle Exit-Pläne decken beide Fälle ab und definieren Szenarien, die den geordneten Ausstieg ebenso ermöglichen wie das Bewältigen einer akuten Krise. Blicken wir zunächst auf die Unterschiede der beiden Szenarien:

Kontrollierte Beendigung: Das Unternehmen steuert den Ausstieg bewusst. Es bleibt ausreichend Zeit, um taktisch zu handeln – aufgrund von Kosten, Qualitätsproblemen oder einer strategischen Neuausrichtung.

Notfall-Beendigung: Der IKT-Drittdienstleister fällt plötzlich weg, zum Beispiel aufgrund einer Insolvenz, wegen eines Cybervorfalls oder geopolitischer Entwicklungen. Trotz Zeitdrucks muss alles reibungslos funktionieren. Der Exit-Plan dient hier als Sicherheitsnetz – sofort einsetzbar, handlungsorientiert und kontinuitätssichernd. Aufgrund der krisenhaften Situation sind auch die Notfallpläne des Business Continuity Management (BCM) zu berücksichtigen und die Kollegen einzubinden.

Regulatorisch erzwungene Beendigung: Neben strategischen oder krisenbedingten Ausstiegen gibt es eine dritte Konstellation, die in der Praxis zunehmend relevant wird: den regulatorisch erzwungenen Ausstieg. Dieser kann notwendig werden, wenn ein IKT-Drittdienstleister regulatorische Anforderungen nicht erfüllt oder deren Umsetzung verweigert – beispielsweise bei Audit-Rechten, Transparenz über Subdienstleister oder Anforderungen aus DORA. Für das auslagernde Institut kann dadurch ein unmittelbares Aufsichts- und Compliance-Risiko entstehen, selbst wenn der Dienstleister operativ weiterhin verfügbar ist. Gerade wenn der Anbieter aufgrund seiner Rolle für kritische oder wichtige Funktionen nicht kurzfristig ersetzt werden kann, sind belastbare Exit-Strategien entscheidend.

Ob geplant oder ad-hoc: Ausstiegspläne für die Zusammenarbeit mit IKT-Dienstleistern sollten darauf abzielen, das Ziel effektiv umzusetzen und dabei variabel zu sein. Einen strukturierten Ansatz dafür bietet das folgende Rahmenwerk aus drei Bausteinen.

1. Steuerung und Verantwortlichkeiten: den Exit-Plan verankern

Ein belastbarer Ausstiegsplan beginnt mit klaren Zuständigkeiten: Wer trägt die Verantwortung, wer entscheidet im Krisenfall, wer aktiviert den Plan? Die zentrale Steuerung (Governance) wird typischerweise im Zentralen Auslagerungsmanagement (ZAM), auch Third Party Risk Management (TPRM) genannt, verankert.

Damit auf einen Exit-Plan im Normalbetrieb ebenso wie im Ausnahmefall Verlass ist, sollten folgende drei Erfolgsfaktoren beachtet werden:

• Regulatorische Klarheit: Einbindung von DORA, EBA-Guidelines und MaRisk-Anforderungen in das interne Regelwerk, um eventuelle Rückfragen für die Motivation hinter den Exit-Plänen beantworten zu können. Darüber hinaus sollten Exit-Strategien auch Szenarien berücksichtigen, in denen eine Fortsetzung der Zusammenarbeit aus regulatorischen Gründen nicht mehr zulässig ist – etwa bei anhaltender Nichterfüllung von DORA-Anforderungen durch den Dienstleister.
  
  
• Definierte Rollen und Eskalationspfade: Wer bewertet, wer eskaliert und wer kommuniziert? Wer das festlegt, schafft eindeutige Zuständigkeiten und stärkt das Verantwortungsgefühl für die einzelnen Prozessschritte.
  
  
• Verzahnung mit BCM und IT-Risikomanagement: Das Vorgehen im Fall des Ausstiegs wird mit diesen beiden Bereichen verzahnt. Das stellt sicher, dass Risiken systematisch adressiert und Geschäftsprozesse widerstandsfähig gestaltet werden

2. Operationalisierung und Dokumentation: Vergleichbarkeit schaffen

Die Ausarbeitung des konkreten Exit-Plans beginnt damit, die betroffenen Verträge sauber zu identifizieren und zu klassifizieren. Dabei ist zu klären, welche IKT-Dienstleistungen als wesentlich einzustufen sind und an welchen Stellen technische oder rechtliche Abhängigkeiten bestehen. Erst dann folgt die eigentliche Dokumentation – über standardisierte Templates, die in allen Organisationseinheiten identisch genutzt werden.

Als gute Praxis hat sich erwiesen, gemeinsame Kick-offs und Q&A-Sessions mit Vertragsverantwortlichen und dem ZAM/TPRM abzuhalten. Solche Termine helfen dabei, alle Beteiligten, insbesondere die Vertragsverantwortlichen, ins Boot zu holen und Missverständnisse frühzeitig zu vermeiden. Das spart am Ende Zeit und Nacharbeiten.

Im nächsten Schritt sollten die relevanten Vertragsunterlagen, Service-Level-Agreements und Schnittstellenübersichten zentral bereitgestellt werden – das schafft Transparenz und gewährleistet die Nachvollziehbarkeit. Um die Vergleichbarkeit und die Zusammenarbeit mit Prüfern zu erleichtern, ist ein einheitlicher Qualitätsrahmen für den ganzen Vorgang hilfreich. So wird aus einem dezentralen Prozess ein steuerbares, prüfbares System.

3. Integration und Szenario-Fähigkeit: Exit-Planung als Teil der Resilienz-Architektur

Ein Exit-Plan darf nicht für sich allein stehen, er muss in den Prozessen zur Stärkung der Resilienz aufgehen. Dafür sind folgende Schritte nötig:

• Abstimmung mit dem BCM: Indem Exit- und Notfallmaßnahmen ineinandergreifen, wird Doppelarbeit vermieden, und die Handlungsfähigkeit in Krisensituationen wird sichergestellt.
  
  
• Einbindung der IT: Welche Systeme, Schnittstellen und Datenflüsse sind betroffen? Wer diese Frage beantwortet, identifiziert technische Risiken frühzeitig und gewährleistet, dass der Plan umsetzbar ist.
  
  
• Szenario-basierte Betrachtung: Sind es zum Beispiel geopolitische Ereignisse oder Cloud-Risiken, die einen Exit auslösen könnten? Wer das klärt, ermöglicht vorausschauendes Handeln und vermeidet Überraschungen im Ernstfall.

In der Praxis führt dieses integrierte Vorgehen zu einer echten Szenario-Fähigkeit, das heißt: Der Plan ist nicht nur da, sondern er funktioniert auch unter Druck.

Ein Exit-Plan ist nur so gut wie seine Umsetzbarkeit. DORA und die EBA fordern daher auch ausdrücklich regelmäßige Tests, um das Funktionieren in der Praxis sicherzustellen.

Beispiele dafür sind:

• Schreibtischtests: Simulation eines konkreten Ausstiegsszenarios („Table-top exercise“). So werden Prozesse, Rollen und Eskalationspfade praxisnah geprüft und potenzielle Lücken frühzeitig erkannt.
  
  
• Testmigrationen: Praktische Probeläufe für Providerwechsel oder Re-Integration. Sie bestätigen die technische Umsetzbarkeit und zeigen eventuelle Herausforderungen auf.
  
  
• Lessons Learned Workshops: Ableitung von Verbesserungsmaßnahmen nach Simulationen – dadurch fließen Erfahrungen systematisch zurück in den Plan und erhöhen seine Wirksamkeit.

Dieses Plus macht den Unterschied, denn Exit-Planung wird so zu einem lernenden System: kontinuierlich verbessert, angepasst und gestärkt.

Wie gut ist Ihr Unternehmen wirklich vorbereitet, wenn ein IKT-Dienstleister ausfällt? Mit einem getesteten Exit-Plan lässt sich diese Frage nicht nur theoretisch, sondern in der Praxis beantworten. Ein solcher Exit-Plan ist kein Papiertiger, sondern ein Ausdruck organisatorischer Reife.

Finanzunternehmen, die sich vorbereiten, gewinnen nicht nur Compliance-Sicherheit, sondern strategische Handlungsfreiheit. Aus regulatorischer Pflicht wird ein Wettbewerbsvorteil: Resilienz mit Substanz.

Dieser Text entstand unter Mitarbeit von Matthias Greeß.