DORA ist da: Was Finanzunternehmen in der DACH-Region jetzt tun müssen

Der Digital Operational Resilience Act ist seit dem 17. Januar 2025 anwendbar und stellt die bedeutendste Überarbeitung der IKT-Risikomanagement-Regulierung für den europäischen Finanzsektor seit einer Generation dar. Für Finanzunternehmen in Deutschland und Österreich ist die Compliance-Frist verstrichen, und die aufsichtliche Prüfung intensiviert sich nun; Schweizer Häuser mit EU-Geschäft und die IKT-Drittdienstleister der Finanzunternehmen trifft DORA mittelbar.

Der Digital Operational Resilience Act (Verordnung (EU) 2022/2554, DORA) schafft einen einheitlichen Satz an Anforderungen für die Sicherheit der Netz- und Informationssysteme, die die Geschäftsprozesse von Finanzunternehmen unterstützen. Erstmals hat die EU einen einheitlichen, unmittelbar anwendbaren Rahmen für IKT-Risikomanagement, Vorfallsmeldung, Tests der operativen Resilienz, Drittanbieter-Risikomanagement und Informationsaustausch für den gesamten regulierten Finanzsektor formuliert. DORA ersetzt ein fragmentiertes Geflecht sektorspezifischer und nationaler Regeln durch eine konsolidierte Verordnung und einen Satz technischer Standards auf europäischer Ebene, die in allen Mitgliedstaaten einheitlich gelten.

Dieser Artikel führt umfassend durch DORA für Finanzunternehmen in der DACH-Region: Anwendungsbereich und Zielsetzung, die fünf inhaltlichen Säulen, die von den Europäischen Aufsichtsbehörden veröffentlichten Level-2-Maßnahmen, die spezifischen Implikationen für Deutschland, Österreich und die Schweiz, das Verhältnis zu bestehenden Rahmenwerken wie den BAIT sowie den praktischen Compliance-Fahrplan, den Unternehmen jetzt umsetzen sollten. Das Ziel: Vorständen, Compliance-Funktionen und Führungskräften das Verständnis zu vermitteln, das sie benötigen, um ihren Ist-Zustand gegen die DORA-Erwartungen zu bewerten und die Remediation-Aktivitäten zu planen, die das aufsichtliche Engagement zunehmend verlangen wird.

DORA im Kontext: Warum er verabschiedet wurde

Die Begründung für DORA beruht auf einer einfachen Beobachtung: Der europäische Finanzsektor ist in kritischer Weise von Informations- und Kommunikationstechnologie abhängig geworden, während das regulatorische Rahmenwerk für IKT-Risikomanagement fragmentiert, inkonsistent und den aktuellen Bedrohungen zunehmend nicht gewachsen war. Einzelne Aufsichtsbehörden hatten sektorspezifische Erwartungen formuliert – die BAIT in Deutschland für Banken, entsprechende Rundschreiben für Versicherungen und Kapitalverwaltungsgesellschaften –, doch diese Erwartungen variierten über Jurisdiktionen, Sektoren und in der Tiefe ihrer Abdeckung. Das Ergebnis war ein Flickenteppich, der wesentliche Lücken hinterließ und grenzüberschreitend tätigen Instituten uneinheitliche Lasten auferlegte.

DORAs Antwort lautet: Harmonisierung. Durch die Schaffung einer einheitlichen Verordnung, die in allen Mitgliedstaaten unmittelbar gilt, begründet DORA eine gemeinsame Grundlage für IKT-Risikomanagement, Vorfallsmeldung, Tests, Drittanbieter-Aufsicht und Informationsaustausch. Die Verordnung wird ergänzt durch technische Regulierungsstandards (RTS) und technische Durchführungsstandards (ITS), die von den Europäischen Aufsichtsbehörden entwickelt wurden und die operativen Details liefern, die Unternehmen für die Gestaltung ihrer Compliance-Programme benötigen.

Wer fällt in den Anwendungsbereich?

DORA gilt für eine breite Palette von Finanzunternehmen, definiert durch Verweis auf ihre bestehenden Zulassungskategorien nach EU-Finanzdienstleistungsrecht. Zu den erfassten Unternehmen gehören:

• Kreditinstitute, die nach der Eigenkapitalrichtlinie zugelassen sind.
• Zahlungsinstitute, die unter der PSD2 zugelassen sind (einschließlich Kontoinformationsdienstleister).
• E-Geld-Institute, die unter der EMD2 zugelassen sind.
• Wertpapierfirmen, die unter MiFID II zugelassen sind.
• Krypto-Dienstleister (CASPs), die unter MiCA zugelassen sind.
• Versicherungs- und Rückversicherungsunternehmen nach Solvency II zusammen mit Versicherungsvermittlern.
• Einrichtungen der betrieblichen Altersversorgung (EbAV).
• Zentrale Gegenparteien (CCPs), Zentralverwahrer (CSDs), Handelsplätze und Transaktionsregister.
• Verwalter alternativer Investmentfonds (AIFM) und OGAW-Verwaltungsgesellschaften.
• Ratingagenturen, Referenzwertadministratoren, Schwarmfinanzierungsdienstleister und mehrere weitere Kategorien spezialisierter Finanzunternehmen.

Der Anwendungsbereich ist bewusst breit angelegt und spiegelt den Anspruch der Verordnung wider, den gesamten europäischen Finanzsektor abzudecken. Für eine abschließende Liste kleiner Unternehmenstypen gilt anstelle der Artikel 5 bis 15 ein vereinfachter IKT-Risikomanagementrahmen nach Artikel 16 DORA: kleine und nicht verflochtene Wertpapierfirmen, nach dem Zahlungsdienste- und E-Geld-Recht der EU ausgenommene Zahlungs- und E-Geld-Institute, nach der Eigenkapitalrichtlinie ausgenommene Institute und kleine Einrichtungen der betrieblichen Altersversorgung. Die Pflicht, schwerwiegende Vorfälle zu melden, bleibt auch für sie bestehen. Alle übrigen Unternehmen können sich nur auf den allgemeinen Verhältnismäßigkeitsgrundsatz des Artikels 4 stützen.

