DORA-Inspektionswelle 2026 — was Aufseher tatsächlich fragen

DORA — Verordnung (EU) 2022/2554 — ist seit dem 17. Januar 2025 vollständig anwendbar ^[1]. Der erste Register-of-Information-Zyklus mit Einreichungs­frist 30. April 2025 war noch eine formale Compliance-Prüfung: Existiert das Register? Sind die ICT-Drittparteien aufgelistet? Ist das Klassifizierungs­schema dokumentiert? Achtzehn Monate später läuft die zweite Inspektions­welle — und der Aufsichts­fokus hat sich verschoben.

Die ESAs (EBA, EIOPA, ESMA) machen in ihrem Arbeitsprogramm 2026 (Gemeinsamer Ausschuss der ESAs) deutlich, dass die Eingangs­kontrolle abgeschlossen ist und die substanzielle Prüfung beginnt: Vollständigkeit der Drittparteienregister, Mapping der Sub-Outsourcing-Ketten, Härte des Incident-Reporting unter Zeitdruck, Beweis­fähigkeit der Vorstands­einbindung ^[2]. Wer ein Register hat, das auf dem Papier komplett aussieht, aber die Sub-Outsourcing-Kette nicht in zumutbarer Tiefe abbildet, wird das in der Inspektion 2026 nicht mehr verbergen.

Dieser Beitrag listet die sieben Schwerpunkt­bereiche, die in den Inspektions­vorbereitungen 2026 konsistent auftauchen — gestützt auf die DORA-Level-1-Texte, die Joint-Committee-RTS, die nationalen Aufsichts­schwerpunkte 2026 und die öffentlich verfügbaren ESA-Q&As. Wer alle sieben sauber beantworten kann, geht in eine DORA-Inspektion vorbereitet.

Art. 28 DORA verpflichtet jedes betroffene Finanz­institut, ein Register sämtlicher ICT-Drittpartei-Dienstleistungs­anbieter zu führen und sie mindestens jährlich an die zuständige Behörde zu übermitteln ^[1]. Der 31. März ist dabei der Stichtag (das Referenzdatum) des Registers, keine gesetzliche Einreichungsfrist; das eigentliche Einreichungsfenster legen die ESAs und die nationalen Behörden jährlich fest — die erste EU-weite Erhebung lief im April 2025, mit Weiterleitung an die ESAs bis 30. April 2025. Die DORA-Durchführungsstandards zum Register of Information (ITS nach Art. 28 Abs. 9) konkretisieren die Mindest­felder: Anbieter­identifikation, Dienstleistungs­art, Kritikalitäts­bewertung, Substituierbarkeit, Vertrags­datum und Lokation der Daten­verarbeitung ^[3].

Die Inspektions­praxis 2026 prüft Vollständigkeit auf drei Ebenen. Erstens: Sind ALLE ICT-Dienstleister im Register, einschließlich SaaS-Tools mit niedrigem Vertrags­volumen, die Compliance- und HR-Daten verarbeiten? Zweitens: Stimmt die Kritikalitäts­bewertung mit der tatsächlichen Funktions­abhängigkeit überein, oder wurde versucht, kritische Anbieter herunter­zustufen, um aufsichts­rechtlichen Mehraufwand zu vermeiden? Drittens — und das ist der häufigste Befund — wird die Sub-Outsourcing-Kette in zumutbarer Tiefe aufgelöst?

Aufseher haben wiederholt darauf hingewiesen, dass ein Register, das nur den Hauptdienstleister aufführt, aber nicht die Kette der Sub-Auftragnehmer, die wesentliche Daten verarbeiten, den Anspruch von Art. 28 nicht erfüllt — Vollständigkeit endet nicht beim Vertragspartner ^[5].

Die häufigste 2026-Inspektions­frage ist nicht „haben Sie das Register?“, sondern „wo läuft Ihr Backend-Hosting tatsächlich?“. In der Praxis bedeutet das: Der direkte ICT-Anbieter ist häufig nur die Vertrags­fassade. Hinter ihm steht ein Hyperscaler, ein PaaS-Anbieter, ein Daten­bank-Service. Die ESAs erwarten, dass das Institut diese Kette mindestens bis zum nicht weiter delegierbaren Infrastruktur­anbieter dokumentiert ^[2].

Die Anforderung „zumutbare Tiefe“ ist nicht trivial — und die Aufsichts­behörden wissen das. In der Aufsichtspraxis haben sich zwei pragmatische Schwellen herausgebildet: (a) Jeder Sub-Anbieter, der personen­bezogene Daten von Kunden oder Mitarbeitern verarbeitet, muss namentlich dokumentiert sein, unabhängig vom Vertrags­volumen; (b) jeder Infrastruktur­anbieter, dessen Ausfall den Betrieb einer kritischen Funktion im Sinne von Art. 3 Abs. 22 unterbrechen würde, muss ebenfalls genannt sein ^[2][5].

