Ein praktischer DORA-Weg für Banken, Versicherer, Zahlungsinstitute und Vermögensverwalter in Belgien, den Niederlanden und Luxemburg – von der IKT-Risiko-Governance bis zur Meldung erheblicher Vorfälle.

Auf einen Blick
- DORA (Verordnung (EU) 2022/2554) gilt seit 17. Januar 2025. Aufsichtsbehörden in der Benelux erwarten nun Nachweise eines funktionierenden Rahmenwerks, nicht eines Projektplans.
- Das IKT-Risikomanagement-Rahmenwerk (Artikel 5–16) und die Delegierte Verordnung (EU) 2024/1774 bilden das Fundament. Kleinere Unternehmen im Anwendungsbereich des Artikels 16 können ein vereinfachtes Rahmenwerk nutzen.
- Größere IKT-bezogene Vorfälle müssen in drei Stufen gemeldet werden, beginnend innerhalb von 4 Stunden nach der Klassifizierung und spätestens 24 Stunden nach Kenntnisnahme.
Diese Anleitung richtet sich an CISOs, CROs, Compliance Officer und IT-Leiter bei Banken, Versicherern, Zahlungs- und E-Geld-Instituten, Wertpapierfirmen, Vermögensverwaltern und anderen Finanzunternehmen in Belgien, den Niederlanden und Luxemburg. Nutzen Sie sie für eine erste Lückenanalyse oder um ein in Eile vor Januar 2025 aufgebautes Rahmenwerk zu straffen. Der Fokus liegt auf IKT-Risikomanagement und Vorfallsbehandlung. Tests, Drittparteienrisiken und Informationsaustausch werden kürzer behandelt.
- Gilt für
- Finanzunternehmen, die in Artikel 2 DORA aufgeführt sind, einschließlich Kreditinstitute, Zahlungs- und E-Geld-Institute, Wertpapierfirmen, Versicherer und Rückversicherer, IORPs, Fondsverwalter und Anbieter von Kryptowerte-Dienstleistungen
- In Kraft seit
- 17. Januar 2025
- Aufsichtsbehörden
- Belgien: NBB und FSMA. Niederlande: DNB und AFM. Luxemburg: CSSF und CAA
- Wichtigste technische Standards
- Delegierte Verordnung (EU) 2024/1774 (IKT-Risikomanagement), 2024/1772 (Klassifizierung von Vorfällen), 2025/301 (Meldeinhalte und Fristen), Durchführungsverordnung (EU) 2024/2956 (Informationsregister)
- Zeitaufwand
- Lückenanalyse: 4–8 Wochen. Schließen von Lücken: 6–12 Monate, je nach Größe
Bevor Sie beginnen
DORA legt die letzte Verantwortung für das IKT-Risiko beim Leitungsorgan (Artikel 5)[1]. Bevor Sie beginnen, stellen Sie sicher, dass ein Vorstandsmitglied die Arbeit unterstützt, dass die IKT-Risikokontrollfunktion unabhängig vom IKT-Betrieb ist, und dass Sie wissen, welche Aufsichtsbehörde für jedes lizenzierte Unternehmen in Ihrer Gruppe zuständig ist. Sammeln Sie Ihre vorhandene ISMS-Dokumentation, Geschäftsauswirkungsanalyse, Vorfallverfahren und das Auslagerungsregister, da die meisten DORA-Nachweise darauf aufbauen. Die Verhältnismäßigkeit (Artikel 4) gilt durchgehend: Größe, Risikoprofil sowie Art, Umfang und Komplexität Ihrer Dienstleistungen bestimmen, wie weit Sie gehen.
Schritt 1: Geltungsbereich und anwendbares Rahmenwerk bestätigen
Bestimmen Sie zunächst, welche Unternehmen in der Gruppe in den Anwendungsbereich fallen, und ob eines von ihnen für das vereinfachte IKT-Risikomanagement-Rahmenwerk des Artikels 16 in Frage kommt. Dieses Regime umfasst unter anderem kleine und nicht miteinander verbundene Wertpapierfirmen, Zahlungs- und E-Geld-Institute, die unter PSD2 oder der E-Geld-Richtlinie befreit sind, und kleine IORPs. Diese Unternehmen folgen Titel III der Delegierten Verordnung 2024/1774 (Artikel 28–41), während alle anderen Titel II (Artikel 2–27) folgen.[2].
- Führen Sie jede Einrichtung, ihre Lizenz, ihre zuständige Behörde und ob Artikel 16 anwendbar ist auf.
- Prüfen Sie, ob eine Einrichtung auch eine wesentliche oder wichtige Einrichtung gemäß NIS2 ist. Im Allgemeinen funktioniert DORA als lex specialis, aber nationale Meldepflichten können unterschiedlich sein.
- Vereinbaren Sie, wie Richtlinien auf Gruppenebene von jedem Leitungsorgan der Einrichtung angenommen werden.
Schritt 2: Governance und das Rahmenwerk für IKT-Risikomanagement festlegen
Artikel 5 verlangt vom Leitungsorgan, das IKT-Risikomanagement-Rahmenwerk zu definieren, zu genehmigen, zu überwachen und dafür verantwortlich zu sein. Er verlangt außerdem, dass Mitglieder des Leitungsorgans ihre IKT-Risikokenntnisse durch regelmäßige Schulungen auf dem neuesten Stand halten. Artikel 6 verlangt ein solides, umfassendes und dokumentiertes Rahmenwerk, eine Strategie für digitale operationale Resilienz, eine unabhängige Kontrollfunktion, eine interne Revision sowie eine Überprüfung mindestens einmal jährlich und nach schwerwiegenden IKT-bezogenen Vorfällen. Einrichtungen unter dem vereinfachten Regime überprüfen ihr Rahmenwerk regelmäßig und berichten über diese Überprüfung, wie in Artikel 41 der RTS beschrieben.
- Lassen Sie das Leitungsorgan das Rahmenwerk, die Strategie für digitale operationale Resilienz und die IKT-Risikotoleranz genehmigen.
- Weisen Sie die IKT-Risikokontrollfunktion gemäß dem Drei-Linien-Modell oder einem gleichwertigen Modell zu und dokumentieren Sie deren Unabhängigkeit.
- Planen Sie Schulungen des Leitungsorgans zum IKT-Risiko und dokumentieren Sie die Teilnahme.
- Planen Sie die jährliche Überprüfung des Rahmenwerks und den in Artikel 27 der RTS erforderlichen Überprüfungsbericht.
Schritt 3: IKT-Vermögenswerte und Funktionen identifizieren und klassifizieren
Artikel 8 verpflichtet Sie, Ihre Geschäftsfunktionen, Rollen, Informationswerte und IKT-Vermögenswerte sowie die Abhängigkeiten zwischen ihnen zu ermitteln und zu dokumentieren. Sie müssen ermitteln, welche Funktionen kritisch oder wichtig sind, die IKT-Vermögenswerte, die diese unterstützen, zuordnen und das IKT-Risiko bei jeder wesentlichen Änderung bewerten. Altsysteme und von Dritten verwaltete Vermögenswerte sind ausdrücklich einbezogen.
- Erstellen oder aktualisieren Sie das Verzeichnis der Informations- und IKT-Vermögenswerte und verknüpfen Sie jeden mit den Geschäftsfunktionen, die er unterstützt.
- Klassifizieren Sie Vermögenswerte nach Kritikalität und dokumentieren Sie die Konfiguration kritischer Vermögenswerte.
- Identifizieren Sie alle ICT-Abhängigkeiten von Dritten, insbesondere solche, die kritische oder wichtige Funktionen unterstützen.
- Führen Sie mindestens einmal pro Jahr eine Risikobewertung für Altsysteme durch.
Schritt 4: Schutz- und Erkennungsmaßnahmen implementieren
Artikel 9 behandelt Schutz und Prävention, Artikel 10 die Erkennung. Titel II, Kapitel 1 und 2 der RTS (Artikel 2–21) enthalten die Details: IKT-Sicherheitsrichtlinien, Vermögensmanagement, Verschlüsselung und Verwaltung kryptografischer Schlüssel, IKT-Betriebssicherheit, Netzwerksicherheit, Projekt- und Änderungsmanagement, physische Sicherheit, Personalrichtlinien sowie Identitäts- und Zugriffsverwaltung. Artikel 23 der RTS legt fest, was die Erkennung anomaler Aktivitäten abdecken muss.
- Ordnen Sie jeden RTS-Artikel einer bestehenden Richtlinie oder Maßnahme zu und dokumentieren Sie die Lücken.
- Überprüfen Sie, dass Ihre Patch-Management-, Schwachstellenscanning-, Logging- und Änderungsmanagement-Verfahren die spezifischen RTS-Anforderungen erfüllen.
- Definieren Sie Erkennungsschwellwerte und Benachrichtigungskriterien und stellen Sie sicher, dass ausreichend Ressourcen für die Überwachung vorhanden sind.
Die begleitende Vorlage enthält eine Lückenanalyse, die die DORA-Artikel 5 bis 45 und die wichtigsten RTS-Artikel Verantwortlichen, Status und Nachweisen zuordnet.
Schritt 5: Reaktion, Wiederherstellung und Sicherungen vorbereiten
Die Artikel 11 und 12 erfordern eine IKT-Geschäftsfortführungsrichtlinie, Reaktions- und Wiederherstellungspläne, eine Geschäftsauswirkungsanalyse sowie Sicherungs- und Wiederherstellungsverfahren mit Wiederherstellungszielen für jede Funktion. Geschäftsfortführungspläne müssen regelmäßig getestet werden, und Pläne für kritische oder wichtige Funktionen mindestens einmal pro Jahr. Die Artikel 24–26 der RTS enthalten die Details zu Geschäftsfortführungsrichtlinie, Tests sowie Reaktions- und Wiederherstellungsplänen.
- Aktualisieren Sie die Geschäftsauswirkungsanalyse und legen Sie Wiederherstellungszeit- und Wiederherstellungspunktziele für kritische oder wichtige Funktionen fest.
- Stellen Sie sicher, dass Sicherungen physisch und logisch von den Quellsystemen getrennt sind, und testen Sie die Wiederherstellung.
- Führen Sie mindestens einmal pro Jahr einen szenariogestützten Geschäftsfortführungstest durch, einschließlich eines schwerwiegenden Cyber-Szenarios.
- Bereiten Sie Krisenkommunikationspläne für Kunden, Personal, Geschäftspartner und die Öffentlichkeit vor (Artikel 14).
Schritt 6: Aufbau von Vorfallmanagement, Klassifizierung und Meldung
Artikel 17 erfordert einen IKT-bezogenen Vorfallmanagement-Prozess, Artikel 18 die Klassifizierung und Artikel 19 die Meldung schwerwiegender Vorfälle an die zuständige Behörde. Die Delegierte Verordnung 2024/1772 legt die Klassifizierungskriterien und Schwellenwerte fest. Die Delegierte Verordnung 2025/301 legt den Inhalt und die Fristen fest und die Durchführungsverordnung 2025/302 die Vorlagen.[3].
| Bericht | Frist |
|---|---|
| Erstmitteilung | Innerhalb von 4 Stunden nach der Klassifizierung des Vorfalls als schwerwiegend, spätestens aber 24 Stunden nach Kenntnisnahme davon |
| Zwischenbericht | Innerhalb von 72 Stunden nach der ersten Meldung, mit Aktualisierungen bei wesentlichen Statusänderungen |
| Abschlussbericht | Spätestens einen Monat nach dem letzten Zwischenbericht |
Für einige Einrichtungen kann eine Frist, die auf ein Wochenende oder einen Feiertag fällt, auf 12:00 Uhr des nächsten Arbeitstages verschoben werden. Dies gilt nicht für erste und Zwischenmeldungen von Kreditinstituten, zentralen Gegenparteien, Betreibern von Handelsplätzen und Einrichtungen, die gemäß NIS2 wesentlich oder wichtig sind.
- Integrieren Sie die Klassifizierungskriterien (betroffene Kunden, Dauer, geografische Ausbreitung, Datenverluste, Kritikalität von Diensten, wirtschaftliche Auswirkungen) in Ihre Vorfallmanagement-Tools.
- Definieren Sie, wer einen Vorfall als schwerwiegend klassifiziert und wer Berichte genehmigt.
- Richten Sie den Zugriff auf den Meldungskanal der Aufsichtsbehörde für benannte Mitarbeiter und Vertreter ein, und üben Sie eine Einreichung.
- Entscheiden Sie, wie Sie die freiwillige Meldung erheblicher Cyber-Bedrohungen und die Kommunikation mit betroffenen Kunden handhaben werden.
Für eine Gegenüberstellung von DORA-, NIS2-, CRA- und DSGVO-Meldungen siehe unseren Handlungsleitfaden zur Vorfallmeldung.
Schritt 7: Test der digitalen operationalen Resilienz
Die Artikel 24 und 25 erfordern ein risikobasiertes Testprogramm mit angemessenen Tests von IKT-Systemen und Anwendungen, die kritische oder wichtige Funktionen unterstützen, mindestens einmal pro Jahr. Tests reichen von Schwachstellenbewertungen und Scans bis zu szenariogestützten Tests und Penetrationstests. Artikel 26 ergänzt dies um bedrohungsgestützte Penetrationstests (TLPT) mindestens alle drei Jahre für von der zuständigen Behörde ermittelte Einrichtungen. In der Praxis folgt dies dem TIBER-EU-Rahmenwerk und seinen nationalen Versionen.
- Erstellen Sie einen mehrjährigen Testplan, der mit der Kritikalität der Vermögenswerte aus Schritt 3 verknüpft ist.
- Verfolgen Sie Feststellungen bis zur Behebung und berichten Sie die Ergebnisse an das Leitungsorgan.
Schritt 8: IKT-Drittparteienrisiko verwalten und das Register aktuell halten
Die Artikel 28–30 erfordern eine Strategie zum IKT-Drittanbieterrisiko, Due Diligence, verbindliche Vertragsbestimmungen und Ausstiegsstrategien. Artikel 28 Absatz 3 erfordert ein Register mit Informationen zu allen Vertragsvereinbarungen mit IKT-Drittanbieter-Dienstleistern im Format der Durchführungsverordnung 2024/2956. Das Register muss der zuständigen Behörde auf Anfrage zur Verfügung gestellt werden und wird jährlich erfasst. Für eine ausführlichere Behandlung siehe unseren Artikel zu Drittanbieter-Risikomanagement 2026.
- Gleichen Sie das Register mindestens vierteljährlich mit Beschaffungs- und Vertragsdaten ab.
- Überprüfen Sie Verträge für kritische oder wichtige Funktionen anhand von Artikel 30 und planen Sie eine Neuverhandlung, falls erforderlich.
Schritt 9: Lernen, teilen und dem Leitungsorgan berichten
Artikel 13 verlangt Überprüfungen nach Vorfällen, die Nutzung gewonnener Erkenntnisse sowie Sensibilisierung und Schulung im Bereich IKT-Sicherheit für alle Mitarbeiter. Artikel 45 ermöglicht es Finanzunternehmen, Informationen und Erkenntnisse über Cyber-Bedrohungen innerhalb vertrauenswürdiger Gemeinschaften auszutauschen; Unternehmen, die beitreten, müssen ihre zuständige Behörde benachrichtigen. In Secrato werden diese wiederkehrenden Aktivitäten Kontrolltests in der Compliance-Engine zugeordnet, sodass ein Ergebnis gleichzeitig DORA, NIS2 und ISO/IEC 27001 abdeckt.
- Führen Sie für jeden größeren Vorfall eine Überprüfung nach dem Vorfall durch und lassen Sie die Erkenntnisse in die Überprüfung des Rahmenwerks einfließen.
- Erwägen Sie den Beitritt zu einer branchenspezifischen Informationsaustauschvereinbarung und benachrichtigen Sie Ihre Aufsichtsbehörde, falls Sie dies tun.
- Berichten Sie Status, Testergebnisse und Vorfallstrends mindestens einmal pro Jahr an das Leitungsorgan.
Benelux-Besonderheiten
Belgien: Die NBB beaufsichtigt Banken, Versicherer, Zahlungs- und E-Geld-Institute sowie Marktinfrastrukturen. Die FSMA beaufsichtigt andere DORA-Unternehmen, wie bestimmte Vermögensverwalter und Vermittler. Nach dem FSMA-Benutzerhandbuch melden Unternehmen, die von der FSMA beaufsichtigt werden, größere Vorfälle und erhebliche Cyber-Bedrohungen über deren FiMiS-Plattform, es sei denn, sie werden auch von der NBB beaufsichtigt. In diesem Fall melden sie nur an die NBB.[4].
Niederlande: DNB und AFM teilen die DORA-Aufsicht gemäß ihren Lizenzen. Von der AFM lizenzierte Unternehmen reichen DORA-Meldungen über die DORA-App im AFM-Portal ein. Die AFM weist darauf hin, dass eine DORA-Meldung keine NIS2-Meldung an das NCSC ersetzt, wenn beide anwendbar sind[5]. Die DNB erhält seit dem 17. Januar 2025 Meldungen über schwerwiegende Vorfälle und veröffentlicht ihre Meldeanweisungen auf ihren DORA-Seiten.[7].
Luxemburg: Die CSSF und das Commissariat aux Assurances (CAA) sind die zuständigen Behörden. Für CSSF-Unternehmen legt das Rundschreiben CSSF 25/893 fest, wie schwerwiegende IKT-bezogene Vorfälle und erhebliche Cyber-Bedrohungen zu melden sind, und das Informationsregister wird über eDesk eingereicht. Die CSSF ist die TLPT-Behörde für ihren Sektor und wendet TIBER-LU an.[6].
Kostenlose Vorlage
DORA-Lückenanalyse-Arbeitsmappe
Eine Lückenanalyse, die die Anforderungen von DORA zu IKT-Risikomanagement, Vorfällen, Tests, Drittanbietern und Informationsaustausch sowie die wichtigsten RTS-Artikel auf aktuellen Stand, Reifegrad, Verantwortliche und Nachweise abbildet. Tabellen zur Festlegung des Geltungsbereichs von Einrichtungen und zum Meldezeitplan helfen Gruppen mit mehreren Lizenzen in den Benelux-Ländern.
Wie dies mit anderen Rahmenwerken verbunden ist
Ein gut verwaltetes ISO/IEC 27001 ISMS deckt einen großen Teil des DORA-Kapitels zum IKT-Risikomanagement ab, und die Maßnahmen des NIS2-Artikels 21 entsprechen eng den Artikeln 8–14. DORA geht weiter bei der Verantwortung des Verwaltungsrats, der Prüfung der Geschäftsfortführung, den Schwellwerten für die Vorfallklassifizierung, TLPT und vertraglichen Bestimmungen mit IKT-Anbietern. Ordnen Sie jeden DORA-Artikel den Kontrollen zu, die Sie bereits für ISO/IEC 27001 prüfen, um doppelte Arbeit zu vermeiden.
Häufig gestellte Fragen
Kann ein Zahlungsinstitut das vereinfachte Rahmenwerk nutzen?
Nur wenn es gemäß PSD2 befreit ist. Zugelassene Zahlungsinstitute wenden das vollständige Rahmenwerk verhältnismäßig an.
Ist die DORA-Vorfallmeldung dasselbe wie die NIS2-Meldung?
Nein. DORA hat eigene Klassifizierungskriterien, Vorlagen und Fristen. Wenn ein Finanzunternehmen auch unter nationale NIS2-Regeln fällt, prüfen Sie mit Ihrer Aufsichtsbehörde, ob eine separate NIS2-Meldung erforderlich ist.
Wie oft muss das Informationsregister eingereicht werden?
Aufsichtsbehörden erfassen es jährlich und können es jederzeit anfordern. Überprüfen Sie den Erfassungskalender Ihrer Aufsichtsbehörde und die Formatanforderungen.
Sind wir verpflichtet, TLPT durchzuführen?
Nur wenn Ihre zuständige Behörde Sie dafür identifiziert. Alle Unternehmen benötigen ein Testprogramm mit jährlichen Tests von Systemen, die kritische oder wichtige Funktionen unterstützen.
Quellen
- EUR-Lex, „Verordnung (EU) 2022/2554 über die digitale operationale Resilienz des Finanzsektors (DORA)", 14. Dezember 2022: https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng
- EUR-Lex, „Delegierte Verordnung (EU) 2024/1774 über IKT-Risikomanagement-Tools, -Methoden, -Prozesse und -Richtlinien sowie das vereinfachte IKT-Risikomanagement-Rahmenwerk", 13. März 2024: https://eur-lex.europa.eu/eli/reg_del/2024/1774/oj/eng
- Advisera, „CDR 2025/301, Artikel 5: Fristen für die Erstmeldung sowie für Zwischen- und Abschlussberichte", abgerufen Oktober 2026: https://advisera.com/cdr-2025-301/time-limits-for-the-initial-notification-and-for-the-intermediate-and-final-reports/
- FSMA, „DORA – Melding van ernstige incidenten en significante cyberdreigingen (Benutzerhandbuch)", Februar 2025: https://www.fsma.be/sites/default/files/media/files/2025-02/dora_userguide_nl.pdf
- AFM, „Häufig gestellte Fragen zu DORA", abgerufen Oktober 2026: https://www.afm.nl/en/sector/themas/belangrijke-europese-wet–en-regelgeving/dora/veelgestelde-vragen-dora
- CSSF, „ICT and cyber risk for DORA entities", abgerufen Oktober 2026: https://www.cssf.lu/en/ict-and-cyber-risk-for-dora-entities/
- DNB, „DORA: het toezicht van DNB per 17 januari 2025", 2024: https://www.dnb.nl/nieuws-voor-de-sector/toezicht-2024/dora-het-toezicht-van-dnb-per-17-januari-2025/