DORA deckt fünf Risikobereiche ab. Die meisten Compliance-Prüfungen decken nur ein oder zwei davon ab.

Ein Vorstand stellt einem Compliance-Beauftragten eine einfache Frage: Sind wir DORA-konform? Die ehrliche Antwort hängt vollständig davon ab, welchen Teil von DORA der Vorstand meint.

DORA ist keine einzelne Anforderung. Es ist eine Verordnung, die auf fünf verschiedenen Verpflichtungen aufbaut, von denen jede ihren eigenen Zeitplan, ihre eigenen technischen Standards und ihre eigenen Fallstricke hat. Wenn man sie als eine einzige Checkliste behandelt, führt dies dazu, dass Unternehmen sich bei den bereits erfüllten Punkten sicher fühlen, während sie die noch offenen Bereiche übersehen.

Zu verstehen, was DORA tatsächlich abdeckt und für wen es gilt, ist der erste Schritt, um diese Frage des Vorstands ehrlich beantworten zu können.

Das Problem, das DORA lösen soll

Finanzdienstleistungen basieren heute auf Technologien, die von einer kleinen Anzahl von Anbietern bereitgestellt werden: Cloud-Plattformen, Zahlungsabwickler, Rechenzentren. Eine Störung bei einem dieser Anbieter bleibt nicht auf eine Bank oder ein Land beschränkt.

Die Europäische Aufsichtsbehörde für das Versicherungswesen und die betriebliche Altersversorgung (EIOPA) bringt es auf den Punkt: Wenn IKT-Risiken nicht ordnungsgemäß verwaltet werden, können sie Finanzdienstleistungen über Grenzen hinweg stören, mit Dominoeffekten für andere Unternehmen, andere Sektoren und die gesamte Wirtschaft (EIOPA, Digital Operational Resilience Act, abgerufen im August 2026). DORA ist am 17. Januar 2025 in Kraft getreten.

Vor DORA hatte jeder EU-Mitgliedstaat seine eigenen Regeln – oder gar keine – für die digitale Resilienz im Finanzwesen. Eine Bank in einem Land konnte einer strengeren Technologieaufsicht unterliegen als eine Bank in einem anderen, obwohl beide auf dieselbe Handvoll globaler Cloud- und Zahlungsanbieter angewiesen waren. DORA ersetzt diesen Flickenteppich durch eine einheitliche Verordnung, die in der gesamten EU gleichermaßen gilt.

Die fünf Bereiche, die DORA tatsächlich abdeckt

Die EIOPA unterteilt den Anwendungsbereich von DORA in sechs Teile, die sich in fünf Kernverpflichtungen sowie einen direkten Aufsichtsmechanismus für die systemrelevantesten Anbieter gruppieren lassen.

IKT-Risikomanagement legt die Grundlage fest: Unternehmen benötigen einen dokumentierten Rahmen, um die Technologie, von der ihr Geschäft abhängt, zu identifizieren und kontinuierlich zu überwachen – keine statische Richtlinie, die nur einmal im Jahr überprüft wird.

IKT-bezogenes Vorfallmanagement regelt, wie Unternehmen Vorfälle erkennen, klassifizieren und an die Aufsichtsbehörden melden, einschließlich der Zeitvorgaben, die bestimmen, wie schnell ein schwerwiegender Vorfall eskaliert werden muss.

Tests der digitalen operationalen Resilienz verpflichtet Unternehmen zur Durchführung eines Testprogramms, das von grundlegenden Überprüfungen bis hin zur anspruchsvollsten Form, dem bedrohungsorientierten Penetrationstest, für als systemrelevant eingestufte Unternehmen reicht.

IKT-Risikomanagement durch Drittanbieter befasst sich mit den Anbietern, auf die Unternehmen angewiesen sind, einschließlich der Überwachungsvereinbarungen und der vertraglichen Bedingungen, die erfüllt sein müssen, bevor einem Anbieter kritische Funktionen anvertraut werden.

Informationsaustausch schafft einen – derzeit freiwilligen – Rahmen für Unternehmen, um Bedrohungsinformationen und Erkenntnisse aus Vorfällen auszutauschen, wobei ein rechtlicher Schutz für den Austausch in gutem Glauben besteht.

Aufsicht über kritische Drittanbieter ist der Teil, der über die Finanzunternehmen selbst hinausgeht: Er verleiht den EU-Aufsichtsbehörden direkte Befugnisse gegenüber Technologieunternehmen, deren Ausfall ein systemweites Risiko darstellen würde (EIOPA, Digital Operational Resilience Act, abgerufen im August 2026).

Wer muss die Anforderungen tatsächlich erfüllen

DORA gilt für rund 20 verschiedene Arten von Finanzunternehmen in der gesamten EU – ein Geltungsbereich, der weit über Banken hinausgeht. Dazu gehören Versicherungs- und Rückversicherungsunternehmen, Wertpapierfirmen, Zahlungsinstitute, E-Geld-Institute, Anbieter von Krypto-Dienstleistungen sowie die kritischen IKT-Drittanbieter, die diese unterstützen.