Wer diese zwei Schwellen sauber abdeckt, hat den substantiellen Test der Sub-Outsourcing-Kette in der Inspektion bestanden — auch wenn die Vertrags­fassade des Hauptdienst­leisters minimal kooperativ war.

Art. 19 DORA und die zugehörige RTS (Del. VO (EU) 2025/301) legen die Meldefristen fest, die in einer Inspektion 2026 retrograd gegen tatsächliche Vorfälle geprüft werden: die initiale Meldung an die zuständige Behörde binnen 4 Stunden nach Klassifizierung als „major incident“ — und spätestens 24 Stunden, nachdem das Institut von dem Vorfall Kenntnis erlangt hat; die Intermediate-Notification binnen 72 Stunden; der Final Report binnen eines Monats ^[1]. Commission Delegated Regulation (EU) 2024/1772 definiert die Klassifizierungs­kriterien — Anzahl betroffener Kunden, Daten­verlust, geografische Reichweite, ökonomische Auswirkung ^[4].

Der schwierigste Test ist nicht der Final Report — der wird unter normalen Umständen rechtzeitig erstellt — sondern die 4-Stunden-Initialmeldung. Sie verlangt, dass das Institut innerhalb von vier Stunden nach Klassifizierung eines Vorfalls als „major“ eine strukturierte Notification an die Aufsicht abgeben kann, vollständig mit Klassifizierungs­kriterien, ersten Schadens­einschätzungen und einer ersten Hypothese zum Root Cause. Wer keinen vorab definierten Incident-Routing-Prozess hat — wer also den Vorfall in der internen Notification entdeckt, dann manuell den richtigen Empfänger ermittelt, dann das Notification-Template ausfüllt — wird die vier Stunden in einer realen Krise nicht halten.

Aufsichtskommunikationen — die der BaFin eingeschlossen — behandeln die Geschwindigkeit der Initial-Notification als Reifeindikator des gesamten ICT-Risk-Management-Frameworks ^[7]. Ein Institut, das die vier Stunden nicht halten kann, hat strukturell ein Reifegrad­problem.

Threat-Led Penetration Testing (TLPT) ist die DORA-Variante des bewährten TIBER-EU-Rahmens — verpflichtend für Institute, die die ESAs als systemisch relevant klassifiziert haben ^[1]. Commission Delegated Regulation (EU) 2025/1190 hat die technischen Detail­anforderungen festgelegt: Testfrequenz mindestens alle drei Jahre, Geltungsbereich umfasst „critical functions“ inkl. ihrer ICT-Lieferkette, externer Threat-Intelligence-Provider und Red Teamer mit nachgewiesener Erfahrung ^[6].

In der Inspektion 2026 ist die TLPT-relevante Frage zweistufig. Erstens: Ist das Institut im Scope? Die Schwellen­werte und Anwendbarkeits­kriterien sind in der TLPT-RTS (Del. VO (EU) 2025/1190) selbst festgelegt ^[6]. Zweitens: Falls ja, ist der TLPT-Plan dokumentiert, ist das Scoping erfolgt, ist ein externer Provider beauftragt? Die ersten verpflichtenden TLPTs laufen über 2026-2027; wer Anfang 2027 noch keinen Plan vorlegen kann, wird Findings produzieren.

DORA verlangt, dass jedes Institut seine „kritischen oder wichtigen Funktionen“ identifiziert und für diese erhöhte Anforderungen erfüllt: dokumentierte ICT-Risk-Bewertung, definierte Recovery-Time-Objectives, Business-Continuity-Plan, regel­mäßige Tests ^[1]. DORA definiert den Begriff in Art. 3 Abs. 22: kritisch oder wichtig ist eine Funktion, deren Ausfall die finanzielle Performance bzw. die Solidität oder Kontinuität der Dienstleistungen des Instituts erheblich beeinträchtigen würde ^[1]. Die erhöhten vertraglichen Anforderungen für ICT-Dienste, die solche Funktionen stützen, regelt Art. 30.

Die Inspektions­praxis ist hier weniger ein Pass/Fail-Test, sondern ein Konsistenz­check. Der Auditor wird die Liste der kritischen Funktionen abfragen, sie mit dem Drittparteienregister abgleichen (welche ICT-Anbieter unterstützen welche kritische Funktion?), und schließlich mit den Incident-Reports der letzten zwölf Monate vergleichen (haben Vorfälle, die kritische Funktionen betreffen, die richtige Klassifizierung und Eskalation erhalten?). Inkonsistenzen über diese drei Datensätze sind 2026 der wahrscheinlichste Pfad zu einem Finding.

Art. 5 – 17 DORA bilden zusammen das ICT-Risk-Management-Framework. In der Inspektion 2026 wird es nicht im Detail geprüft — dafür reichen die Inspektions­tage nicht — sondern stichprobenartig getestet. Die häufigsten Stichproben­fragen: Wer ist der ICT-Risk-Owner? Wann wurde das Framework zuletzt aktualisiert? Ist die Aktualisierung im Vorstands­protokoll vermerkt? Wie wurden die Erkenntnisse aus dem letzten Major-Incident in die Risk-Assessments zurückgespielt?

