DORA-Compliance-Checkliste für Finanzinstitute (2026)

Die Digital Operational Resilience Act (DORA) ist seit dem 17. Januar 2025 vollständig anwendbar. Für Finanzunternehmen in der EU ist sie kein Projekt mehr, das geplant werden muss — sie ist ein Mindeststandard, der nachgewiesen werden muss. Diese Checkliste unterteilt DORA in ihre fünf Säulen und die dahinter stehenden konkreten, prüfbaren Anforderungen, damit Sie schnell erkennen, wo Ihr Programm solide aufgestellt ist und wo die Lücken liegen.

Was ist DORA und für wen gilt es?

DORA — Verordnung (EU) 2022/2554 — legt einheitliche Anforderungen an die Sicherheit von Netz- und Informationssystemen fest, die die Geschäftsprozesse von Finanzunternehmen unterstützen. Ziel ist es sicherzustellen, dass der EU-Finanzsektor allen Arten von IKT-bezogenen Störungen und Bedrohungen standhalten, darauf reagieren und sich davon erholen kann.

Die Verordnung gilt weit — für rund zwanzig Kategorien von Finanzunternehmen, darunter:

• Kreditinstitute, Zahlungsinstitute und E-Geld-Institute
• Wertpapierfirmen und Anbieter von Krypto-Dienstleistungen (CASPs)
• Versicherungs- und Rückversicherungsunternehmen sowie -vermittler
• Zentralverwahrer, zentrale Gegenparteien und Handelsplätze
• Verwaltungsgesellschaften, Crowdfunding-Dienstleister und mehr

Entscheidend: DORA erfasst auch IKT-Drittdienstleister — und die Europäischen Aufsichtsbehörden (ESAs) können einige davon als kritische IKT-Drittanbieter (CTPPs) designieren und direkt beaufsichtigen. Ein Verhältnismäßigkeitsprinzip gilt: Der Umfang der erwarteten Kontrollen orientiert sich an Größe und Risikoprofil des Unternehmens.

Die fünf DORA-Säulen

Säule 1 — IKT-Risikomanagement (Artikel 5–16)

Das Fundament. DORA verlangt einen dokumentierten IKT-Risikorahmen, der vom Leitungsorgan genehmigt und überwacht wird und den gesamten Lebenszyklus abdeckt: Identifizieren, Schützen, Erkennen, Reagieren und Wiederherstellen. Das Leitungsorgan ist ausdrücklich verantwortlich — diese Kontrolle lässt sich nicht vollständig an die IT-Abteilung delegieren.

• Das Leitungsorgan hat den IKT-Risikorahmen genehmigt und überwacht ihn aktiv
• Ein aktuelles IKT-Assetinventar wird gepflegt (Hardware, Software, Datenflüsse und Drittanbieter-Abhängigkeiten)
• Sicherheitsrichtlinien decken Zugangskontrolle, Verschlüsselung, Patch-Management, Netzwerksicherheit, physische Sicherheit und Protokollierung ab
• Business-Continuity- (BCP) und Disaster-Recovery-Pläne (DRP) sind dokumentiert und getestet
• Recovery Time Objectives (RTO) und Recovery Point Objectives (RPO) sind je kritischer oder wichtiger Funktion definiert
• Ein Incident-Response-Plan (IRP) ist vorhanden und die Mitarbeiter sind geschult
• Post-Incident-Reviews fließen als Lessons Learned in den Rahmen zurück

Säule 2 — IKT-Incident-Management und -Meldung (Artikel 17–23)

IKT-bezogene Vorfälle müssen erkannt, gehandhabt und klassifiziert werden; schwerwiegende Vorfälle sind der zuständigen Behörde in drei Phasen zu melden. Dokumentierte Klassifizierungskriterien vorab sind entscheidend, damit Teams bei laufendem Zeitdruck nicht darüber diskutieren müssen, ob eine Meldung erforderlich ist.

• Eine Incident-Klassifizierungsmatrix unterscheidet schwerwiegende von nicht-schwerwiegenden Vorfällen anhand der DORA-Kriterien (betroffene Kunden, Datenverluste, Dauer, geografische Ausbreitung, wirtschaftliche Auswirkungen)
• Ein Vorfallsregister wird mit allen erforderlichen Feldern geführt
• Vorlagen für Erst-, Zwischen- und Abschlussberichte sind vorbereitet
• Die zuständige Behörde und der Meldekanal sind identifiziert (über den nationalen Aufseher an EBA / ESMA / EIOPA je nach Unternehmenstyp)
• Verfahren zur Benachrichtigung betroffener Kunden bei schwerwiegenden Vorfällen und erheblichen Cyberbedrohungen bestehen
• Mitarbeiter kennen die Klassifizierungskriterien und den Eskalationsweg

Säule 3 — Testen der digitalen operationalen Resilienz (Artikel 24–27)

