DORA und die digitale operationale Resilienz im Finanzsektor: Was Zahlungsdienstleister wissen müssen

Warum DORA erlassen wurde

Der Finanzsektor gehört zu den am stärksten digitalisierten Branchen. Zahlungen, Konten, Handel und Kundenservice laufen nahezu vollständig über Informationssysteme, und ein wachsender Teil dieser Systeme wird von externen Anbietern wie Cloud-Diensten und Softwareherstellern bezogen. Das steigert die Effizienz, bedeutet aber auch, dass sich eine einzelne technische Störung oder ein Cyberangriff schnell über mehrere Unternehmen ausbreiten kann.

Vor DORA waren die Anforderungen an IKT-Risiken über verschiedene Rechtsakte und Aufsichtsleitlinien verstreut und unterschieden sich je nach Sektor. Die Europäische Union hat sie in der Verordnung (EU) 2022/2554 über die digitale operationale Resilienz im Finanzsektor gebündelt, bekannt als DORA (Digital Operational Resilience Act). Ergänzt wird sie durch die Änderungsrichtlinie (EU) 2022/2556, mit der frühere sektorspezifische Rechtsakte an den neuen Rahmen angepasst wurden.

DORA gilt seit dem 17. Januar 2025. Als Verordnung ist sie in allen Mitgliedstaaten unmittelbar anwendbar. Die detaillierten Anforderungen werden durch technische Standards konkretisiert, die von den Europäischen Aufsichtsbehörden (ESAs) ausgearbeitet und von der Kommission als delegierte Verordnungen und Durchführungsverordnungen erlassen wurden.

Ein zentraler Gedanke von DORA ist die Verlagerung des Schwerpunkts von der reinen Verhinderung von Störungen hin zur Fähigkeit, ihnen standzuhalten und sich von ihnen zu erholen. Vollständigen Schutz gibt es nicht; ein Unternehmen muss daher davon ausgehen, dass Störungen eintreten, und sicherstellen, dass kritische Funktionen fortgeführt oder kontrolliert wiederhergestellt werden. Aus diesem Grund behandelt die Verordnung Informationssicherheit, Kontinuitätsmanagement, Auslagerungen und Meldewesen als Gesamtheit und nicht als getrennte Bereiche.

Anwendungsbereich und Verhältnismäßigkeit

DORA gilt für ein breites Spektrum von Finanzunternehmen. Für den Zahlungsverkehr sind vor allem Kreditinstitute, Zahlungsinstitute und E-Geld-Institute relevant; zum Anwendungsbereich gehören aber auch beispielsweise Wertpapierfirmen, Versicherungsunternehmen und Marktinfrastrukturen. Darüber hinaus schafft die Verordnung einen Überwachungsrahmen für bestimmte kritische IKT-Drittdienstleister, die für den Finanzsektor tätig sind.

Für Zahlungsdienstleister brachte DORA eine wesentliche Änderung: DORA ersetzte die Meldung schwerwiegender Vorfälle nach PSD2 für Zahlungsdienstleister, die in den Anwendungsbereich von DORA fallen. Vorfälle werden daher nach den Klassifizierungs- und Meldevorschriften von DORA gemeldet und nicht mehr über ein gesondertes PSD2-Verfahren.

Die Verordnung folgt dem Grundsatz der Verhältnismäßigkeit. Bei der Umsetzung werden Größe, Risikoprofil sowie Art und Umfang der Dienstleistungen des Unternehmens berücksichtigt. Für bestimmte kleinere Unternehmen sieht die Verordnung einen vereinfachten Rahmen für das IKT-Risikomanagement vor. In Finnland überwacht die Finnische Finanzaufsichtsbehörde (Finanssivalvonta) die Einhaltung durch Finanzunternehmen.

Die fünf Säulen

Der Inhalt von DORA wird üblicherweise in fünf Säulen gegliedert, die gemeinsam einen umfassenden Resilienzrahmen bilden:

Der Rahmen für das IKT-Risikomanagement

Grundlage von DORA ist ein dokumentierter Rahmen für das IKT-Risikomanagement. Es handelt sich nicht um eine einzelne Sicherheitsrichtlinie, sondern um ein Gesamtsystem aus Strategien, Leitlinien, Verfahren, Werkzeugen und Zuständigkeiten. Ein zentraler Grundsatz lautet, dass das Leitungsorgan verantwortlich ist für das IKT-Risikomanagement und dessen Angemessenheit; diese Verantwortung kann nicht vollständig auf technische Einheiten oder Anbieter übertragen werden.

