DORA-konforme Verträge mit IT-Dienstleistern (Art. 28 ff.)
DORA-Vertragsgestaltung bezeichnet die Pflicht von Finanzunternehmen, Verträge mit IT- und KI-Dienstleistern nach Art. 28 ff. der Verordnung (EU) 2022/2554 (DORA) mit verbindlichen Klauseln auszustatten: Leistungsbeschreibung, Datenstandorte, Audit-Rechte, Exit/Kündigung, Regeln zum Sub-Outsourcing, Vorfallsmeldung und Service-Level. DORA ist seit 17. Januar 2025 anwendbar.
Auf einen Blick
- DORA (VO (EU) 2022/2554) ist seit 17. Januar 2025 anwendbar; Art. 28-30 regeln das IKT-Drittparteienrisiko, Art. 30 enthält den verbindlichen Vertragsklauselkanon (primäre Adressaten der BaFin-Orientierungshilfe sind CRR-Institute und Solvency-II-Versicherer).
- Der Pflichtumfang hängt davon ab, ob der Dienstleister eine kritische oder wichtige Funktion unterstützt: Bei kritischen/wichtigen Funktionen gelten die vollen Art.-30-Klauseln inklusive Exit-Strategie, vollständiger Audit-Rechte und SLA mit messbaren Zielen.
- Pflicht-Klauseln umfassen Leistungsbeschreibung, Datenstandorte/Datenverarbeitungsorte, Audit- und Zugangsrechte, Kündigungs- und Exit-Regelungen, Regeln zum Sub-Outsourcing, Vorfallsmeldung und kooperationspflichtige Sicherheitsmaßnahmen.
- Die ESAs haben am 18. November 2025 erstmals 19 kritische IKT-Drittdienstleister (CTPPs) benannt (u. a. AWS, Microsoft, Google Cloud, Oracle, IBM, SAP, Deutsche Telekom, Equinix, Accenture und Bloomberg). Exit-Pläne für kritische oder wichtige Funktionen müssen ausreichend getestet und regelmäßig überprüft werden; Multi-Cloud schreibt DORA nicht vor.
- Bei Hyperscalern ist der Art.-30-Klauseltext Stand 2026 weitgehend Standard; bei KI-Startups ohne diese Klauseln ist die Vertragsfähigkeit ein häufiger Procurement-Blocker. KI-Systeme gelten laut BaFin-Orientierungshilfe vom 18. Dezember 2025 als Netzwerk- und Informationssysteme nach DORA Art. 3 Nr. 2.
DORA-Vertragsgestaltung bezeichnet die Pflicht von Finanzunternehmen, Verträge mit IT- und KI-Dienstleistern nach Art. 28 ff. der Verordnung (EU) 2022/2554 (DORA) mit verbindlichen Klauseln auszustatten: Leistungsbeschreibung, Datenstandorte, Audit-Rechte, Exit/Kündigung, Regeln zum Sub-Outsourcing, Vorfallsmeldung und Service-Level. DORA ist seit 17. Januar 2025 anwendbar und adressiert in der BaFin-Aufsichtspraxis primär CRR-Institute und Solvency-II-Versicherer.
- Wer ist betroffen? Finanzunternehmen im DORA-Anwendungsbereich (Banken, Versicherer und weitere Finanzentitäten) sowie deren IT-/KI-Dienstleister, die ohne die Pflichtklauseln nicht vertragsfähig sind.
- Was ist der Kern? Art. 28-30 regeln das IKT-Drittparteienrisiko; Art. 30 enthält den verbindlichen Klauselkanon. Der Umfang skaliert mit der Kritikalität der ausgelagerten Funktion.
- Was ist der häufigste Stolperstein? Bei Hyperscalern ist der Klauseltext Stand 2026 Standard; bei KI-Startups fehlen Audit-Rechte, Exit- und Sub-Outsourcing-Klauseln und werden zum Procurement-Blocker.
Warum KI-Dienstleister unter DORA fallen
Die zentrale Weichenstellung für KI-Projekte: KI-Systeme sind kein Sonderfall, sondern ein Unterfall der „Netzwerk- und Informationssysteme“ gemäß Art. 3 Nr. 2 DORA. Die BaFin-Orientierungshilfe zu IKT-Risiken beim Einsatz von KI in Finanzunternehmen vom 18. Dezember 2025 stellt das ausdrücklich klar und zieht damit den vollständigen DORA-Pflichtenkanon in die KI-Governance: Art. 5-15 (IKT-Risikomanagement), Art. 24-27 (Resilienztests einschließlich Threat-Led Penetration Testing) und Art. 28-30 (IKT-Drittparteienrisiko). Adressaten sind primär CRR-Institute und Solvency-II-Versicherer.
Für die Schweiz besteht ein analoges, nicht voll deckungsgleiches Regime: Die FINMA-Aufsichtsmitteilung 08/2024 vom 18. Dezember 2024 und das FINMA-Rundschreiben 2023/1 (Operationelle Risiken und Resilienz) prägen die Erwartungen an externe IKT-Lieferanten. Für Österreich ist uns Stand Oktober 2026 keine sektorale KI-Leitlinie der FMA bekannt, die der BaFin-Orientierungshilfe entspricht. Bei der Vorstellung ihres Jahresberichts 2025 im Juni 2026 nannte die FMA die Anwendung von KI im Finanzsektor und die kommende Aufsicht darüber als Schwerpunkt des laufenden Jahres. Österreichische Institute orientieren sich überwiegend an BaFin und EBA. DORA selbst gilt als EU-Verordnung in Deutschland und Österreich unmittelbar.
Eine wichtige Einordnung vorweg: Dieser Artikel ist eine fachliche Orientierung, keine Rechtsberatung. Mustervertragsklauseln und ihre Übertragung auf den konkreten Einzelfall sind anwaltlich zu prüfen.
Der Klauselkanon nach Art. 30 DORA
Art. 30 DORA verlangt, dass die Rechte und Pflichten des Finanzunternehmens und des IKT-Drittdienstleisters klar zugewiesen und schriftlich fixiert werden. Die Verordnung trennt dabei zwei Stufen: einen Mindestumfang für alle IKT-Verträge (Art. 30 Abs. 2) und einen erweiterten Katalog für Dienste, die eine kritische oder wichtige Funktion unterstützen (Art. 30 Abs. 3).
Der Klauselkanon umfasst nach der DORA-Systematik insbesondere verpflichtende Audit-Rechte, Exit-Klauseln, Sub-Processor-Kontrollen, Festlegungen zu Datenstandorten und Service-Level-Vereinbarungen mit präzisen quantitativen und qualitativen Leistungszielen; bei KI-Diensten gehören dazu in der Praxis oft Latenz- und Kapazitätszusagen. Bei Hyperscalern ist dieser Text aktuell Standard; bei KI-Startups ist er ein häufiger Procurement-Blocker. Hintergrund: DORA hat die früheren EBA Outsourcing Guidelines (EBA/GL/2019/02) sowie die ESMA-Outsourcing-Guidelines (ESMA50-164-4285) substantiell modifiziert und in einen unmittelbar geltenden Verordnungsstandard überführt.
Einfache versus kritische/wichtige Funktionen
Die Pflichttiefe hängt davon ab, ob der ausgelagerte IKT-Dienst eine kritische oder wichtige Funktion unterstützt, also eine Funktion, deren Ausfall die finanzielle Belastbarkeit, die Kontinuität der Dienstleistungen oder die Einhaltung der Zulassungsbedingungen des Instituts wesentlich beeinträchtigen würde. Diese Klassifizierung ist die erste Aufgabe jeder DORA-Vertragsgestaltung und entscheidet über den Vertragsumfang.
Für einen KI-Dienst lautet die Leitfrage konkret: Greift der Agent in einen kritischen Prozess ein (z. B. Echtzeit-Betrugserkennung im Zahlungsverkehr, regulatorisches Reporting) oder unterstützt er nur einen nachgelagerten, leicht ersetzbaren Hilfsprozess (z. B. interne Texterstellung ohne Kundendatenbezug)? Bei kritischen/wichtigen Funktionen greifen die zusätzlichen Anforderungen des Art. 30 Abs. 3: dokumentierte Exit-Strategien, uneingeschränkte Zugangs-, Inspektions- und Prüfrechte, SLA mit präzisen quantitativen und qualitativen Leistungszielen sowie die Mitwirkung an TLPT. Die Datenstandorte sind dagegen schon nach Art. 30 Abs. 2 lit. b in jedem IKT-Vertrag festzulegen.
Pflicht-Klauseln im Überblick
Die folgende Tabelle ordnet die zentralen Vertragsbestandteile ihrem Zweck zu und kennzeichnet, ob sie für alle IKT-Verträge oder verschärft für kritische/wichtige Funktionen gelten. Die Artikelzuordnung folgt der DORA-Systematik (Art. 30 Abs. 2 für den Mindestumfang, Art. 30 Abs. 3 für kritische/wichtige Funktionen).
Klausel | Zweck | Pflicht? |
|---|---|---|
Leistungsbeschreibung (Scope, Funktionen, Service-Levels) | Klare, vollständige Beschreibung aller IKT-Dienste; Grundlage für Steuerung und Audit | Pflicht (alle Verträge, Art. 30 Abs. 2) |
Datenstandorte / Datenverarbeitungsorte | Festlegung, wo Daten gespeichert und verarbeitet werden; Steuerung von Residenz und Zugriff | Pflicht (alle Verträge, Art. 30 Abs. 2 lit. b) |
Audit- und Zugangsrechte | Vor-Ort-Prüfungen und Inspektionen durch Institut, Prüfer und Aufsicht | Pflicht; uneingeschränkt bei kritisch/wichtig (Art. 30 Abs. 3) |
Kündigung und Exit-Strategie | Geordnete Beendigung ohne Unterbrechung kritischer Funktionen; Datenrückgabe, Migration | Pflicht; dokumentierte Exit-Strategie bei kritisch/wichtig (Art. 30 Abs. 3) |
Regeln zum Sub-Outsourcing | Kontrolle über Unterauftragnehmer, die kritische/wichtige Funktionen mitausführen | Pflicht (alle Verträge): Angabe, ob und unter welchen Bedingungen Unterauftragsvergabe bei kritisch/wichtig erlaubt ist (Art. 30 Abs. 2 lit. a) |
Incident-Meldung | Verpflichtung zur Meldung von IKT-Vorfällen, damit das Institut Art.-19-Fristen einhält | Pflicht (Art. 30 i. V. m. Art. 19) |
SLA mit Verfügbarkeits-/Sicherheitszielen | Messbare quantitative und qualitative Leistungsziele, Monitoring, Reporting | Pflicht; präzise Zielwerte bei kritisch/wichtig (Art. 30 Abs. 3) |
Mitwirkung bei Resilienztests / TLPT | Teilnahme und volle Mitwirkung am TLPT des Instituts nach Art. 26 und 27 | Pflicht bei kritisch/wichtig (Art. 30 Abs. 3 lit. d) |
Konzentrationsrisiko und CTPP-Designation
DORA regelt neben dem einzelnen Vertrag auch das systemische Konzentrationsrisiko. Die Europäischen Aufsichtsbehörden (ESAs) haben am 18. November 2025 erstmals 19 kritische IKT-Drittdienstleister (Critical ICT Third-Party Providers, CTPPs) benannt, darunter AWS, Microsoft, Google Cloud, Oracle, IBM, SAP, Deutsche Telekom, Equinix, Accenture und Bloomberg. Seitdem unterliegen diese Anbieter der direkten EU-Aufsicht. Für jeden CTPP führt ein Lead Overseer (EBA, EIOPA oder ESMA) die Aufsicht, mit allgemeinen Untersuchungen und Vor-Ort-Inspektionen, unterstützt von einem gemeinsamen Prüfteam (Art. 33 und 38 bis 40 DORA). Das Oversight Forum nach Art. 32 bereitet gemeinsame Positionen vor und unterstützt den Lead Overseer; Prüfungen führt es nicht selbst durch.
Für die Vertragsgestaltung auf Institutsseite zählt vor allem die Exit-Planung, unabhängig davon, ob der Anbieter als CTPP benannt ist: Nach Art. 28 Abs. 8 DORA müssen Exit-Pläne für kritische oder wichtige Funktionen umfassend und dokumentiert sein sowie ausreichend getestet und regelmäßig überprüft werden. Einen festen Jahresturnus schreibt die Verordnung nicht vor. Dazu kommt nach Art. 29 die Bewertung des Konzentrationsrisikos, bevor ein Vertrag über solche Funktionen geschlossen wird. Multi-Cloud verlangt DORA nicht. Offen ist Stand 2026, ob Institute wegen der Exit- und Konzentrationspflichten trotzdem systematisch auf Multi-Cloud umstellen oder es bei eher symbolischen Exit-Plänen bleibt. Eine vollständige Multi-Cloud-KI-Architektur ist für Banken technisch und kommerziell anspruchsvoll. In der DACH-Praxis ergibt sich daraus ein präferiertes Sourcing-Muster: souveräne oder On-Premise-Lösungen für sensitive Workloads, Hyperscaler dort, wo das CTPP-Konzentrationsrisiko aktiv gemanagt wird.
Praxisbeispiel: KI-gestützte Betrugserkennung einbinden
Eine Bank (CRR-Institut) möchte einen KI-Agenten eines Drittanbieters für die Echtzeit-Betrugserkennung im Zahlungsverkehr einsetzen. Die Schritte einer DORA-konformen Vertragsgestaltung lassen sich wie folgt skizzieren:
- Klassifizierung: Die Betrugserkennung ist eine kritische oder wichtige Funktion, weil ihr Ausfall die Kontinuität der Dienstleistung wesentlich beeinträchtigt. Damit gilt der erweiterte Katalog des Art. 30 Abs. 3.
- Leistungsbeschreibung und SLA: Der Vertrag fixiert Funktionsumfang, Verfügbarkeit und messbare Zielwerte. Bei der Betrugserkennung gehören dazu etwa die maximale Antwortzeit pro Transaktion und Kennzahlen zur Erkennungsqualität wie die Falsch-Positiv-Rate.
- Datenstandorte: Festlegung, dass Trainings- und Inferenzdaten innerhalb der EU verarbeitet werden.
- Audit-Rechte und Sub-Outsourcing: Uneingeschränkte Prüfrechte für Institut und Aufsicht; jeder Unterauftragnehmer, der die kritische Funktion mitausführt, unterliegt einem vertraglichen Zustimmungsvorbehalt.
- Incident-Meldung: Der Anbieter wird vertraglich verpflichtet, IKT-Vorfälle so unverzüglich zu melden, dass die Bank ihre DORA-Art.-19-Meldepflicht erfüllen kann. Zur Einordnung der Relevanz: In den ersten drei Quartalen 2025 wurden der BaFin 525 schwerwiegende IKT-Vorfälle gemeldet, rund 70 Prozent davon von Kreditinstituten.
- Exit: Dokumentierte Exit-Strategie mit Datenrückgabe in nutzbarem Format und Migrationsunterstützung; der Exit-Plan wird ausreichend getestet und regelmäßig überprüft, wie es Art. 28 Abs. 8 DORA verlangt.
Hinzu kommt die Schnittstelle zum EU AI Act: Für Finanzunternehmen substituiert die DORA-Vorfallsmeldung nach Art. 19 die Meldepflicht nach Art. 73 AI Act, mit Ausnahme der Meldung von Grundrechtsverletzungen. Doppelmeldungen lassen sich so vermeiden, wenn die Workflows aufeinander abgestimmt sind.
Für Agenturen und B2B
Für Marketing-Agenturen und B2B-Dienstleister, die KI-Lösungen an Banken oder Versicherer verkaufen, ist die Botschaft eindeutig: Ohne den Art.-30-Klauselkanon scheitert die Vendor-Auswahl regelmäßig in der finalen Runde. Wer Audit-Rechte, Exit- und Sub-Outsourcing-Klauseln, Datenstandort-Zusagen und eine belastbare Incident-Meldekette von Beginn an im Standardvertrag mitliefert, verkürzt das Procurement und qualifiziert sich überhaupt erst für regulierte Auftraggeber. Für B2B-Entscheider auf Institutsseite empfiehlt sich, die Kritikalitätsklassifizierung als ersten Schritt zu standardisieren und die Vertragsklauseln daran zu skalieren. Blck Alpaca begleitet die inhaltliche und kommunikative Aufbereitung solcher Compliance-Themen und die technische KI-Agent-Integration; die juristische Prüfung der konkreten Verträge bleibt anwaltliche Aufgabe.
Öffnet den Chat mit einem vorbereiteten Prompt.
Häufig gestellte Fragen
Für wen gelten die DORA-Vertragspflichten nach Art. 28 ff.?
Was ist der Unterschied zwischen einfachen und kritischen oder wichtigen Funktionen?
Sind Standard-Cloud-Verträge der Hyperscaler bereits DORA-konform?
Was muss eine DORA-konforme Exit-Klausel leisten?
Ersetzt die DORA-Vorfallsmeldung andere Meldepflichten?
Tiefer einsteigen?
Erhalte neue Analysen direkt ins Postfach, oder sieh dir an, wie wir dieses Wissen für Unternehmen umsetzen.