DORA verstehen: Ziel, Anwendungsbereich und die fünf Säulen

Problem in der Praxis

Viele Finanzunternehmen behandeln DORA als reines IT-Sicherheitsthema und delegieren es in die Linie. Damit wird die zentrale Aussage der Verordnung verfehlt: Die Verantwortung für den IKT-Risikomanagementrahmen liegt beim Leitungsorgan und ist nicht vollständig delegierbar.

Ein zweites Praxisproblem ist die Unsicherheit über den Anwendungsbereich. DORA adressiert rund 20 Typen von Finanzunternehmen sowie kritische IKT-Drittdienstleister. Häuser, die bisher nur sektorspezifische Anforderungen kannten, unterschätzen leicht, ob und in welchem Umfang sie betroffen sind und wie die Proportionalität wirkt.

Drittens herrscht Verwirrung über das Verhältnis zu bekannten Rahmenwerken. Gilt jetzt NIS2 oder DORA? Sind die bisherigen BaFin-Anforderungen wie BAIT, VAIT, KAIT und ZAIT weiter maßgeblich? Ersetzt ein ISO-27001-Zertifikat den Nachweis? Diese Fragen müssen geklärt sein, bevor ein Umsetzungsprogramm sinnvoll aufgesetzt wird.

CISO-Einordnung

Der CISO sollte DORA nicht als isolierten Pflichtenkatalog lesen, sondern als regulatorische Klammer um die operationale Resilienz. DORA beschreibt das Was und Wozu; das Wie kann ein bestehendes ISMS liefern. Viele DORA-Anforderungen, etwa Governance, Risikobehandlung, Asset- und Zugriffsmanagement, Notfallmanagement, Lieferantensteuerung und Incident-Prozesse, sind über ISMS-Controls abbildbar.

Für die Einordnung gegenüber NIS2 gilt: DORA ist für Finanzunternehmen lex specialis. Wo beide Rahmen dieselbe Materie regeln, geht DORA vor. Banken, Versicherer und vergleichbare Adressaten erfüllen ihre IKT-Resilienzpflichten also primär über DORA, während NIS2 als horizontaler Bezugspunkt bestehen bleibt. Das verhindert doppelte Programme und falsche Prioritäten.

DORA fordert jedoch Spezifika, die über ein klassisches ISMS hinausgehen: bedrohungsgeleitete Penetrationstests, eine standardisierte Vorfallmeldung an die Aufsicht, ein Register der IKT-Verträge, Schlüsselvertragsklauseln gegenüber Dienstleistern und den EU-Aufsichtsrahmen für kritische Drittdienstleister. Ein ISO-Zertifikat ist hilfreich, ersetzt diese Pflichten aber nicht.

Umsetzungsperspektive

Die fünf Säulen entsprechen im Wesentlichen den Kapiteln II bis VI der Verordnung. Sie bilden eine sinnvolle Programmstruktur:

• IKT-Risikomanagement: Verantwortung des Leitungsorgans, ein umfassender Risikomanagementrahmen sowie Schutz, Erkennung, Reaktion, Wiederherstellung, Backup und kontinuierliches Lernen. Für bestimmte kleinere Einheiten sieht DORA einen vereinfachten Rahmen vor.
• Behandlung, Klassifizierung und Meldung IKT-bezogener Vorfälle: ein durchgängiger Managementprozess, eine einheitliche Klassifizierung schwerwiegender Vorfälle sowie die Meldung an die zuständige Behörde.
• Testen der digitalen operationalen Resilienz: ein regelmäßiges Testprogramm mit Basistests und, für identifizierte Einheiten, bedrohungsgeleitete Penetrationstests (TLPT) mindestens alle drei Jahre, methodisch an TIBER-EU angelehnt.
• IKT-Drittparteienrisiko: Grundsätze des Drittparteienmanagements, ein Register der Informationen über alle IKT-Verträge, Mindest-Vertragsinhalte sowie der EU-Aufsichtsrahmen für kritische IKT-Drittdienstleister.
• Informationsaustausch: freiwillige Vereinbarungen zum Austausch von Cyber-Bedrohungsinformationen zwischen Finanzunternehmen.

DORA wird durch umfangreiches Level-2-Recht konkretisiert. Die europäischen Aufsichtsbehörden (EBA, EIOPA, ESMA im Joint Committee) erarbeiten technische Regulierungs- und Durchführungsstandards (RTS/ITS), etwa zum Risikorahmen, zur Vorfallklassifizierung und -meldung, zum Register der Informationen und zu TLPT. Konkrete Werte, insbesondere die gestaffelten Meldefristen für schwerwiegende Vorfälle und die genauen Klassifizierungsschwellen, ergeben sich aus diesen delegierten Rechtsakten und sind dort verbindlich nachzuschlagen, nicht aus dem Verordnungsgrundtext abzuleiten.

