De Digital Operational Resilience Act — Verordening (EU) 2022/2554 — is van toepassing vanaf 17 januari 2025. DORA geldt voor alle financiële entiteiten onder Europees financieel toezicht: banken, verzekeraars, beleggingsondernemingen, betalingsinstellingen, cryptodienstaanbieders en hun ICT-derde-partijen. In Nederland zijn dat de entiteiten die staan onder toezicht van de AFM en DNB.

DORA gaat aanzienlijk verder dan NIS2 voor de financiële sector. Wie als financiële instelling dacht dat NIS2-compliance het einddoel was, heeft een aanzienlijke compliance-gap die dringend gedicht moet worden.

De vier pijlers van DORA

DORA is opgebouwd rond vier kernverplichtingen die samen een integraal kader vormen voor digitale operationele weerbaarheid.

De eerste pijler is het ICT-risicomanagementkader. Elke financiële entiteit moet een gedocumenteerd risicoframework hebben, met duidelijke governance, een actuele ICT-asset inventarisatie, dreigings- en kwetsbaarheidsanalyse per asset, en een maatregelregister met gespecificeerde control-eigenaren, testfrequenties en residuele risicobeoordelingen. Het bestuursorgaan is eindverantwoordelijk en rapporteert jaarlijks aan de toezichthouder over de staat van ICT-beveiliging.

De tweede pijler omvat resilience testing. Alle entiteiten voeren periodieke tests uit van hun digitale veerkracht, waaronder kwetsbaarheidsscans, scenario-gebaseerde tests en penetratietests. Voor significante entiteiten gaat dit verder: zij moeten minimaal driejaarlijks een Threat-Led Penetration Test uitvoeren — een geavanceerde red team-test gebaseerd op actuele dreigingsinformatie over de specifieke organisatie, uitgevoerd in de productieomgeving door gecertificeerde TLPT-providers conform het TIBER-NL framework.

De derde pijler is ICT-derde-partijrisicobeheer. Dit is het meest verstrekkende onderdeel van DORA voor de meeste organisaties. DORA vereist een volledig register van alle significante ICT-leveranciers, inclusief een concentratierisicoanalyse voor cloudproviders. Contracten met kritieke leveranciers moeten specifieke bepalingen bevatten die in DORA artikel 30 zijn gespecificeerd.

De vierde pijler is meldplicht bij significante ICT-incidenten. De tijdlijn is strikt: een vroege waarschuwing binnen vier uur na classificatie als significant incident, een gedetailleerde tussentijdse rapportage binnen 72 uur, en een eindverslag met root cause en herstelmaatregelen binnen één maand.

Hoe het IT-risicomanagementkader er in de praktijk uitziet

Het DORA-risicoframework vraagt om aantoonbare structuur, niet alleen om beleidsdocumenten. De drie verdedigingslinies moeten zijn uitgewerkt: operationele control owners in de eerste lijn, risicobeheer in de tweede lijn en audit in de derde lijn. Dit is geen papieren exercitie — de toezichthouder toetst op de daadwerkelijke werking.

Een actueel maatregelregister bevat voor elke ICT-beveiligingsmaatregel de volgende informatie: welke asset wordt beschermd, welke dreiging wordt gemitigeerd, een beschrijving van de control, de eigenaar van die control, en de testfrequentie inclusief de datum van de laatste test. Als dit register niet up-to-date is bij een toezichtonderzoek, is dat op zichzelf al een bevinding.

De ICT-asset inventarisatie is het fundament. Systemen, applicaties, data, mensen, en externe leveranciers moeten allemaal zijn opgenomen. Een inventarisatie die zes maanden achterloopt op de werkelijkheid is voor regulatoire doeleinden waardeloos.

Resilience testing: wat je documenteert en bewaart

Elke test die wordt uitgevoerd in het kader van DORA moet volledig gedocumenteerd zijn. Per test bewaar je de testomvang en de gehanteerde methodologie, alle bevindingen met een risicorating per bevinding, de herstelmaatregel voor elke bevinding en de afgesproken hersteltermijn. Testrapportages moeten minimaal vijf jaar worden bewaard.

Voor TLPT gelden aanvullende eisen. De test omvat productiesystemen — dus geen sandbox of simulatieomgeving. Resultaten worden gedeeld met de toezichthouder. De TLPT-provider moet gecertificeerd zijn en werkt conform TIBER-NL, het Nederlandse implementatiekader voor TIBER-EU.

