Der Digital Operational Resilience Act, Verordnung (EU) 2022/2554, gilt seit dem 17. Januar 2025. Anders als NIS2 ist er eine Verordnung und keine Richtlinie, gilt also in jedem Mitgliedstaat unmittelbar, ohne auf eine nationale Umsetzung zu warten, und beaufsichtigt wird er von den Finanzaufsichtsbehörden, nicht von den Cybersicherheitsbehörden.
Die Grundidee ist einfach: Eine Bank, ein Versicherer oder ein Handelsplatz kann durch einen IKT-Ausfall genauso zu Fall kommen wie durch einen Kreditverlust, also ist die operative Widerstandsfähigkeit gegen IKT-Risiken eine Frage der Aufsicht. Die Folge für die Technologiebranche ist weniger offensichtlich und reicht weiter: DORA regelt die Beziehung zwischen Finanzunternehmen und den Dienstleistern, von denen sie abhängen. Die Pflichten fließen also in die Verträge mit Cloud-Anbietern, Softwareherstellern und Managed-Service-Providern, die selbst gar nicht reguliert sind.
Wer betroffen ist
In Artikel 2 sind zwanzig Arten von Finanzunternehmen aufgeführt: Kreditinstitute, Zahlungs- und E-Geld-Institute, Wertpapierfirmen, Anbieter von Krypto-Dienstleistungen, Zentralverwahrer, Handelsplätze, Versicherungs- und Rückversicherungsunternehmen, Versicherungsvermittler, Pensionseinrichtungen, Ratingagenturen, Schwarmfinanzierungsdienstleister und mehr. Ein Verhältnismäßigkeitsgrundsatz skaliert die Pflichten nach Größe und Risikoprofil, und einige Kleinstunternehmen bekommen ein vereinfachtes Regime.
IKT-Drittdienstleister sind auf zwei Wegen betroffen. Alle erreicht DORA indirekt, über die Vertragsanforderungen, die ihre Finanzkunden ihnen auferlegen müssen. Eine kleine Zahl, von den Europäischen Aufsichtsbehörden als kritisch eingestuft, erreicht DORA direkt, über einen Überwachungsrahmen mit einer federführenden Aufsichtsbehörde, Prüfungsbefugnissen und Zwangsgeldern. Die ersten Einstufungen erfolgten Ende 2025 und betreffen die größten Cloud- und Infrastrukturanbieter.
Die fünf Säulen
IKT-Risikomanagement (Kapitel II). Das Leitungsorgan trägt die Verantwortung für IKT-Risiken und muss einen Rahmen genehmigen und regelmäßig überprüfen, der Identifizierung, Schutz, Erkennung, Reaktion, Wiederherstellung, Lernen und Kommunikation abdeckt. Der Rahmen muss dokumentiert, getestet und intern auditiert sein. Wiederherstellungsziele, Backup-Richtlinien und ein Krisenkommunikationsplan sind ausdrückliche Anforderungen, keine stillschweigenden.
Behandlung und Meldung IKT-bezogener Vorfälle (Kapitel III). Unternehmen müssen Vorfälle anhand von Schwellenwerten aus technischen Regulierungsstandards einstufen und schwerwiegende an ihre zuständige Behörde melden: eine Erstmeldung innerhalb von vier Stunden nach der Einstufung und spätestens 24 Stunden nach Kenntnis, ein Zwischenbericht innerhalb von 72 Stunden und ein Abschlussbericht innerhalb eines Monats. Erhebliche Cyberbedrohungen dürfen freiwillig gemeldet werden.
Testen der digitalen operationalen Resilienz (Kapitel IV). Jedes Unternehmen betreibt ein Testprogramm: Schwachstellenbewertungen, szenariobasierte Tests, Quellcode-Reviews und Ähnliches, risikobasiert, für kritische Systeme mindestens jährlich. Als bedeutend eingestufte Unternehmen müssen zusätzlich alle drei Jahre bedrohungsorientierte Penetrationstests (TLPT) durchführen, nach dem Vorbild des TIBER-EU-Rahmens, auf produktiven Systemen, und die Ergebnisse mit der Behörde teilen.
IKT-Drittparteienrisiko (Kapitel V). Das ist die Säule, die die Dienstleister erreicht. Unternehmen müssen ein Informationsregister führen, das jede vertragliche Vereinbarung über IKT-Dienstleistungen auflistet und die kennzeichnet, die kritische oder wichtige Funktionen unterstützen. Vor Vertragsschluss müssen sie das Konzentrationsrisiko und die Eignung des Dienstleisters bewerten. Verträge müssen die Bestimmungen aus Artikel 30 enthalten: Beschreibung und Orte der Leistung, Datenschutz, Zusagen zu Verfügbarkeit und Integrität, Unterstützung bei Vorfällen, Prüf- und Zugangsrechte für das Unternehmen und die Behörde, Ausstiegsstrategien mit Übergangsfristen und, für kritische Funktionen, Service-Level, Teilnahme an Tests und Notfallvorkehrungen.
Informationsaustausch (Kapitel VI). Unternehmen dürfen in vertrauenswürdigen Gemeinschaften Informationen über Cyberbedrohungen austauschen, mit Schutzvorkehrungen. Diese Säule ist eine Erlaubnis, keine Pflicht.
Was ein Auditor verlangt
Ein DORA-Auftrag, ob internes Audit, Bereitschaftsprüfung oder Lieferantenprüfung, arbeitet die Säulen meist der Reihe nach ab und fragt nach dem Artefakt, das jede davon impliziert:
- Der Rahmen für das IKT-Risikomanagement und die Vorstandsprotokolle, die ihn genehmigen, dazu Nachweise der regelmäßigen Überprüfung und der eigenen Schulung des Leitungsorgans zu IKT-Risiken, die Artikel 5 verlangt.
- Das Asset-Inventar mit der Zuordnung von IKT-Assets zu Geschäftsfunktionen und der Kennzeichnung kritischer oder wichtiger Funktionen.
- Das Verfahren zur Einstufung von Vorfällen, das Vorfallprotokoll und Kopien aller bei der Behörde eingereichten Meldungen, mit Zeitstempeln, die zeigen, dass die Fristen eingehalten wurden.
- Das Testprogramm, die Ergebnisse der letzten jährlichen Tests kritischer Systeme, die Nachverfolgung der Behebung und, bei bedeutenden Unternehmen, Umfang und Bescheinigung des TLPT.
- Das Informationsregister im von den ESAs vorgegebenen Format und eine Stichprobe von Verträgen, Klausel für Klausel gegen Artikel 30 geprüft.
- Die Ausstiegsstrategien für kritische Funktionen und der Nachweis, dass sie getestet oder wenigstens durchgespielt wurden.
- Die Analyse des Konzentrationsrisikos: Wie viele kritische Funktionen hängen an einem Anbieter, und was ist der Plan, wenn dieser Anbieter ausfällt.
Für IKT-Dienstleister
Wer Software oder Dienstleistungen an eine Bank oder einen Versicherer in der EU verkauft, hat vermutlich schon einen überarbeiteten Vertrag bekommen, einen Fragebogen oder beides. Ihr Kunde füllt damit sein Informationsregister und erfüllt Artikel 30. Was Sie zu einem Dienstleister macht, den man gern behält:
- Schriftlich sagen zu können, wo Daten verarbeitet und gespeichert werden, und Änderungen mitzuteilen.
- Prüf- und Zugangsrechte zu akzeptieren, auch für die Aufsicht Ihres Kunden, und einen Weg zu haben, sie einzulösen, ohne die anderen Kunden zu stören, meist über einen unabhängigen Prüfbericht als erste Antwort.
- Vorfallmeldungen so detailliert und so schnell zu unterstützen, wie es die Fristen Ihres Kunden verlangen.
- Einen Ausstiegsplan zu haben, den Sie beschreiben können: Formate für die Datenrückgabe, Unterstützung beim Übergang, Löschbestätigung.
- Am Resilienztest Ihres Kunden teilzunehmen, wo Sie eine kritische Funktion unterstützen.
Ein ISO-27001-Zertifikat oder ein SOC-2-Bericht ist keine DORA-Konformität, aber ein Dienstleister, der eines hat, hat die meisten Fragen im Register schon beantwortet. Die Lücke sind meist die Vertragsbedingungen und die Zusagen zu Ausstieg und Tests, die kein Zertifikat abdeckt.
Der Fehler, den man vermeiden sollte
Das häufigste Versäumnis im ersten Anwendungsjahr war, DORA als Sicherheitsprojekt des CISO zu behandeln. Es ist eine Governance-Verordnung. Das Leitungsorgan ist ausdrücklich verantwortlich, das Register ist eine Meldung an die Aufsicht, die Vorfallfristen sind gesetzliche Fristen, und die Vertragsklauseln sind eine gesetzliche Anforderung. Die Unternehmen, die vorbereitet waren, hatten Recht, Einkauf, Risiko und Technik von Anfang an in einem Raum.