Artikel vom 24. Februar 2026
DORA-Compliance: ICT-Drittanbieter bewerten und managen
1. Was DORA zu ICT-Drittanbietern konkret fordert (Art. 28 bis 44) #
unterscheidet sich von früheren Anforderungen wie BAIT oder MaRisk dadurch, dass es ICT-Drittanbieter direkt reguliert, nicht nur die Finanzinstitute, die sie nutzen. Der regulatorische Druck wirkt in beide Richtungen.
Der Regelungsrahmen im Überblick #
- Art. 28 Abs. 3: Informationsregister über alle vertraglichen Vereinbarungen mit ICT-Drittanbietern
- Art. 28 Abs. 4 und 5: Risikobewertung vor Vertragsabschluss, insbesondere bei Diensten für kritische oder wichtige Funktionen
- Art. 28 Abs. 8: Exit-Strategien für ICT-Dienste, die kritische oder wichtige Funktionen unterstützen
- Art. 30: Mindestanforderungen an Vertragsklauseln
- Art. 31: Einstufung kritischer ICT-Drittdienstleister durch die europäischen Aufsichtsbehörden (ESAs)
- Art. 32 bis 44: Überwachungsrahmen für kritische ICT-Drittdienstleister unter direkter ESA-Aufsicht (EBA, EIOPA, ESMA)
Für die operative Umsetzung in IT-Abteilungen und Compliance-Teams sind vor allem Art. 28 und 30 relevant. Die ESA-Direktaufsicht betrifft die Anbieter selbst (zum Beispiel große Cloud-Provider). Finanzinstitute müssen aber wissen und dokumentieren, ob ihre Anbieter als kritische ICT-Drittdienstleister eingestuft sind.
2. Kritische oder wichtige Funktionen: Die Unterscheidung, die alles verändert #
knüpft die strengsten Pflichten nicht an den Anbieter als solchen, sondern an die Frage, ob ein ICT-Dienst eine kritische oder wichtige Funktion des Finanzunternehmens unterstützt. Diese Einstufung bestimmt den Aufwand für Vertragsgestaltung, Monitoring und Exit-Planung.
Kritische ICT-Drittdienstleister (Einstufung durch die ESAs) #
Daneben gibt es die Einstufung auf Anbieterebene: Ein Anbieter gilt als kritischer ICT-Drittdienstleister, wenn ein Ausfall oder eine Beeinträchtigung seiner Leistung zu einem systemischen Risiko für den Finanzsektor führen kann. Diese Einstufung erfolgt durch die europäischen Aufsichtsbehörden nach Art. 31. Betroffene Anbieter unterliegen dann der direkten ESA-Aufsicht, unabhängig von ihrer Rechtsform oder ihrem Hauptsitz.
Für Finanzinstitute bedeutet das: Prüfen Sie, ob Ihre Cloud-Backup-Provider auf den ESA-Listen kritischer ICT-Drittdienstleister erscheinen, und dokumentieren Sie das Ergebnis im Register.
Dienste für kritische oder wichtige Funktionen des Instituts #
Unabhängig von der ESA-Einstufung gilt: Unterstützt ein ICT-Dienst eine kritische oder wichtige Funktion Ihres Unternehmens, greifen die verschärften Anforderungen an Verträge (Art. 30 Abs. 3), Risikobewertung und Exit-Strategie.
Für Backup-Provider: Ein Anbieter, der Ihre primäre Datensicherung oder Ihr Disaster Recovery bereitstellt, unterstützt nach -Logik nahezu immer eine kritische oder wichtige Funktion, da der Ausfall dieser Funktion Ihre operative Resilienz direkt beeinträchtigt.
Konsequenz: Identifizieren Sie alle ICT-Drittanbieter, die an Backup, Archivierung oder Disaster Recovery beteiligt sind, und stufen Sie die bezogenen Dienste ein. Das Ergebnis dokumentieren Sie im Informationsregister.
3. ICT-Drittanbieter-Register aufbauen: Schritt für Schritt #
Das Informationsregister ist die Grundlage jeder -Prüfung. Ohne vollständiges und aktuelles Register haben Sie keine Compliance, unabhängig davon, wie gut Ihre Einzelverträge sind.
Schritt 1: Bestandsaufnahme #
Erfassen Sie alle ICT-Dienstleister, die für Ihren Betrieb relevant sind. Starten Sie mit den Kategorien:
- Cloud-Infrastruktur und Hosting (IaaS, PaaS)
- Software as a Service (SaaS), Kern- und Nebensysteme
- Backup und Disaster Recovery (intern und extern bereitgestellt)
- Netzwerk- und Telekommunikationsanbieter
- IT-Sicherheitsdienstleister (SOC, SIEM, E)
- Wartungs- und Support-Dienstleister für Hardware
- Rechenzentrum-Colocation
Typischer Fehler: Nur die großen Verträge erfassen und spezialisierte Nischenanbieter übersehen, zum Beispiel den Backup-Software-Hersteller, dessen Agent auf jedem Server läuft, oder den Hardware-Wartungsanbieter mit Remote-Zugang zu Storage-Systemen.
Schritt 2: Mindest-Datenfelder pro Anbieter #
Art. 28 Abs. 3 verlangt ein Informationsregister auf Ebene der vertraglichen Vereinbarungen; die technischen Durchführungsstandards der ESAs definieren die Pflichtfelder. Erfassen Sie mindestens:
- Name des Anbieters (Pflicht): vollständiger rechtlicher Name
- Art der bezogenen Dienste (Pflicht): welche ICT-Funktion wird erbracht?
- Unterstützte Geschäftsfunktionen (Pflicht): welche kritischen oder wichtigen Funktionen sind abhängig?
- Einstufung (Pflicht): unterstützt der Dienst eine kritische oder wichtige Funktion?
- Land des Anbieters (Pflicht): Hauptsitz, relevant für Rechtsrahmen und Datenschutz
- Unterauftragnehmer (Pflicht): relevante Sub-Dienstleister des Anbieters
- Vertragsbeginn und Laufzeit (Pflicht): mit Kündigungsfristen
- SLA-Kennzahlen (empfohlen): Verfügbarkeit, RTO, RPO
- Auditrechte vertraglich vereinbart (empfohlen): ja oder nein
- Exit-Strategie vorhanden (empfohlen): Referenz auf das Exit-Plan-Dokument
- Letztes Review-Datum (empfohlen): wann wurde der Anbieter zuletzt bewertet?
Schritt 3: Priorisierung und Pflege #
Führen Sie das Register in einem System, das Versionierung und Änderungshistorie unterstützt. Aktualisieren Sie es mindestens jährlich sowie anlassbezogen bei:
- Neuverträgen oder wesentlichen Vertragsänderungen
- Sicherheitsvorfällen beim Anbieter
- Übernahmen oder Insolvenzen im Anbieterumfeld
- Änderung der eigenen Systemlandschaft
4. Vertragsanforderungen nach DORA Art. 30: Was muss drin stehen? #
Art. 30 ist die detaillierteste Vertragsvorschrift, die der europäische Finanzsektor je bekommen hat. Prüfen Sie bestehende Verträge gegen diese Anforderungen und fordern Sie Ergänzungen, wo sie fehlen.
Pflichtinhalte nach Art. 30 Abs. 2 und 3 DORA #
Beschreibung der Dienste: Der Vertrag muss eine vollständige Beschreibung der ICT-Dienste enthalten, einschließlich der Unterauftragnehmer, die wesentliche Teile der Leistung erbringen.
Standorte der Datenverarbeitung: Wo werden Ihre Daten verarbeitet und gespeichert? Das muss vertraglich fixiert sein, inklusive der Verpflichtung, Standortänderungen vorab zu kommunizieren.
Datenzugang und Datenrückgabe: Der Vertrag muss regeln, wie Sie im Krisenfall, bei Insolvenz des Anbieters oder bei Vertragsende vollständigen Zugang zu Ihren Daten erhalten und diese in einem gängigen Format zurückerhalten.
Verfügbarkeitsgarantien und Leistungsniveaus: SLAs sind kein Nice-to-have, sie sind -Pflicht. Definieren Sie RTO und RPO vertraglich für alle kritischen Funktionen.
Auditrechte: Sie müssen das Recht haben, den Anbieter selbst oder durch Dritte zu auditieren. Ein Vertrag ohne Auditrecht für Dienste mit kritischen oder wichtigen Funktionen ist nicht -konform.
Kooperationspflichten: Der Anbieter muss mit Ihrer zuständigen Aufsichtsbehörde kooperieren, wenn diese Informationen anfordert.
Kündigungsrechte: Definierte Kündigungsgründe, auch bei regulatorisch bedingten Beendigungen, und angemessene Kündigungsfristen.
Exit-Unterstützung: Der Anbieter muss bei der Beendigung des Vertragsverhältnisses aktiv unterstützen: Datenmigration, Wissenstransfer, paralleler Betrieb während der Transition.
Prüfliste für bestehende Verträge #
Gehen Sie Ihre bestehenden Verträge mit ICT-Drittanbietern gegen diese Liste durch. Fehlt ein Pflichtinhalt, haben Sie Verhandlungsbedarf, und bei Diensten für kritische oder wichtige Funktionen einen regulatorischen Mangel, der in der nächsten BaFin-Prüfung auffällt.
5. Exit-Strategie: Warum Cloud-Backup-Provider ein DORA-Risiko sein können #
Art. 28 Abs. 8 verlangt Exit-Strategien für ICT-Dienste, die kritische oder wichtige Funktionen unterstützen. Das ist kein formaler Compliance-Baustein, sondern die praktische Konsequenz aus der Erkenntnis, dass Lock-in ein operatives Risiko ist.
Das Lock-in-Problem bei Cloud-Backup-Providern #
Cloud-Backup-Anbieter erzeugen strukturellen Lock-in auf mehreren Ebenen:
Datenmenge und Egress-Kosten: Wer große Backup-Datenmengen in der Cloud hat, braucht für den Exit Wochen bis Monate und zahlt erhebliche Datentransferkosten. Diese wirtschaftliche Barriere erschwert den Exit im Krisenfall massiv.
Proprietäre Formate: Viele Backup-as-a-Service-Lösungen speichern Daten in herstellerspezifischen Formaten. Ohne Lizenz des bisherigen Anbieters sind diese Daten nicht lesbar. Der Exit bedeutet dann Datenverlust oder Neusicherung von Grund auf.
Abhängigkeit von Anbieter-Infrastruktur für Recovery: Wenn ein Recovery nur mit den Tools des Anbieters funktioniert, ist die Wiederherstellung bei Insolvenz des Anbieters oder regulatorisch erzwungenem Anbieterwechsel gefährdet.
Was eine DORA-konforme Exit-Strategie enthalten muss #
- Zeitplan: Wie lange dauert eine vollständige Migration zu einem anderen Anbieter?
- Datenportabilität: In welchem Format liegen die Daten vor, und können sie ohne Anbieter-Tools gelesen werden?
- Parallelbetrieb: Kann der bisherige Anbieter während der Transition weiterarbeiten?
- Verantwortlichkeiten: Wer im Unternehmen ist für die Exit-Planung zuständig?
- Testzyklus: Wann wurde der Exit-Plan zuletzt geprobt?
6. DORA-Risikobewertung: Cloud-Backup-Provider vs. On-Premises #
- ICT-Drittanbieter-Abhängigkeit: Beim Cloud-Provider hoch durch laufende operative Abhängigkeit; On-Premises gering, beschränkt auf Hersteller für Hardware und Wartung.
- Datensouveränität: In der Cloud eingeschränkt, die Daten liegen beim Anbieter; On-Premises vollständig unter eigener Kontrolle.
- Exit-Aufwand: In der Cloud hoch (Datenmigration, Egress-Kosten, Formatfragen); On-Premises gering, die Daten bleiben im Haus.
- Lock-in-Risiko: In der Cloud strukturell vorhanden; On-Premises für Betriebsdaten nicht vorhanden.
- Auditrecht: Gegenüber Cloud-Providern oft nur eingeschränkt durchsetzbar (SOC-2-Bericht statt Direktaudit); On-Premises vollständig, eigene Infrastruktur.
- Standort der Datenverarbeitung: In der Cloud vertraglich fixierbar, aber faktisch schwer kontrollierbar; On-Premises bekannt und physisch kontrolliert.
- Verfügbarkeit bei Anbieterausfall: In der Cloud gefährdet, das Recovery hängt an der Anbieter-Infrastruktur; On-Premises nicht betroffen.
- Vertragsklauseln nach Art. 30: Bei Hyperscalern nur eingeschränkt verhandelbar; für den laufenden On-Premises-Betrieb nicht erforderlich.
- Exit-Strategie nach Art. 28 Abs. 8: In der Cloud komplex und oft teuer; On-Premises einfach, keine externe Abhängigkeit.
- Risiko bei Anbieter-Insolvenz: In der Cloud hoch, das Recovery ist gefährdet; On-Premises nicht vorhanden.
Fazit: On-Premises-Speicher reduziert die Anzahl der -pflichtigen ICT-Drittanbieter-Beziehungen strukturell. Das vereinfacht Ihr Register, Ihre Vertragsarbeit und Ihre Exit-Planung und reduziert das operative Risiko bei einem erzwungenen Anbieterwechsel.
Das bedeutet nicht, dass Cloud-Lösungen in jedem Fall ungeeignet sind. Aber jede Cloud-Backup-Lösung erzeugt eine ICT-Drittanbieter-Abhängigkeit, die Sie vollständig nach Art. 28 bis 30 managen müssen. Wer On-Premises sichert, hat diesen Aufwand für die laufende Datenhaltung nicht.
7. Der Datensouveränitäts-Aspekt: Warum der Standort der Daten zählt #
Art. 30 verlangt, dass Verträge die Standorte der Datenverarbeitung festschreiben. Das ist kein bürokratisches Detail, es hat direkte Konsequenzen für Ihre .
Das US-CLOUD-Act-Problem: Daten, die bei US-Anbietern gespeichert sind, unabhängig davon, in welchem Land die Server stehen, können US-Behörden auf Grundlage des CLOUD Act anfordern. Ein Vertrag mit dem deutschen Rechenzentrum eines US-Unternehmens schützt nicht vor dieser Zugriffsmöglichkeit.
Praktische Konsequenz für : Ihr Informationsregister muss den Hauptsitz des Anbieters und damit dessen Rechtsrahmen ausweisen. Wenn Ihr Backup-Anbieter dem US CLOUD Act unterliegt, ist das ein dokumentiertes Risiko, das Sie entweder akzeptieren, mitigieren oder durch einen alternativen Anbieter eliminieren müssen.
On-Premises-Speicher unter eigener physischer Kontrolle, betrieben mit Hardware eines Herstellers mit Sitz in der EU, eliminiert dieses Risiko für die laufende Datenverarbeitung. FAST LTA hat Firmensitz und Fertigung in München; Silent Brick Systeme und Silent Cubes werden in Deutschland entwickelt und produziert.
8. Checkliste für das nächste DORA-Audit #
Nutzen Sie diese Checkliste zur Vorbereitung auf BaFin-Prüfungen oder interne -Assessments.
ICT-Drittanbieter-Register
- Alle ICT-Drittanbieter vollständig erfasst (kein Anbieter mit Systemzugang fehlt)
- Einstufung der Dienste (kritische oder wichtige Funktion ja/nein) durchgeführt und dokumentiert
- Register innerhalb der letzten 12 Monate aktualisiert
- Unterauftragnehmer wesentlicher Anbieter erfasst
Vertragskonformität nach Art. 30
- Alle Pflichtinhalte nach Art. 30 in Verträgen mit wesentlichen Anbietern vorhanden
- Auditrechte vertraglich verankert
- Standort der Datenverarbeitung vertraglich fixiert
- Datenzugang und Datenrückgabe bei Vertragsende geregelt
- RTO und RPO für kritische Funktionen vertraglich festgelegt
Exit-Strategien nach Art. 28 Abs. 8
- Exit-Strategie für jeden wesentlichen Anbieter dokumentiert
- Zeitplan und Kosten für Migration beziffert
- Datenportabilität geprüft (Format, Tools, Abhängigkeiten)
- Exit-Plan mindestens einmal geprobt oder im Tabletop-Exercise geprüft
Risikoüberwachung
- Prozess für anlassbezogene Neubewertung von Anbietern definiert
- Verantwortliche für ICT-Drittanbieter-Monitoring namentlich benannt
- Eskalationspfad bei Sicherheitsvorfall beim Anbieter dokumentiert
Datensouveränität
- Rechtsrahmen aller wesentlichen Anbieter dokumentiert (EU oder Drittland)
- US-CLOUD-Act-Risiko für alle relevanten Anbieter bewertet
- Restrisiken aus Drittland-Rechtsrahmen akzeptiert, mitigiert oder eliminiert
Weiterführende Ressourcen #
→ : Anforderungen, Backup-Pflichten und Bußgelder im Finanzsektor (/de/blog/dora-anforderungen-finanzsektor/) → Was ist Datensouveränität? (/de/blog/was-ist-datensouveraenitaet/) → EU US Data Privacy Framework: Was Finanzunternehmen wissen müssen (/de/blog/eu-us-data-privacy-framework/) → US Cloud Act: Was er für europäische Unternehmen bedeutet (/de/blog/us-cloud-act-erklaert/) → Lieferkettensicherheit nach NIS2: Hardware-Hersteller bewerten (/de/blog/lieferkettensicherheit-nis2-hardware/)
DORA
DORA (Digital Operational Resilience Act, EU 2022/2554) ist eine EU-Verordnung, die seit Januar 2025 für alle regulierten Finanzmarktteilnehmer gilt und konkrete Anforderungen an IKT-Risikomanagement, Backup-Systeme (Art. 11 und 12), Drittanbieter-Management (Art. 28–30) sowie Incident-Meldung stellt.
DORA
DORA (Digital Operational Resilience Act, EU 2022/2554) ist eine EU-Verordnung, die seit Januar 2025 für alle regulierten Finanzmarktteilnehmer gilt und konkrete Anforderungen an IKT-Risikomanagement, Backup-Systeme (Art. 11 und 12), Drittanbieter-Management (Art. 28–30) sowie Incident-Meldung stellt.
DORA
DORA (Digital Operational Resilience Act, EU 2022/2554) ist eine EU-Verordnung, die seit Januar 2025 für alle regulierten Finanzmarktteilnehmer gilt und konkrete Anforderungen an IKT-Risikomanagement, Backup-Systeme (Art. 11 und 12), Drittanbieter-Management (Art. 28–30) sowie Incident-Meldung stellt.
DORA
DORA (Digital Operational Resilience Act, EU 2022/2554) ist eine EU-Verordnung, die seit Januar 2025 für alle regulierten Finanzmarktteilnehmer gilt und konkrete Anforderungen an IKT-Risikomanagement, Backup-Systeme (Art. 11 und 12), Drittanbieter-Management (Art. 28–30) sowie Incident-Meldung stellt.
DORA
DORA (Digital Operational Resilience Act, EU 2022/2554) ist eine EU-Verordnung, die seit Januar 2025 für alle regulierten Finanzmarktteilnehmer gilt und konkrete Anforderungen an IKT-Risikomanagement, Backup-Systeme (Art. 11 und 12), Drittanbieter-Management (Art. 28–30) sowie Incident-Meldung stellt.
DORA
DORA (Digital Operational Resilience Act, EU 2022/2554) ist eine EU-Verordnung, die seit Januar 2025 für alle regulierten Finanzmarktteilnehmer gilt und konkrete Anforderungen an IKT-Risikomanagement, Backup-Systeme (Art. 11 und 12), Drittanbieter-Management (Art. 28–30) sowie Incident-Meldung stellt.
DORA
DORA (Digital Operational Resilience Act, EU 2022/2554) ist eine EU-Verordnung, die seit Januar 2025 für alle regulierten Finanzmarktteilnehmer gilt und konkrete Anforderungen an IKT-Risikomanagement, Backup-Systeme (Art. 11 und 12), Drittanbieter-Management (Art. 28–30) sowie Incident-Meldung stellt.
DORA
DORA (Digital Operational Resilience Act, EU 2022/2554) ist eine EU-Verordnung, die seit Januar 2025 für alle regulierten Finanzmarktteilnehmer gilt und konkrete Anforderungen an IKT-Risikomanagement, Backup-Systeme (Art. 11 und 12), Drittanbieter-Management (Art. 28–30) sowie Incident-Meldung stellt.
DORA
DORA (Digital Operational Resilience Act, EU 2022/2554) ist eine EU-Verordnung, die seit Januar 2025 für alle regulierten Finanzmarktteilnehmer gilt und konkrete Anforderungen an IKT-Risikomanagement, Backup-Systeme (Art. 11 und 12), Drittanbieter-Management (Art. 28–30) sowie Incident-Meldung stellt.
DORA
DORA (Digital Operational Resilience Act, EU 2022/2554) ist eine EU-Verordnung, die seit Januar 2025 für alle regulierten Finanzmarktteilnehmer gilt und konkrete Anforderungen an IKT-Risikomanagement, Backup-Systeme (Art. 11 und 12), Drittanbieter-Management (Art. 28–30) sowie Incident-Meldung stellt.
Datensouveränität
Datensouveränität beschreibt die vollständige Kontrolle einer Organisation über ihre Daten: wo sie gespeichert werden, wer darauf zugreifen kann, welchem Rechtsrahmen sie unterliegen und ob sie jederzeit ohne Abhängigkeit von einem einzelnen Anbieter verfügbar sind.
DORA
DORA (Digital Operational Resilience Act, EU 2022/2554) ist eine EU-Verordnung, die seit Januar 2025 für alle regulierten Finanzmarktteilnehmer gilt und konkrete Anforderungen an IKT-Risikomanagement, Backup-Systeme (Art. 11 und 12), Drittanbieter-Management (Art. 28–30) sowie Incident-Meldung stellt.
DORA
DORA (Digital Operational Resilience Act, EU 2022/2554) ist eine EU-Verordnung, die seit Januar 2025 für alle regulierten Finanzmarktteilnehmer gilt und konkrete Anforderungen an IKT-Risikomanagement, Backup-Systeme (Art. 11 und 12), Drittanbieter-Management (Art. 28–30) sowie Incident-Meldung stellt.
DORA
DORA (Digital Operational Resilience Act, EU 2022/2554) ist eine EU-Verordnung, die seit Januar 2025 für alle regulierten Finanzmarktteilnehmer gilt und konkrete Anforderungen an IKT-Risikomanagement, Backup-Systeme (Art. 11 und 12), Drittanbieter-Management (Art. 28–30) sowie Incident-Meldung stellt.
DORA
DORA (Digital Operational Resilience Act, EU 2022/2554) ist eine EU-Verordnung, die seit Januar 2025 für alle regulierten Finanzmarktteilnehmer gilt und konkrete Anforderungen an IKT-Risikomanagement, Backup-Systeme (Art. 11 und 12), Drittanbieter-Management (Art. 28–30) sowie Incident-Meldung stellt.
Disaster Recovery
Disaster Recovery bezeichnet die strukturierten Prozesse und technischen Maßnahmen, die sicherstellen, dass IT-Systeme nach einem schwerwiegenden Ausfall — Ransomware-Angriff, Hardwareversagen, Rechenzentrumsausfall — innerhalb definierter Zeitrahmen (RTO) mit maximalem Datenverlust (RPO) wiederhergestellt werden können.