DORA stap voor stap voor financiële entiteiten in Benelux

Een praktisch DORA-traject voor banken, verzekeraars, betalingsinstellingen en vermogensbeheerders in België, Nederland en Luxemburg, van ICT-risicobeheer tot melding van grote incidenten.

Deze gids is voor CISO's, CRO's, compliance officers en IT-directeuren bij banken, verzekeraars, betaal- en e-geldinstellingen, beleggingsondernemingen, vermogensbeheerders en andere financiële entiteiten in België, Nederland en Luxemburg. Gebruik hem voor een eerste gapanalyse of om een framework op te ruimen dat voor januari 2025 in haast is gebouwd. De focus ligt op beheer van ICT-risico's en incidentafhandeling. Testen, risico's van derden en informatie-uitwisseling worden korter behandeld.

Voordat je begint

DORA legt de uiteindelijke verantwoordelijkheid voor ICT-risico bij het bestuursorgaan (artikel 5)^[1]. Zorg voordat je begint dat een bestuurslid het werk sponsort, dat de ICT-risicocontrolefunctie onafhankelijk is van ICT-operaties, en dat je weet welke toezichthouder bevoegd is voor elke gelicentieerde entiteit in je groep. Verzamel je bestaande ISMS-documentatie, bedrijfsimpactanalyse, incidentprocedure en outsourcingregister, want het meeste DORA-bewijs is hierop gebaseerd. Proportionaliteit (artikel 4) geldt door de hele aanpak: omvang, risicoprofiel en de aard, schaal en complexiteit van je diensten bepalen hoe ver je gaat.

Stap 1: Bevestig scope en het toepasselijke framework

Begin met bepalen welke entiteiten in de groep in scope vallen en of een van hen in aanmerking komt voor het vereenvoudigde framework voor beheer van ICT-risico's van artikel 16. Dat regime geldt onder meer voor kleine en niet-onderling verbonden beleggingsondernemingen, betaal- en e-geldinstellingen die zijn vrijgesteld onder PSD2 of de E-geldrichtlijn, en kleine IORP's. Deze entiteiten volgen Titel III van Gedelegeerde Verordening 2024/1774 (artikelen 28–41), terwijl alle anderen Titel II volgen (artikelen 2–27).^[2].

• Maak een lijst van elke entiteit, haar licentie, haar bevoegde autoriteit en of artikel 16 van toepassing is.
• Controleer of een entiteit ook een essentiële of belangrijke entiteit is onder NIS2. Over het algemeen werkt DORA als lex specialis, maar nationale rapportageregelingen kunnen verschillen.
• Kom overeen hoe groepsbeleid door het bestuursorgaan van elke entiteit zal worden aangenomen.

Stap 2: Stel governance en het framework voor beheer van ICT-risico's vast

Artikel 5 vereist dat het bestuursorgaan het framework voor beheer van ICT-risico's bepaalt, goedkeurt, bewaakt en daarvoor verantwoordelijk is. Het vereist ook dat bestuursleden hun kennis van ICT-risico's actueel houden door regelmatige training. Artikel 6 vereist een solide, uitgebreid en gedocumenteerd framework, een strategie voor digitale operationele weerbaarheid, een onafhankelijke controlefunctie, interne audit, en een beoordeling minstens eenmaal per jaar en na grote ICT-gerelateerde incidenten. Entiteiten onder het vereenvoudigde regime beoordelen hun framework periodiek en rapporteren over die beoordeling zoals beschreven in artikel 41 van de RTS.

• Zorg dat het bestuursorgaan het framework, de strategie voor digitale operationele weerbaarheid en de ICT-risicotolerantie goedkeurt.
• Wijs de ICT-risicocontroolfunctie toe onder het model van drie verdedigingslinies, of een gelijkwaardig model, en documenteer de onafhankelijkheid ervan.
• Plan training van het bestuursorgaan over ICT-risico en registreer de aanwezigheid.
• Plan de jaarlijkse beoordeling van het framework en het beoordelingsrapport dat vereist is door artikel 27 van de RTS.

Stap 3: Identificeer en classificeer ICT-activa en functies

Artikel 8 verplicht je om je bedrijfsfuncties, rollen, informatie-activa en ICT-activa te identificeren en te documenteren, evenals de afhankelijkheden daartussen. Je moet bepalen welke functies kritiek of belangrijk zijn, de ICT-activa die ze ondersteunen in kaart brengen, en ICT-risico's beoordelen wanneer er een grote wijziging plaatsvindt. Verouderde systemen en activa die door derden worden beheerd, zijn expliciet inbegrepen.

