DORA — Digital Operational Resilience Act

Was ist DORA?

Der Digital Operational Resilience Act (Verordnung (EU) 2022/2554) ist eine EU-Verordnung, die am 16. Januar 2023 in Kraft trat und seit dem 17. Januar 2025 unmittelbar in allen EU-Mitgliedstaaten gilt. DORA wurde als Teil des Digital Finance Package der EU-Kommission verabschiedet und adressiert ein zentrales Risiko: Die zunehmende Abhängigkeit des Finanzsektors von Informations- und Kommunikationstechnologie (IKT) hat die Angriffsfläche für Cyberangriffe, IT-Ausfälle und operative Störungen drastisch vergrößert.

Die Motivation hinter DORA ist klar: IT-Ausfälle bei Banken, Zahlungsdienstleistern und Börsen können systemische Risiken für die gesamte Finanzstabilität verursachen. Der Ausfall eines großen Cloud-Providers, ein Ransomware-Angriff auf ein Kernbankensystem oder eine kompromittierte Zahlungsinfrastruktur können Dominoeffekte auslösen, die Millionen von Kunden und die gesamte Wirtschaft betreffen. Die COVID-19-Pandemie hat diese Abhängigkeit nochmals verschärft: Remote-Banking, digitale Zahlungen und Cloud-Migrationen haben die IT-Infrastruktur des Finanzsektors grundlegend verändert — und damit auch dessen Verwundbarkeit.

Vor DORA existierte ein Flickenteppich aus nationalen Regelungen und sektorspezifischen Leitlinien (EBA, EIOPA, ESMA), die unterschiedliche Anforderungen an Banken, Versicherer und Wertpapierfirmen stellten. DORA harmonisiert diese Anforderungen erstmals EU-weit und schafft ein einheitliches Rahmenwerk für digitale Betriebsresilienz. Der Anwendungsbereich ist bewusst breit gewählt und umfasst 21 Kategorien von Finanzunternehmen: Kreditinstitute, Zahlungsinstitute, E-Geld-Institute, Wertpapierfirmen, zentrale Gegenparteien, Handelsplätze, Versicherungs- und Rückversicherungsunternehmen, Einrichtungen der betrieblichen Altersversorgung, Ratingagenturen, Verbriefungsregister, Crowdfunding-Dienstleister und — neu seit der MiCA-Verordnung — auch Krypto-Asset-Dienstleister.

Ein wesentlicher Unterschied zu NIS2: DORA ist eine Verordnung, keine Richtlinie. Das bedeutet, sie gilt unmittelbar und direkt in jedem EU-Mitgliedstaat, ohne dass nationale Umsetzungsgesetze erforderlich sind. Es gibt keine Verzögerungen durch nationale Gesetzgebung wie beim deutschen NIS2UmsuCG. Für Finanzunternehmen in der EU gelten die DORA-Anforderungen seit dem 17. Januar 2025 ohne Einschränkung. Die Europäischen Aufsichtsbehörden (ESAs) haben die Einhaltung bereits in ihren Prüfprogrammen für 2025/2026 verankert.

Die 5 Säulen von DORA

DORA basiert auf fünf zentralen Säulen, die zusammen ein umfassendes Rahmenwerk für digitale Betriebsresilienz bilden. Jede Säule wird durch delegierte Rechtsakte (Regulatory Technical Standards, RTS) und Implementierungsstandards (ITS) der ESAs konkretisiert.

Die ESAs (EBA, EIOPA, ESMA) haben zwischen Januar 2024 und Juli 2024 zwei Chargen von technischen Standards veröffentlicht, die die DORA-Anforderungen operationalisieren. Diese RTS und ITS sind für die praktische Umsetzung unverzichtbar, da sie die konkreten Anforderungen an Dokumentation, Prozesse und technische Maßnahmen definieren.