Voor entiteiten die nog niet zijn begonnen met resilience testing: start met de basis. Kwetsbaarheidsscans op kritieke systemen, een scenario-test voor het meest impactvolle disruption-scenario (ransomware, DDoS, uitval van een kritieke cloudleverancier), en een penetratietest op de meest kwetsbare externfacing systemen.

Third-party management: het register, de contracteisen en de exitstrategie

Het ICT-derde-partijregister is voor veel financiële instellingen het meest arbeidsintensieve onderdeel van DORA-compliance. Het register bevat voor elke significante leverancier de aard van de dienst, de scope van de levering, de contractduur, de kritikaliteit voor bedrijfscontinuïteit en de locatie(s) waar data wordt verwerkt en opgeslagen.

De contractuele minimumvereisten van DORA artikel 30 zijn concreet. Contracten met kritieke ICT-leveranciers moeten een exitstrategie bevatten met een minimale exitperiode en bijstandsverplichtingen bij de overgang naar een andere leverancier. Auditrechten moeten contractueel zijn vastgelegd. Datalocatie en subcontractors moeten zijn gespecificeerd. Veel grote cloudproviders hebben inmiddels DORA-riders beschikbaar die de artikel 30-eisen adresseren; controleer per leverancier of die riders zijn afgesloten en daadwerkelijk de volledige EBA RTS-vereisten afdekken.

Concentratierisico is een onderbelicht thema. Als een groot deel van de kritieke bedrijfsfuncties bij één cloudprovider is ondergebracht, is een concentratierisicoanalyse verplicht — inclusief een exitstrategie voor het geval die provider uitvalt of niet langer aan DORA-eisen voldoet.

DORA versus NIS2: de compliance-gap

DORA is lex specialis ten opzichte van NIS2 voor de financiële sector. Financiële entiteiten die aan DORA voldoen, voldoen automatisch aan de relevante NIS2-verplichtingen. Maar dit werkt niet andersom. NIS2-compliance voor financiële entiteiten is onvoldoende: DORA gaat op meerdere onderdelen verder. TLPT heeft geen equivalent in NIS2. De artikel 30-contractvereisten gaan verder dan NIS2 toeleveranciersverplichtingen. De concentratierisicoanalyse voor cloudproviders is DORA-specifiek.

Organisaties uit de financiële sector die nog sturen op NIS2 als einddoel, moeten hun gap-analyse herhalen met DORA als toetsingskader.

Standpunt

DORA is een van de meest concrete en operationeel uitgewerkte cybersecurity-regelgevingen die de Europese wetgever tot nu toe heeft geproduceerd. De wetgever heeft duidelijk geleerd van de abstractheid van NIS2 — DORA werkt met specifieke termijnen, specifieke contractseisen, en specifieke testvereisten. Dat maakt naleving moeilijker te ontwijken door het schrijven van vague beleidsnotities.

Ik waardeer die concreetheid. In mijn dagelijkse werk zie ik dat governance-vereisten pas landen als ze operationeel uitgewerkt zijn. “Tref passende maatregelen” is een uitnodiging voor minimale compliance. “Voer elke drie jaar een TLPT uit in de productieomgeving door een gecertificeerde provider” is dat niet.

Tegelijkertijd zie ik dat DORA veel kleine financiële entiteiten overweldigt. Het register bijhouden, de contracten updaten, de exitstrategieën documenteren — dat is maanden werk voor een kleine organisatie met een IT-team van drie mensen. Proportionaliteit is in DORA ingebakken via de vereenvoudigde naleving voor micro-entiteiten, maar de administratieve lasten zijn ook voor middelgrote organisaties aanzienlijk.

Hier klopt voor mij het uitgangspunt van CyberSecurity AD. Wij bouwen een platform waar beveiligingsmaatregelen, audittrails en documentatie in de architectuur zijn ingebakken — niet als aparte compliance-laag die handmatig wordt bijgehouden. Voor financiële instellingen die met ons werken, is een deel van de DORA-documentatieverplichtingen al systeem-native gelost. Niet als vervanger van de organisatorische DORA-governance, maar als ondersteuning ervan.

Compliance is kosten en governance is een investering. Het verschil zit in hoe je begint: als reactie op de toezichthouder, of als integraal onderdeel van hoe je je organisatie runt. DORA dwingt financiële instellingen naar het tweede model. Dat is ongemakkelijk voor wie gewend is aan het eerste. Het is ook correct.