Entscheidend ist auch, dass DORA einen Aufsichtsrahmen für IKT-Drittdienstleister schafft, die von den Europäischen Aufsichtsbehörden als kritische IKT-Drittdienstleister (CTPPs) benannt werden. Nach einer solchen Benennung unterliegt ein CTPP der direkten Aufsicht durch die ESAs, einschließlich der Möglichkeit von Vor-Ort-Prüfungen, Empfehlungen und – wenn der Anbieter Auskünfte oder Prüfungen verweigert – Zwangsgeldern. Diese Erweiterung der aufsichtlichen Reichweite auf nicht-finanzielle IKT-Anbieter ist eines der innovativsten Merkmale von DORA.

Säule 1: IKT-Risikomanagement (Artikel 5 bis 16)

Die erste Säule von DORA legt die grundlegenden Erwartungen an das IKT-Risikomanagement fest. Artikel 5 bis 16 verpflichten Finanzunternehmen, ein solides, umfassendes und gut dokumentiertes IKT-Risikomanagement-Rahmenwerk einzurichten und aufrechtzuerhalten, das es ihnen ermöglicht, IKT-Risiken koordiniert zu identifizieren, zu schützen, zu erkennen, auf sie zu reagieren und von ihnen zu genesen.

Die Governance-Dimension dieser Säule ist zentral. DORA legt die Verantwortung für IKT-Risiken ausdrücklich beim Leitungsorgan des Finanzunternehmens. Das Leitungsorgan muss die IKT-Strategie, das IKT-Risikomanagement-Rahmenwerk, die Geschäftskontinuitätsrichtlinie und die Informationssicherheitsrichtlinie genehmigen. Es muss ein ausreichendes Budget für IKT-Risikomanagement bereitstellen, eine angemessene Personalausstattung sicherstellen und aktive Aufsicht führen. Von Vorstandsmitgliedern wird erwartet, dass sie über ausreichende Kenntnisse und Fähigkeiten verfügen, um IKT-Risiken zu verstehen, und die Verordnung begründet Weiterbildungsanforderungen für Mitglieder des Leitungsorgans.

Inhaltlich muss das IKT-Risikomanagement-Rahmenwerk folgende Elemente umfassen: eine mit der Gesamtgeschäftsstrategie abgestimmte IKT-Strategie; eine Abbildung aller IKT-gestützten Geschäftsfunktionen und ihrer Abhängigkeiten von konkreten Systemen und Prozessen; eine Business-Impact-Analyse, die identifiziert, welche Funktionen kritisch sind und welche Wiederherstellungsziele für jede gelten sollen; Schutzmaßnahmen zu Informationssicherheit, Zugriffskontrollen, Verschlüsselung und Netzwerksicherheit; Erkennungsmaßnahmen, die ungewöhnliche Aktivitäten identifizieren können; Reaktions- und Wiederherstellungsverfahren einschließlich Backup, Geschäftskontinuität und Disaster-Recovery-Arrangements; sowie einen Lernprozess, durch den Vorfälle und Beinahevorfälle die Weiterentwicklung des Rahmenwerks prägen.

Für deutsche Institute, die bisher den BAIT der BaFin unterlagen (Rundschreiben 10/2017, zuletzt in der Fassung vom 16. Dezember 2024), tritt DORA an deren Stelle und ist in mehreren Bereichen genauer: Die Erwartungen an das IKT-Asset-Management sind granularer, die Verschlüsselungsanforderungen präziser und die Pflichten zur Netzwerksegmentierung expliziter. Die sektorspezifischen Rundschreiben KAIT, VAIT und ZAIT hat die BaFin mit Ablauf des 16. Januar 2025 aufgehoben, um Doppelregulierung zu vermeiden. Seit DORA anwendbar ist, gelten die BAIT nur noch für Institute, die kein IKT-Risikomanagement nach DORA betreiben müssen; mit Ablauf des 31. Dezember 2026 werden sie vollständig aufgehoben.

Säule 2: IKT-bezogene Vorfallsmeldungen (Artikel 17 bis 23)

Die zweite Säule führt ein harmonisiertes Rahmenwerk für die Klassifizierung und Meldung IKT-bezogener Vorfälle ein. Unter DORA müssen Finanzunternehmen IKT-bezogene Vorfälle gegen Kriterien klassifizieren, die in den von den Europäischen Aufsichtsbehörden veröffentlichten technischen Regulierungsstandards definiert sind. Vorfälle, die die Schwellen zur Einstufung als schwerwiegend erreichen, müssen der zuständigen Behörde – der BaFin in Deutschland, der FMA in Österreich – mittels standardisierter Vorlagen gemeldet werden. Die Verordnung unterstützt auch die freiwillige Meldung erheblicher Cyberbedrohungen.

Die Meldefristen der Delegierten Verordnung (EU) 2025/301 sind anspruchsvoll. Die Erstmeldung muss innerhalb von 4 Stunden ab dem Zeitpunkt erfolgen, zu dem das Unternehmen den Vorfall als schwerwiegend einstuft, und in keinem Fall später als 24 Stunden, nachdem es von dem Vorfall Kenntnis erlangt hat. Eine Zwischenmeldung muss innerhalb von 72 Stunden nach der Erstmeldung folgen und ist zu aktualisieren, spätestens sobald der reguläre Betrieb wiederhergestellt ist. Die Abschlussmeldung ist spätestens einen Monat nach der Zwischenmeldung oder, falls es eine gab, nach der letzten aktualisierten Zwischenmeldung vorzulegen.