Der Rahmen muss den gesamten Lebenszyklus abdecken:

• Identifizierung: Erfassung kritischer Funktionen, Informationswerte und ihrer Abhängigkeiten.
• Schutz und Prävention: Zugriffsverwaltung, Verschlüsselung, Änderungsmanagement und Schwachstellenmanagement.
• Erkennung: Überwachung auffälliger Aktivitäten und Alarmierung.
• Reaktion und Wiederherstellung: Kontinuitäts- und Wiederherstellungspläne sowie deren Erprobung.
• Lernen: Nachbereitung von Vorfällen und Umsetzung der Erkenntnisse in die Praxis.

Aus Sicht des Datenschutzes unterstützen die Anforderungen von DORA unmittelbar die Sicherheitsmaßnahmen nach Art. 32 DSGVO. Siehe hierzu auch den Leitfaden Datenschutz bei Finanzdaten im Open Banking.

Klassifizierung und Meldung von Vorfällen

DORA verlangt, dass ein Unternehmen über ein Verfahren zur Erkennung, Erfassung und Klassifizierung IKT-bezogener Vorfälle verfügt. Ein Vorfall gilt als schwerwiegend, wenn er die in den technischen Standards festgelegten Kriterien erfüllt, die sich beispielsweise auf die Auswirkungen auf Kunden, die Dauer, die geografische Ausbreitung und kritische Dienste beziehen.

Ein schwerwiegender IKT-bezogener Vorfall wird der zuständigen Behörde in drei Stufen gemeldet. Die Fristen beruhen auf der Delegierten Verordnung (EU) 2025/301 der Kommission:

Die kurzen Fristen bedeuten, dass die Meldung im Voraus geplant werden muss. Klassifizierungskriterien, Verantwortliche, Entscheidungswege und Meldevorlagen müssen bereitstehen, bevor ein Vorfall eintritt. In der Praxis erfolgt die Erstmeldung oft mit unvollständigen Informationen, die im Zwischen- und Abschlussbericht ergänzt werden.

Die Meldungen sind zugleich eine Informationsquelle für die Aufsicht. Werden Vorfallsdaten in einheitlicher Form erhoben, können die Behörden Risiken erkennen, die den Sektor insgesamt betreffen, etwa die Auswirkungen einer Störung bei einem Anbieter auf mehrere Unternehmen. Für das einzelne Unternehmen bedeutet die einheitliche Klassifizierung, dass dieselben Kriterien auch im internen Risikoreporting und im Lagebild der Geschäftsleitung genutzt werden können.

Testen der digitalen operationalen Resilienz

DORA verlangt ein risikobasiertes Testprogramm, das beispielsweise Schwachstellenbewertungen, Bewertungen der Netzwerksicherheit, szenariobasierte Tests, Leistungstests und Quellcodeprüfungen umfassen kann. Der Umfang der Tests richtet sich nach Größe und Risiken des Unternehmens.

Von den zuständigen Behörden benannte Unternehmen müssen zusätzlich mindestens alle drei Jahre bedrohungsorientierte Penetrationstests (TLPT) durchführen. Ein TLPT simuliert das Vorgehen realer Angreifer in der Produktionsumgebung und richtet sich auf kritische oder wichtige Funktionen.

Der Wert der Tests liegt im Umgang mit den Ergebnissen. Feststellungen müssen priorisiert, Abhilfemaßnahmen dokumentiert und deren Umsetzung überwacht werden.

Drittparteienrisiken und kritische Anbieter

Die Zahlungsinfrastruktur stützt sich zunehmend auf Cloud-Dienste, Softwareplattformen und ausgelagerte Dienstleistungen. DORA verbietet Auslagerungen nicht, betont aber, dass die Verantwortung beim Finanzunternehmen verbleibt. Die zentralen Pflichten sind:

• Informationsregister: Das Unternehmen muss ein Register aller vertraglichen Vereinbarungen über IKT-Dienstleistungen führen.
• Vertragsbestimmungen: Art. 30 DORA legt den Mindestinhalt von IKT-Dienstleistungsverträgen fest, etwa Leistungsbeschreibungen, Standortangaben, Verfügbarkeitsanforderungen, Prüfrechte und Kündigungsbestimmungen.
• Ausstiegsstrategien: Für kritische oder wichtige Funktionen muss ein Plan für den Anbieterwechsel oder die Rückführung der Funktion bestehen.
• Konzentrationsrisiko: Die Abhängigkeit von einem einzelnen Anbieter muss erkannt und bewertet werden.

