Management des IKT-Drittparteienrisikos unter DORA

Problem in der Praxis

In vielen Häusern ist die Sicht auf die IKT-Dienstleister historisch verteilt: Register in der Compliance, Verträge im Einkauf, technische Abhängigkeiten in der IT, Cloud-Verträge teils direkt in den Fachbereichen. Niemand kann auf Knopfdruck sagen, welche Dienstleister welche kritischen Funktionen stützen und welche Unterauftragnehmer dahinterstehen.

Den ersten harten Prüfstein lieferte das Register der Informationen. Zum 30.04.2025 mussten die zuständigen Behörden es erstmals an die Europäischen Aufsichtsbehörden (ESAs) übermitteln; die Finanzunternehmen lieferten zuvor an die nationale Behörde, wobei die nationalen Termine teils früher lagen und national zu prüfen sind. Das eigentliche Problem ist selten der Stichtag, sondern dass ein Register nur so gut ist wie der Prozess dahinter: einmalig befüllt veraltet es sofort.

CISO-Einordnung

DORA regelt das Drittparteienrisiko in Kapitel V der Verordnung (EU) 2022/2554 (Säule 4). Zwei Logiken sind zu trennen:

• Pflichten des Finanzunternehmens: Grundsätze des Managements von IKT-Drittparteienrisiko, das Register der Informationen über alle IKT-Dienstverträge sowie verpflichtende Mindest- und Schlüsselvertragsbestimmungen, einschließlich der Bewertung des Konzentrationsrisikos vor wesentlichen Abhängigkeiten.
• EU-Aufsicht über kritische Anbieter: Die ESAs benennen kritische IKT-Drittdienstleister (CTPPs) und stellen sie unter einen direkten Aufsichtsrahmen mit einem führenden Aufseher (Lead Overseer aus EBA, ESMA oder EIOPA) mit Auskunfts-, Untersuchungs- und Empfehlungsbefugnissen.

Das Finanzunternehmen bleibt für Auswahl, Steuerung und Ausstieg verantwortlich, auch wenn ein Anbieter zentral beaufsichtigt wird; die EU-Aufsicht ersetzt die eigene Risikobehandlung nicht, sie ergänzt sie. Am 18.11.2025 wurde die erste Liste kritischer Anbieter veröffentlicht (19 Anbieter, darunter große Cloud- und Software-Anbieter); die Zuordnung einzelner Anbieter ist im Einzelfall zu prüfen. Konzentrationsrisiko entsteht nicht nur bei vielen Funktionen auf einem Anbieter, sondern auch indirekt, wenn verschiedene Dienstleister denselben Hyperscaler oder dieselbe Region nutzen. Solche verdeckten Klumpen sind ohne Register und ohne Blick auf Unterauftragnehmer kaum sichtbar.

Umsetzungsperspektive

Der CISO sollte das Drittparteienmanagement als laufenden Regelkreis aufsetzen, nicht als jährliche Meldeübung:

• Datenbasis: ein gepflegtes Register der Informationen als zentrale Quelle, gespeist aus Vertrags-, Einkaufs- und Architekturdaten, mit eindeutiger Anbieteridentifikation und Zuordnung zu kritischen Funktionen.
• Vertragslebenszyklus: systematische Prüfung der Schlüsselvertragsbestimmungen bei Abschluss und Verlängerung; konzeptionell betrifft das Leistungsbeschreibung, Zugriffs-, Prüf- und Auditrechte, Datenstandorte, Sicherheits- und Incident-Mitwirkung, Regelungen zu Unterauftragnehmern sowie Ausstiegs- und Kündigungsrechte. Die Pflichtinhalte sind dem Verordnungstext und den technischen Standards zu entnehmen.
• Risikobewertung: Konzentrations- und Substituierbarkeitsanalyse vor Vertragsabschluss, mit Augenmerk auf schwer ersetzbare Anbieter.
• Exit-Fähigkeit: getestete, nicht nur dokumentierte Ausstiegsstrategien inklusive Datenrückführung und Übergang.

Typische Fehler

