Kaum eine EU-Verordnung hat den Finanzsektor operativ so durchgeschüttelt wie DORA. Der Digital Operational Resilience Act — formal die Verordnung (EU) 2022/2554 — gilt seit dem 17. Januar 2025 unmittelbar in allen Mitgliedstaaten. Anders als frühere Regelwerke begnügt sich DORA nicht mit abstrakten Governance-Vorgaben: Die Verordnung schreibt konkret vor, wie Banken, Versicherungen, Zahlungsinstitute und Wertpapierfirmen ihre IKT-Risiken managen, Vorfälle melden und ihre Widerstandsfähigkeit testen müssen. Und sie reicht weit über die Finanzbranche hinaus — denn wer als IT-Dienstleister Finanzunternehmen beliefert, bekommt die Anforderungen über Vertragsklauseln direkt auf den eigenen Tisch.
Wen DORA betrifft
Der Anwendungsbereich ist bewusst breit gefasst. Erfasst sind über zwanzig Kategorien von Finanzunternehmen: Kreditinstitute, Versicherungen und Rückversicherungen, Wertpapierfirmen, Zahlungs- und E-Geld-Institute, Verwalter alternativer Investmentfonds, Krypto-Dienstleister und weitere. In Deutschland führt die BaFin die Aufsicht.
Die zweite, oft unterschätzte Gruppe sind IKT-Drittdienstleister. Cloud-Provider, Rechenzentren, Softwareanbieter und Managed-Service-Provider, die als kritisch eingestuft werden, unterliegen einem eigenen europäischen Überwachungsrahmen. Aber auch unterhalb dieser Schwelle gilt: Jedes Finanzunternehmen muss seine IKT-Verträge nach den Vorgaben aus Artikel 30 DORA gestalten — mit Auditrechten, Kündigungsklauseln, Unterstützungspflichten bei Vorfällen und definierten Service-Leveln. Wer solche Klauseln nicht akzeptiert, fliegt mittelfristig aus dem Lieferantenportfolio.
Die fünf Pflichtenblöcke
DORA lässt sich in fünf Säulen gliedern, die zusammen ein geschlossenes Resilienz-System ergeben:
1. IKT-Risikomanagement. Kern ist ein dokumentierter Risikomanagementrahmen mit klarer Verantwortung des Leitungsorgans. Die Geschäftsführung kann die Verantwortung nicht delegieren — sie muss IKT-Risiken verstehen, Strategien freigeben und Budgets bereitstellen. Verlangt werden unter anderem Asset-Inventare, Schutzmaßnahmen, Erkennungsmechanismen und getestete Wiederanlaufpläne.
2. Behandlung und Meldung von IKT-Vorfällen. Schwerwiegende Vorfälle sind nach einem gestaffelten Schema zu melden: Erstmeldung, Zwischenbericht, Abschlussbericht — jeweils mit festen Fristen und standardisierten Meldeformaten. Das setzt voraus, dass Vorfälle intern überhaupt sauber klassifiziert werden können. Ohne funktionierenden Incident-Response-Prozess ist die Meldepflicht schlicht nicht einhaltbar.
3. Testen der digitalen Betriebsstabilität. Alle betroffenen Unternehmen müssen ihre Systeme regelmäßig testen — von Schwachstellenscans bis zu szenariobasierten Übungen. Für bedeutende Institute kommen bedrohungsorientierte Penetrationstests (Threat-Led Penetration Testing, TLPT) hinzu, die mindestens alle drei Jahre auf Live-Systemen durchzuführen sind.
4. Management des IKT-Drittparteirisikos. Jedes Finanzunternehmen führt ein Informationsregister über sämtliche IKT-Dienstleistungsverträge und meldet es der Aufsicht. Vor jeder Auslagerung stehen Risikoanalyse und Due Diligence; Konzentrationsrisiken — etwa die Abhängigkeit von einem einzigen Cloud-Anbieter — sind ausdrücklich zu bewerten.
5. Informationsaustausch. Der freiwilligste Teil: DORA schafft einen rechtlichen Rahmen, damit Finanzunternehmen Bedrohungsinformationen untereinander teilen können, ohne mit Vertraulichkeits- oder Datenschutzpflichten zu kollidieren.
Warum DORA auch Nicht-Finanzunternehmen erreicht
Die praktische Reichweite entsteht über die Lieferkette. Ein Softwarehaus, das eine Fachanwendung an eine Versicherung liefert, ein Hoster, der ein Zahlungsinstitut bedient, eine Agentur, die das Kundenportal einer Bank betreibt — sie alle bekommen DORA-konforme Vertragsanhänge vorgelegt. Typische Anforderungen: Mitwirkung an Resilienz-Tests, Meldung eigener Sicherheitsvorfälle innerhalb weniger Stunden, dokumentierte Exit-Strategien und Nachweise über das eigene Sicherheitsniveau.
Wer als Dienstleister bereits ein Managementsystem nach ISO 27001 betreibt oder sich am BSI-Grundschutz orientiert, deckt viele dieser Anforderungen strukturell ab und kann Nachweise aus dem laufenden Betrieb liefern. Wer bislang ohne systematisches Sicherheitsmanagement arbeitet, steht dagegen vor der Wahl: nachrüsten oder Finanzkunden verlieren.
Berührungspunkte mit NIS-2 und dem Datenschutz
DORA ist im Finanzsektor grundsätzlich lex specialis gegenüber NIS-2 — wer unter DORA fällt, wendet für die dort geregelten Bereiche die strengeren DORA-Vorgaben an. Unternehmen mit gemischtem Geschäft sollten beide Regelwerke gegeneinander abgrenzen, statt doppelte Strukturen aufzubauen. Und wo IKT-Vorfälle personenbezogene Daten betreffen, laufen die DORA-Meldeprozesse parallel zur 72-Stunden-Meldung nach Artikel 33 DSGVO: Ein Vorfall, zwei Meldestränge, unterschiedliche Empfänger. Gerade hier lohnt es sich, Incident-Response-Playbooks einmal integriert aufzusetzen — inklusive Notfall- und Wiederanlaufplanung, wie sie ein sauberes Business Continuity Management ohnehin vorsieht.
Wo Unternehmen jetzt nachschärfen sollten
Anderthalb Jahre nach Geltungsbeginn zeigt sich in der Praxis ein wiederkehrendes Muster: Die Papierlage stimmt, die Umsetzung hakt. Drei Punkte tauchen in Prüfungen immer wieder auf:
- Das Informationsregister ist unvollständig. Schatten-IT und über Fachabteilungen beschaffte SaaS-Tools fehlen häufig — genau die Verträge, die nie über den Einkauf gelaufen sind.
- Meldefristen scheitern an der Erkennung. Wer einen Vorfall erst nach Tagen bemerkt, kann keine fristgerechte Erstmeldung abgeben. Detektionsfähigkeit ist die eigentliche Baustelle, nicht das Meldeformular.
- Wiederanlaufpläne sind ungetestet. Ein Plan, der noch nie unter realistischen Bedingungen geübt wurde, ist eine Hypothese. DORA verlangt getestete Resilienz, keine dokumentierte Absicht.
Der pragmatische Einstieg: Bestandsaufnahme der IKT-Verträge, Abgleich des vorhandenen Sicherheitsmanagements mit den fünf Pflichtenblöcken, dann eine priorisierte Lückenliste. Finanzunternehmen kennen dieses Vorgehen aus jeder Aufsichtsprüfung — für ihre IT-Dienstleister ist es oft der erste Kontakt mit regulierter Sicherheit. Je früher man ihn gestaltet, desto weniger diktieren ihn später die Vertragsanhänge der Kunden.