DORA im Jahr 2026: Pflichten, Vorfälle, TLPT und IKT-Drittdienstleister

Rechtsstand von DORA am 29. August 2026

DORA trat am 16. Januar 2023 in Kraft; der überwiegende Teil der Vorschriften ist seit dem 17. Januar 2025 anzuwenden. Dieses Datum war nicht der Beginn eines Umsetzungsprojekts, sondern der Zeitpunkt, ab dem betroffene Unternehmen ihre Pflichten erfüllen mussten.^[1]

Die Grundverordnung wird durch Level-2-Rechtsakte ergänzt. Wesentliche Themen sind das IKT-Risikomanagement, die Klassifizierung von Vorfällen, Inhalt und Fristen von Meldungen, Richtlinien für IKT-Dienste, das Informationsregister, Unterauftragsvergabe und TLPT. Eine Prüfung, die nur den Text der DORA-Grundverordnung betrachtet, bleibt daher unvollständig.

Polen: Das Gesetz vom 25. Juni 2025 passte sektorale Gesetze und das KSC an, legte Aufsichtskompetenzen fest und führte nationale Durchsetzungsmechanismen ein. DORA bleibt jedoch die unmittelbar geltende Grundlage der wesentlichen Pflichten von Finanzunternehmen.^[2]

Wen DORA erfasst

Artikel 2 Absatz 1 nennt 20 Kategorien von Finanzunternehmen. Dazu gehören unter anderem Kreditinstitute, Zahlungs- und E-Geld-Institute, Wertpapierfirmen, unter MiCA fallende Kryptowerte-Dienstleister, Finanzmarktinfrastrukturen, Fondsverwalter, Versicherungsunternehmen und -vermittler, Einrichtungen der betrieblichen Altersversorgung, Ratingagenturen, Crowdfunding-Dienstleister und Verbriefungsregister.^[1]

Der Anwendungsbereich darf nicht allein aus einer Branchenbezeichnung oder dem Begriff "Fintech" abgeleitet werden. Entscheidend sind der regulatorische Status des konkreten Unternehmens und die Ausnahmen in Artikel 2 Absatz 3. Der Verhältnismäßigkeitsgrundsatz passt die Umsetzung an Größe, Risikoprofil und Komplexität an, schafft aber keine pauschale Ausnahme für jede kleine Organisation.

IKT-Drittdienstleister

Ein gewöhnlicher IKT-Dienstleister wird durch einen Vertrag mit einem Finanzunternehmen nicht selbst zum "DORA-Finanzunternehmen". Seine Pflichten ergeben sich in erster Linie aus dem Vertrag. Einen anderen Status haben von den Europäischen Aufsichtsbehörden als kritisch benannte IKT-Drittdienstleister (CTPP); sie unterliegen einem direkten europäischen Aufsichtsrahmen.

IKT-Risikomanagement und Verantwortung des Leitungsorgans

Das Leitungsorgan trägt die letztendliche Verantwortung für das IKT-Risikomanagement. Es muss Rahmenwerk, Rollen, Resilienzstrategie, Kontinuitäts- und Wiederanlaufpläne, Budget und Richtlinie für IKT-Drittdienstleistungen genehmigen und überwachen. Mitglieder des Leitungsorgans müssen über ausreichende Kenntnisse verfügen, um IKT-Risiken verstehen und beurteilen zu können.^[1]

Die Artikel 5-16 umfassen sechs miteinander verbundene Fähigkeiten:

• Identifikation von Geschäftsfunktionen, Informations- und IKT-Assets sowie Abhängigkeiten;
• Schutz und Prävention einschließlich Zugriffskontrolle, Konfiguration, Änderungen und Datensicherheit;
• Erkennung von Anomalien und Vorfällen;
• Reaktion und Wiederherstellung mit definierten Zielen und Verfahren;
• Lernen aus Vorfällen und Tests;
• interne und externe Kommunikation.