Für die ICT-Risiken aus dem KI-Einsatz greift bereits DORAs eigenes Rahmenwerk (Art. 6–16): Wer ein Foundation Model oder eine LLM-API in einer kritischen Funktion einsetzt, muss die modellspezifischen ICT-Risk-Themen — Halluzinationen, Daten-Leakage, Modell-Drift — dokumentiert behandelt haben. Die älteren EBA-Leitlinien zum ICT- und Sicherheitsrisikomanagement (EBA/GL/2019/04) wurden 2025 sogar verengt (EBA/GL/2025/02), weil DORA dieses Feld für Finanzunternehmen nun unmittelbar besetzt ^[8]; KI-spezifische ICT-Aufsicht entsteht derzeit national — etwa die BaFin-Hinweise vom Dezember 2025 zu ICT-Risiken beim KI-Einsatz ^[7] — und rückt 2026 erstmals systematisch in den Prüfungsfokus.

DORA Art. 5 Abs. 2 verlangt, dass das ICT-Risk-Management-Framework von der „Management Body“ — also dem Vorstand bzw. der Geschäfts­leitung — verabschiedet und regelmäßig überprüft wird ^[1]. Eine feste Kadenz schreibt DORA dabei nicht vor — der Text spricht von „regelmäßig“. Verankert ist eine mindestens jährliche umfassende Überprüfung des Rahmens (Art. 6 Abs. 5 ^[1]); häufigere Briefings zu wesentlichen Updates und Vorfällen sind gute Praxis, aber keine ausdrückliche regulatorische Pflicht.

Der Inspektions­test ist der „soft test“: Der Auditor fragt nach Vorstands­protokollen, die ICT-Risk-Themen behandeln. Vorhanden / nicht vorhanden / formal-aber-leer / substantiell-und-protokolliert. Die letzten beiden Kategorien sind der Unterschied zwischen einer guten und einer schlechten Inspektion. Eine substantielle Vorstands­protokoll-Eintragung sieht so aus: „Vorstand zur Kenntnis genommen: 3 Critical-Findings aus DORA-Quellen im letzten Quartal, davon 1 betreffend kritische Funktion ‚Zahlungs­abwicklung‘. Aktion: Risk-Assessment des betroffenen Drittanbieters wird neu durchgeführt; Status-Update im nächsten Quartals­bericht.“

Wer Vorstands­protokolle hat, die ICT-Risk-Themen substantiell behandeln, wird in einer DORA-Inspektion 2026 nicht angreifbar.

Die sieben Schwerpunkte oben haben ein gemeinsames technisches Substrat: ein unveränderbares, zeit­gestempeltes Audit-Log. Wer in einer Inspektion behauptet, ein Finding sei „rechtzeitig erkannt und richtig geroutet worden“, muss das mit einem Log nachweisen, das nicht nachträglich editierbar ist. Wer behauptet, ein Vorstands­briefing zum Sub-Outsourcing-Risk sei am 12. März 2026 erfolgt, muss das mit einem Eintrag belegen können, der am 12. März 2026 erstellt wurde.

Das ist der praktische Maßstab für „audit-ready“ im Jahr 2026. Die DORA-Level-1-Texte verlangen es zwar nicht wortwörtlich — aber die Inspektions­praxis macht es zur faktischen Voraussetzung. Institute, deren Compliance-Dokumentation in unstrukturierten Outlook-Postfächern, geteilten OneDrive-Folders und manuell gepflegten Excel-Trackern lebt, werden in 2026-Inspektionen Findings produzieren — nicht wegen fehlender Substanz, sondern wegen fehlender Beweis­fähigkeit.

Horizon Scanner überwacht alle drei ESAs (EBA, EIOPA, ESMA) parallel zu allen nationalen DORA-Quellen — RTS, ITS, Q&As, nationale Umsetzungs­akte, Aufsichts­schreiben — und routet jedes DORA-relevante Finding am Tag der Veröffentlichung an das zuständige Team. Jedes Finding wird gegen drei Dimensionen klassifiziert: Impact, Reach, Substantiveness — Score ≥ 3 löst Vier-Augen-Prinzip aus. Jeder Routing-Schritt wird im Audit-Log dokumentiert; die Retentions­dauer ist fünf Jahre, der Export geht als CSV oder JSON.

Für die sieben Inspektions­schwerpunkte aus diesem Beitrag heißt das konkret: Sub-Outsourcing-Updates werden gegen das Drittparteienregister abgeglichen; 4-Stunden-Incident-Routings sind als vorgefertigte Workflows eingerichtet; Vorstands­briefings zum DORA-Quartals­update werden automatisch zusammengestellt; jeder Audit-Log-Eintrag ist zeit­gestempelt und nicht nachträglich editierbar. In einer DORA-Inspektion 2026 ist das die Beweis­schicht, die der Auditor sehen will — vorhanden, vollständig, prüfungssicher.