Kernaussagen
- • DORA gilt seit Januar 2025 verbindlich für über 22.000 Finanzunternehmen in der EU: Banken, Versicherungen, Zahlungsdienstleister, Asset Manager und ihre kritischen IKT-Anbieter.
- • Art. 28 verlangt ein vollständiges Register aller IKT-Drittanbieter mit dokumentierten Abhängigkeiten. Die meisten Institute verwalten es bislang als Tabellenkalkulation.
- • Art. 30 schreibt aufsichtsfeste Vertragsklauseln vor: Prüfrechte, Exit-Strategien, SLA-Messung. Technische Infrastruktur-Belege für Verfügbarkeit und Integrität machen den Vertrag bei der Aufsicht erst verwertbar.
- • Der BaFin50-Scan (DACH Enterprise Readiness Report 2026) zeigt: 0 von 50 Finanzdomains CERTIFIED. Der Rückstand auf technischer Nachweisebene übertrifft den auf Vertragsebene.
- • Technische Infrastruktur-Evidenz (DNS-Integrität, TLS-Kette, SOVP-Parameter) bildet das dritte Standbein neben Vertragswerk und internem Risikomanagement.
Der Digital Operational Resilience Act (DORA) gilt seit dem 17. Januar 2025 als unmittelbar anwendbares EU-Recht: eine Verordnung mit direkter Geltung in allen 27 Mitgliedstaaten, ohne nationalen Umsetzungsschritt. Betroffen sind über 22.000 Finanzunternehmen: Kreditinstitute, Versicherungen, Zahlungsdienstleister, Wertpapierfirmen, Asset Manager, Kryptodienstleister und die IKT-Anbieter, die ihnen kritische Dienste erbringen.
Die regulatorische Logik hinter DORA ist klar: Wer seine kritische IT an externe Dienstleister ausgelagert hat, muss die operationelle Resilienz dieser Auslagerung messbar und aufsichtsfest nachweisen. Dieser Beitrag zeigt, wo der Nachweis heute steht.
Was DORA vom Finanzunternehmen verlangt: Der Art. 28-Kern
Art. 28 DORA ist das regulatorische Herzstück der IKT-Drittanbieter-Anforderungen. Er verpflichtet Finanzunternehmen zu einem vollständigen, aktuellen und revisionsfesten Register aller IKT-Drittanbieter, mit denen eine vertragliche Beziehung besteht. Das Register dient den Aufsichtsbehörden (BaFin, EZB, ESMA, EIOPA) als Datenbasis zur Identifikation systemischer Konzentrationsrisiken im Finanzsektor.
| DORA-Artikel | Anforderung | Nachweisform |
|---|---|---|
| Art. 28 Abs. 3 | Register aller IKT-Drittanbieter: vollständig, laufend aktualisiert, kategorisiert nach Kritikalität | Strukturiertes Register, meldepflichtig an ESAs auf Anfrage |
| Art. 28 Abs. 4 | Klassifizierung aller IKT-Dienstleistungen nach Kritikalitätsstufe, Bewertungsgrundlage dokumentieren | Risikoklassifizierung mit nachvollziehbaren Kriterien |
| Art. 29 | Vorausprüfung neuer IKT-Drittanbieter: Due Diligence vor Vertragsabschluss | Prüfprotokoll, technische und organisatorische Bewertung |
| Art. 30 Abs. 2 | Wesentliche Vertragsklauseln: SLA-Definitionen, Prüfrechte, Exit-Strategien, Incident-Meldepflichten | Vertragstext plus Nachweise der tatsächlichen SLA-Erfüllung |
| Art. 11 Abs. 5 | Getestete Backup- und Wiederherstellungsverfahren, Datenintegrität nachweisbar | Testberichte, Integritätsprüfung der Backup-Infrastruktur |
| Art. 19 | Meldung schwerwiegender IKT-Vorfälle an die zuständige Behörde innerhalb definierter Fristen | Incident-Klassifizierung, Meldeprotokoll, Ursachenanalyse |
NIS2 verpflichtet zur Umsetzung von Sicherheitsmaßnahmen. DORA verlangt den laufenden, messbaren und aufsichtsfesten Nachweis der operationellen Resilienz. Der Zustand der IKT-Infrastruktur muss jederzeit dokumentierbar sein.
Die Dokumentations-Realität: BaFin50 unter dem Scanner
Der DACH Enterprise Readiness Report 2026 liefert die bisher umfangreichste öffentliche Messung der technischen Compliance-Bereitschaft im deutschen Finanzsektor. CERTavia hat die 50 größten deutschen Finanzdomains aus dem BaFin-Register (Banken, Versicherungen, Asset Manager und Zahlungsdienstleister) nach dem SOVP-Protokoll gescannt.
Diese Zahlen dokumentieren, wo der deutsche Finanzsektor technisch steht. DORA bewertet technische Parameter im vertraglichen Kontext. Institute, die weder ihre eigene DNS-Infrastruktur noch die ihres IKT-Dienstleisters technisch nachweisen, tragen ein Art.-28-Risiko ins nächste BaFin-Prüfungsgespräch.
Warum Tabellenkalkulation als DORA-Register zu kurz greift
Die überwiegende Mehrzahl der IKT-Drittanbieter-Register, die Finanzunternehmen heute unterhalten, sind Excel-Tabellen oder ERM-System-Exports: Anbietername, Vertragsvolumen, Klassifikation, letzte Prüfung. Ausgeblendet bleibt der kontinuierliche technische Zustand: ob der Anbieter heute, in diesem Moment, die vertraglich vereinbarte Verfügbarkeit und Integrität tatsächlich liefert.
Ein Register mit laufender technischer Verifikation ist ein Nachweis der operationellen Resilienz. DORA verlangt genau das.
Die EBA-Leitlinien zur Auslagerung (EBA/GL/2019/02) und die JC/2023/86-Leitlinien der ESAs konkretisieren dies: Prüfrechte und Monitoring-Pflichten müssen nicht nur vertraglich vereinbart, sondern tatsächlich ausgeübt worden sein. Das Monitoring muss nachweisbar dokumentiert vorliegen.
Die drei Nachweis-Ebenen nach DORA
Aus den Art. 28 bis 30 DORA und den ESA-Leitlinien ergibt sich eine dreigliedrige Nachweis-Struktur, die Finanzunternehmen für jeden kritischen IKT-Drittanbieter aufbauen:
| Ebene | Inhalt | Häufigkeit | Lücke in der Praxis |
|---|---|---|---|
| 1. Vertragsebene | SLA-Definition, Prüfrechte, Exit-Klausel, Incident-Meldepflichten nach Art. 30 | Bei Vertragsabschluss und Verlängerung | Klauseln vorhanden, Aufsichtsfestigkeit der Formulierung ausbaufähig |
| 2. Governance-Ebene | Risikobewertung, Klassifikation nach Kritikalität, Due-Diligence-Protokoll nach Art. 29 | Jährlich und anlassbezogen | Klassifikation existiert, Aktualisierungsrhythmus noch zu etablieren |
| 3. Technische Evidenz-Ebene | Nachweisbarer IKT-Zustand: DNS-Integrität, TLS-Kette, Verfügbarkeits-Metriken, Infrastruktur-Parameter | Kontinuierlich, mindestens quartalsweise | Aufzubauen bei nahezu allen Instituten |
Die erste und zweite Ebene sind bei den meisten DORA-pflichtigen Instituten in irgendeiner Form vorhanden, wenngleich ausbaufähig. Die dritte Ebene ist der offene Punkt. Sie ist auch die erste, die eine Aufsichtsbehörde einfordern wird, wenn ein IKT-Vorfall eingetreten ist und das Institut belegen muss, dass es seinen Drittanbieter tatsächlich überwacht hat.
BaFin-Prüfer starten mit der Monitoring-Dokumentation: „Zeigen Sie mir die Aufzeichnungen der letzten 12 Monate für diesen Anbieter.“ Wer eine vollständige Monitoring-Historie vorlegen kann, besteht diesen Test.
Was konkret dokumentiert werden muss: Die Art. 30-Checkliste
Art. 30 Abs. 2 DORA listet die wesentlichen Vertragsklauseln abschließend auf. Hinter jeder Klausel steht eine Dokumentationspflicht, die über den bloßen Vertragstext hinausgeht:
DORA, NIS2, EU AI Act: Der Dreiklang schließt sich
DORA vervollständigt für den Finanzsektor den regulatorischen Dreiklang, der auf dieser Plattform seit dem ersten Beitrag beschrieben wird: EU AI Act verlangt Infrastruktur-Evidenz für Hochrisiko-KI-Systeme nach Art. 15. NIS2 verlangt Sicherheitsmaßnahmen für kritische Infrastruktur. DORA verlangt operative Resilienz-Nachweise für den gesamten IKT-Stack: für KI-Systeme ebenso wie für alle weiteren kritischen digitalen Abhängigkeiten.
| Regulierung | Zielgruppe | Kernforderung an Infrastruktur-Evidenz | Überschneidung |
|---|---|---|---|
| EU AI Act | Anbieter & Betreiber von Hochrisiko-KI | Art. 15: Robustheit, Genauigkeit, Cybersicherheit der IKT-Basis | Finanzunternehmen mit KI-Kreditscoring, Betrugserkennung, Risikomodellen |
| NIS2 | Wesentliche & wichtige Einrichtungen | Art. 21: Technische Sicherheitsmaßnahmen inkl. Lieferkettenrisiken | Banken und Finanzinfrastruktur als „wesentliche Einrichtungen“ |
| DORA | Finanzunternehmen und krit. IKT-Anbieter | Art. 28 bis 30: IKT-Drittanbieter-Register, Monitoring, technische Nachweise | Vollständige Überlappung mit NIS2; präzediert EU AI Act für Finanzsektor |
Für eine Bank, die ein KI-gestütztes Kreditscoring-System betreibt und dabei auf Cloud-IKT-Anbieter angewiesen ist, gelten alle drei Regelwerke gleichzeitig. Infrastruktur-Evidenz ist einmalig erstellte, mehrfach verwertbare Nachweis-Dokumentation: Ein SOVP-Scan des IKT-Anbieters bedient Art. 15 EU AI Act, Art. 21 NIS2 und Art. 30 DORA in einem Schritt.
Risikomatrix: DORA-Prüfungsrisiken für Finanzinstitute 2026
| Risiko | Wahrsch. | Auswirkung | Kontrolle | Reg. | Reputation | Gesamt |
|---|---|---|---|---|---|---|
| IKT-Register auf Bestandsaufnahme-Stand: laufende technische Verifikation steht aus | 5 | 5 | 2 | 5 | 4 | 5.0 |
| IKT-Register mit überfälligem Aktualisierungszyklus | 4 | 5 | 2 | 5 | 4 | 4.8 |
| Prüfrechte nach Art. 30 ohne dokumentierte Ausübung | 4 | 5 | 2 | 5 | 3 | 4.6 |
| Ungetestete Exit-Strategien für kritische Anbieter | 4 | 5 | 3 | 4 | 4 | 4.4 |
| Incident-Meldehistorie für IKT-Vorfälle noch aufzubauen | 3 | 4 | 3 | 5 | 3 | 4.1 |
| Konzentrationsrisiko: Alternativanbieter-Register ausbaufähig | 3 | 4 | 3 | 4 | 3 | 3.8 |
Die fünf Sofortmaßnahmen für DORA-Compliance 2026
Technische Infrastruktur-Nachweise behalten für Audit-Zwecke bis zu 90 Tage ihre volle Aussagekraft. Was im Januar CERTIFIED war, muss im April neu gemessen sein. Das gilt für das eigene Unternehmen ebenso wie für jeden kritischen IKT-Drittanbieter im Register. Einen festen Monitoring-Rhythmus von mindestens quartalsweise in den Governance-Prozess einzubauen ist DORA-Mindeststandard.
Was CERTavia zur DORA-Dokumentation beiträgt
CERTavia ist ein deterministischer Infrastruktur-Verifier, der technische Evidenz für Ebene 3 der DORA-Nachweis-Struktur liefert. Ein SOVP-Scan des IKT-Drittanbieters erzeugt einen kryptografisch signierten, DNS-verankerten Befund: DNS-Integrität, TLS-Konfiguration, Sicherheitsheader, AI-Infrastruktur-Parameter, maschinenlesbar, datiert, unveränderlich archivierbar.
Dieser Befund ist ein technisches Messprotokoll. Er ergänzt die Risikoklassifikation nach Art. 28, die Vertragsklauseln nach Art. 30 und die organisatorische Governance um die technische Beweisebene: den Nachweis, dass zum Zeitpunkt X der Anbieter Y die technischen Anforderungen Z tatsächlich erfüllt hat.
Banken, die bereits mit CERTavia-Nachweisen nach Art. 15 EU AI Act arbeiten (wie in Teil 1 unserer Banken-Serie beschrieben), erweitern die Infrastruktur-Evidenz direkt auf DORA-Anforderungen. Derselbe Scan, derselbe Nachweis, dreifacher regulatorischer Nutzen.
CERTavia analysiert technische Infrastruktursignale und erzeugt maschinenlesbare Befunde. Das Ergebnis ist ein technisches Messprotokoll. Für rechtsverbindliche Compliance-Bewertungen im Sinne von DORA wenden Sie sich an eine zugelassene Wirtschaftsprüfungs- oder Beratungsgesellschaft mit regulatorischer Finanzsektor-Expertise.