UK-FCA-Regeln vom 16. April 2026 und der Weg zu DORA 2.0: Was Finanzinstitute jetzt architektonisch vorbereiten

8 Min. Lesezeit

Am 16. April 2026 hat die britische Finanzaufsicht neue Operational-Incident- und Third-Party-Reporting-Rules veröffentlicht und damit die erste Post-DORA-Regulierungswelle in Europa eingeläutet. Die Financial Conduct Authority verlangt von Finanzinstituten und ihren ICT-Drittanbietern neue Klassifizierungs- und Meldefristen, die in Tiefe und Prüfungsschärfe über DORA hinausgehen. In Brüssel laufen parallel die Vorbereitungen für eine DORA-Evaluation, die Ende 2026 in einen Review-Bericht fließen soll und für 2027 eine Nachschärfung wahrscheinlich macht. Security-Teams sollten jetzt nicht auf DORA 2.0 warten, sondern ihre Architektur gegen die bekannten Defizite testen.

VerwandtASP.NET Core CVE: Compliance-Folgen unter DORA und NIS2  /  OT-Security 2026: IEC 62443 und Cyber Resilience Act

Was die UK-FCA am 16. April konkret geändert hat

Die Financial Conduct Authority hat ihre Policy Statement zu Operational Incident and Third-Party Reporting Rules am 16. April 2026 publiziert. Die zentrale Verschärfung ist eine neue Zwei-Klassen-Meldepflicht: jede betriebsrelevante ICT-Störung ab einem quantifizierten Impact-Schwellwert muss binnen sechs Stunden als Initial Notification gemeldet werden, mit einer detaillierten Post-Incident-Analyse binnen 30 Tagen. Bemerkenswert ist das Third-Party-Reporting-Element: Finanzinstitute müssen nicht mehr nur ihre eigenen Störungen melden, sondern auch materielle Incidents bei ihren ICT-Drittanbietern, wenn diese Auswirkungen auf britische Finanzdienste haben.

DORA in seiner aktuellen Form verlangt ebenfalls Incident-Reporting, lässt aber die Schwellwerte für die Klassifizierung deutlich interpretationsoffener. Die ESA-RTS von 2024 definieren qualitative Kriterien, aber die Umsetzungspraxis in den ersten 15 Monaten zeigt, dass Finanzhäuser in der gleichen Situation sehr unterschiedliche Bewertungen vornehmen. Die UK hat das offenbar gesehen und in ihrer Nachfolgeregelung den Klassifizierungs-Katalog quantifiziert.

Für DACH-Finanzinstitute ist die UK-Welle aus drei Gründen relevant. Erstens betreiben die meisten Großbanken und Versicherer signifikante UK-Operationen und müssen die Regeln ohnehin implementieren. Zweitens dient der UK-Text faktisch als Blueprint für die DORA-Evaluation, die die EU-Kommission bis Ende 2026 abschließt. Drittens setzen die UK-Schwellwerte einen neuen Benchmark, an dem Supervisors in EU-Mitgliedstaaten ihre Erwartungen kalibrieren werden, noch bevor eine formale DORA-Anpassung kommt.

Was ist DORA 2.0? DORA 2.0 ist aktuell kein verabschiedeter Rechtsakt, sondern die branchenübliche Kurzbezeichnung für die erwartete Nachschärfung der EU-Verordnung 2022/2554. Die EU-Kommission ist gesetzlich verpflichtet, bis zum 17. Januar 2028 eine Evaluierung der bisherigen DORA-Umsetzung vorzulegen. Erste Arbeitsdokumente der ESAs sprechen bereits für 2026 eine Nachschärfung der Technical Standards an, insbesondere bei Incident-Klassifizierung, TLPT-Scoping und ICT-Third-Party-Risk. Finanzinstitute sollten den Begriff als Platzhalter lesen, unter dem sich eine Kombination aus geänderten RTS und möglichen Ergänzungen der Verordnung bündelt.

Die drei Schwachstellen, die DORA-Audits 2025/2026 konsequent finden

