Leitfaden12. März 202611 Min. Lesezeit

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.

DORA Schritt für Schritt für Finanzunternehmen in der Benelux – Secrato Guides

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.

Verantwortlicher: Compliance Officer mit Rechtsabteilung

Zu bewahrende Nachweise: Geltungsbereichsmemo pro Einrichtung mit dem anwendbaren Rahmenwerk und der Aufsichtsbehörde

Häufiger Fehler: Anwendung des vereinfachten Rahmenwerks auf eine Einrichtung, die die Kriterien des Artikels 16 nicht erfüllt

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.

Verantwortlicher: CRO oder CISO mit dem Leitungsorgan

Zu bewahrende Nachweise: Vorstandsprotokolle, genehmigtes Rahmenwerk und Strategie, Schulungsunterlagen, Überprüfungsbericht

Häufiger Fehler: Ein von einem IT-Ausschuss genehmigtes Rahmenwerk, das aber nie vom Leitungsorgan selbst genehmigt wurde

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.

Verantwortlich: IT-Leiter, zusammen mit Verantwortlichen der Geschäftsfunktionen

Aufzubewahrende Nachweise: Vermögensverzeichnis, Funktionszuordnung, Kritikalitätsklassifizierung, Ergebnisse der Risikobewertung

Häufiger Fehler: Ein Vermögensverzeichnis, das nicht mit Geschäftsfunktionen verknüpft ist, sodass Sie nicht nachweisen können, welche Vermögenswerte kritisch sind

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.

Verantwortlicher: CISO

Aufzubewahrende Nachweise: Richtliniensatz, Beschreibungen von Maßnahmen, Überwachungsregeln, Testergebnisse

Häufiger Fehler: Die Annahme, dass die ISO/IEC 27001-Zertifizierung die RTS vollständig abdeckt; mehrere RTS-Anforderungen sind spezifischer

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).

Verantwortlich: Business-Continuity-Manager

Nachweise, die aufzubewahren sind: BIA, Geschäftsfortführungs- und Wiederherstellungspläne, Testberichte, Wiederherstellungsprotokolle

Häufiger Fehler: Sicherungen, die Anmeldedaten oder Netzwerkpfade mit der Produktionsumgebung teilen und bei demselben Ransomware-Angriff verschlüsselt würden

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.

Verantwortlich: Vorfallmanager, mit Compliance

Nachweise, die aufzubewahren sind: Vorfallverfahren, Klassifizierungsunterlagen, eingereichte Berichte, Ursachenanalysen

Häufiger Fallstrick: Starten der 4-Stunden-Frist erst, wenn der Vorstand entscheidet, anstatt wenn der Vorfall die Kriterien erfüllt

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.

Verantwortlicher: CISO

Zu bewahrende Nachweise: Testprogramm, Testberichte, Verfolgung der Behebung

Häufiger Fehler: Ein Testprogramm, das die Infrastruktur abdeckt, aber nicht die Anwendungen, die kritische Funktionen unterstützen

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.

Verantwortlich: Leiter Vendor Management

Zu bewahrende Nachweise: Register mit Informationen, Due-Diligence-Dateien, Vertragsüberprüfungen, Ausstiegspläne

Häufiger Fallstrick: Das Register als jährliche Berichtsübung statt als aktuelle Bestandsaufnahme behandeln

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.

Verantwortlich: CISO und CRO

Zu bewahrende Nachweise: Berichte nach Vorfällen, Schulungsunterlagen, Vorstandsberichte, Benachrichtigungen zum Informationsaustausch

Häufiger Fehler: Gewonnene Erkenntnisse, die dokumentiert, aber nie in eine Kontrollanpassung umgesetzt werden

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.

Vorlage abrufen →

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

  1. 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
  2. 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
  3. 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/
  4. 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
  5. 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
  6. CSSF, „ICT and cyber risk for DORA entities", abgerufen Oktober 2026: https://www.cssf.lu/en/ict-and-cyber-risk-for-dora-entities/
  7. 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/
Secrato