• Säule 1 — IKT-Risikomanagement (Kapitel II, Art. 5–16): Finanzunternehmen müssen ein umfassendes IKT-Risikomanagement-Rahmenwerk einrichten, das in die Gesamtrisikostrategie integriert ist. Dazu gehören: Identifikation und Klassifizierung aller IKT-Assets, kontinuierliche Risikoanalyse, Schutzmaßnahmen (Netzwerksegmentierung, Verschlüsselung, Zugangskontrollen), Erkennungsmechanismen für Anomalien und Angriffe sowie dokumentierte Reaktions- und Wiederherstellungspläne. Die Leitungsebene (Vorstand, Geschäftsführung) trägt die Gesamtverantwortung und muss das Rahmenwerk genehmigen und überwachen. Für kleinere Finanzunternehmen (z. B. Kleinstunternehmen gemäß Art. 16) gelten vereinfachte Anforderungen.
• Säule 2 — IKT-Vorfallmanagement und -meldung (Kapitel III, Art. 17–23): Finanzunternehmen müssen einen strukturierten Prozess für die Erkennung, Klassifizierung und Meldung von IKT-bezogenen Vorfällen implementieren. Schwerwiegende IKT-Vorfälle müssen der zuständigen Aufsichtsbehörde gemeldet werden: eine Erstmeldung unverzüglich (spätestens 4 Stunden nach Klassifizierung, 24 Stunden nach Entdeckung), ein Zwischenbericht innerhalb von 72 Stunden und ein Abschlussbericht innerhalb eines Monats. Die Klassifizierungskriterien umfassen: betroffene Kunden, Dauer des Ausfalls, geografische Ausbreitung, Datenverlust, Kritikalität der betroffenen Dienste und wirtschaftliche Auswirkungen. Ab 2026 wird zudem eine freiwillige Meldung signifikanter Cyberbedrohungen eingeführt.
• Säule 3 — Testen der digitalen Betriebsresilienz (Kapitel IV, Art. 24–27): Alle Finanzunternehmen müssen jährliche Basistests ihrer IKT-Systeme durchführen: Schwachstellenscans, Open-Source-Analysen, Netzwerksicherheitsbewertungen und GAP-Analysen. Systemrelevante Finanzunternehmen müssen darüber hinaus alle drei Jahre Threat-Led Penetration Tests (TLPT) nach dem TIBER-EU-Rahmenwerk durchführen — realitätsnahe Angriffssimulationen, die von spezialisierten Red-Team-Anbietern durchgeführt werden. TLPTs müssen kritische Funktionen und Live-Produktionssysteme einbeziehen und von der Aufsichtsbehörde genehmigt werden.
• Säule 4 — IKT-Drittanbieter-Risikomanagement (Kapitel V, Art. 28–44): Finanzunternehmen müssen ein Register aller IKT-Drittanbieterverträge führen und Risiken aus der Auslagerung systematisch bewerten. Verträge mit IKT-Drittanbietern müssen verbindliche Klauseln zu Sicherheitsniveaus, Datenstandorten, Auditrechten, Subunternehmer-Kontrolle, Exit-Strategien und Unterstützung bei Vorfällen enthalten. Kritische IKT-Drittanbieter (z. B. große Cloud-Provider wie AWS, Azure, Google Cloud) werden von einer Lead Oversight Authority (federführende Überwachungsbehörde) direkt beaufsichtigt. Die ESAs können bei Verstößen Zwangsgelder von bis zu 1 % des durchschnittlichen Tagesumsatzes verhängen — pro Tag.
• Säule 5 — Informationsaustausch (Kapitel VI, Art. 45): DORA fördert den freiwilligen Austausch von Informationen über Cyberbedrohungen, Schwachstellen, Taktiken und Techniken (TTPs) zwischen Finanzunternehmen. Dieser Austausch soll über vertrauenswürdige Gemeinschaften und ISACs (Information Sharing and Analysis Centres) erfolgen und die kollektive Resilienz des Finanzsektors stärken. Finanzunternehmen müssen sicherstellen, dass der Informationsaustausch die Datenschutz- und Wettbewerbsvorschriften einhält.

DORA vs. NIS2 — Unterschiede und Überschneidungen

DORA und NIS2 verfolgen ähnliche Ziele — die Stärkung der Cyberresilienz in der EU —, unterscheiden sich jedoch in Anwendungsbereich, Detailtiefe und rechtlicher Natur erheblich. Für Unternehmen, die potenziell unter beide Regelungen fallen, ist das Verständnis der Abgrenzung entscheidend.