DORA schafft außerdem einen Überwachungsrahmen für kritische IKT-Drittdienstleister. Die Europäischen Aufsichtsbehörden veröffentlichten am 18. November 2025 die erste Liste der als kritisch benannten IKT-Drittdienstleister und überwachen diese Anbieter unmittelbar. Die Benennung entbindet das Finanzunternehmen jedoch nicht von seiner eigenen Verantwortung für das Risikomanagement.

In der Praxis bedeutete DORA für viele Unternehmen eine Überprüfung bestehender Verträge und gegebenenfalls deren Neuverhandlung. Große Cloud- und Softwareanbieter haben ihre Standardverträge häufig um Anhänge für den Finanzsektor ergänzt, die die Anforderungen der Verordnung abdecken. Das Unternehmen muss dennoch selbst beurteilen, ob die Bedingungen seinen eigenen Risiken und kritischen Funktionen entsprechen, denn ein Standardanhang garantiert nicht automatisch Angemessenheit.

Praktische Umsetzung in der Zahlungsinfrastruktur

Bei Zahlungsdiensten ist Resilienz für Kunden unmittelbar sichtbar: Schlägt eine Zahlung fehl oder bleibt ihr Status unklar, sind die Auswirkungen sofort spürbar. Die Grundsätze von DORA sollten daher bis auf die Architekturebene umgesetzt werden. Zentrale Gestaltungsprinzipien beschreibt der Technologiebereich Transaktionsinfrastruktur.

• Verfügbarkeit: eine Aktiv-Aktiv-Architektur, in der mehrere Standorte oder Verfügbarkeitszonen den Datenverkehr gleichzeitig verarbeiten.
• Idempotenz: sichere Wiederholung von Zahlungsanforderungen nach einer Störung ohne Doppelbelastungen.
• Beobachtbarkeit: Metriken, Protokolle und Tracing, mit denen ein Vorfall schnell erkannt und klassifiziert werden kann – eine Voraussetzung für die Einhaltung kurzer Meldefristen.
• Ausstiegspläne: technische Machbarkeit eines Wechsels des Cloud-Anbieters oder einer teilweisen Rückführung, etwa durch Datenportabilität und Infrastructure as Code.
• Steuerung des Konzentrationsrisikos: Streuung kritischer Abhängigkeiten, wo dies begründet und umsetzbar ist.

Über die Architektur hinaus muss Resilienz geübt werden. In szenariobasierten Übungen lässt sich beispielsweise der Ausfall einer Cloud-Verfügbarkeitszone, die Unterbrechung der Verbindung zu einem Clearingsystem oder eine Störung bei einem kritischen Softwareanbieter simulieren. Solche Übungen decken häufig Lücken auf, die in der Dokumentation nicht sichtbar sind, etwa unklare Zuständigkeiten, fehlende Kontaktdaten oder zu optimistische Annahmen zur Wiederherstellungszeit.

Checkliste

1. Der Rahmen für das IKT-Risikomanagement ist dokumentiert und vom Leitungsorgan genehmigt.
2. Kritische und wichtige Funktionen und ihre Abhängigkeiten sind erfasst.
3. Klassifizierungskriterien, Zuständigkeiten und Meldevorlagen für Vorfälle liegen vor.
4. Der Meldeprozess wurde anhand der Fristen erprobt.
5. Ein Testprogramm besteht, und die Behandlung von Feststellungen ist nachverfolgbar.
6. Das Informationsregister zu IKT-Verträgen ist aktuell.
7. Verträge über kritische Dienste enthalten die nach Art. 30 erforderlichen Bestimmungen.
8. Ausstiegspläne sind erstellt und ihre Machbarkeit ist bewertet.

Quellen und weiterführende Literatur

1. Verordnung (EU) 2022/2554 (DORA), EUR-Lex
2. Europäische Bankenaufsichtsbehörde (EBA): Joint Technical Standards on major incident reporting
3. ESMA: European Supervisory Authorities designate critical ICT third-party providers
4. Finnische Finanzaufsichtsbehörde (Finanssivalvonta)