Die praktische Einhaltung dieser Fristen erfordert operative Bereitschaft, die viele Institute historisch nicht hatten. Die Vorfallserkennung muss schnell genug sein, um eine Klassifizierung innerhalb von Stunden zu ermöglichen. Die interne Governance muss so strukturiert sein, dass die Klassifizierungsentscheidung rasch getroffen werden kann, mit klarer Delegation von Befugnissen. Meldevorlagen müssen vorbefüllt und innerhalb des verfügbaren Zeitfensters prüfbar sein. Externe Kommunikation an Kunden, Gegenparteien und Öffentlichkeit muss mit der regulatorischen Meldung koordiniert werden.

Daneben können Finanzunternehmen erhebliche Cyberbedrohungen freiwillig an die zuständige Behörde melden (Art. 19 Abs. 2 DORA); eine Pflicht besteht nur für schwerwiegende IKT-bezogene Vorfälle. Die Verordnung unterstützt damit ein breiteres Ökosystem des Informationsaustauschs, das auf die Verbesserung der sektorweiten Resilienz abzielt.

Säule 3: Tests der digitalen operationellen Resilienz (Artikel 24 bis 27)

Die dritte Säule verpflichtet Finanzunternehmen, die Resilienz ihrer IKT-Systeme regelmäßig zu testen. Das Testregime ist nach Größe und Bedeutung gestaffelt: Alle erfassten Unternehmen müssen eine Grundstufe an Tests durchführen, während als bedeutend eingestufte Unternehmen zusätzlich bedrohungsgeleitete Penetrationstests (TLPT) durchführen müssen.

Die Grundanforderung an Tests verpflichtet Unternehmen zu einem umfassenden Testprogramm, das ihre kritischen IKT-Systeme und Anwendungen abdeckt. Dazu zählen Schwachstellenbewertungen, Open-Source-Analysen, Netzwerksicherheitsbewertungen, Lückenanalysen, physische Sicherheitsüberprüfungen, Fragebögen und Scanning-Softwarelösungen, Quellcode-Reviews soweit machbar, szenariobasierte Tests, Kompatibilitätstests, Performance-Tests, End-to-End-Tests und Penetrationstests. Das Programm muss risikobasiert umgesetzt werden, wobei Tiefe und Häufigkeit der Tests an die Kritikalität der beteiligten Systeme angepasst sein müssen.

Für bedeutende Unternehmen führt DORA verpflichtende bedrohungsgeleitete Penetrationstests ein. TLPT ist eine fortgeschrittene Form des Tests, bei dem ein Red Team, ausgestattet mit maßgeschneiderter Threat Intelligence, versucht, die kritischen Funktionen des Unternehmens in einer realistischen Simulation des Verhaltens eines Angreifers zu kompromittieren. Die Methodik ist eng am TIBER-EU-Rahmenwerk der Europäischen Zentralbank und der nationalen Zentralbanken ausgerichtet, das im Mai 2018 veröffentlicht wurde und national in Deutschland als TIBER-DE von der Deutschen Bundesbank umgesetzt wird.

TLPT unter DORA muss für betroffene Unternehmen mindestens alle drei Jahre durchgeführt werden. Er muss die kritischen Funktionen des Unternehmens abdecken, von qualifizierten und unabhängigen Testern durchgeführt werden, einer strukturierten Methodik folgen, die Threat Intelligence, Red-Teaming und eine Abschlussphase umfasst, und mit einem Remediationsplan für identifizierte Schwächen abschließen. Die Kosten und die operative Auswirkung einer vollständigen TLPT-Übung sind erheblich, und betroffene Unternehmen sollten ihre Testzyklen sorgfältig planen, um sowohl die Kosten als auch die Störung des Normalbetriebs zu steuern.

Säule 4: IKT-Drittanbieter-Risikomanagement (Artikel 28 bis 44)

Die vierte Säule hat für Finanzunternehmen die größte operative Komplexität erzeugt und ist der Bereich, an dem viele Institute noch arbeiten. Artikel 28 bis 44 DORA begründen einen umfassenden Rahmen zur Steuerung der Risiken, die aus der Abhängigkeit von IKT-Drittdienstleistern erwachsen, einschließlich Cloud-Dienstleistern, Managed-Service-Providern, Software-Anbietern und Datenhosting-Anbietern.

Die grundlegende Pflicht ist das Informationsregister (Register of Information, RoI), das jedes erfasste Finanzunternehmen führen und seiner zuständigen Behörde vorlegen muss. Das Register muss detaillierte Informationen über alle IKT-Drittanbieter-Vereinbarungen enthalten, einschließlich der Art der Dienste, der Gegenparteiidentität, des geografischen Ortes der Diensterbringung und Datenspeicherung, der Identifizierung etwaiger Unterauslagerungen und der Einstufung der Vereinbarung als Unterstützung einer kritischen oder wichtigen Funktion. Die für das RoI erforderlichen Informationen sind in den von den ESAs veröffentlichten technischen Durchführungsstandards spezifiziert.

DORA begründet zudem verpflichtende Vertragsklauseln für IKT-Drittanbieter-Vereinbarungen. Artikel 30 legt die Mindestklauseln fest, die in Verträge mit IKT-Anbietern aufgenommen werden müssen, und deckt Bereiche wie Leistungsbeschreibungen, Service Levels, Datenschutz, Ort der Datenverarbeitung, Prüfungsrechte, Vorfallsbenachrichtigung, Geschäftskontinuitätsregelungen, Kündigungsrechte, Unterstützung bei Aufsichtsanfragen und Zusammenarbeit mit Aufsichtsbehörden ab. Für Vereinbarungen, die kritische oder wichtige Funktionen unterstützen, gelten zusätzliche Anforderungen, einschließlich Exit-Strategie-Bestimmungen und erweiterter Prüfungsrechte.