Die Delegierte Verordnung (EU) 2024/1774 konkretisiert Anforderungen unter anderem an Richtlinien, Asset Management, Kryptografie, IKT-Betrieb, Netzsicherheit, Change Management, Kontinuität und Reporting. Sie enthält auch Einzelheiten des vereinfachten Rahmens nach Artikel 16 für bestimmte Kategorien von Unternehmen - nicht für jedes Unternehmen, das sich selbst als klein einstuft.^[3]

IKT-Vorfälle: Klassifikation und Meldefristen

Ein Unternehmen muss IKT-bezogene Vorfälle erfassen, nach einem dokumentierten Prozess bearbeiten und anhand der Kriterien des Artikels 18 DORA klassifizieren. Wesentlichkeitsschwellen legt die Delegierte Verordnung (EU) 2024/1772 fest. Bewertet werden unter anderem betroffene Kunden und Gegenparteien, Dauer und Ausfallzeit, geografische Ausbreitung, Verlust von Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit, Kritikalität der betroffenen Dienste und wirtschaftliche Auswirkungen.^[4]

Wird ein Vorfall als schwerwiegend eingestuft, gilt ein dreistufiges Meldeverfahren. Die Delegierte Verordnung (EU) 2025/301 regelt Inhalt und Fristen, die Durchführungsverordnung (EU) 2025/302 Formulare und Verfahren.^[5][6]

In Polen werden Meldungen schwerwiegender IKT-Vorfälle und Mitteilungen erheblicher Cyberbedrohungen über das von der KNF bereitgestellte SOID-System übermittelt. Die KNF veröffentlicht außerdem ein Notfallverfahren für den Fall der Nichtverfügbarkeit des Systems. Über einen Ersatzkanal übermittelte Meldungen sind nach Wiederherstellung des Dienstes im System nachzuerfassen. Zugangsdaten und Verfahren sollten vor einem Vorfall direkt auf der KNF-Webseite geprüft werden.^[15]

Die Mitteilung einer erheblichen Cyberbedrohung ist freiwillig. Beeinträchtigt ein schwerwiegender IKT-Vorfall finanzielle Interessen von Kunden, verlangt Artikel 19 Absatz 3 eine unverzügliche Information über den Vorfall und über Maßnahmen zur Begrenzung seiner Auswirkungen. Derselbe Vorfall kann zusätzlich Meldepflichten nach DSGVO oder anderen Vorschriften auslösen; eine DORA-Meldung ersetzt andere Meldungen nicht automatisch.

Resilienztests und TLPT

Das Testprogramm muss risikobasiert sein und angemessene Techniken umfassen: von Schwachstellenbewertungen, Scans und Konfigurationsprüfungen bis zu szenariobasierten Tests, Kontinuitäts-, Leistungs-, End-to-End- und Penetrationstests. Systeme und Anwendungen, die kritische oder wichtige Funktionen unterstützen, sind regelmäßig zu testen; Umfang und Intensität müssen Risiken und Änderungen berücksichtigen.

TLPT betrifft nicht automatisch jedes Unternehmen

Threat-Led Penetration Testing wird von Unternehmen durchgeführt, die die zuständige Behörde nach den Kriterien von DORA und der Delegierten Verordnung (EU) 2025/1190 bestimmt. Die Grundfrequenz beträgt mindestens einmal in drei Jahren, kann jedoch je nach Risikoprofil und betrieblichen Umständen durch die Behörde verringert oder erhöht werden. Kleinstunternehmen und Unternehmen, die den vereinfachten Rahmen nach Artikel 16 Absatz 1 anwenden, sind von dieser Pflicht ausgenommen.^[7]

TLPT umfasst kritische oder wichtige Funktionen und Produktionssysteme einschließlich wesentlicher Abhängigkeiten zu Dienstleistern. Der Prozess enthält Scoping, Threat Intelligence, kontrollierte Red-Team-Aktivitäten, Abschluss und Maßnahmenplan. Ein gewöhnlicher Anwendungspentest wird nicht dadurch zu TLPT, dass realistische Angriffsszenarien verwendet werden.

Die Sicherheit des Tests bleibt wesentlich: Umfang, Abbruchkriterien, Vertraulichkeit, Krisenkommunikation und Verantwortung für Produktionssysteme müssen vor Beginn vereinbart sein. DORA rechtfertigt kein unkontrolliertes Testen in Produktion.