Wer sich die ersten Supervisor-Rückmeldungen aus Deutschland, Frankreich und den Niederlanden ansieht, findet immer die gleichen drei Lücken. Sie sind der wahrscheinlichste Fokus einer DORA-Nachschärfung.

Incident-Klassifizierung ohne Einheitlichkeit. Die RTS definieren Impact-Kriterien qualitativ: Kundenbetroffenheit, Dauer, Datenschutz-Dimension, reputationale Wirkung. Das klingt sauber, produziert aber in der Praxis inkonsistente Entscheidungen. Zwei Häuser, die denselben Cloud-Ausfall erleben, kommen oft zu unterschiedlichen Klassifizierungen. Wir haben in Incident-Reviews mehrfach gesehen, dass ein Vorfall intern als „major“ gilt, aber gegenüber der BaFin als „significant“ gemeldet wurde, weil die Reporting-Pflicht bei „major“ früher greift. Der UK-Ansatz mit harten Schwellwerten ist die direkte Antwort darauf.

TLPT-Scoping zu eng. Threat-Led Penetration Testing ist unter DORA für systemrelevante Institute verpflichtend, der TIBER-EU-Rahmen ist der faktische Standard. In den ersten TLPT-Runden 2025 haben viele Institute den Scope auf die eigenen digitalen Kanäle verengt. ICT-Supply-Chain wurde häufig ausgeklammert. Die ESMA hat in einem Quartals-Bericht Q1 2026 darauf hingewiesen, dass künftige Prüfungen die gesamte kritische ICT-Kette abdecken müssen. Das ist technisch ein großer Sprung: Red-Team-Szenarien gegen Managed Service Provider und ihre Infrastruktur zu fahren, setzt Vertragswerk und Kooperationsbereitschaft voraus, die heute selten dokumentiert ist.

ICT-Third-Party-Register unvollständig. Das DORA-ICT-Register ist in der Theorie eine vollständige Darstellung aller kritischen ICT-Dienste. In der Praxis werden Sub-Processor-Beziehungen oft nicht erfasst. Der Commvault-Push auf Google Cloud vom 22. April ist ein gutes Beispiel: wer heute Commvault als Backup-Dienstleister im Register führt, muss nach der Integration potenziell auch Google Cloud als Sub-Processor ergänzen. Wenn diese Verschiebungen nicht nachgezogen werden, entsteht eine Lücke zwischen operativer Realität und Register-Stand, die bei der nächsten Prüfung auffällt.

Wer ein ICT-Register führt wie eine Inventurliste, das einmal im Jahr aktualisiert wird, hat 2026 weder die UK-Regel noch die kommende DORA-Nachschärfung verstanden. Register sind 2026 operativ – oder sie sind nutzlos.

Was die ersten ESA-Bewertungen 2025/26 nüchtern zeigen

Die europäischen Aufsichtsbehörden EBA, ESMA und EIOPA haben Anfang 2026 eine gemeinsame Auswertung der ersten DORA-Anwendungsphase veröffentlicht. Die Kernbefunde decken sich weitgehend mit den Erkenntnissen einzelner nationaler Supervisors wie der BaFin und der niederländischen DNB. Drei Befunde ziehen sich konsistent durch die Berichte.

Erstens: Die Reporting-Qualität ist ungleichmäßig. Für denselben Incident-Typus variieren Impact-Angaben zwischen Instituten um einen Faktor drei bis fünf. Das ist weniger ein Böswilligkeit-Problem als ein Methoden-Problem. Die RTS definieren qualitative Kriterien ohne konkretes Rechenmodell; die Incident-Manager in den Banken haben keine einheitliche Vorlage, an die sie sich halten. Die Folge: Supervisor können Quer-Vergleiche nur mit Mühe führen, obwohl genau das der Sinn einer europaweiten Verordnung ist.