Die praktische Herausforderung lag in der Nachverhandlung bestehender Verträge, um diesen Anforderungen gerecht zu werden. Viele Finanzunternehmen sind stark von standardisierten Bedingungen großer Cloud-Dienstleister abhängig, und die Verhandlungsposition einzelner Finanzunternehmen gegenüber diesen Anbietern ist begrenzt. Die Hyperscale-Cloud-Anbieter haben mit DORA-spezifischen Vertragsänderungen reagiert, doch der Prozess, diese über den Bestand bestehender Verträge auszurollen, hat sektorweit erhebliche Ressourcen gebunden.

Die Benennung kritischer IKT-Drittdienstleister (CTPPs) durch die Europäischen Aufsichtsbehörden führt eine neue Ebene direkter aufsichtlicher Kontrolle ein. Nach erfolgter Benennung unterliegt ein CTPP der Aufsicht durch einen Lead Overseer unter den ESAs, der Informationen anfordern, Untersuchungen und Vor-Ort-Prüfungen durchführen und Empfehlungen aussprechen kann; Auskunfts- und Prüfungsverlangen kann er mit periodischen Zwangsgeldern durchsetzen. Dies ist eine genuin neuartige Erweiterung der aufsichtlichen Reichweite auf nicht-finanzielle Unternehmen und markiert eine bedeutende Entwicklung in der EU-Regulierungspolitik.

Säule 5: Informationsaustausch (Artikel 45)

Die fünfte Säule von DORA fördert – verpflichtet aber nicht zu – den Austausch von Cyberbedrohungsinformationen zwischen Finanzunternehmen. Artikel 45 schafft eine Rechtsgrundlage für freiwillige Informationsaustauschvereinbarungen zwischen Finanzunternehmen, die es ihnen erlauben, Kompromissindikatoren, Taktiken, Techniken und Verfahren (TTPs), Cybersicherheitswarnungen und Konfigurationstools auszutauschen. Ein solcher Austausch muss den Datenschutzanforderungen entsprechen und darf keine kommerziell sensiblen Informationen offenlegen.

In der Praxis hat die Branche diese Säule begrüßt, die lange den Wert kollektiver Intelligenz bei der Abwehr zunehmend ausgefeilter Cyberbedrohungen anerkannt hat. Informations- und Analysezentren des Finanzsektors (ISACs), vertrauenswürdige Gemeinschaften und sektorspezifische Threat-Intelligence-Plattformen bilden die operativen Vehikel, über die Vereinbarungen nach Artikel 45 umgesetzt werden. Die Säule schafft an sich keine neuen Compliance-Lasten; vielmehr beseitigt sie die rechtliche Unsicherheit, die zuvor einige Unternehmen davon abgehalten hatte, an Informationsaustauschvereinbarungen teilzunehmen.

Die Level-2-Maßnahmen: RTS und ITS

DORA schafft den hochrangigen Rahmen, doch viele operative Details finden sich in Level-2-Maßnahmen – technischen Regulierungsstandards (RTS) und technischen Durchführungsstandards (ITS), die von den Europäischen Aufsichtsbehörden (EBA, ESMA, EIOPA, gemeinsam die ESAs) entwickelt und von der Europäischen Kommission angenommen werden. Diese technischen Standards decken Bereiche wie die Kriterien für die Einstufung von Vorfällen als schwerwiegend, den Inhalt und das Format von Vorfallsmeldungen, den Inhalt des Informationsregisters, die Methodik für bedrohungsgeleitete Penetrationstests, die Kriterien für die Benennung kritischer IKT-Drittdienstleister und den detaillierten Inhalt von IKT-Risikomanagement-Rahmenwerken ab.

Die ESAs haben die technischen Standards in zwei Tranchen vorgelegt. Die erste Tranche vom Januar 2024 betraf das IKT-Risikomanagement, die Kriterien für die Einstufung von Vorfällen, die Leitlinie für IKT-Dienste zur Unterstützung kritischer oder wichtiger Funktionen und das Informationsregister. Die zweite Tranche vom Juli 2024 betraf Inhalt, Format und Fristen der Vorfallsmeldungen (heute Delegierte Verordnung (EU) 2025/301), bedrohungsgeleitete Penetrationstests und die Überwachung kritischer IKT-Drittdienstleister. Finanzunternehmen sollten sicherstellen, dass ihre Compliance-Programme die aktuellsten angenommenen Versionen dieser Standards referenzieren, und Compliance-Funktionen sollten die laufende Arbeit der ESAs in diesem Bereich aufmerksam verfolgen.

Verhältnismäßigkeit: Wie DORA skaliert

Eine der politischen Herausforderungen bei der Ausarbeitung von DORA war die verhältnismäßige Kalibrierung einer Verordnung, die über einen Sektor hinweg gelten soll, der von den größten global systemrelevanten Instituten bis hin zu kleinen Wertpapierfirmen und Schwarmfinanzierungsplattformen reicht. DORA adressiert dies durch den allgemeinen Verhältnismäßigkeitsgrundsatz des Artikels 4 und durch Artikel 16, der für bestimmte kleine Unternehmenstypen ein vereinfachtes Regime begründet.

Das vereinfachte Regime ersetzt die Artikel 5 bis 15 durch einen schlankeren IKT-Risikomanagementrahmen; es steht nur den in Artikel 16 genannten Unternehmenstypen offen, nicht jedem kleinen Institut. Unternehmen, die dem vereinfachten Regime unterliegen, müssen weiterhin ein IKT-Risikomanagement-Rahmenwerk umsetzen, schwerwiegende Vorfälle melden und das Informationsregister führen, doch das erwartete Detailniveau ist an ihre Größe angepasst. Wie streng der vereinfachte Rahmen in der Praxis geprüft wird, wird die nationale Aufsichtspraxis im Zeitverlauf prägen.

