Was ist die DORA-Verordnung? EU-Gesetz zur digitalen Resilienz erklärt

Die DORA-Verordnung – der Digital Operational Resilience Act – ist das EU-Gesetz zur Cyberresilienz im Finanzsektor. Sie legt fest, wie Finanzinstitute mit Cybersicherheit und IT-Risiken umgehen müssen. Vereinfacht gesagt: Jede Bank, jedes Zahlungsunternehmen, jede Wertpapierfirma, jeder Versicherer und jede Kryptobörse in der EU muss auch bei einem Hack, einem Cloud-Ausfall oder einem fehlerhaften Software-Update arbeitsfähig bleiben und die eingesetzten IT-Anbieter überwachen.

Dieser Leitfaden richtet sich an Menschen ohne juristischen oder IT-Hintergrund. Er erläutert, für wen DORA gilt, was sie verlangt, wie schnell Vorfälle gemeldet werden müssen, worin sie sich von NIS2 und GDPR unterscheidet, welche Sanktionen drohen und was die DORA-Anforderungen für Fintech- und Kryptounternehmen bedeuten. Abschließend folgt eine kurze DORA-Compliance-Checkliste.

Was bedeutet DORA einfach erklärt?

DORA – manchmal auch EU DORA oder DORA Act genannt – ist die Verordnung (EU) 2022/2554 über die digitale operationale Resilienz im Finanzsektor. „Digitale operationale Resilienz“ klingt kompliziert, meint aber nur eines: Kann Ihr Unternehmen seine Kundschaft weiter bedienen, wenn die IT ausfällt? Dringt ein Hacker ein, scheitert ein Update, fällt ein Anbieter aus – funktionieren Zahlungen weiter, können sich Kunden noch anmelden, sind ihre Daten weiterhin sicher? DORA macht aus dieser guten Praxis eine gesetzliche Pflicht.

Vor DORA hatte jedes EU-Land und jeder Teil des Finanzsektors eigene IT-Sicherheitsvorschriften und eigene Meldeformulare. DORA ersetzt diesen Flickenteppich durch ein einheitliches Regelwerk für den gesamten EU-Finanzsektor. Weil es sich um eine Verordnung und nicht um eine Richtlinie handelt, gilt sie in jedem Mitgliedstaat unmittelbar und wortgleich – ohne dass ein nationales Gesetz sie erst in Kraft setzen muss.

Die Frist zur DORA-Umsetzung ist bereits abgelaufen. Die zweijährige Vorbereitungszeit nach der Verabschiedung ist vorbei, alle DORA-Pflichten gelten, und nationale Finanzaufsichtsbehörden prüfen ihre Einhaltung. Der DORA-Rahmen beruht auf fünf Säulen, die dieser Leitfaden nacheinander erläutert:

• ICT-Risikomanagement – ein schriftlicher Plan für IT-Risiken unter Verantwortung des Leitungsorgans (des Vorstands);
• Management und Meldung ICT-bezogener Vorfälle – Erkennung, Protokollierung und Meldung von IT-Vorfällen an die Aufsicht;
• Tests der digitalen operationalen Resilienz – von regelmäßigen Schwachstellenscans bis zu vollständigen Angriffssimulationen durch „Red Teams“;
• ICT-Drittparteienrisikomanagement – Kontrolle der IT-Anbieter, von denen das Unternehmen abhängt, einschließlich eines Registers aller Anbieter;
• Informationsaustausch – freiwilliger Austausch von Bedrohungsinformationen zwischen Finanzunternehmen.

Zentrale DORA-Begriffe erklärt

Eine Reihe definierter Begriffe taucht in jedem Artikel der DORA-Verordnung, jedem Aufsichtsformular und jedem Anbietervertrag auf. Wer sie kennt, versteht den Rest wesentlich leichter.

Für wen gilt DORA?