• Lex specialis: DORA gilt als lex specialis (spezielleres Gesetz) gegenüber NIS2 für den Finanzsektor. Das bedeutet: Finanzunternehmen, die unter DORA fallen, müssen die DORA-Anforderungen erfüllen, nicht die allgemeineren NIS2-Vorgaben. Art. 4 der NIS2-Richtlinie stellt dies ausdrücklich klar. Allerdings können IKT-Drittanbieter, die nicht ausschließlich den Finanzsektor bedienen, zusätzlich unter NIS2 fallen.
• Rechtsform: DORA ist eine Verordnung (unmittelbar anwendbar), NIS2 eine Richtlinie (erfordert nationale Umsetzung). Das erklärt, warum DORA seit Januar 2025 gilt, während NIS2 in Deutschland noch auf das NIS2UmsuCG wartet.
• Detailtiefe: DORA ist deutlich granularer als NIS2. Während NIS2 zehn übergeordnete Risikomanagement-Maßnahmen beschreibt, definiert DORA detaillierte Anforderungen an IKT-Governance, Vorfallklassifizierung, Testmethodik, Vertragsinhalte und Drittanbieter-Überwachung — konkretisiert durch über 20 RTS und ITS der ESAs.
• Meldepflichten: DORA verlangt eine Erstmeldung innerhalb von 4 Stunden nach Klassifizierung (maximal 24 Stunden nach Entdeckung). NIS2 setzt die Frühwarnung bei 24 Stunden an. DORA ist also strenger bei der initialen Meldefrist.
• Drittanbieter-Überwachung: DORA geht weit über NIS2 hinaus, indem es eine direkte Beaufsichtigung kritischer IKT-Drittanbieter durch EU-Behörden vorsieht. NIS2 fordert lediglich ein Supply-Chain-Risikomanagement. Für IT-Dienstleister bedeutet dies: Wer kritische Dienste für den Finanzsektor erbringt, wird direkt in das regulatorische Ökosystem einbezogen.
• Sanktionen: DORA ermächtigt die nationalen Aufsichtsbehörden, verwaltungsrechtliche Sanktionen und Abhilfemaßnahmen zu verhängen — die konkrete Höhe wird durch nationales Recht der Mitgliedstaaten festgelegt. Für kritische IKT-Drittanbieter können die ESAs Zwangsgelder von bis zu 1 % des durchschnittlichen täglichen weltweiten Umsatzes verhängen. NIS2 definiert dagegen feste Obergrenzen (10 Mio. EUR / 2 % des Jahresumsatzes für wesentliche Einrichtungen).
• Proportionalität: Beide Regelungen wenden das Proportionalitätsprinzip an, allerdings unterschiedlich: DORA definiert in Art. 16 ein vereinfachtes IKT-Risikomanagement-Rahmenwerk für Kleinstunternehmen im Finanzsektor (unter 10 Mitarbeiter, unter 2 Mio. EUR Bilanzsumme). NIS2 nutzt die „Size-Cap“-Regel (50 Mitarbeiter / 10 Mio. EUR Umsatz) als generelle Schwelle, unterhalb derer Unternehmen in der Regel nicht betroffen sind.

Praxis-Empfehlung: Für IT-Dienstleister, die sowohl Finanzkunden als auch Kunden in anderen kritischen Sektoren bedienen, empfiehlt sich eine Dual-Compliance-Strategie: Erfüllen Sie die strengeren DORA-Anforderungen als Baseline und ergänzen Sie die NIS2-spezifischen Anforderungen (insbesondere BSI-Registrierung und nationale Meldewege). In der Praxis deckt DORA-Compliance rund 85 % der NIS2-Anforderungen ab.

Auswirkungen auf IT-Dienstleister

DORA betrifft nicht nur Finanzunternehmen selbst, sondern erstreckt sich ausdrücklich auf deren IKT-Drittanbieter — also IT-Dienstleister, Managed-Service-Provider, Cloud-Anbieter, Rechenzentren, SaaS-Anbieter und alle Unternehmen, die IKT-Dienste für den Finanzsektor erbringen. Dies hat tiefgreifende Konsequenzen für die gesamte IT-Branche.