Über Artikel 16 hinaus ist Verhältnismäßigkeit durch die operativen Bestimmungen der Verordnung hindurch verwoben. Häufigkeit und Tiefe der Tests, Granularität der Risikobewertungen, Ausgereiftheit der Vorfallsreaktionsarrangements und Formalität der Governance-Strukturen können alle an die Größe und Komplexität des Unternehmens angepasst werden. Diese Verhältnismäßigkeit ist ein echtes Merkmal der Verordnung, kein Schlupfloch, und Unternehmen sollten sich inhaltlich damit auseinandersetzen, statt anzunehmen, dass die volle Übernahme der anspruchsvollsten Erwartungen stets erforderlich sei.

Verhältnis zu bestehenden Rahmenwerken: BAIT und NIS2

Für deutsche Finanzunternehmen hat DORA die IT-Rundschreiben der BaFin weitgehend abgelöst. KAIT, VAIT und ZAIT wurden mit Ablauf des 16. Januar 2025 aufgehoben. Aus dem Anwenderkreis der BAIT sind alle Institute ausgenommen, die ein IKT-Risikomanagement nach DORA betreiben müssen; die BAIT gelten nur noch übergangsweise für Institute außerhalb von DORA und werden mit Ablauf des 31. Dezember 2026 vollständig aufgehoben. Die praktische Konsequenz: Institute im Anwendungsbereich von DORA müssen nicht zwei Rahmenwerken zugleich genügen; maßgeblich sind DORA und die dazugehörigen technischen Standards.

DORA verzahnt sich zudem mit der NIS2-Richtlinie (Richtlinie (EU) 2022/2555), die Cybersicherheitsanforderungen für einen breiteren Sektorenkreis jenseits der Finanzdienstleistungen festlegt. Für Finanzunternehmen im Anwendungsbereich von DORA gelten die NIS2-Vorschriften zu Risikomanagement, Meldepflichten und Aufsicht nicht (Art. 4 NIS2); an ihre Stelle tritt DORA. Unternehmen, die Teil größerer Konzerngruppen mit nicht-finanziellen Aktivitäten sind, müssen gegebenenfalls dennoch beide Regime über ihren Konzern hinweg steuern. Die Verzahnung wird über das Lex-specialis-Prinzip vermittelt, wonach die spezifischere Finanzsektor-Verordnung (DORA) für Finanzunternehmen Vorrang vor der allgemeinen Cybersicherheitsrichtlinie (NIS2) hat.

DORA in Deutschland: Der Ansatz der BaFin

Die BaFin hat die DORA-Umsetzung als Konsolidierung und Vertiefung ihres bestehenden aufsichtlichen Fokus auf IKT-Risikomanagement angegangen. Deutsche Institute, die bereits stark in die BAIT-Compliance investiert hatten, stellten fest, dass DORA ihre bestehenden Arrangements erweitert statt verdrängt, wenngleich die neuen Anforderungen zu Vorfallsmeldungsfristen, Drittanbieter-Risikomanagement und Tests echten zusätzlichen Aufwand erfordert haben.

Das aufsichtliche Engagement der BaFin mit DORA hat die Bedeutung echter operativer Leistungsfähigkeit gegenüber dokumentarischer Compliance betont. Von Instituten wird erwartet, dass sie nachweisen können, dass ihre Vorfallsreaktionsverfahren in der Praxis funktionieren, dass ihre Drittanbietervereinbarungen aktiv gesteuert werden und dass ihre Testprogramme substanziell sind. Thematische Aufsichtsreviews, Vor-Ort-Prüfungen und gezielte Informationsanforderungen wurden von der BaFin sämtlich als Werkzeuge zur Bewertung der DORA-Bereitschaft im deutschen Finanzsektor eingesetzt.

Für neu lizenzierte Institute ist die Integration der DORA-Anforderungen in den Lizenzantrag selbst zu einem Standardelement der BaFin-Prüfung geworden. Zahlungsinstitute, E-Geld-Institute und Wertpapierfirmen, die heute Anträge einreichen, müssen im Antragspaket darlegen, wie sie DORA-konform sein werden, und die BaFin prüft diese Darlegungen inhaltlich. Gründer, die annehmen, dass DORA-Compliance nach Zulassung nachgeholt werden kann, werden mit Nachforderungen konfrontiert, die das Antragsverfahren verlängern und im schlimmsten Fall die Zulassungserteilung blockieren.

DORA in Österreich: Engagement der FMA

Die österreichische FMA hat Leitlinien zu ihren Erwartungen an die DORA-Umsetzung veröffentlicht und DORA-Aufsicht in ihr laufendes Engagement mit beaufsichtigten Unternehmen integriert. Österreichische Institute profitieren von der allgemeinen Zugänglichkeit der FMA und der Bereitschaft der Behörde, sich inhaltlich mit Auslegungsfragen auseinanderzusetzen. Der Aufsichtsansatz der FMA zu DORA spiegelt ihre allgemeine Philosophie wider: rigorose Anwendung von EU-Standards in Kombination mit praktischem Dialog zu Umsetzungsfragen.

Für kleinere österreichische Institute ist der Verhältnismäßigkeitsgrundsatz des Artikels 4 DORA besonders wichtig; das vereinfachte Regime des Artikels 16 steht nur den dort genannten Unternehmenstypen offen. Die FMA hat ihre Bereitschaft signalisiert, mit Unternehmen an der praktischen Kalibrierung von Compliance-Programmen an ihre Größe und ihr Risikoprofil zu arbeiten, doch dies verringert nicht die Kernanforderungen an Vorfallsmeldung, Governance und Drittanbieter-Risikomanagement.

Auch die Verzahnung von DORA mit bestehenden FMA-Erwartungen zu IT-Governance und Auslagerung verdient Aufmerksamkeit. Österreichische Institute, die bereits den Rundschreiben und Leitlinien der FMA in diesen Bereichen entsprochen haben, finden, dass DORA ihre bestehenden Arrangements erweitert und nicht ersetzt, wenngleich die neuen Anforderungen zu Meldefristen und Drittanbieter-Verträgen echten inkrementellen Aufwand erfordert haben. Compliance-Funktionen sollten eine Gap-Analyse zwischen ihrem bestehenden Zustand und den DORA-Erwartungen durchführen und die Ergebnisse in ein priorisiertes Umsetzungsprogramm überführen.