Zweitens: Die Drittanbieter-Sichtbarkeit endet fast immer an der ersten Ebene. Ein Institut kennt seine direkten ICT-Dienstleister, aber selten den zweiten oder dritten Layer. Das widerspricht dem DORA-Anspruch, denn die Verordnung verlangt Ketten-Transparenz bis zu kritischen Sub-Processorn. Die Compliance-Praxis ist hinter der Regel-Erwartung. Wenn ein Major-Incident bei einem Sub-Processor die Bank trifft, ist nachträgliche Rekonstruktion mühsam bis unmöglich.

Drittens: TLPT-Ergebnisse werden intern oft als Einzelereignis behandelt. Die RTS sehen vor, dass Erkenntnisse in die laufende Risikoanalyse einfließen. In der Praxis landen sie häufig in einem dicken Report, der dem Vorstand einmalig vorgestellt wird, ohne dass daraus systematisch Architektur-Entscheidungen abgeleitet werden. Der Lern-Effekt bleibt unter dem, was die Verordnung angelegt hat.

Fünf Schritte, die Security-Teams jetzt gehen

Die Nachschärfung kommt, aber nicht heute. Die nützliche Reaktion ist nicht Abwarten, sondern gezielte Vorarbeit, die unabhängig vom genauen Wortlaut einer DORA-2-RTS Sinn ergibt. Fünf Punkte, die in den nächsten 120 Tagen laufen sollten.

Erstens: Unified Incident Taxonomy. Die interne Klassifikation an die FCA-Schwellwerte angleichen, selbst wenn das Institut nicht in UK operiert. Quantitative Kriterien reduzieren die Varianz zwischen verschiedenen Incident-Managern und liefern eine verteidigbare Argumentation gegenüber Supervisors. Der Aufwand ist eine Woche Workshop plus Tooling-Anpassung.

Zweitens: TLPT-Scope ausweiten. Wenn das nächste TLPT-Fenster in 2026 oder 2027 ansteht, sollte die ICT-Supply-Chain in den Scope. Das heißt konkret: mindestens einen zentralen Managed Service Provider explizit ins Red-Team-Szenario aufnehmen, mit vertraglicher Zustimmung. Auch wenn DORA 2.0 es noch nicht verlangt, ist der Erkenntnisgewinn für die eigene Architektur hoch.

Drittens: ICT-Register operativ halten. Das Register nicht als Compliance-Dokument behandeln, sondern als laufende Datenbank mit automatisierten Integrationen zu Contract-Management und CMDB. Jede neue Integration eines ICT-Dienstleisters sollte das Register automatisch anstoßen. Bei Änderungen in der Sub-Processor-Kette ein quartalsweises Review.

Viertens: Third-Party-Monitoring. Die UK-Regel verlangt Meldungen über Vorfälle bei Drittanbietern. Das funktioniert nur, wenn das Institut aktives Monitoring bei seinen kritischen Dienstleistern hat. Konkret: Incident-APIs, Status-Page-Scraping und regelmäßige SOC-Coordination-Calls. Viele Institute haben das für ihre Kernsysteme, aber nicht für Sub-Processor.

Fünftens: Runbooks überarbeiten. Die Sechs-Stunden-Meldefrist der FCA ist realistisch nur einzuhalten, wenn das interne Runbook die ersten 90 Minuten strikt definiert. Wer während eines Major-Incidents noch diskutiert, wer die BaFin-Hotline anruft, wird die Frist nicht halten.

Ein Detail, das in der Debatte oft untergeht: DORA und die UK-Regel verlangen beide keine zeitgleiche Veröffentlichung gegenüber der breiten Öffentlichkeit. Die Meldung geht an den Supervisor, die Kommunikation mit Kunden und Presse bleibt Sache des Instituts. Wer das verwechselt, produziert unnötige Reputationsrisiken. Für die Drei-Linien-Verteidigung heißt das: Compliance, Kommunikation und IT-Security müssen klar abgegrenzte Rollen im Incident-Response-Playbook haben. Das scheint trivial, ist in der Praxis aber eine der häufigsten Pannenursachen.

