Wenn Ihr kritischer ICT-Provider morgen ausfällt: Was steht still — und wie lange?
Auf einen Blick
Es geht nicht mehr nur um den Provider.
Es geht darum, ob das Institut Kontinuität belegen kann.
Board AskBestätigen, ob das Institut Kontinuität und Exit-Fähigkeit für ICT-Services belegen kann, die kritische oder wichtige Funktionen unterstützen.
Situation
Nehmen wir folgende Situation an.
Ein kritischer ICT-Drittanbieter fällt aus. Er unterstützt eine Plattform, einen Datendienst, eine Cloud-Umgebung, eine Workflow Engine, eine Reporting-Schicht oder einen KI-gestützten Prozess des Instituts. Innerhalb weniger Stunden lautet die Frage nicht mehr, ob der Provider vertraglich verpflichtet ist, den Service wiederherzustellen.
Die Frage ist, was innerhalb der Bank stillsteht.
Welche kritischen oder wichtigen Funktionen sind betroffen? Welche Kunden-, Risiko-, operative oder entscheidungsbezogene Ketten hängen vom Provider ab? Welche Wiederherstellungszeit wurde getestet? Kann der Service innerhalb der Toleranz des Instituts ersetzt, beendet oder wiederhergestellt werden?
Es geht nicht mehr nur um den Provider.
Es geht darum, ob das Institut Kontinuität belegen kann.
Management Summary
DORA macht ICT-Drittparteienrisiko zu einer board-relevanten und evidenzbasierten Disziplin. Finanzunternehmen bleiben für Compliance verantwortlich, auch wenn ICT-Services von Drittanbietern erbracht werden; DORA verlangt außerdem ICT-Drittparteienrisikomanagement, ein Register of Information und Exit-Strategien für ICT-Services, die kritische oder wichtige Funktionen unterstützen.
Die Europäischen Aufsichtsbehörden veröffentlichten am 18. November 2025 die erste Liste von 19 designierten kritischen ICT-Drittanbietern unter DORA. Die Designierung stützte sich auf Daten aus den Registers of Information und auf eine Kritikalitätsbewertung, die systemische Bedeutung, Unterstützung kritischer oder wichtiger Funktionen und Substituierbarkeit berücksichtigt.
Eine starke Antwort lautet nicht: „Wir haben eine Exit-Policy." Eine starke Antwort zeigt, welche Services stillstehen, welches Recovery Objective gilt, wo Abhängigkeiten zusammenlaufen, welcher Exit-Pfad getestet wurde und wer entscheiden kann, ein Arrangement einzuschränken, zu ersetzen, zu beenden oder fortzuführen.
Management-Report-Panel
Kalibrierung der Antwortqualität
Der RAG-Status kalibriert die Qualität der Antwort. Er bewertet nicht das Institut.
Wer antworten sollte
- Procurement kann den Vertrag verantworten.
- Technology kann die Plattform verantworten.
- Das Business verantwortet die Auswirkung.
- Das Board muss die Kette sehen.
Nachweise, die der Vorstand anfordern sollte
- 01Register of Information
- 02Critical Function Mapping
- 03Provider Criticality Classification
- 04Concentration Risk Assessment
- 05Fourth-Party Dependency Map
- 06RTO / RPO / MTPD View
- 07Tested Exit Strategy
- 08Contractual Exit and Transition Evidence
- 09Incident and Recovery Exercise Log
- 10Board Resilience Dashboard
Warnsignale
- “Wir haben eine Exit-Policy.”
- “Der Provider wird direkt unter DORA beaufsichtigt.”
- “Das wird von Procurement gesteuert.”
- “Der Provider hat starke SLAs.”
- “Wir nutzen mehrere Provider.”
- “Der Service ist nicht kundennah.”
- “Der Exit-Plan ist dokumentiert.”
- “Wir könnten aussteigen, wenn es notwendig wäre.”
Keine dieser Aussagen ist notwendigerweise falsch. Sie sind nur keine ausreichende Evidenz für Board-Level Reliance.
Weg zu Grün
- Abhängigkeiten sichtbar
- Kritikalität klassifiziert
- Konzentration verstanden
- Recovery gemessen
- Exit ermöglicht
- Residual Risk gesteuert
GRÜN ist kein Vertragsstatus.
GRÜN ist ein getesteter Kontinuitätsstatus.
Empfohlene nächste Frage
Welche kritische oder wichtige Funktion würde die größte Störung erzeugen, wenn ihr ICT-Provider morgen ausfällt — und können wir den getesteten Recovery-Pfad belegen?
Ausgewählte Quellenbasis
- Regulation (EU) 2022/2554, Digital Operational Resilience Act, especially Articles 28, 29 and 30.
- European Supervisory Authorities, designation of critical ICT third-party providers under DORA, 18 November 2025.
- ESMA, official list of designated CTPPs under Article 31(9) of DORA.
- ECB Banking Supervision, Supervisory Priorities 2026–28.
- ESAs, Guide on DORA oversight activities, JC 2025 29.
- BCBS, Principles for Operational Resilience, 2021.
- FSB, Enhancing Third-Party Risk Management and Oversight, 2023.
- NIST Cybersecurity Framework 2.0.
- ISO 22301 Business Continuity Management.
Experten-Kommentar — 7 Min. Lesezeit
ICT-Drittparteienresilienz wird häufig über Verträge, Outsourcing-Register und Provider-Oversight diskutiert. Diese Elemente sind wichtig. Aber sie beantworten nicht die praktischste Frage des Boards.
Was steht still — und wie lange?
Diese Frage ist bewusst operativ. Sie übersetzt DORA aus regulatorischem Text in Board-Level-Managementrealität. Ein kritischer ICT-Provider kann eine Cloud-Umgebung, eine Workflow Engine, eine Reporting-Schicht, eine Cybersecurity-Fähigkeit, einen Datendienst, einen Marktdatenfeed, eine Dokumentenplattform oder einen KI-gestützten Prozess unterstützen. Der Provider muss für Kunden nicht sichtbar sein. Die Abhängigkeit kann trotzdem kritisch sein.
DORA macht den Verantwortlichkeitspunkt ausdrücklich. Finanzunternehmen, die ICT-Services nutzen, bleiben für die Einhaltung ihrer Pflichten verantwortlich, und ICT-Drittparteienrisiko muss als Teil des ICT-Risk-Management-Frameworks gesteuert werden. DORA verlangt außerdem, dass Finanzunternehmen ein Register of Information führen und aktualisieren, das alle vertraglichen Arrangements über die Nutzung von ICT-Services durch ICT-Drittanbieter erfasst.
Sichtbarkeit
Damit wird Sichtbarkeit zur ersten Disziplin.
Ein Board kann keine Abhängigkeit beaufsichtigen, die es nicht sieht. Eine Bank kann keine Provider-Kette steuern, die sie nicht gemappt hat. Und sie kann „wie lange" nicht beantworten, ohne ein getestetes Recovery Objective, das mit einer spezifischen kritischen oder wichtigen Funktion verbunden ist.
Konzentration
Die zweite Disziplin ist Konzentration.
DORA verlangt, dass Finanzunternehmen Konzentrationsrisiko berücksichtigen, wenn sie Arrangements für ICT-Services eingehen, die kritische oder wichtige Funktionen unterstützen. Dazu gehört, ob ein Provider nicht leicht substituierbar ist oder ob mehrere Arrangements Abhängigkeiten vom selben oder eng verbundenen Providern schaffen.
Das ist wichtig, weil Diversifikation irreführend sein kann.
Zwei Provider können auf Vertragsebene unabhängig erscheinen, aber auf Cloud-, Rechenzentrums-, Netzwerk-, Identity-, DNS-, Software-, Subcontracting- oder operativen Support-Schichten zusammenlaufen. Eine boardfähige Antwort endet daher nicht bei „wir haben mehr als einen Provider". Sie fragt, ob die Ausfallmodi tatsächlich unabhängig sind.
Exit-Fähigkeit
Die dritte Disziplin ist Exit-Fähigkeit.
DORA verlangt Exit-Strategien für ICT-Services, die kritische oder wichtige Funktionen unterstützen; diese Exit-Pläne müssen umfassend, dokumentiert, ausreichend getestet und regelmäßig überprüft sein. DORA verlangt außerdem schriftliche vertragliche Arrangements, die Rechte und Pflichten zuweisen, einschließlich Regelungen zu Zugang, Recovery, Rückgabe von Daten, Kündigung und Exit.
Genau hier klingen schwache Antworten oft plausibel.
Und direkte Aufsicht über einen kritischen Provider ersetzt nicht das eigene Third-Party-Risk-Management des Instituts. Die ECB Supervisory Priorities 2026–28 erklären, dass DORA-Anforderungen, insbesondere ICT-Drittparteienrisiko und Incident Response Management, konsistent und zügig umgesetzt werden müssen. Sie stellen außerdem klar, dass das DORA-Oversight-Framework für kritische Drittanbieter solides Third-Party-Risk-Management ergänzt, aber nicht ersetzt.
Die praktische Board-Frage lautet daher nicht, ob der Provider stark ist.
Sie lautet, ob das Institut gegenüber einem Provider-Ausfall resilient ist.
Das verlangt eine andere Antwortstruktur. Das Board sollte eine Abhängigkeitskarte, eine Kritikalitätssicht, eine Konzentrationsbewertung, ein Recovery Objective, einen getesteten Exit-Pfad, vertragliche Evidenz und ein Dashboard zum verbleibenden Risiko sehen. Es sollte auch sehen, wo Substitution nicht realistisch ist. In diesen Fällen muss Resilienz aus Continuity Arrangements, Contingency Planning, vertraglichem Schutz, Monitoring und formaler Akzeptanz verbleibender Risiken entstehen.
Das Ziel ist nicht, jede Abhängigkeit zu eliminieren.
Das wäre unrealistisch.
Das Ziel ist zu wissen, welche Abhängigkeiten zählen, was bei ihrem Ausfall bricht, wie lange Recovery dauert, wer die Reaktion verantwortet und welche Evidenz die Antwort trägt.
Ein beaufsichtigter Provider ist nicht dasselbe wie ein resilientes Institut.
Resilienz beginnt, wenn das Board die Frage stellen kann — und eine Antwort erhält, die gemappt, getestet und steuerbar ist.