DORA und die Schweiz: Indirekte Exposition

Die Schweiz stellt einen Sonderfall dar. Als Nicht-EU- und Nicht-EWR-Jurisdiktion gilt DORA nicht direkt für Schweizer Finanzinstitute. Schweizer Unternehmen, die EU-Kunden über Niederlassungen oder Tochtergesellschaften bedienen, Schweizer Unternehmen, deren IKT-Anbieter auch Dienste an EU-Finanzunternehmen erbringen, und Schweizer Unternehmen, die an EU-Finanzmarktinfrastrukturen teilnehmen, stehen jedoch alle einer indirekten Compliance-Exposition gegenüber.

Der eigene FINMA-Rahmen für IKT-Risikomanagement und operationelle Resilienz ist primär im FINMA-Rundschreiben 2023/1 ‚Operationelle Risiken und Resilienz – Banken‘ sowie in weiteren Leitlinien zu Auslagerung und Cyberrisiken formuliert. Der Schweizer Rahmen weist konzeptionelle Ähnlichkeiten mit DORA auf – Betonung von Governance, Risikomanagement und Resilienz –, unterscheidet sich aber in spezifischer Terminologie, Vorfallsmeldungsfristen und Drittanbieter-Bestimmungen. Schweizer Unternehmen, die EU-gerichtete Geschäfte aufbauen, sollten einen harmonisierten Rahmen planen, der sowohl den Schweizer als auch den DORA-Erwartungen genügt, statt sie als unabhängige Compliance-Stränge zu behandeln.

Die praktische Konsequenz für Schweizer Gruppen mit EU-Tochtergesellschaften besteht darin, dass sie ein gruppenweites IKT-Risikomanagement-Modell aufbauen müssen, in dem die EU-Tochter DORA-konform ist und die Schweizer Muttergesellschaft den FINMA-Erwartungen genügt, während konzerninterne Dienstleistungen und Abhängigkeiten so dokumentiert sind, dass sie beide Aufsichtssichtweisen befriedigen. Diese Integration ist mit zusätzlichem Aufwand verbunden, bietet aber auch die Möglichkeit, ein einheitliches Resilienz-Betriebsmodell zu schaffen, das in beiden Jurisdiktionen als ausgereift wahrgenommen wird.

DORA für CASPs: Eine neue Compliance-Ebene

Unter MiCA zugelassene Krypto-Dienstleister unterliegen DORA ab dem Zeitpunkt, zu dem ihre MiCA-Zulassung wirksam wird. Dies schafft eine interessante Compliance-Verzahnung: CASPs müssen gleichzeitig ihre Governance- und operativen Rahmenwerke so aufbauen, dass sie den MiCA-Anforderungen genügen und die DORA-Erwartungen zu IKT-Risikomanagement, Vorfallsmeldung, Tests und Drittanbieter-Risikomanagement erfüllen. Für Neueinsteiger, die Greenfield-CASP-Betriebe aufbauen, schafft dies die Chance, von Anfang an einen einheitlichen Compliance-Rahmen zu gestalten; für bestehende Krypto-Unternehmen, die sich an das neue regulatorische Umfeld anpassen, kann es eine erhebliche Steigerung der operativen Erwartungen darstellen.

Die DORA-Anforderungen haben für CASPs besondere Bedeutung, weil Krypto-Operationen typischerweise starke Abhängigkeit von Cloud-Infrastruktur, spezialisierten Drittdiensten (Verwahrung, Blockchain-Analyse, Node-Betrieb) und komplexen Technologie-Beständen umfassen. Das Informationsregister, die Vertragsklausel-Anforderungen und die Vorfallsmeldungspflichten gelten in vollem Umfang, und CASPs sollten diese Erwartungen vom Zeitpunkt der Aufnahme ihrer regulierten Tätigkeit an erfüllen.

Für Gründer, die einen CASP-Antrag vorbereiten, bedeutet dies, dass die DORA-Dokumentation Teil des ursprünglichen Antragspakets sein muss. Aufsichtsbehörden erwarten, dass neue CASPs bei Aufnahme der Tätigkeit DORA-konform sind, und die Zulassungsprüfung deckt häufig Elemente wie die IKT-Risikomanagement-Rahmenwerke, die Vorfallsreaktionsverfahren und die Drittanbieter-Register ab. Der Aufbau von MiCA- und DORA-Compliance als parallele Arbeitsstränge – statt als sequenzielle Projekte – ist für die meisten neuen CASPs der praktikable Weg.

Die Benennung kritischer IKT-Drittdienstleister

Die Benennung kritischer IKT-Drittdienstleister ist eine der folgenreichsten Innovationen von DORA. Nach der Verordnung benennen die Europäischen Aufsichtsbehörden bestimmte IKT-Anbieter als kritisch auf Grundlage von Kriterien wie den systemischen Auswirkungen auf die Finanzstabilität im Falle eines Ausfalls des Anbieters, der Anzahl und Bedeutung der vom Anbieter abhängigen Finanzunternehmen, der Substituierbarkeit des Anbieters und der Konzentration der Diensterbringung im Anbieter.