DORA verpflichtet jedes Unternehmen zu einem risikobasierten Testprogramm; für bedeutende Unternehmen gilt ein anspruchsvolleres Regime. Der häufigste Fehler: Findings, die niemand behebt — DORA erwartet den vollständigen Zyklus einschließlich nachverfolgter Remediation.

Basistests (alle Unternehmen, mindestens jährlich):

• Ein jährliches Testprogramm umfasst Schwachstellenanalysen, Netzwerksicherheitsbewertungen, Gap-Analysen und Penetrationstests
• Tests decken IKT-Systeme und -Dienste ab, die kritische oder wichtige Funktionen unterstützen
• Findings werden nachverfolgt; Remediation ist geplant, hat einen Verantwortlichen und wird bis zum Abschluss überwacht

Threat-Led Penetration Testing — TLPT (bedeutende Unternehmen, mindestens alle 3 Jahre):

• Die TLPT-Pflicht wurde mit der zuständigen Behörde bewertet
• Der TLPT-Scope umfasst kritische Funktionen in der Live-Produktion
• Akkreditierte Threat-Intelligence-Anbieter und Tester sind identifiziert; TLPT erfolgt auf TIBER-EU-Basis
• Eine Bestätigung der zuständigen Behörde wird nach Abschluss des Tests eingeholt

Säule 4 — IKT-Drittparteienrisikomanagement (Artikel 28–44)

Die operativ aufwändigste Säule — und für die meisten Institute der größte Rückstand. DORA legt Due-Diligence-Erwartungen, verpflichtende Vertragsklauseln (Artikel 30) und ein strukturiertes Register der Informationen fest, das alle vertraglichen Vereinbarungen über IKT-Dienstleistungen beschreibt.

• Eine IKT-Drittparteienrisiko-Richtlinie ist dokumentiert und genehmigt
• Alle vertraglichen IKT-Drittparteienvereinbarungen sind inventarisiert
• Vereinbarungen, die kritische oder wichtige Funktionen (CIFs) unterstützen, sind klar identifiziert
• Ein Register der Informationen wird im vorgeschriebenen Format der ESAs geführt und ist für die Aufsichtsmeldung bereit
• Ein vorvertraglicher Due-Diligence-Prozess ist definiert und wird auf neue Anbieter angewendet
• Verträge werden gegen die verpflichtenden Klauseln aus Artikel 30 geprüft — Prüf- und Zugangsrechte, Servicelevel-Beschreibungen, Datensicherheit, Unterauftragsvergabe-Limits, Business-Continuity-Pflichten und Kündigungsrechte
• Konzentrationsrisiken über Anbieter hinweg werden überwacht
• Dokumentierte Exit-Strategien und Transitionspläne bestehen für Anbieter, die kritische Funktionen unterstützen
• Als kritische IKT-Drittanbieter (CTPPs) von den ESAs designierte Anbieter werden nachverfolgt

Säule 5 — Informationsaustausch (Artikel 45)

Freiwillig, aber strategisch wertvoll. Die Teilnahme an vertrauenswürdigen Cyber-Threat-Intelligence-Austauschvereinbarungen reduziert Exposition und signalisiert Aufsehern eine proaktive Resilienzhaltung.

• Die Organisation kennt relevante Austauschnetzwerke (Sektor-ISACs, ENISA, nationale CERTs)
• Eine dokumentierte Entscheidung besteht, ob und unter welchem Governance- und Vertraulichkeitsrahmen teilgenommen wird

Die fünf häufigsten Lücken

1. Governance nur auf dem Papier. DORA macht das Leitungsorgan echten Rechenschaftspflichten unterworfen. Formale Genehmigung ohne Verständnis erfüllt nicht den Geist der Anforderung — Vorstandsmitglieder müssen IKT-Risiken wirklich verantworten.
2. Unvollständiges Assetinventar. Ohne eine aktuelle, vollständige Karte der IKT-Assets und Abhängigkeiten ruhen Risikobewertung und Resilienztest auf unsicherem Fundament.
3. Legacy-Drittanbieterverträge. Die Klauseln aus Artikel 30 sind spezifisch und in älteren Verträgen selten vorhanden. Die Vertragsanpassung ist meist die größte operative Belastung.
4. Keine Klassifizierungsmatrix. Ohne dokumentierte Kriterien debattieren Teams, ob ein Vorfall „schwerwiegend" ist, anstatt die Meldefrist zu starten.
5. Testen ohne Remediation. Penetrationstest- und Schwachstellen-Findings, die in einer Tabelle liegen, belegen keine Resilienz — DORA erwartet den vollständigen Kreislauf bis zur Behebung.

Wie SephiraSec helfen kann

SephiraSec bietet unabhängige DORA-Gap-Assessments, IKT-Risikorahmen-Design, Vulnerability- und Exposure-Management-Programme, Incident-Response-Planung sowie technische Unterstützung bei TLPT-Scoping und Drittanbieter-Registervorbereitung. Sitz in Wien, verfügbar in der gesamten EU, auf Englisch, Deutsch und Rumänisch.