IKT-Dienstleister, Verträge und Informationsregister

Die Nutzung externer Dienste überträgt die regulatorische Verantwortung nicht. Das Finanzunternehmen muss Risiken über den gesamten Vertragslebenszyklus steuern: von Funktionsklassifizierung und Due Diligence über Verhandlung, Überwachung und Audit bis zu Vertragsende und Exit-Planung.

Das Register umfasst alle Vereinbarungen über IKT-Dienste

Artikel 28 Absatz 3 verlangt ein laufend aktualisiertes Informationsregister über sämtliche vertraglichen Vereinbarungen zu IKT-Diensten. Vereinbarungen, die kritische oder wichtige Funktionen unterstützen, müssen eindeutig gekennzeichnet sein. Standardvorlagen und Taxonomien bestimmt die Durchführungsverordnung (EU) 2024/2956.^[8]

Verträge müssen das Risiko abbilden

Artikel 30 nennt erforderliche Vertragsbestandteile, darunter Leistungsbeschreibung und Standorte, Datenschutz, Unterstützung bei Vorfällen, Pflichten nach Vertragsende sowie Zusammenarbeit mit Behörden. Für Dienste zur Unterstützung kritischer oder wichtiger Funktionen kommen Anforderungen an Service Levels, Kontinuitätspläne, Teilnahme an Tests, Zugangs-, Inspektions- und Audit-Rechte sowie Exit-Strategien hinzu. Die Delegierte Verordnung (EU) 2024/1773 konkretisiert die Richtlinie für diese Vertragsbeziehungen.^[9]

Unterauftragsvergabe

Die Delegierte Verordnung (EU) 2025/532 verlangt die Bewertung von Unterauftragnehmerketten, die kritische oder wichtige Funktionen unterstützen. Verträge sollten Bedingungen der Unterbeauftragung, Information über wesentliche Änderungen, Kontrollrechte und Kündigungsfälle regeln. Eine ausschließliche Abstützung auf die Bewertung des Hauptdienstleisters beseitigt die Verantwortung des Finanzunternehmens nicht.^[10]

CTPP: direkte Aufsicht über kritische Anbieter

Die Europäischen Aufsichtsbehörden veröffentlichten am 18. November 2025 die erste Liste von 19 kritischen IKT-Drittdienstleistern. Darunter befanden sich Unternehmen aus Gruppen wie Accenture, AWS, Google Cloud, IBM, Microsoft, Oracle und SAP sowie Betreiber von Telekommunikations- und Rechenzentrumsinfrastruktur. Die Liste ist mindestens jährlich zu aktualisieren.^[11]

Für jeden CTPP wird ein Lead Overseer benannt. Dieser bewertet das Risikomanagement, kann Inspektionen durchführen und Empfehlungen aussprechen. Die Einstufung als CTPP ist kein Sicherheitszertifikat und entbindet Finanzunternehmen nicht von Due Diligence, Konzentrationsrisikomanagement oder Exit-Planung.^[12]

Kooperiert ein CTPP nicht mit der Aufsicht, kann der Lead Overseer ein periodisches Zwangsgeld in Höhe von 1 % des durchschnittlichen täglichen weltweiten Umsatzes des Vorjahres für jeden Tag der Nichtbefolgung verhängen, höchstens für sechs Monate. Dies ist kein allgemeiner Bußgeldtarif für Finanzunternehmen.^[1]

Freiwilliger Informationsaustausch

Artikel 45 erlaubt Finanzunternehmen, Informationen und Analysen über Cyberbedrohungen in vertrauenswürdigen Gemeinschaften auszutauschen, wenn dies der Resilienz dient und Vertraulichkeit, personenbezogene Daten und Geschäftsgeheimnisse geschützt werden. Es handelt sich um eine Möglichkeit, nicht um eine Pflicht zur Weitergabe vollständiger Logbestände. Rechtsgrundlage, Datenklassifizierung, Minimierung und Regeln für Weitergabe sollten vorab festgelegt werden.

DORA, NIS2, KSC und DSGVO

DORA und NIS2