Nach der Benennung unterliegt ein CTPP der direkten Aufsicht durch einen Lead Overseer, der eine der ESAs ist, die im Namen aller Aufsichtsbehörden handelt. Der Lead Overseer kann Informationen anfordern, allgemeine Untersuchungen und Vor-Ort-Prüfungen durchführen und Empfehlungen aussprechen. Kommt ein Anbieter einem Auskunfts-, Untersuchungs- oder Prüfungsverlangen nicht nach, kann der Lead Overseer ein tägliches Zwangsgeld von bis zu 1 Prozent des durchschnittlichen weltweiten Tagesumsatzes verhängen, höchstens sechs Monate lang (Art. 35 Abs. 6 bis 8 DORA). Erklärt ein Anbieter nicht binnen 60 Kalendertagen, einer Empfehlung zu folgen, und begründet er das nicht ausreichend, macht der Lead Overseer dies öffentlich bekannt; als letztes Mittel können die zuständigen Behörden von Finanzunternehmen verlangen, die Nutzung des Dienstes auszusetzen oder den Vertrag zu kündigen (Art. 42 DORA). Die Aufsicht soll den Aufsichtsbehörden Sichtbarkeit und Hebelwirkung über Anbieter verschaffen, deren Ausfall systemische Folgen hätte, obwohl die Anbieter selbst keine Finanzunternehmen sind.

Am 18. November 2025 haben die Europäischen Aufsichtsbehörden erstmals kritische IKT-Drittdienstleister benannt und die Liste veröffentlicht; nach Artikel 31 Absatz 9 DORA wird sie jährlich aktualisiert. Finanzunternehmen sollten prüfen, ob ihre wichtigsten IKT-Anbieter auf der Liste stehen, und verstehen, dass benannte Anbieter direkter aufsichtlicher Kontrolle unterliegen, auch wenn das Finanzunternehmen selbst der primäre regulatorische Ansprechpartner bleibt.

Das Informationsregister im Detail

Das Informationsregister ist eine der greifbarsten Compliance-Pflichten von DORA und hat bei vielen Finanzunternehmen erheblichen Aufwand gebunden. Das Register muss strukturierte Informationen zu jeder IKT-Drittanbieter-Vereinbarung enthalten, mit einem höheren Detailniveau für Vereinbarungen, die kritische oder wichtige Funktionen unterstützen. Die ESAs haben technische Durchführungsstandards veröffentlicht, die die exakten Datenfelder, Codes und Formatierungen spezifizieren, die im Register erwartet werden.

Die praktische Herausforderung besteht für die meisten Institute nicht darin zu verstehen, was das Register erfordert, sondern darin, die zugrundeliegenden Daten aus fragmentierten Quellen zusammenzuführen. Informationen über IKT-Anbieter sind typischerweise auf Beschaffungssysteme, Vertragsrepositorien, Finanzsysteme und informelle Lieferantenbeziehungen verteilt, und ihre Konsolidierung in ein einziges Register, das den ITS-Format-Anforderungen genügt, erfordert koordinierten Einsatz über mehrere interne Funktionen hinweg. Unternehmen, die diese Arbeit Anfang 2024 begannen, waren für den Wirksamkeitstermin Januar 2025 im Allgemeinen besser aufgestellt als solche, die gewartet haben.

Das Register muss aktuell gehalten werden und Änderungen in der IKT-Anbieterlandschaft, neue oder beendete Dienste und Aktualisierungen der Kritikalitätsklassifikation spezifischer Vereinbarungen widerspiegeln. Es muss der zuständigen Behörde auf Anfrage vorgelegt werden und wird in der Praxis jährlich im Rahmen der routinemäßigen aufsichtlichen Berichterstattung eingereicht. Zuständige Behörden nutzen das Register als Input für ihre eigene aufsichtliche Bewertung von Konzentrationsrisiken und Drittanbieter-Abhängigkeit.

Die Qualität des Registers ist selbst ein aufsichtliches Signal. Ein sorgfältig gepflegtes, vollständiges und plausibles Register suggeriert, dass das Institut seine Drittanbieter-Beziehungen tatsächlich im Griff hat. Ein lückenhaftes oder inkonsistentes Register wirft umgekehrt Zweifel an der Tragfähigkeit der gesamten IKT-Governance auf und zieht typischerweise detaillierte Nachfragen der Aufsicht nach sich. Finanzunternehmen sollten daher Ressourcen für die kontinuierliche Pflege des Registers bereitstellen und seine Aktualisierung nicht als einmalige Übung betrachten, sondern als einen wiederkehrenden Prozess, der in das laufende Betriebsmodell integriert ist.

Praktischer Compliance-Fahrplan

Für Unternehmen, die noch an der vollständigen DORA-Compliance arbeiten, oder für Unternehmen, die ihre Compliance-Programme über das Januar-2025-Baseline hinaus ausbauen wollen, ist ein strukturierter Fahrplan unerlässlich. Prioritäre Maßnahmen umfassen typischerweise:

• Governance-Aufwertung: Sicherstellung, dass das Leitungsorgan das IKT-Risikomanagement-Rahmenwerk, die IKT-Strategie und die Geschäftskontinuitätsrichtlinie formell genehmigt hat und dass die Berichterstattung auf Vorstandsebene zu IKT-Risiken etabliert ist.
• Review des Risikomanagement-Rahmenwerks: Durchführung einer Lückenanalyse zwischen dem bestehenden IKT-Risikomanagement-Rahmenwerk und den spezifischen DORA-Anforderungen, Identifikation von Bereichen, in denen Dokumentation oder operative Praxis gestärkt werden muss.
• Fertigstellung des Informationsregisters: Finalisierung und Pflege des Informationsregisters, einschließlich aller IKT-Drittanbieter-Vereinbarungen und der Einstufung als Unterstützung kritischer oder wichtiger Funktionen.
• Vertragliche Remediation: Überprüfung der IKT-Drittanbieter-Verträge gegen die verpflichtenden Klauselanforderungen des Artikels 30, Verhandlung von Änderungen wo erforderlich und Priorisierung von Vereinbarungen, die kritische Funktionen unterstützen.
• Bereitschaft der Vorfallsreaktion: Aktualisierung der Vorfallsklassifizierungs- und Meldeverfahren zur Einhaltung der harmonisierten DORA-Fristen, mit besonderer Aufmerksamkeit auf das 4-Stunden-Fenster für die Erstmeldung schwerwiegender Vorfälle.
• Abstimmung des Testprogramms: Gestaltung oder Aktualisierung des Programms für Tests der digitalen operationellen Resilienz zur Einhaltung der Grundanforderungen und Bewertung, ob Pflichten zu bedrohungsgeleiteten Penetrationstests bestehen.
• TLPT-Planung (wo anwendbar): Für Unternehmen, die der TLPT-Anforderung unterliegen, Planung des Dreijahres-Testzyklus, Beschaffung qualifizierter Tester und Engagement mit der nationalen Zentralbank oder zuständigen Behörde zur Methodik-Abstimmung.
• Beteiligung am Informationsaustausch: Beitritt zu oder Formalisierung der Teilnahme an sektoralen Informationsaustausch-Arrangements, um von kollektiver Intelligenz über Bedrohungen zu profitieren.