Der DORA-Anwendungsbereich ist in Artikel 2 festgelegt, der zwanzig Kategorien von Finanzunternehmen aufführt. Hält ein Finanzinstitut irgendwo in der EU eine dieser Lizenzen, fällt es unabhängig von seiner Größe in den Anwendungsbereich, sofern keine besondere Ausnahme gilt. Die wichtigsten Gruppen sind nachstehend aufgeführt.

Was ist mit den IT-Unternehmen selbst? Cloud-Plattformen, Rechenzentren, Softwareanbieter und Managed-Security-Unternehmen sind keine Finanzunternehmen, doch DORA erfasst sie auf zwei Wegen. Erstens muss jedes Finanzunternehmen DORA-konforme Klauseln in seine Verträge mit ihnen aufnehmen; ein Anbieter, der dies ablehnt, riskiert den Verlust des Kunden. Zweitens werden die größten Anbieter – bedeutende Cloud-, Rechenzentrums-, Telekommunikations- und Finanzsoftwareanbieter – als kritische ICT-Drittdienstleister benannt und auf EU-Ebene direkt beaufsichtigt; die Liste wird jährlich aktualisiert.

Gilt DORA für Unternehmen außerhalb der EU? Unmittelbar nur für in der EU zugelassene Unternehmen – einschließlich EU-Tochtergesellschaften und Zweigstellen britischer, US-amerikanischer oder asiatischer Gruppen. Mittelbar erfasst sie jeden ausländischen Anbieter, der ein EU-Finanzunternehmen bedient, weil die zwingenden Vertragsklauseln unabhängig vom Sitz des Anbieters gelten. Ein als kritisch benannter Nicht-EU-Anbieter muss innerhalb von zwölf Monaten eine EU-Tochtergesellschaft gründen.

Schließlich gilt bei DORA der Grundsatz der Verhältnismäßigkeit: Die Pflichten wachsen mit Größe und Komplexität des Finanzinstituts. Kleinstunternehmen – mit weniger als zehn Beschäftigten und unter zwei Millionen Euro Umsatz oder Bilanzsumme – sind von mehreren Anforderungen ausgenommen, darunter TLPT sowie bestimmten Governance- und Meldepflichten. Eine definierte Gruppe kleinerer Unternehmen, etwa kleine und nicht verflochtene Wertpapierfirmen sowie bestimmte ausgenommene Zahlungs- und E-Geld-Institute, folgt nach Artikel 16 einem vereinfachten ICT-Risikomanagementrahmen. Klein zu sein nimmt ein zugelassenes Unternehmen nicht aus DORA heraus; es verringert nur den Aufwand.

DORA-Anforderungen: Die fünf Säulen erklärt

Die DORA-Compliance-Anforderungen gliedern sich in fünf Bereiche. Zusammen bilden sie einen Kreislauf – vorbeugen, erkennen, reagieren, wiederherstellen, lernen – und die Aufsicht erwartet für jeden Schritt Nachweise.

ICT-Risikomanagementrahmen (Artikel 5–16)

Einfach gesagt: Wissen Sie, welche IT Sie haben, was dabei schiefgehen kann, und erstellen Sie einen schriftlichen Plan, um sie zu schützen und wiederherzustellen. Der Rahmen muss IT-Vermögenswerte und Abhängigkeiten aufführen sowie darlegen, wie das Unternehmen Probleme verhindert und erkennt, darauf reagiert, sich davon erholt und aus Vorfällen lernt. Er wird mindestens jährlich und nach jedem schwerwiegenden Vorfall überprüft. Das Leitungsorgan genehmigt ihn, bestimmt das akzeptable Risiko und stellt das Budget bereit. Kritische Funktionen müssen abgebildet, Backups tatsächlich getestet und ein IT-Kontinuitätsplan neben dem allgemeinen Kontinuitätsplan des Unternehmens geführt werden.

Vorfallmeldung: Die Fristen von 4 Stunden, 72 Stunden und einem Monat