• Vertragliche Pflichten (Art. 30): DORA definiert verbindliche Mindestinhalte für Verträge zwischen Finanzunternehmen und IKT-Drittanbietern. Dazu gehören: vollständige Beschreibung der erbrachten Dienste, Service Level Agreements (SLAs) mit messbaren Kennzahlen, Datenverarbeitungsstandorte, Auditrechte des Finanzunternehmens und der Aufsichtsbehörde, Pflicht zur Unterstützung bei Vorfällen und Migrationen, Exit-Strategien und Übergabefristen sowie Subunternehmer-Kontrolle und -Transparenz. IT-Dienstleister müssen ihre Vertragsvorlagen überarbeiten und die DORA-Anforderungen als Standardklauseln aufnehmen.
• Audit-Pflichten: Finanzunternehmen müssen das Recht haben, IKT-Drittanbieter zu auditieren — entweder selbst oder durch unabhängige Prüfer. Für IT-Dienstleister bedeutet das: regelmäßige Sicherheitsaudits durch Kunden oder deren Auditoren, Bereitstellung von SOC-2-Berichten oder vergleichbaren Nachweisen, Transparenz über Sicherheitsmaßnahmen, Vorfälle und Schwachstellen. Praxis-Tipp: Lassen Sie proaktiv einen SOC 2 Type II-Bericht erstellen — er deckt die meisten DORA-Auditanforderungen ab und vermeidet individuelle Audits durch jeden einzelnen Finanzkunden.
• Kritische IKT-Drittanbieter — direkte Überwachung: IKT-Drittanbieter, die von den ESAs als kritisch eingestuft werden (Kriterien: Systemrelevanz, Konzentrationsrisiko, Substituierbarkeit), unterliegen einer direkten Beaufsichtigung durch eine federführende Überwachungsbehörde. Diese kann Informationen anfordern, Vor-Ort-Inspektionen durchführen, Empfehlungen aussprechen und bei Nichteinhaltung Zwangsgelder von bis zu 1 % des täglichen weltweiten Umsatzes verhängen — und zwar für bis zu sechs Monate. In der Praxis betrifft dies zunächst große Cloud-Provider (AWS, Azure, Google Cloud) und systemrelevante Finanzinfrastruktur-Anbieter (SWIFT, Bloomberg).
• Was IT-Dienstleister jetzt tun sollten: 1) Identifizieren Sie alle Kunden im Finanzsektor und prüfen Sie, ob Ihre Dienste als IKT-Dienste im Sinne von DORA gelten. 2) Überarbeiten Sie Ihre Vertragsvorlagen mit den DORA-Pflichtklauseln (Art. 30). 3) Implementieren Sie ein Vorfallmanagement, das DORA-konforme Meldungen an Finanzkunden ermöglicht. 4) Bereiten Sie sich auf Audits vor — dokumentieren Sie Sicherheitsmaßnahmen, Prozesse und Zertifizierungen. 5) Definieren Sie Exit-Strategien und Übergabeprozesse für jeden Finanzkunden. 6) Prüfen Sie Ihre Subunternehmer-Kette — DORA verlangt Transparenz über die gesamte Lieferkette.
• Konzentrationsrisiko und Multi-Cloud-Strategie: DORA verlangt von Finanzunternehmen, Konzentrationsrisiken bei IKT-Drittanbietern zu bewerten und zu minimieren. Wenn ein Finanzunternehmen alle kritischen Dienste bei einem einzigen Cloud-Provider betreibt und dieser ausfällt, ist die gesamte Betriebsfähigkeit gefährdet. Für IT-Dienstleister bedeutet das: Finanzkunden werden verstärkt nach Multi-Provider-Fähigkeit, Portabilitätsnachweisen und Interoperabilität fragen. Bereiten Sie Nachweise vor, wie Kunden ihre Daten und Workloads im Bedarfsfall zu einem alternativen Anbieter migrieren können.
• Informationsregister (Art. 28 Abs. 3): Finanzunternehmen müssen ein vollständiges Register aller vertraglichen Vereinbarungen mit IKT-Drittanbietern führen und der Aufsichtsbehörde auf Anfrage vorlegen. Dieses Register enthält: Art der erbrachten Dienste, Vertragspartner und Subunternehmer, Datenverarbeitungsstandorte, Kritikalitätsbewertung und Datum der letzten Risikobewertung. IT-Dienstleister sollten ihren Finanzkunden die für dieses Register benötigten Informationen proaktiv und in einem standardisierten Format bereitstellen.

Insider-Tipp: Die BaFin hat im Januar 2025 klargestellt, dass sie DORA ab sofort aktiv prüft — im Rahmen der regulären Vor-Ort-Prüfungen sowie anlassbezogen. Erfahrungen aus den ersten Prüfungen zeigen, dass die Aufsicht besonderes Augenmerk auf das IKT-Drittanbieter-Register, die Vorfallklassifizierung und die vertraglichen Mindestinhalte legt. Unternehmen, die diese drei Bereiche vollständig abdecken, bestehen den Großteil der DORA-Prüfung.

Für mittelständische IT-Dienstleister, die bisher keine regulierten Branchen bedient haben, stellt DORA eine erhebliche neue Compliance-Last dar — bietet aber auch eine Chance: Wer frühzeitig DORA-konforme Prozesse und Vertragsstandards implementiert, kann sich als vertrauenswürdiger IKT-Partner für den Finanzsektor positionieren und einen Wettbewerbsvorteil gegenüber Anbietern erzielen, die noch nicht vorbereitet sind.

Abschließend sei betont: DORA ist nicht nur ein Compliance-Projekt, sondern eine Chance, die operative Widerstandsfähigkeit tatsächlich zu stärken. Unternehmen, die DORA als reines „Checkbox-Exercise“ behandeln, verpassen den eigentlichen Mehrwert: bessere Incident-Response-Fähigkeiten, stärkere Kontrolle über IKT-Risiken und eine systematische Übersicht über alle kritischen Abhängigkeiten. Die Investition in DORA-Compliance zahlt sich auch jenseits der regulatorischen Pflicht aus — denn die nächste Cyber-Krise kommt mit Sicherheit.