Banken, Versicherungen und Zahlungsdienstleister hängen heute vollständig an ihrer IT. Fällt ein Kernbankensystem aus oder wird ein Cloud-Dienstleister angegriffen, sind Zahlungen, Depots und Kundenkonten betroffen, oft bei mehreren Instituten gleichzeitig. Genau dieses Risiko adressiert der Digital Operational Resilience Act, kurz DORA.
Seit dem 17. Januar 2025 gilt die Verordnung in der gesamten EU. Sie verlangt von Finanzunternehmen, dass sie IT-Risiken systematisch steuern, schwerwiegende Vorfälle schnell melden, ihre Widerstandsfähigkeit regelmäßig testen und ihre IT-Dienstleister eng kontrollieren. Und sie wirkt weit über den Finanzsektor hinaus, denn auch IT-Dienstleister von Finanzunternehmen spüren die Anforderungen direkt.
In diesem Beitrag erfahren Sie, was DORA Compliance bedeutet, wer betroffen ist, welche Pflichten aus den fünf Säulen folgen, was die BaFin in Deutschland erwartet und wie die Umsetzung gelingt.
Was ist DORA?
DORA steht für Digital Operational Resilience Act, auf Deutsch Verordnung über die digitale operationale Resilienz im Finanzsektor. Die offizielle Bezeichnung ist Verordnung (EU) 2022/2554. Sie trat am 16. Januar 2023 in Kraft und gilt seit dem 17. Januar 2025.
Digitale operationale Resilienz bedeutet: Ein Finanzunternehmen muss in der Lage sein, seinen Betrieb auch bei IT-Störungen und Cyberangriffen aufrechtzuerhalten oder schnell wiederherzustellen. Es geht also nicht nur darum, Angriffe abzuwehren, sondern auch darum, mit Ausfällen umgehen zu können.
Verordnung statt Richtlinie
Anders als die NIS2-Richtlinie ist DORA eine Verordnung. Sie gilt unmittelbar in allen Mitgliedstaaten, ohne dass ein nationales Gesetz die Inhalte übertragen muss. In Deutschland hat das Finanzmarktdigitalisierungsgesetz, kurz FinmadiG, lediglich die nationalen Zuständigkeiten, Sanktionen und Anpassungen in bestehenden Gesetzen wie dem Kreditwesengesetz geregelt. Zuständige Aufsichtsbehörde ist die BaFin.
Wer ist von DORA betroffen?
Direkt betroffene Finanzunternehmen
DORA erfasst nach Art. 2 eine lange Liste von Finanzunternehmen, darunter:
- Kreditinstitute
- Zahlungs- und E-Geld-Institute
- Wertpapierfirmen
- Anbieter von Krypto-Dienstleistungen
- Zentralverwahrer, Handelsplätze und zentrale Gegenparteien
- Versicherungs- und Rückversicherungsunternehmen sowie größere Versicherungsvermittler
- Einrichtungen der betrieblichen Altersversorgung
- Verwalter alternativer Investmentfonds und OGAW-Verwaltungsgesellschaften
- Ratingagenturen und Administratoren kritischer Referenzwerte
- Schwarmfinanzierungsdienstleister
Für Kleinstunternehmen und einige kleinere Institute gelten Erleichterungen, insbesondere ein vereinfachter Rahmen für das IKT-Risikomanagement nach Art. 16. Der Grundsatz der Verhältnismäßigkeit zieht sich durch die gesamte Verordnung: Größe, Risikoprofil und Komplexität bestimmen, wie umfangreich die Maßnahmen sein müssen.
IT-Dienstleister von Finanzunternehmen
DORA richtet sich nicht nur an Finanzunternehmen, sondern auch an deren IKT-Drittdienstleister. Dazu gehören Cloud-Anbieter, Rechenzentren, Softwarehersteller, Managed Service Provider und andere IT-Dienstleister. Sie werden auf zwei Wegen erfasst:
- Vertraglich: Finanzunternehmen müssen nach Art. 30 bestimmte Inhalte in ihre Verträge mit IT-Dienstleistern aufnehmen, etwa Prüf- und Zugangsrechte, Kündigungsrechte, Vorgaben zur Datensicherheit und zur Unterstützung bei Vorfällen. Diese Anforderungen landen also direkt beim Dienstleister.
- Direkte Aufsicht: IKT-Drittdienstleister, die für den Finanzsektor als kritisch eingestuft werden, unterliegen nach Art. 31 ff. einer eigenen Aufsicht durch die europäischen Finanzaufsichtsbehörden. Diese können Prüfungen durchführen und bei Verstößen Zwangsgelder verhängen.
Verhältnis zu NIS2
Viele Finanzunternehmen fallen grundsätzlich auch unter NIS2. DORA geht für den Finanzsektor aber als spezielleres Recht vor. Die BaFin weist darauf hin, dass DORA-Unternehmen bei der Meldung von IKT-Vorfällen von der Meldepflicht nach § 32 BSIG befreit sind, weil die BaFin Meldungen an das BSI weiterleitet. Einen Überblick über NIS2 gibt unser Beitrag NIS2-Richtlinie einfach erklärt.
Die fünf Säulen von DORA
| Säule | Artikel | Kern der Anforderung |
|---|---|---|
| IKT-Risikomanagement | Art. 5 bis 16 | dokumentierter Rahmen zur Steuerung aller IT-Risiken, Verantwortung der Leitung |
| Behandlung und Meldung von IKT-Vorfällen | Art. 17 bis 23 | Vorfälle erkennen, klassifizieren, schwerwiegende Vorfälle fristgerecht melden |
| Tests der digitalen operationalen Resilienz | Art. 24 bis 27 | regelmäßige Tests, bei bedeutenden Unternehmen bedrohungsorientierte Penetrationstests |
| Management des IKT-Drittparteienrisikos | Art. 28 bis 44 | Steuerung und Überwachung von IT-Dienstleistern, Informationsregister, Vertragsinhalte |
| Informationsaustausch | Art. 45 | freiwilliger Austausch von Informationen über Cyberbedrohungen |
1. IKT-Risikomanagement
Finanzunternehmen müssen einen umfassenden, dokumentierten Rahmen für das IKT-Risikomanagement einrichten. Dazu gehören unter anderem:
- eine Strategie für die digitale operationale Resilienz,
- die Identifikation aller IT-Systeme, Informationen und Abhängigkeiten,
- Schutz- und Präventionsmaßnahmen, etwa Zugriffskontrollen, Verschlüsselung und Patch-Management,
- die Erkennung ungewöhnlicher Aktivitäten,
- Pläne zur Reaktion, Wiederherstellung und Betriebsfortführung, einschließlich Backup und Wiederherstellung,
- Lernen aus Vorfällen und regelmäßige Schulungen.
Besonders wichtig ist Art. 5: Das Leitungsorgan, also Vorstand oder Geschäftsführung, trägt die letzte Verantwortung für das IKT-Risikomanagement. Es muss den Rahmen festlegen, genehmigen, überwachen und sich regelmäßig fortbilden.
2. Behandlung und Meldung von IKT-Vorfällen
Finanzunternehmen müssen einen Prozess einrichten, der IT-Vorfälle erkennt, klassifiziert, dokumentiert und behandelt. Schwerwiegende IKT-bezogene Vorfälle sind der Aufsicht zu melden. Die Fristen ergeben sich aus der Delegierten Verordnung (EU) 2025/301:
| Meldung | Frist |
|---|---|
| Erstmeldung | innerhalb von 4 Stunden nach Einstufung als schwerwiegend, spätestens 24 Stunden nach Kenntnis |
| Zwischenmeldung | innerhalb von 72 Stunden nach der Erstmeldung |
| Abschlussmeldung | innerhalb eines Monats nach der letzten Zwischenmeldung |
In Deutschland erfolgen die Meldungen laut BaFin über die Melde- und Veröffentlichungsplattform der BaFin. In Erst- und Zwischenmeldung dürfen Schätzungen verwendet werden, die Abschlussmeldung soll genaue Angaben enthalten. Zusätzlich können erhebliche Cyberbedrohungen freiwillig gemeldet werden.
Die Vier-Stunden-Frist ist anspruchsvoll. Sie setzt voraus, dass Erkennung, Klassifizierung und Entscheidungswege auch nachts und am Wochenende funktionieren.
3. Tests der digitalen operationalen Resilienz
DORA verlangt ein Programm für regelmäßige Tests. Dazu gehören je nach Größe und Risikoprofil Schwachstellenanalysen, Netzwerksicherheitsprüfungen, Szenario-Tests, Quellcodeprüfungen und Penetrationstests. Mindestens einmal jährlich sind alle IT-Systeme und Anwendungen zu testen, die kritische oder wichtige Funktionen unterstützen.
Bestimmte, von der Aufsicht ausgewählte Finanzunternehmen müssen zusätzlich mindestens alle drei Jahre bedrohungsorientierte Penetrationstests durchführen, sogenannte Threat-Led Penetration Tests (TLPT). Dabei simulieren spezialisierte Tester realistische Angriffe auf Produktivsysteme. Mehr zu Penetrationstests auf unserer Seite Penetrationstest.
4. Management des IKT-Drittparteienrisikos
Diese Säule ist für viele Unternehmen die aufwendigste. Finanzunternehmen bleiben voll verantwortlich, auch wenn sie IT-Leistungen auslagern. Daraus folgen unter anderem:
- Strategie für IKT-Drittparteienrisiken mit Grundsätzen für die Auswahl und Steuerung von Dienstleistern.
- Informationsregister: Alle vertraglichen Vereinbarungen über IKT-Dienstleistungen sind in einem Register zu erfassen und der Aufsicht auf Anfrage beziehungsweise jährlich zu übermitteln. Laut BaFin erfolgt die Einreichung über die Melde- und Veröffentlichungsplattform.
- Prüfung vor Vertragsschluss, etwa zu Sicherheitsniveau, Abhängigkeiten und Konzentrationsrisiken.
- Mindestinhalte in Verträgen nach Art. 30, darunter Leistungsbeschreibung, Standorte der Datenverarbeitung, Sicherheitsanforderungen, Unterstützung bei Vorfällen, Prüf- und Zugangsrechte sowie Kündigungsrechte.
- Ausstiegsstrategien für den Fall, dass ein Dienstleister ausfällt oder gewechselt werden muss.
5. Informationsaustausch
Finanzunternehmen dürfen und sollen sich untereinander über Cyberbedrohungen, Angriffsmuster und Schwachstellen austauschen, etwa in vertrauenswürdigen Gemeinschaften. Diese Säule ist freiwillig, wird aber ausdrücklich gefördert.
Was die BaFin in Deutschland geändert hat
Mit DORA hat sich die IT-Aufsicht in Deutschland grundlegend verändert. Laut BaFin wurden die Rundschreiben zu den IT-Anforderungen für Versicherer (VAIT), Kapitalverwaltungsgesellschaften (KAIT) sowie Zahlungs- und E-Geld-Institute (ZAIT) mit Ablauf des 16. Januar 2025 aufgehoben, um Doppelregulierung zu vermeiden. Die BAIT für Banken gelten nur noch für Institute, die DORA erst später anwenden müssen, und laufen Ende 2026 aus.
Für Unternehmen bedeutet das: Die bekannten deutschen IT-Rundschreiben sind nicht mehr die Messlatte. Maßgeblich sind DORA selbst, die dazugehörigen technischen Regulierungsstandards und die Hinweise der BaFin. Wer bisher die BAIT oder VAIT erfüllt hat, hat eine gute Grundlage, muss aber insbesondere beim Meldewesen, beim Testen und bei der Dienstleistersteuerung nachlegen. Orientierung bietet die Aufsichtsmitteilung der BaFin mit Umsetzungshinweisen zu DORA.
Die wichtigsten Termine im Überblick
| Datum | Ereignis |
|---|---|
| 16. Januar 2023 | DORA tritt in Kraft |
| 17. Januar 2025 | DORA gilt verbindlich, KAIT, VAIT und ZAIT der BaFin werden aufgehoben |
| jährlich | Einreichung des Informationsregisters bei der BaFin über die Melde- und Veröffentlichungsplattform |
| mindestens alle drei Jahre | bedrohungsorientierte Penetrationstests für ausgewählte Finanzunternehmen |
| 31. Dezember 2026 | BAIT laufen vollständig aus |
| 1. Januar 2027 | weitere Institute müssen die Anforderungen an das IKT-Risikomanagement nach DORA anwenden |
Cloud-Dienste und Konzentrationsrisiko
Ein Schwerpunkt von DORA ist die Abhängigkeit des Finanzsektors von wenigen großen Cloud- und IT-Anbietern. Fällt ein solcher Anbieter aus, können viele Institute gleichzeitig betroffen sein. DORA verlangt deshalb, dass Finanzunternehmen Konzentrationsrisiken bewerten, bevor sie wichtige Funktionen an einen Dienstleister auslagern.
Für die Praxis heißt das:
- Abhängigkeiten sichtbar machen: Welche kritischen Funktionen hängen an welchem Anbieter, und welche Unterauftragnehmer stehen dahinter?
- Daten sichern, unabhängig vom Anbieter: Auch bei Cloud-Diensten wie Microsoft 365 bleibt das Finanzunternehmen für die Wiederherstellbarkeit seiner Daten verantwortlich. Wie eine unabhängige Sicherung aussieht, zeigt unser Beitrag Keepit Backup für Microsoft 365.
- Ausstieg planen: Für kritische Dienstleister braucht es realistische Ausstiegsstrategien, die im Ernstfall auch umsetzbar sind, mit Zeitplan, Datenmigration und Übergangslösung.
- Verträge nachschärfen: Standorte der Datenverarbeitung, Prüfrechte und Unterstützung bei Vorfällen müssen auch bei großen Anbietern vertraglich geregelt sein.
Welche Sanktionen drohen?
DORA überlässt die konkreten Sanktionen gegenüber Finanzunternehmen weitgehend den Mitgliedstaaten. In Deutschland sind die Bußgeldvorschriften über das FinmadiG in die Aufsichtsgesetze eingeflossen. Daneben stehen der Aufsicht die bekannten Instrumente zur Verfügung, von Anordnungen bis hin zu Maßnahmen gegen Geschäftsleiter.
Für kritische IKT-Drittdienstleister regelt DORA selbst ein Zwangsgeld: Die federführende europäische Aufsichtsbehörde kann bis zu 1 Prozent des durchschnittlichen weltweiten Tagesumsatzes pro Tag verhängen, für bis zu sechs Monate, um die Einhaltung von Anordnungen durchzusetzen.
Unabhängig von Bußgeldern ist das größte Risiko der Ausfall selbst. Für Finanzunternehmen bedeutet ein mehrtägiger IT-Ausfall nicht nur Umsatzverlust, sondern auch einen Vertrauensschaden bei Kunden und Aufsicht.
Was DORA für IT-Dienstleister bedeutet
Für Systemhäuser, Managed Service Provider, Softwarehersteller und Cloud-Anbieter mit Kunden aus dem Finanzsektor ändert sich viel, auch wenn sie nicht als kritisch eingestuft sind:
- Neue Vertragsklauseln: Kunden verlangen Prüf- und Zugangsrechte, Mitwirkung bei Tests, Meldung von Vorfällen in kurzen Fristen und klare Regelungen zur Beendigung.
- Nachweise: Fragebögen, Zertifikate wie ISO/IEC 27001 und Auditberichte werden Standard.
- Unterauftragnehmer: Auch die eigenen Dienstleister geraten in den Blick, weil Finanzunternehmen ganze Lieferketten bewerten müssen.
- Meldefähigkeit: Damit der Kunde seine Vier-Stunden-Frist einhalten kann, muss der Dienstleister Vorfälle sehr schnell weitergeben.
Wer diese Anforderungen früh erfüllt, verschafft sich einen klaren Vorteil bei Ausschreibungen im Finanzsektor.
DORA Compliance umsetzen in sechs Schritten
- Betroffenheit und Rolle klären. Fällt das Unternehmen unter Art. 2? Gilt der vereinfachte Rahmen? Ist man selbst IKT-Dienstleister für Finanzunternehmen?
- Gap-Analyse durchführen. Den Ist-Stand mit den Anforderungen der fünf Säulen und der technischen Regulierungsstandards vergleichen. Wer bisher BAIT oder VAIT erfüllt hat, startet nicht bei null.
- Governance festlegen. Verantwortung der Geschäftsleitung, Rollen, Berichtswege und Schulungen der Leitungsorgane klären.
- Meldeprozess aufbauen. Klassifizierungskriterien, Bereitschaft rund um die Uhr, Vorlagen und Zugang zur Meldeplattform vorbereiten. Ein Alarmierungssystem hilft, das Krisenteam schnell zusammenzubringen.
- Dienstleistersteuerung aufsetzen. Informationsregister befüllen, Verträge nach Art. 30 anpassen, Ausstiegsstrategien für kritische Dienstleister entwickeln.
- Testen und verbessern. Ein Testprogramm einführen, Ergebnisse in Maßnahmen übersetzen und die Wirksamkeit regelmäßig überprüfen.
Viele dieser Aufgaben lassen sich mit einer GRC-Lösung strukturiert abbilden, etwa Risikoregister, Kontrollen, Nachweise und Fristen. Wie das funktioniert, zeigt unser Beitrag Commugen GRC: Compliance automatisieren und unsere Seite zu Governance, Risk und Compliance.
Praxisbeispiele
Regionale Bank mit 400 Beschäftigten: Die Bank hatte die BAIT weitgehend umgesetzt. Die Gap-Analyse zeigte vor allem Lücken beim Meldewesen, weil die Klassifizierung von Vorfällen bisher nur zu Bürozeiten erfolgte, und beim Informationsregister, weil Verträge über mehrere Abteilungen verteilt waren. Beide Themen wurden mit klaren Zuständigkeiten, einer Rufbereitschaft und einer zentralen Vertragsdatenbank gelöst.
Zahlungsinstitut mit 60 Beschäftigten: Als kleineres Institut prüfte es zunächst, ob der vereinfachte Rahmen für das IKT-Risikomanagement greift. Der größte Aufwand lag in der Steuerung des Cloud-Anbieters und des externen Rechenzentrums, einschließlich Ausstiegsstrategie und angepasster Verträge.
IT-Dienstleister mit Kunden aus dem Finanzsektor: Das Unternehmen fällt selbst nicht direkt unter DORA, erhielt aber von mehreren Kunden neue Vertragsentwürfe mit Prüfrechten, Meldefristen und Testpflichten. Es baute einen eigenen Meldeprozess auf, ließ sich nach ISO/IEC 27001 zertifizieren und nutzt diese Nachweise inzwischen aktiv im Vertrieb.
Typische Fehler bei der Umsetzung
- DORA als reines IT-Projekt behandeln. Die Verantwortung liegt bei der Geschäftsleitung, und viele Anforderungen betreffen Einkauf, Recht, Risikomanagement und Fachbereiche.
- Dienstleister unterschätzen. Informationsregister und Vertragsanpassungen sind aufwendig und brauchen Zeit, besonders bei großen Anbietern.
- Meldefristen theoretisch planen. Ein Prozess, der nur zu Bürozeiten funktioniert, reicht für eine Vier-Stunden-Frist nicht aus.
- Tests als Einmalaktion sehen. DORA verlangt ein laufendes Testprogramm mit Nachverfolgung der Ergebnisse.
- Dokumentation vernachlässigen. Ohne nachvollziehbare Nachweise lässt sich gegenüber der Aufsicht nicht belegen, dass Maßnahmen umgesetzt sind.
DORA, NIS2 und ISO 27001 im Vergleich
| Merkmal | DORA | NIS2 | ISO/IEC 27001 |
|---|---|---|---|
| Rechtsform | EU-Verordnung, gilt unmittelbar | EU-Richtlinie, in Deutschland über das BSI-Gesetz umgesetzt | freiwillige internationale Norm |
| Zielgruppe | Finanzunternehmen und deren IKT-Dienstleister | Unternehmen in 18 Sektoren ab bestimmter Größe | alle Organisationen |
| Aufsicht in Deutschland | BaFin | BSI | Zertifizierungsstellen |
| Vorfallmeldung | Erstmeldung binnen 4 Stunden nach Einstufung, spätestens 24 Stunden | Erstmeldung binnen 24 Stunden | keine gesetzliche Meldepflicht |
| Besonderheit | detaillierte Dienstleistersteuerung, TLPT | breiter Geltungsbereich | Managementsystem als Rahmen |
Eine ISO-27001-Zertifizierung ist eine gute Grundlage, ersetzt DORA Compliance aber nicht. Meldewesen, Informationsregister, Vertragsinhalte und Testpflichten gehen deutlich darüber hinaus.
Fazit: DORA ist Daueraufgabe, nicht Projekt
DORA hat die Anforderungen an die IT im Finanzsektor europaweit vereinheitlicht und deutlich verschärft. Finanzunternehmen müssen IT-Risiken systematisch steuern, schwerwiegende Vorfälle innerhalb von Stunden melden, ihre Widerstandsfähigkeit regelmäßig testen und ihre Dienstleister eng kontrollieren. IT-Dienstleister spüren die Anforderungen über Verträge und Nachweispflichten. Wer DORA als laufenden Prozess versteht und nicht als einmaliges Projekt, schafft die Grundlage für einen stabilen Betrieb und eine entspannte Aufsichtsprüfung.
Sie möchten Ihren Stand bei DORA bewerten oder sich als IT-Dienstleister auf die Anforderungen Ihrer Finanzkunden vorbereiten? Wir unterstützen Sie mit Gap-Analyse, GRC-Lösungen, Penetrationstests und Notfallprozessen. Jetzt kostenlose Erstberatung buchen.