Jeder ICT-bezogene Vorfall muss nach denselben EU-weit geltenden Kriterien protokolliert und eingestuft werden: Anzahl betroffener Kunden, Reputationsschaden, Dauer, Ausbreitung, Datenverlust, Kritikalität des Dienstes und finanzielles Risiko. Überschreitet ein Vorfall die Schwellenwerte, ist er „schwerwiegend“ und muss der Aufsicht in drei Schritten gemeldet werden: Erstmeldung innerhalb von vier Stunden nach der Einstufung als schwerwiegend, jedoch spätestens 24 Stunden nachdem das Unternehmen davon Kenntnis erlangt hat; Zwischenbericht innerhalb von 72 Stunden nach der ersten Meldung; Abschlussbericht innerhalb eines Monats nach dem Zwischenbericht. Kunden, deren Geld oder Daten betroffen sind, müssen unverzüglich informiert werden. Schwere Cyberbedrohungen, die noch nicht zu Vorfällen geworden sind, können freiwillig gemeldet werden.

Resilienztests und Threat-Led Penetration Testing (TLPT)

Tests der digitalen operationalen Resilienz sind ein jährliches Programm: Jedes System, das eine kritische oder wichtige Funktion unterstützt, muss Schwachstellenscans, Lückenanalysen, Quellcodeprüfungen, Szenariotests, Leistungstests und Penetrationstests durchlaufen. Unternehmen, die die Aufsicht wegen ihrer Größe oder der Auswirkungen eines Ausfalls als bedeutend einstuft, müssen zusätzlich mindestens alle drei Jahre TLPT durchführen. Dies ist ein kontrollierter Angriff qualifizierter ethischer Hacker auf Live-Systeme nach einem anerkannten Rahmen. Kleinstunternehmen und Unternehmen unter dem vereinfachten Rahmen sind von TLPT befreit und testen nach einem leichteren, risikobasierten Zeitplan.

Drittparteienrisiko, Auslagerung und Informationsregister

Die Auslagerung von IT – an einen Cloud-Dienstleister oder andere Anbieter – lagert Verantwortung nicht aus. ICT-Drittparteienrisikomanagement beginnt mit einer schriftlichen Strategie für Anbieterrisiken: Ein Unternehmen muss Anbieter vor Vertragsabschluss prüfen, eine zu starke Abhängigkeit von einem einzelnen Anbieter vermeiden und ein Informationsregister – eine strukturierte Liste aller IT-Verträge – führen, das mindestens einmal jährlich an die Aufsicht geht. Die Verträge selbst müssen einen festen Klauselkatalog enthalten: Art und zugesagtes Niveau der Dienstleistung, Speicherort der Daten, Prüf- und Auditrecht, Unterstützungspflicht bei Vorfällen, Vertragsbeendigung und den Wechsel zu einem anderen Anbieter, falls nötig. Das Unternehmen bleibt voll verantwortlich, selbst wenn der Anbieter ein auf EU-Ebene beaufsichtigter kritischer Dienstleister ist.

Informationsaustausch über Cyberbedrohungen

Finanzunternehmen dürfen innerhalb vertrauenswürdiger Gruppen Bedrohungsinformationen – Angriffsmuster und Kompromittierungsindikatoren – austauschen. Niemand muss teilnehmen. Wer es tut, muss jedoch seine Aufsicht informieren; außerdem müssen Vertraulichkeits- und Datenschutzvorschriften eingehalten werden.

DORA vs. NIS2 vs. GDPR: Wie die Regeln zusammenwirken

Drei EU-Rechtsakte überschneiden sich bei Cyberresilienz und Vorfallmeldungen, und viele Finanzinstitute unterliegen mehr als einem davon. Die Tabelle zeigt, wen die einzelnen Regelwerke erfassen und wie sich die Meldefristen unterscheiden.

In der Praxis meldet ein Finanzunternehmen IT-Vorfälle seiner Finanzaufsicht, nicht der nationalen Cybersicherheitsbehörde. GDPR gilt parallel: Führt ein Cyberangriff zum Abfluss von Kundendaten, meldet das Unternehmen ihn zweimal – nach DORA an die Finanzaufsicht und nach GDPR an die Datenschutzbehörde – mit zwei getrennten Fristen.