Die Disziplin-Lücke zwischen DORA-Anspruch und Umsetzung erklärt auch, warum manche Institute nach einem einzigen Incident plötzlich unverhältnismäßig hohe Nachbesserungskosten tragen. Wer die Runbooks vorher sauber schreibt und mit Tabletop-Exercises drei- bis viermal im Jahr durchspielt, liegt im mittleren fünfstelligen Bereich. Wer reagiert, nachdem ein Major-Incident dokumentiert wurde, liegt schnell bei mehreren hunderttausend Euro externer Beratung, weil jede Anpassung unter Zeitdruck läuft.

In der Praxis zeigt sich zudem, dass die Abstimmung mit kritischen ICT-Dienstleistern besser läuft, wenn das eigene Haus saubere interne Prozesse hat. Ein Dienstleister, der von seinem Bank-Kunden drei widersprüchliche Anfragen zu ein und demselben Incident bekommt, wird defensiv und liefert minimale Informationen. Ein Bank-Kunde mit eindeutigem Single-Point-of-Contact und klarem Eskalationspfad erhält deutlich umfangreichere Kooperation. Das ist kein regulatorisches Argument, sondern operative Betriebserfahrung; in informellen Gesprächen mit Supervisorn wird das oft bestätigt.

Für die Budgetplanung 2027 lohnt sich ein einfacher Reality-Check. Institute, die ihre DORA-Architektur bisher als Kostenblock gesehen haben, sollten die kommenden zwölf Monate nutzen, um den operativen Nutzen sichtbar zu machen. Ein sauber geführtes ICT-Register mit Anbindung an CMDB und Contract Management ist nicht nur Compliance-Arbeit, sondern die Grundlage für vernünftiges Vendor-Management. Ein operationalisiertes Incident-Taxonomy-Modell beschleunigt Post-Mortems und reduziert Mean Time to Resolution. Wer das anschlussfähig formuliert, bekommt die Budgets für Phase zwei einfacher durch.

Häufige Fragen

Wann kommt DORA 2.0?

Es gibt kein bestätigtes Datum. Die EU-Kommission muss bis 17. Januar 2028 eine Evaluierung vorlegen. Erste RTS-Anpassungen sind 2026 bis 2027 wahrscheinlich. Der Begriff DORA 2.0 fasst diese Nachschärfungen branchenüblich zusammen, ist aber kein offizieller Rechtsakt.

Sind die UK-Regeln für EU-Institute verbindlich?

Nur wenn ein Institut im UK-Perimeter operiert, dann ja. Für rein EU-ansässige Institute haben sie Signalwirkung. Supervisors auf dem Kontinent orientieren ihre Erwartungen an der Nachbarschaft; die FCA-Schwellwerte werden wahrscheinlich als Benchmark für künftige RTS-Revisionen herangezogen.

Was ist TLPT konkret?

Threat-Led Penetration Testing ist ein umfangreicher Red-Team-Test unter realen Angreifer-Bedingungen. Der TIBER-EU-Rahmen der EZB ist der europäische Standard. Scope, Regelwerk und Ablauf sind deutlich strenger als bei klassischen Pentests. Für systemrelevante Institute ist TLPT unter DORA verpflichtend.

Wie oft sollte das ICT-Register aktualisiert werden?

Mindestens quartalsweise, bei Änderungen in der kritischen Dienstleister-Kette sofort. Als Faustregel: wenn ein neuer Sub-Processor aufgenommen wird oder ein bestehender seine Infrastruktur migriert, muss das Register synchron gepflegt werden. Tools wie OneTrust oder Archer bieten entsprechende Workflows.

Welche Kosten sind für die fünf Schritte realistisch?

Für ein mittelgroßes Finanzinstitut liegen die Zusatzkosten bei 150.000 bis 400.000 Euro im ersten Jahr, abhängig vom Reifegrad des bestehenden ICT-Risikomanagements. Der größere Aufwand steckt in der TLPT-Scope-Erweiterung, am wenigsten in der Taxonomie-Angleichung.

Quelle Titelbild: Pexels / Sora Shimazaki (px:5669619)

Hier schreibt Alec Chizhik für Sie

Mehr Artikel vom Autor Alec Chizhik