• Bouw of werk de inventaris van informatie- en ICT-activa bij, waarbij je elk actief koppelt aan de bedrijfsfuncties die het ondersteunt.
• Classificeer activa naar kritikaliteit en registreer de configuratie van kritieke activa.
• Identificeer alle ICT-afhankelijkheden van derden, vooral die welke kritieke of belangrijke functies ondersteunen.
• Voer minstens eenmaal per jaar een risicobeoordeling uit op verouderde ICT-systemen.

Stap 4: Implementeer beschermings- en detectiecontroles

Artikel 9 behandelt bescherming en preventie, en artikel 10 detectie. Titel II, Hoofdstukken 1 en 2 van de RTS (artikelen 2–21) geven de details: ICT-beveiligingsbeleid, activabeheer, versleuteling en beheer van cryptografische sleutels, operationele ICT-beveiliging, netwerkbeveiliging, project- en wijzigingsbeheer, fysieke beveiliging, personeelsbeleid en identiteits- en toegangsbeheer. Artikel 23 van de RTS bepaalt wat detectie van afwijkende activiteiten moet omvatten.

• Koppel elk RTS-artikel aan een bestaand beleid of control, en registreer de hiaten.
• Controleer of je patchbeheer, kwetsbaarheidsscanning, logging en wijzigingsbeheer procedures voldoen aan de specifieke RTS-vereisten.
• Definieer detectiedrempels en waarschuwingscriteria, en zorg ervoor dat er voldoende middelen zijn voor monitoring.

De bijbehorende sjabloon bevat een hiatenanalyse die DORA-artikelen 5 tot 45 en de belangrijkste RTS-artikelen koppelt aan eigenaren, status en bewijs.

Stap 5: Bereid respons, herstel en back-ups voor

Artikelen 11 en 12 vereisen een beleid voor ICT-bedrijfscontinuïteit, respons- en herstelplannen, een bedrijfsimpactanalyse en back-up- en herstelprocedures, met herstelstreefdoelen voor elke functie. Bedrijfscontinuïteitsplannen moeten regelmatig worden getest, en plannen voor kritieke of belangrijke functies minstens eenmaal per jaar. Artikelen 24–26 van de RTS voegen details toe over continuïteitsbeleid, testen en respons- en herstelplannen.

• Werk de bedrijfsimpactanalyse bij en stel hersteltijd- en herstelpuntdoelstellingen in voor kritieke of belangrijke functies.
• Zorg ervoor dat back-ups fysiek en logisch gescheiden zijn van de bronsystemen, en test het herstel.
• Voer minstens één scenariogebaseerde continuïteitstest per jaar uit, inclusief een ernstig cyberscenario.
• Bereid crisiscommunicatieplannen voor voor klanten, personeel, tegenpartijen en het publiek (artikel 14).

Stap 6: Bouw incidentbeheer, classificatie en rapportage op

Artikel 17 vereist een ICT-gerelateerd incidentbeheerproces, artikel 18 classificatie, en artikel 19 rapportage van grote incidenten aan de bevoegde autoriteit. Gedelegeerde Verordening 2024/1772 bepaalt de classificatiecriteria en drempels. Gedelegeerde Verordening 2025/301 bepaalt de inhoud en termijnen, en Uitvoeringsverordening 2025/302 de sjablonen^[3].

Rapport	Termijn
Initiële melding	Binnen 4 uur na classificatie van het incident als groot, en uiterlijk 24 uur nadat je ervan op de hoogte bent
Tussenrapport	Binnen 72 uur na de eerste melding, met updates wanneer de status aanzienlijk verandert
Eindrapport	Uiterlijk één maand na het meest recente tussentijdse rapport

Voor sommige entiteiten kan een termijn die op een weekend of een openbare feestdag valt, verschuiven naar 12:00 uur op de volgende werkdag. Dit geldt niet voor initiële en tussentijdse meldingen van kredietinstellingen, centrale tegenpartijen, exploitanten van handelsplatforms en entiteiten die essentieel of belangrijk zijn onder NIS2.

• Integreer de classificatiecriteria (getroffen klanten, duur, geografische verspreiding, gegevensverlies, kriticaliteit van diensten, economische impact) in je incidenttooling.
• Definieer wie een incident als groot classificeert en wie rapporten goedkeurt.
• Zet toegang op tot het rapportagekanaal van de toezichthouder voor aangewezen medewerkers en plaatsvervangers, en oefen een indiening.
• Bepaal hoe je vrijwillige melding van significante cyberbedreigingen en communicatie met getroffen klanten zult afhandelen.

