DORA Is Geen Voorbereiding Meer
Toen DORA op 17 januari 2025 van toepassing werd, behandelden veel financiële instellingen het als een andere compliance-deadline die op beleidsniveau kon worden beheerd. Raamwerken werden geschreven, bestuursbesluiten werden genomen en GAP-analyses werden ingediend.
Wat de meeste instellingen niet bouwden, was operationele realiteit achter die documenten. Het ICT-risicobeheerkader vereist door Art. 5 bestaat als beleid — maar de dagelijkse governanceprocessen, escalatiepaden en toezichtmechanismen op bestuursniveau zijn niet aanwezig. Het bedrijfscontinuïteitsplan vereist door Art. 11 is een document — maar het is nooit getest tegen een realistisch scenario.
AFM en DNB hebben in hun toezichtprioriteiten voor 2026 duidelijk gemaakt dat ze niet langer geïnteresseerd zijn in documentatie. Ze onderzoeken operationele inbedding — of DORA-vereisten leven in de werkelijke operatie van een instelling, niet alleen in de beschrijving op papier.
De kloof die toezichthouders vinden: 75% gedocumenteerd, minder dan 30% operationeel.
Dit is geen theoretisch risico. Het is de bevinding van toezichtsbeoordelingen bij Europese financiële instellingen. Een inspectie die deze kloof blootlegt kan resulteren in openbare correctieve orders, materiële boetes en persoonlijke aansprakelijkheid voor C-suite executives op grond van DORA Art. 5.
De Kloof in Cijfers
De DORA Gereedheidskloof
Bron: Toezichtsbeoordelingen bij EU-financiële instellingen, 2025–2026
De Drie Knelpunten Waar de Meeste Instellingen Kritiek Blootgesteld Zijn
Op basis van onze ervaring met financiële instellingen in Nederland vertegenwoordigen drie DORA-vereisten consistent de grootste operationele kloof tussen wat gedocumenteerd is en wat werkelijk bestaat. Dat zijn ook de drie gebieden die toezichthouders het meest hebben gemarkeerd in hun inspectierapporten van 2026.
Register van Informatie (Art. 28)
ICT-leveranciersregisterDORA vereist een volledig, actueel Register van Informatie voor elke ICT-derdepartijenregeling — inclusief cloudproviders, SaaS-leveranciers en subverwerkers. De meeste instellingen hebben een contractenregister, geen Register van Informatie. Het onderscheid is cruciaal: DORA vereist gedocumenteerde kritikaliteitsbeoordelingen, exitstrategieën en concentratierisicoanalyse voor elke regeling.
Wat de meeste instellingen hebben: een spreadsheet met leverancierscontracten. Wat DORA vereist: een gestructureerd register met kritikaliteitsclassificatie, vervangbaarheidsanalyse en doorlopend monitoringsbewijs.
ICT-incidentrapportage (Art. 17–23)
Driedelige MeldingsketenDe incidentrapportageregeling van DORA vereist een driedelige rapportagestructuur: een eerste melding binnen 4 uur na classificatie van een groot incident, een tussentijds rapport binnen 72 uur en een eindrapport met grondoorzaakanalyse binnen een maand. De classificatiecriteria op grond van Art. 17 zijn specifiek — en de meeste instellingen hebben hun incidentclassificatie niet getest aan de hand van DORA-drempelwaarden.
Wat de meeste instellingen hebben: een generiek incidentbeheerproces. Wat DORA vereist: een DORA-specifieke classificatiematrix, gedocumenteerde meldingsketens naar AFM/DNB en geteste rapportagesjablonen voor alle drie de fasen.
ICT-risicobeheer Derde Partijen (Art. 28–30)
Contractbepalingen & Doorlopend ToezichtArt. 30 specificeert verplichte contractbepalingen die aanwezig moeten zijn in alle ICT-derdepartijenarrangementen — inclusief dienstverleningsniveauspecificaties, auditrechten, bedrijfscontinuïteitsverplichtingen en exitbepalingen. Bestaande contracten die dateren van vóór DORA zullen deze bepalingen vrijwel zeker missen. Heronderhandelen bij verlenging is niet snel genoeg voor kritieke aanbieders.
Wat de meeste instellingen hebben: erfeniscontracten met generieke IT-bepalingen. Wat DORA vereist: contracten met specifieke Art. 30-clausules, doorlopend monitoringsbewijs en gedocumenteerde exitstrategie-tests voor kritieke aanbieders.
Compliance-prioriteiten: Waar Beperkte Middelen te Concentreren
Niet elk DORA-hiaat draagt hetzelfde toezichtsrisico. De matrix hieronder brengt DORA-vereisten in kaart tegen twee dimensies die bepalen waar u zich het eerst op moet richten: toezichtsaandacht (hoe waarschijnlijk is het dat dit onderzocht wordt?) en implementatiecomplexiteit (hoe lang duurt dit realistisch?). Focus eerst op het linkerbovenkwadrant — hoog toezichtsrisico, lagere complexiteit.
- ICT-incidentclassificatiematrix (Art. 17)
- Sjablonen voor grote incidentmeldingen (Art. 19)
- ICT-risicorapportage op bestuursniveau (Art. 5)
- Structuur Register van Informatie (Art. 28)
- Contractherziening Art. 30 voor kritieke ICT-leveranciers
- Digitale operationele veerkrachttests (Art. 25)
- Concentratierisicoanalyse en exitstrategieën
- TLPT threat-led penetratietests (Art. 26)
- ICT-strategiedocumentatie (Art. 6)
- BCP-testscenario's voor niet-kritieke systemen
- ICT-beveiligingsbewustzijnstraining
- Meldingsprocessen voor subcontractors
- Volledig TLPT-programmaontwerp (alleen indien in scope)
- Geavanceerde dreigingsintelligentie-integratie
- Jurisdictie-overschrijdende coördinatie voor EU-groepen
- AI-ondersteunde risicoscenariomodellering
Is Uw DORA-Programma Inspectie-Gereed?
Wij voeren een DORA Operationele Gereedheidstoetsing uit die uw werkelijke compliance-positie in kaart brengt tegen wat AFM en DNB onderzoeken in inspecties van 2026 — niet wat de verordening op papier zegt.
Boek een DORA GereedheidstoetsingUw 90-Dagenplan voor een Inhaalslag
Voor middelgrote financiële instellingen met beperkte interne DORA-bandbreedte kan een gestructureerd programma van 90 dagen de kritieke hiaten sluiten die het hoogste toezichtsrisico dragen. De volgorde is cruciaal: u kunt operationele beheersmaatregelen niet inbedden zonder governance-helderheid, en u kunt geen geloofwaardig bewijs produceren zonder werkende beheersmaatregelen.
Outcome: Bestuursgekeurde ICT-risicobeheerkader met gedocumenteerde rollen, escalatiepaden en rapportagelijnen.
- 1Breng huidige ICT-risicogovernance in kaart tegen Art. 5-vereisten
- 2Identificeer en documenteer ICT-risicorapportagemechanismen op bestuursniveau
- 3Definieer de ICT-functie met duidelijke verantwoordelijkheid onder DORA
- 4Stel de ICT-incidentclassificatiematrix op per Art. 17-criteria
- 5Ontwwerp de structuur van het Register van Informatie en begin met vulling
Outcome: Geteste incidentmeldingsketen, initiële veerkrachttests voltooid, kritieke leverancierscontracten beoordeeld.
- 1Bouw en test de driedelige incidentmeldingsketen (AFM/DNB-sjablonen)
- 2Voer een bureauoefening uit op basis van een realistisch ICT-verstoringscenario
- 3Voer Art. 30 gap-analyse uit voor uw top 10 kritieke ICT-leveranciers
- 4Documenteer bedrijfscontinuïteit en disaster recovery voor kritieke functies (Art. 11)
- 5Valideer BCP/DRP tegen DORA-hersteltijddoelstellingen
Outcome: Inspectie-gereed bewijspakket voor alle kritieke DORA-vereisten, met geïdentificeerde resterende hiaten en remediëringstraject.
- 1Stel bewijspakket samen: governancebeslissingen, testresultaten, monitoringslogboeken
- 2Voltooi het Register van Informatie voor alle ICT-derdepartijenarrangementen
- 3Start Art. 30 contractherziening met kritieke leveranciers bij eerstvolgende verlenging
- 4Voer interne DORA-zelfevaluatie uit aan de hand van ESA-technische standaarden
- 5Documenteer resterende hiaten met risico-acceptatie of remediëringstraject
Drie Vragen Die Uw DORA-Auditor Zal Stellen
Dit zijn de vragen die consistent terugkomen in de inspectielijsten van AFM en DNB. Als uw CISO of complianceteam niet alle drie zonder aarzeling — en met gedocumenteerd bewijs — kan beantwoorden, heeft u een kritiek hiaat.
Als er vandaag een groot ICT-incident zou optreden, wie zou AFM dan binnen 4 uur informeren — en weet die persoon dat?
DORA Art. 19 vereist een eerste melding binnen 4 uur na classificatie van een incident als groot. De meeste instellingen hebben een incidentmanager — maar het DORA-specifieke meldingsproces, de classificatiecriteria en de AFM/DNB-contactgegevens maken geen deel uit van het dienstdraaiboek. Wanneer een inspecteur vraagt naar uw meldingshandboek, verwacht die gedocumenteerde contactketens te zien, niet een beleid dat zegt "we zullen de toezichthouder informeren."
Heeft u voor uw drie meest kritieke ICT-leveranciers gedocumenteerde exitstrategieën met geteste hersteltijdlijnen?
DORA Art. 28 vereist concentratierisicoanalyse en gedocumenteerde exitstrategieën voor kritieke ICT-leveranciers. Dit omvat cloudproviders (AWS, Azure, Google Cloud) en kritieke SaaS-platforms. "We zouden een alternatieve leverancier vinden" is geen exitstrategie. Een gedocumenteerde strategie omvat een vervangbaarheidsanalyse, geschatte migratietijdlijn, dataporabiliteitsmechanisme en een geteste back-upcapaciteit.
Heeft uw bestuur in de afgelopen 12 maanden een gestructureerd ICT-risicorapport ontvangen dat de DORA Art. 5-vereisten dekt?
DORA legt persoonlijke verantwoordelijkheid bij bestuursorganen, niet alleen bij instellingen. Art. 5 vereist toezicht op ICT-risico op bestuursniveau — wat betekent dat het bestuur regelmatig gestructureerde ICT-risicorapportages moet ontvangen en aantoonbaar betrokken moet zijn bij strategische ICT-risicobeslissingen. Een bestuurspaper dat cybersecurity terloops noemt is niet voldoende. Inspecteurs vragen om bestuursnotulen en risicorapportages om actieve governance te verifiëren.
Het Venster om de Kloof te Dichten Is Smal — Maar Nog Open
DORA is geen nieuw raamwerk. De vereisten zijn duidelijk geweest sinds de verordening werd gepubliceerd. Wat nieuw is, is dat het handhavingsvenster is aangebroken en toezichthouders documentatie niet langer accepteren als vervanging voor operationele gereedheid.
De instellingen die 2026-inspecties zonder materiële bevindingen doorstaan zijn niet die met de meest geavanceerde DORA-raamwerken op papier. Het zijn de instellingen die hebben geïnvesteerd in het operationeel maken van hun programma's — geteste incidentketens, gevulde Registers van Informatie, governance op bestuursniveau die functioneert en leveranciers met Art. 30-conforme contracten.
Als uw instelling een DORA-raamwerk heeft maar de kloof tussen documentatie en operatie niet heeft gesloten, zijn de komende 90 dagen uw venster. Gebruik ze.
Enterprise GRC & Regulatory Compliance
DORA GAP-analyses, NIS2-implementatie en doorlopend compliancebeheer voor financiële instellingen die actief zijn in Nederland en de EU.
Bekijk GRC-dienstenThird Party Risk Management
DORA Art. 28–30 vereist een gestructureerd ICT-risicobeheerprogram voor derde partijen. Onze TPRM-dienst bouwt het Register van Informatie en het monitoringsprogramma dat uw DORA-compliance vereist.
Bekijk TPRM-diensten