NIS2 behandelt DORA für erfasste Finanzunternehmen als sektorspezifischen Unionsrechtsakt mit zumindest gleichwertiger Wirkung hinsichtlich IKT-Risikomanagement und Meldung schwerwiegender Vorfälle. Daraus folgt nicht, dass jede Rechtsfrage eines Finanzunternehmens ausschließlich durch DORA geregelt wird. Anwendungsbereich, Gegenstand und nationale Vorschriften sind miteinander abzugleichen.^[13]

DORA und das polnische KSC

Das polnische Gesetz von 2025 führte Artikel 16a in das KSC ein, um bestimmte Doppelpflichten für Betreiber in Bankwesen und Finanzmarktinfrastruktur im DORA-Bereich zu begrenzen. Die KSC-Novelle von 2026 zur Umsetzung von NIS2 ändert nichts daran, dass beide Regime anhand ihres aktuellen Wortlauts geprüft werden müssen.

DORA und DSGVO

DORA schützt die operationale Resilienz und erfasst IKT-Vorfälle; die DSGVO regelt die Verarbeitung personenbezogener Daten und Verletzungen ihres Schutzes. Die rechtlichen Prüfmaßstäbe sind unterschiedlich. Ein Ereignis kann unter beiden, unter einem oder unter keinem der beiden Regime meldepflichtig sein - abhängig von der DORA-Klassifikation und dem Risiko für Rechte und Freiheiten betroffener Personen.^[14]

Umsetzung und Nachweise organisieren

1. Anwendungsbereich bestätigen. Regulatorischen Status, Niederlassungen, Ausnahmen und zuständige Behörden bestimmen.
2. Funktionen identifizieren. Kritische oder wichtige Funktionen, Prozesse, Verantwortliche und Störungstoleranz festlegen.
3. Abhängigkeiten abbilden. Funktionen mit Assets, Daten, Anwendungen, Standorten und IKT-Dienstleistern verknüpfen.
4. Risikomanagement prüfen. Leitungsentscheidungen, Richtlinien, Rollen, Ressourcen, Kennzahlen und Reporting verifizieren.
5. Vorfälle üben. Klassifikation, beide Zeituhren der Erstmeldung, Formulare, Kommunikation und parallele Meldewege testen.
6. Register ordnen. Identifikatoren, Taxonomien, Vertragsvollständigkeit und Datenqualitätskontrollen abstimmen.
7. Verträge nachbessern. Dienste für kritische oder wichtige Funktionen und deren Unterauftragnehmerketten priorisieren.
8. Testprogramm aufbauen. Tests mit Risiko, Änderungen und Funktionen verknüpfen; TLPT nur vorbereiten, wenn die Pflicht tatsächlich besteht.
9. Nachweise sichern. Beschlüsse, Berichte, Logs, Testergebnisse und akzeptierte Ausnahmen sollten Umfang, Datum, Verantwortlichen und Folgemaßnahmen ausweisen.

Es gibt keine universellen Kosten oder Zeitpläne für die DORA-Umsetzung. Aufwand hängt von Lizenzmodell, Architektur, Vertragslage, Zahl der Dienstleister, Qualität der Inventarisierung und Reife des Incident-Prozesses ab. Eine fertige Richtlinie ohne Umsetzung und Nachweise schließt keine Lücke.

Häufige Fehler

• Beschränkung des Programms auf das Security-Team ohne Business Owner und Leitungsorgan;
• Behandlung jedes Vertrags als Outsourcing oder umgekehrt das Übersehen von IKT-Diensten als Bestandteil größerer Leistungen;
• Führung des Registers nur für Anbieter kritischer oder wichtiger Funktionen;
• keine rund-um-die-Uhr-Fähigkeit zur Klassifikation und Freigabe einer Incident-Meldung;
• Verwechslung eines gewöhnlichen Penetrationstests mit TLPT;
• Akzeptieren eines Dienstleisterberichts als Ersatz für die eigene Risikobewertung;
• fehlende belastbare Exit-Strategie und keine Wiederherstellungstests;
• Annahme, ein ISO/IEC-27001-Zertifikat beweise automatisch DORA-Konformität.