1. Das Register wird als einmalige Meldepflicht zum Stichtag behandelt statt als dauerhaft gepflegte Datenbasis.
2. Unterauftragnehmer werden ausgeblendet, wodurch das Konzentrationsrisiko systematisch unterschätzt wird.
3. Schlüsselvertragsbestimmungen werden nur bei Neuverträgen beachtet, Bestandsverträge bleiben unangepasst.
4. Ausstiegsstrategien existieren auf Papier, sind aber nie getestet und im Ernstfall nicht belastbar.
5. Die Benennung eines Anbieters als kritisch wird als Entlastung missverstanden statt die eigene Risikobehandlung fortzuführen.
6. Drittparteienrisiko bleibt im Einkauf, ohne Verzahnung mit IKT-Risikomanagement, Incident-Prozess und Resilienztests.

Risiken und Trade-offs

Zentralisierung auf wenige starke Anbieter senkt Kosten und kann das Sicherheitsniveau heben, erhöht aber das Konzentrationsrisiko. Multi-Provider-Strategien verringern Klumpenrisiken, erzeugen jedoch Komplexität, höhere Steuerungskosten und neue Schnittstellenrisiken. Diesen Zielkonflikt muss das Management bewusst entscheiden.

Auch die Tiefe des Registers ist ein Trade-off: sehr granular liefert maximale Transparenz, ist aber pflegeintensiv; zu grob erfüllt formal die Pflicht, taugt aber nicht zur Steuerung. Maßstab ist die Angemessenheit nach Größe, Risikoprofil und Komplexität im Sinne der Proportionalität, die DORA durchgängig vorsieht. Marktstarke Anbieter setzen Schlüsselvertragsbestimmungen zudem nicht immer ohne Weiteres um; der CISO muss früh klären, welche Klauseln nicht verhandelbar sind.

Entscheidungspunkte

• Welche Funktionen gelten als kritisch oder wichtig, und welche Dienstleister stützen sie unmittelbar oder mittelbar?
• Wie wird Konzentrationsrisiko definiert, und ab welcher Schwelle löst es Eskalation oder eine Multi-Provider-Entscheidung aus?
• Wer ist Owner des Registers, und aus welchen Quellsystemen wird es verlässlich gespeist?
• Welche Schlüsselvertragsbestimmungen sind nicht verhandelbar, und welche Bestandsverträge müssen nachgezogen werden?
• Welche Ausstiegsszenarien werden tatsächlich getestet, und mit welcher Taktung?

Praktische Empfehlungen

1. Betreiben Sie das Register der Informationen als lebende Datenbasis mit klarem Owner, fester Taktung und eindeutiger Anbieteridentifikation.
2. Erfassen Sie Unterauftragnehmer und gemeinsame Abhängigkeiten, um verdeckte Konzentrationsrisiken sichtbar zu machen.
3. Verankern Sie die Prüfung der Schlüsselvertragsbestimmungen fest im Vertragslebenszyklus, für Neu- und Bestandsverträge.
4. Verzahnen Sie das Drittparteienmanagement mit IKT-Risikomanagement, Incident-Meldung und Resilienztests statt es im Einkauf zu isolieren.
5. Testen Sie Ausstiegs- und Übergangsszenarien für die wichtigsten Anbieter regelmäßig statt sie nur zu dokumentieren.
6. Nutzen Sie vorhandene ISMS-Strukturen (Lieferantenmanagement, Risikobehandlung, BCM) als Basis und ergänzen Sie die DORA-Spezifika.

Relevante Normreferenzen

• DORA, Verordnung (EU) 2022/2554, insbesondere Kapitel V (IKT-Drittparteienrisiko, Säule 4): unmittelbar geltendes EU-Recht; Grundsätze, Register der Informationen, Schlüsselvertragsbestimmungen und Aufsichtsrahmen für kritische Anbieter.
• RTS/ITS der ESAs zu DORA, u. a. zum Register der Informationen und zu Unterauftragnehmern: Level-2-Recht, für verbindliche Details maßgeblich.
• ISO/IEC 27001 (Lieferanten-/Drittparteienmanagement, Risikobehandlung): nutzbar als Umsetzungsrahmen, kein Ersatz für DORA-Pflichten.
• NIS2 (Richtlinie (EU) 2022/2555), Lieferketten- und Risikomanagementbezug: DORA ist für Finanzunternehmen lex specialis und geht insoweit vor.
• NIST Cybersecurity Framework als Outcome- und Control-Bezugsrahmen (Mapping möglich, nicht normativ).