In Deutschland flankiert das Finanzmarktdigitalisierungsgesetz (FinmadiG, verkündet am 27.12.2024) das DORA-Paket und enthält unter anderem das DORA-Durchführungsgesetz. Zuständig sind BaFin und Deutsche Bundesbank. Die bisherigen aufsichtlichen IT-Anforderungen ZAIT, VAIT und KAIT wurden zum 16.01.2025 aufgehoben; für BAIT gelten Übergangsregelungen, deren genaue Endtermine national zu prüfen sind.

Typische Fehler

1. DORA wird als reines IT-Thema behandelt, obwohl das Leitungsorgan verantwortlich ist.
2. Der Anwendungsbereich wird nicht sauber gegen Art. 2 geprüft, sodass Betroffenheit oder Proportionalität falsch eingeschätzt werden.
3. NIS2 und DORA werden parallel betrieben, statt DORA als lex specialis zu führen.
4. Ein bestehendes ISO-Zertifikat wird als DORA-Nachweis missverstanden.
5. Konkrete Meldefristen oder Schwellen werden frei zitiert, statt sie dem einschlägigen RTS/ITS zu entnehmen.
6. Das Drittparteienrisiko wird unterschätzt, obwohl Register und Schlüsselvertragsklauseln erheblichen Vorlauf brauchen.

Risiken und Trade-offs

DORA erzwingt eine Balance zwischen Vollständigkeit und Verhältnismäßigkeit. Ein überdimensioniertes Programm bindet Ressourcen, die kleinere Häuser nicht haben; ein zu schlankes Programm verfehlt aufsichtliche Erwartungen. Die in DORA angelegte Proportionalität ist daher bewusst zu nutzen, nicht als Vorwand für Untererfüllung.

Ein zweiter Trade-off betrifft das Drittparteienrisiko. Die Konzentration auf wenige große Cloud- und IT-Anbieter erhöht die Effizienz, schafft aber Klumpenrisiken. Mit der direkten EU-Aufsicht über kritische IKT-Drittdienstleister wird dieses Risiko erstmals aufsichtlich adressiert; die Verantwortung für die eigene Steuerung bleibt jedoch beim Finanzunternehmen.

Drittens besteht ein Timing-Risiko: Da viele Details erst auf Level 2 entstehen, ist eine Umsetzung, die sich allein am Verordnungstext orientiert, unvollständig. Wer den RTS/ITS-Stand nicht laufend beobachtet, riskiert Nacharbeiten.

Entscheidungspunkte

• Sind wir vom Anwendungsbereich erfasst, und wenn ja, als welcher Typ nach Art. 2 mit welchem Proportionalitätsgrad?
• Wer im Leitungsorgan trägt die Verantwortung für den IKT-Risikomanagementrahmen, und wie wird das dokumentiert?
• Nutzen wir das bestehende ISMS als Umsetzungsbasis, und welche DORA-Spezifika müssen wir ergänzen?
• Wie führen wir das Verhältnis zu NIS2 und zu den abgelösten BaFin-Anforderungen sauber zusammen?
• Wie organisieren wir das laufende Monitoring der RTS/ITS und der nationalen Durchführung?

Praktische Empfehlungen

1. Klären Sie zuerst die Betroffenheit anhand von Art. 2 und dokumentieren Sie die Einordnung samt Proportionalität.
2. Verankern Sie die Verantwortung im Leitungsorgan ausdrücklich, inklusive Berichtswegen und Entscheidungstaktung.
3. Strukturieren Sie das Programm entlang der fünf Säulen und mappen Sie vorhandene ISMS-Controls dagegen.
4. Behandeln Sie DORA für Finanzunternehmen als vorrangig gegenüber NIS2 und vermeiden Sie doppelte Programme.
5. Priorisieren Sie früh das Drittparteienrisiko: Register der Informationen, Vertragsinhalte und Schlüsselklauseln.
6. Entnehmen Sie verbindliche Fristen und Schwellen stets dem einschlägigen RTS/ITS und der nationalen Durchführung, nicht Sekundärquellen.

Relevante Normreferenzen

• DORA, Verordnung (EU) 2022/2554: zentrale Rechtsgrundlage; Anwendungsbereich in Art. 2, Säulen in den Kapiteln II bis VI. Verbindlich ist der EUR-Lex-Volltext nebst zugehörigen RTS/ITS.
• Richtlinie (EU) 2022/2556 (DORA-Änderungsrichtlinie): passt bestehende Finanzmarktrichtlinien an DORA an.
• Richtlinie (EU) 2022/2555 (NIS2): horizontaler Rahmen; DORA ist für Finanzunternehmen lex specialis.
• ISO/IEC 27001: mögliche Umsetzungsbasis für das Wie; ersetzt DORA-Pflichten nicht.
• NIST Cybersecurity Framework: optionaler Control- und Outcome-Bezugsrahmen ohne Rechtsbeziehung zu DORA.