Nicht jede Verpflichtung gilt für jedes Unternehmen im gleichen Maße. Bedrohungsorientierte Penetrationstests sind Unternehmen vorbehalten, die von einer nationalen Behörde offiziell als bedeutend eingestuft wurden – in der Regel die größten Banken, bedeutende Versicherer und systemrelevante Marktinfrastrukturen. Das grundlegende IKT-Risikomanagement und die Meldepflichten bei Vorfällen gelten weitaus umfassender, auch für kleinere Zahlungsinstitute und Wertpapierfirmen.

Ein mittelgroßer Versicherer und eine global systemrelevante Bank fallen beide unter DORA, doch die Intensität der Anforderungen unterscheidet sich erheblich. Genau hier wird die Frage nach der Compliance kompliziert: Ein Unternehmen kann in vier der fünf Bereiche vollständig konform sein und dennoch eine wesentliche Lücke im fünften aufweisen. Welche Lücke am schwerwiegendsten ist, hängt dabei ganz von der Größe und Rolle des Unternehmens ab.

Wichtige Erkenntnis: DORA ist eine Verordnung zur operativen Resilienz, keine Cybersicherheitsverordnung

DORA liest sich wie eine Cybersicherheitsverordnung, fungiert jedoch als Verordnung zur operativen Resilienz, die durch Cybersicherheitsmechanismen durchgesetzt wird. Diese Unterscheidung ist nicht nur semantischer Natur.

Eine Cybersicherheitsverordnung fragt, ob ein Unternehmen einen Angriff abwehren kann. DORA fragt, ob ein Unternehmen den Betrieb aufrechterhalten und gegenüber einer Aufsichtsbehörde nachweisen kann, dass es dies auch dann tut, wenn etwas in seinem Technologie-Stack ausfällt – unabhängig davon, ob die Ursache ein Angreifer, ein Ausfall bei einem Anbieter oder ein interner Fehler war.

Diese Herangehensweise ändert die Bedeutung von „Bereitschaft“ in der Praxis. Es geht weniger um eine einzelne Kontrollmaßnahme, sondern vielmehr darum, ob das Unternehmen auf Verlangen nachweisen kann, dass seine Mitarbeiter und Systeme so agieren, wie es in der Dokumentation beschrieben ist.

Für Compliance- oder Sicherheitsverantwortliche ist es wenig hilfreich, die Frage „Sind wir DORA-konform?“ als Ganzes zu stellen. Sinnvoller ist es, jeden der fünf Bereiche separat zu analysieren und ehrlich zu bewerten, wo die Nachweise lückenhaft sind.

Zwei Bereiche, in denen diese Nachweislücken am häufigsten auftreten, sind die Klassifizierung von Vorfällen unter Zeitdruck und Resilienztests gegen realistisches Angreiferverhalten. Es lohnt sich, direkt zu untersuchen, wie die Vier-Stunden-Frist für die Meldung von Vorfällen in der Praxis funktioniert und warum bedrohungsorientierte Penetrationstests KI-gestützte Betrugstaktiken wie Voice-Cloning berücksichtigen müssen – Taktiken, die laut FBI-Daten von 2025 längst keine Einzelfälle mehr sind.

Beides lässt sich nicht allein durch eine Richtlinie lösen. Beides hängt davon ab, dass Mitarbeiter unter realen Bedingungen die richtigen Entscheidungen treffen – eine Fähigkeit, die man besser direkt testet, anstatt sie vorauszusetzen.

Betrachten Sie die Lücke, die dies in der Praxis schafft: Ein Unternehmen kann über einen vollständig dokumentierten Plan zur Reaktion auf Vorfälle, einen genehmigten Testkalender und einen lückenlosen Audit-Trail verfügen und dennoch während eines tatsächlichen Vorfalls feststellen, dass die zuständige Person die Klassifizierungskriterien nicht schnell genug anwenden kann oder dass das Red-Team-Szenario nie einen Anrufer berücksichtigt hat, der exakt wie ein vertrauenswürdiger Kollege klingt. Dokumentation beweist, dass ein Plan existiert. Sie beweist nicht, dass er unter Druck funktioniert.

DORA wird weiterhin schrittweise umgesetzt. Technische Standards werden laufend finalisiert, Informationsregister Jahr für Jahr verfeinert, und die Aufsichtsbehörden gehen dazu über, nicht nur die Dokumentation, sondern die tatsächlichen Maßnahmen der Unternehmen aktiv zu prüfen.

Diejenigen Unternehmen, die DORA als fünf separate, fortlaufende Verpflichtungen betrachten und nicht als ein Projekt mit einem festen Enddatum, werden am wenigsten Gefahr laufen, Lücken erklären zu müssen, von denen sie nichts wussten.

Diese Unterscheidung bestimmt auch, wie die Compliance-Funktion intern über Fortschritte berichten sollte. Eine einzelne Kennzahl wie „DORA-Bereitschaft: 80 % abgeschlossen“ auf einer Folie für den Vorstand verschleiert, welche 20 % fehlen. Dabei birgt eine Lücke bei der Meldung von Vorfällen ein völlig anderes Risiko als eine Lücke bei der Aufsicht über Drittanbieter. Die Berichterstattung nach Bereichen ist zwar aufwendiger, liefert dem Vorstand aber ein präzises statt eines beschönigenden Bildes.