DORA und Krypto: Was sie für CASPs und Token-Emittenten bedeutet

Für Kryptounternehmen wirken die DORA-Verordnung und der MiCA-Rahmen zusammen. MiCA entscheidet, wer in der EU Kryptodienstleistungen anbieten oder Token emittieren darf; DORA bestimmt, wie die Technologie hinter diesen Diensten betrieben werden muss. Ein nach MiCA zugelassener Kryptowerte-Dienstleister ist ab Erteilung seiner Lizenz ein Finanzunternehmen im Sinne von DORA; dies gilt ebenso für jeden Emittenten vermögenswertereferenzierter Token. MiCA verweist für IT- und Sicherheitsanforderungen selbst auf DORA, weshalb jede Aufsicht beide Regelwerke gemeinsam auslegt.

In der Praxis wird die Resilienz bereits im Zulassungsverfahren geprüft, nicht erst danach. Prüft die Aufsicht einen CASP-Antrag, gehören der IT-Risikorahmen, der Geschäftsfortführungsplan, die Vorfallverfahren und Auslagerungsvereinbarungen zur Akte; DORA ist der Maßstab dafür. Eine Kryptobörse oder Verwahrstelle kann keine Lizenz erhalten oder behalten, wenn ihr Resilienzplan nur auf dem Papier existiert.

Kryptounternehmen haben zudem IT-Abhängigkeiten, die eine Bank nicht hat: Verwahrung privater Schlüssel, Blockchain-Knoten-Anbieter, Wallet-Infrastruktur Dritter, Smart-Contract-Komponenten und Märkte, die rund um die Uhr ohne Wartungsfenster handeln. Unter DORA ist jedes davon ein IT-Vermögenswert oder eine Anbieterbeziehung, die erfasst, bewertet, vertraglich geregelt und getestet werden muss. So erfüllen auch nicht zugelassene Anbieter von Hosting, Schlüsselverwaltung oder Blockchain-Infrastruktur DORA mittelbar – über die Verträge ihrer Kunden.

DORA-Sanktionen, Bußgelder und Folgen bei Verstößen

Es gibt keine einheitliche EU-weite Tabelle mit DORA-Sanktionen. Stattdessen verpflichtet Artikel 50 jeden Mitgliedstaat, „wirksame, verhältnismäßige und abschreckende“ Sanktionen festzulegen, und gibt den Aufsichten die Befugnis, Unterlagen anzufordern, Prüfungen durchzuführen, Abhilfemaßnahmen anzuordnen und Warnungen zu veröffentlichen. Die nationale zuständige Behörde jedes Mitgliedstaats wendet sie nach dem jeweiligen sektoralen Zulassungsrecht an. Deshalb unterliegen Banken, Zahlungsunternehmen und Kryptobörsen jeweils der Sanktionsleiter ihres eigenen Sektors.

Vielleicht haben Sie von einem „DORA-Bußgeld“ in Höhe von einem Prozent des durchschnittlichen weltweiten Tagesumsatzes gelesen. Diese Zahl ist real, richtet sich aber an andere: Sie ist die tägliche Sanktion, die die Europäischen Aufsichtsbehörden einem kritischen ICT-Drittdienstleister bei Missachtung einer Aufsichtsentscheidung für bis zu sechs Monate auferlegen können. Sie ist kein Bußgeld für Banken oder Kryptounternehmen. Die daneben gelegentlich genannten „2 % des Jahresumsatzes“ stehen ebenfalls nicht in DORA, sondern stammen aus NIS2: Dort ist dies die Mindestobergrenze, die Staaten für wesentliche Einrichtungen festlegen müssen. Für ein Finanzunternehmen sind die realistischen Folgen:

• aufsichtliche Maßnahmen – Anordnungen zur Behebung, Beschränkungen von Tätigkeiten und in schweren Fällen Aussetzung oder Verlust der Lizenz;
• Verwaltungsbußgelder nach dem nationalen Recht des jeweiligen Sektors;
• persönliche Haftung von Vorstandsmitgliedern, weil DORA den Vorstand für den IT-Rahmen verantwortlich macht;
• strafrechtliche Haftung in Ländern, die diese zusätzlich eingeführt haben, was Artikel 52 erlaubt;
• Reputations- und Geschäftsschäden – verlorene Kunden, Bankpartner und Investoren.

Wer beaufsichtigt DORA? Aufsichtsbehörden auf nationaler und EU-Ebene

Die tägliche DORA-Aufsicht bleibt bei der Behörde, die das Unternehmen bereits zulässt – der Zentralbank oder Finanzaufsichtsbehörde seines Herkunftsmitgliedstaats. Diese zuständige Behörde erhält Vorfallmeldungen und Informationsregister, entscheidet, wer TLPT durchführen muss, und prüft den IT-Risikorahmen im Rahmen der regulären Aufsicht. Die meisten Behörden veröffentlichen DORA-Leitlinien, Vorlagen und Fristen auf ihren Websites.

Auf EU-Ebene teilen sich drei Stellen die Arbeit: die Europäische Wertpapier- und Marktaufsichtsbehörde, die Europäische Bankenaufsichtsbehörde und EIOPA, die Aufsichtsbehörde für Versicherungen und Altersversorgung. Sie erstellen die technischen Standards, welche die Einzelheiten regeln, und bestimmen gemeinsam die kritischen ICT-Drittdienstleister. Jeder von ihnen wird anschließend von einer der drei Stellen als Lead Overseer beaufsichtigt.

DORA-Compliance-Checkliste: So erfüllen Sie die Anforderungen

Ob ein Unternehmen eine Lizenz beantragt oder bereits beaufsichtigt wird: Dieselben Unterlagen belegen die DORA-Compliance bei einer Prüfung. Ein praktischer Ausgangspunkt für einen DORA-Umsetzungsplan oder eine Lückenanalyse:

• Prüfen Sie Ihren Anwendungsbereich: In welche Kategorie nach Artikel 2 Sie fallen und ob der vereinfachte Rahmen oder eine Kleinstunternehmensausnahme gilt.
• Erfassen Sie jedes IT-Asset, System und jeden Datenfluss, das oder der eine kritische oder wichtige Funktion unterstützt.
• Verabschieden Sie eine vom Vorstand genehmigte ICT-Risikomanagementrichtlinie mit benannten Verantwortlichen und jährlicher Überprüfung.
• Richten Sie Vorfallklassifizierung, Vorfallsprotokoll und Meldevorlagen ein, die den gesetzlichen Fristen entsprechen.
• Erstellen Sie einen jährlichen Testkalender und prüfen Sie, ob die Aufsicht Sie auf die TLPT-Liste gesetzt hat.
• Erstellen Sie das Informationsregister aller IT-Anbieter und ergänzen Sie ihre Verträge um die Pflichtklauseln.
• Prüfen Sie Konzentrationsrisiken und erstellen Sie Ausstiegspläne für Anbieter, die kritische Funktionen unterstützen.
• Testen Sie Backups, Wiederherstellung und den IT-Kontinuitätsplan mindestens einmal jährlich.
• Schulen Sie den Vorstand und bewahren Sie Nachweise über die Schulung auf.

Eesti Firma berät Fintech- und Kryptounternehmen zu den rechtlichen Aspekten von DORA: Wir klären, welche Pflichten gelten, stimmen den IT-Rahmen auf die MiCA-Zulassungsanforderungen ab, prüfen Anbieterverträge und bereiten die Unterlagen vor, die eine Aufsicht erwartet. Kontaktieren Sie uns, um zu besprechen, wie die Verordnung auf Ihr Unternehmen anzuwenden ist.

Beratung anfragen

Häufig gestellte Fragen zu DORA