Voor een vergelijking van DORA, NIS2, CRA en AVG-rapportage naast elkaar, zie ons draaiboek voor incidentrapportage.

Stap 7: Test digitale operationele weerbaarheid

Artikelen 24 en 25 vereisen een risicogebaseerd testprogramma, met passende tests van ICT-systemen en toepassingen die kritieke of belangrijke functies ondersteunen, minstens eenmaal per jaar. Tests variëren van kwetsbaarheidsbeoordelingen en scans tot scenariogebaseerde tests en penetratietests. Artikel 26 voegt threat-led penetration testing (TLPT) toe, minstens eenmaal per drie jaar voor entiteiten die door de bevoegde autoriteit zijn aangewezen. In de praktijk volgt dit het TIBER-EU-framework en de nationale versies daarvan.

• Stel een meerjarig testplan op dat gekoppeld is aan de kriticaliteit van activa uit Stap 3.
• Volg bevindingen tot aan herstel en rapporteer de resultaten aan het bestuursorgaan.

Stap 8: Beheer ICT-risico's van derden en houd het register actueel

Artikelen 28–30 vereisen een strategie voor ICT-risico's van derden, due diligence, verplichte contractuele bepalingen en exitstrategieën. Artikel 28(3) vereist een register met informatie over alle contractuele regelingen met ICT-dienstverleners van derden, in het formaat dat is vastgesteld in Uitvoeringsverordening 2024/2956. Het register moet op verzoek aan de bevoegde autoriteit worden verstrekt en wordt jaarlijks verzameld. Voor een diepere behandeling, zie ons artikel over risicobeheer van derden in 2026.

• Stem het register minstens driemaandelijks af met inkoopgegevens en contractgegevens.
• Controleer contracten voor kritieke of belangrijke functies aan de hand van artikel 30 en plan heronderhandeling waar nodig.

Stap 9: Leer, deel en rapporteer terug aan het bestuursorgaan

Artikel 13 vereist post-incidentevaluaties, het gebruik van geleerde lessen en ICT-beveiligingsbewustzijn en -training voor alle medewerkers. Artikel 45 stelt financiële entiteiten in staat om cyber threat information en intelligence uit te wisselen binnen vertrouwde gemeenschappen, en entiteiten die deelnemen moeten hun bevoegde autoriteit in kennis stellen. In Secrato worden deze terugkerende activiteiten gekoppeld aan controle-tests in de Compliance-engine, zodat één resultaat tegelijk DORA, NIS2 en ISO/IEC 27001 ondersteunt.

• Voer voor elk groot incident een post-incidentevaluatie uit en verwerk de bevindingen in de framework-review.
• Overweeg deel te nemen aan een sector-informatiedeling-regeling en stel je toezichthouder hiervan op de hoogte als je dat doet.
• Rapporteer status, testresultaten en incidenttrends minstens eenmaal per jaar aan het bestuursorgaan.

Hoe dit aansluit op andere frameworks

Een goed beheerd ISO/IEC 27001 ISMS dekt een groot deel van het DORA-hoofdstuk beheer van ICT-risico's, en NIS2 artikel 21-maatregelen sluiten nauw aan op artikelen 8–14. DORA gaat verder op verantwoordelijkheid van het bestuur, testen van bedrijfscontinuïteit, drempels voor incidentclassificatie, TLPT en contractuele bepalingen met ICT-leveranciers. Koppel elk DORA-artikel aan de controls die je al test voor ISO/IEC 27001 om dubbel werk te voorkomen.

Veelgestelde vragen

Kan een betalingsinstelling het vereenvoudigde framework gebruiken?

Alleen als het is vrijgesteld onder PSD2. Geautoriseerde betalingsinstellingen passen het volledige framework toe, proportioneel.

Is DORA-incidentrapportage hetzelfde als NIS2-rapportage?

Nee. DORA heeft zijn eigen classificatiecriteria, sjablonen en termijnen. Waar een financiële entiteit ook onder nationale NIS2-regels valt, controleer bij je toezichthouder of een afzonderlijke NIS2-melding nodig is.

Hoe vaak moet het register van informatie worden ingediend?

Toezichthouders verzamelen het jaarlijks en kunnen het op elk moment opvragen. Controleer de verzamelkalender en formaateisen van je toezichthouder.

Moeten we TLPT uitvoeren?

Alleen als je bevoegde autoriteit je daarvoor aanwijst. Alle entiteiten hebben een testprogramma nodig met jaarlijkse tests van systemen die kritieke of belangrijke functies ondersteunen.