Typische Fehler in der DORA-Umsetzung

Über die Population erfasster Unternehmen hinweg lassen sich mehrere wiederkehrende Fehlermuster beobachten. Typische Fehler umfassen:

• Dokumentation ohne operative Leistungsfähigkeit: Erstellung von Dokumentation, die anspruchsvolle Compliance-Arrangements beschreibt, die die tatsächliche operative Realität nicht widerspiegeln.
• Unvollständiges Informationsregister: Register, die wesentliche Anbieter auslassen, die Kritikalität von Vereinbarungen fehlklassifizieren oder Unterauslagerungsketten nicht erfassen.
• Nicht remediated Drittanbieter-Verträge: Abhängigkeit von Anbietern, deren Verträge die verpflichtenden DORA-Klauseln noch nicht enthalten, was Compliance-Lücken und aufsichtliche Exposition schafft.
• Vorfallsreaktion nicht unter Zeitdruck getestet: Vorfallsverfahren, die auf Papier gut aussehen, aber niemals unter der 4-Stunden-Erstmeldungsbeschränkung geübt wurden.
• Fragmentierte Governance: IKT-Risikomanagement, das bei der Technologie-Funktion angesiedelt ist ohne angemessene Einbeziehung von Compliance, Risikomanagement und Leitungsorgan.
• Unterschätzung der Testkosten: Fehlende Planung für die erheblichen Kosten im Zusammenhang mit bedrohungsgeleiteten Penetrationstests für bedeutende Unternehmen, die der Anforderung unterliegen.

Kostenerwartungen

Die Kosten der DORA-Compliance variieren stark innerhalb des Sektors. Für große Banken und Versicherer mit ausgereiften IKT-Risikomanagement-Funktionen mag der zusätzliche Kostenaufwand der DORA-Compliance im Verhältnis zu ihren bestehenden Investitionen in Resilienz moderat ausfallen. Für kleinere Institute kann der Aufwand einen bedeutenderen Anteil am Betriebsbudget darstellen, insbesondere wo substantielle Lücken in bestehenden Rahmenwerken bestehen. Die laufenden Compliance-Kosten umfassen Compliance-Personal, externe Beratungsunterstützung, Testkosten (insbesondere TLPT für bedeutende Unternehmen), Vertragsmanagement, Registerpflege, Vorfallsreaktionsbereitschaft und aufsichtliche Berichterstattung. Unternehmen sollten realistisch für die Vollzykluskosten budgetieren, statt DORA als einmaliges Projekt zu behandeln.

Laufendes Programm-Management

DORA ist kein einmaliges Compliance-Ereignis, sondern ein fortlaufendes Programm. Die Verordnung erwartet, dass sich das IKT-Risikoumfeld weiter entwickelt, dass Bedrohungen ausgefeilter werden und dass sich die aufsichtlichen Erwartungen weiter reifen. Finanzunternehmen sollten kontinuierliches Programm-Management planen: regelmäßige Aktualisierungen des IKT-Risikomanagement-Rahmenwerks, periodische Überprüfung des Drittanbieter-Registers und der Verträge, fortlaufendes Testing, kontinuierliche Beobachtung der Level-2-Maßnahmen und ihrer Revisionen sowie regelmäßiges Engagement mit zuständigen Behörden und Aufsicht.

Unternehmen, die DORA als abzuschließendes Projekt behandeln, werden feststellen, dass die Compliance rasch verfällt, sobald sich ihr Technologieumfeld, ihre Drittanbieter-Beziehungen und die Bedrohungslage verändern. Unternehmen, die dauerhafte Programm-Management-Arrangements etablieren – einschließlich klarer Verantwortlichkeiten, periodischer Reviewzyklen und Integration mit dem breiteren Unternehmensrisikomanagement –, werden besser aufgestellt sein, Compliance im Zeitverlauf aufrechtzuerhalten.

Fazit

DORA markiert einen echten Wandel darin, wie IKT-Risiken im europäischen Finanzsektor reguliert werden. Er begründet erhebliche neue Pflichten, hebt die Messlatte für operative Resilienz sektorweit an und erweitert die aufsichtliche Reichweite in das IKT-Drittanbieter-Ökosystem auf beispiellose Weise. Für Finanzunternehmen in der DACH-Region besteht die unmittelbare Aufgabe darin sicherzustellen, dass die Januar-2025-Baseline tatsächlich erfüllt ist und dass das Compliance-Programm für den dauerhaften Betrieb konfiguriert ist. Die Unternehmen, die DORA als Chance ergreifen, tatsächlich resilientere Operationen aufzubauen – statt als zu minimierende Compliance-Last –, werden am besten für das aufsichtliche Umfeld aufgestellt sein, das DORA geschaffen hat. Die Aegiron Capital Group unterstützt Fintechs und Softwareanbieter beim Markteintritt im DACH-Raum dabei, sich auf die DORA-Anforderungen ihrer Bankkunden und Partner vorzubereiten; Rechtsberatung und IT-Sicherheitsprüfungen übernehmen die Kanzlei und die Spezialisten, die Sie beauftragen.