KENNIS BLOG
DORA: de digitale ruggengraat van de financiële sector
13 maart 2026
Achtergrond
De hele financiële sector draait inmiddels op ICT: betalingen, handel, kredietverlening en beleggingsdiensten zijn volledig afhankelijk van stabiele digitale systemen. Door de sterke verwevenheid van meer dan 22.000 financiële entiteiten kunnen lokale incidenten zich razendsnel over grenzen verspreiden en leiden tot grootschalige verstoringen en vertrouwensverlies in het systeem. Na de crisis van 2008 lag de nadruk vooral op kapitaal en solvabiliteit, terwijl de digitale infrastructuur relatief onderbelicht bleef.
Dat veranderde toen de European Banking Authority (EBA), de European Insurance and Occupational Pensions Authority (EIOPA) en de European Securities and Markets Authority (ESMA) adviseerden om één sectorspecifiek, Europees kader voor digitale operationele weerbaarheid te creëren. Het eerdere lappendeken van nationale regels zorgde voor fragmentatie, hogere nalevingskosten en vooral: inconsistente eisen voor het testen van weerbaarheid en het monitoren van derde ICT‑aanbieders. DORA moet dat doorbreken met één gemeenschappelijk rulebook dat stabiliteit, marktintegriteit en consumentenbescherming centraal stelt. Wij nemen je mee langs de belangrijkste bouwstenen van de verordening, de impact op verschillende typen instellingen én de nieuwe werkelijkheid voor kritieke ICT‑dienstverleners zoals Amazon Web Services, Google Cloud, Microsoft en Equinix.
Wat is DORA precies?
DORA (Digital Operational Resilience Act) is een EU‑verordening die sinds januari 2025 van kracht is en directe werking heeft in alle lidstaten. De regels gelden voor een brede groep financiële entiteiten, waaronder banken, verzekeraars, betaalinstellingen, beleggingsondernemingen en cryptodienstverleners. In plaats van verspreide regels over ICT‑risico’s brengt DORA alle eisen samen in één integraal kader voor digitale operationele weerbaarheid.
DORA is bewust vormgegeven als verordening in plaats van richtlijn om harmonisatie te bevorderen en nationale afwijkingen te beperken. Daarnaast is DORA in Nederland een lex specialis ten opzichte van de Network and Information Security 2‑richtlijn (NIS2‑richtlijn): voor financiële entiteiten gaan de DORA‑regels over ICT‑risico dus vóór de algemene Cyberbeveiligingswet en andere algemene wetten, regels of besluiten die overlap hebben. Daarmee wordt voorkomen dat instellingen worden geconfronteerd met tegenstrijdige eisen rond cyberbeveiliging en incidentmelding.
De vijf pijler van DORA
DORA rust op vijf samenhangende pijlers die samen de digitale weerbaarheid moeten borgen. Deze pijlers zijn in de regelgeving verder uitgewerkt in technische regulerings‑ en uitvoeringsstandaarden. Tot nu toe zijn er zeven van zulke technische standaarden, het lijstje hier beneden is een momentopname. Zoals de stand van zaken er nu voorstaan ziet het er als volgt uit:
Een integraal ICT‑risicobeheerkader;
Financiële entiteiten zijn verplicht tot het hebben van een solide, alomvattend en goed gedocumenteerd kader voor ICT-risicobeheer.
- RTS inzake risicobeheer: beschrijft hoe instellingen hun ICT‑risico’s gestructureerd moeten inrichten, monitoren en beheersen, met een eenvoudiger regime voor kleinere partijen.
- RTS inzake ICT-diensten verricht door ICT-dienstenleveranciers van derden: Specificeert de gedetailleerde inhoud van de beleidseisen voor contractuele afspraken over ICT-diensten die kritieke of belangrijke functies ondersteunen bij ICT-dienstenleveranciers.
Beheer en rapportage van ICT-incidenten;
Financiële entiteiten moeten een proces inrichten om ICT-gerelateerde incidenten te detecteren, te beheren en te registreren. Ernstige incidenten moeten verplicht en volgens strikte termijnen worden gemeld aan de bevoegde autoriteiten met gebruikmaking van geharmoniseerde modellen;
- RTS inzake classificatie ICT‑incidenten: bepaalt wanneer een ICT‑incident als “majeur” telt en dus formeel aan de toezichthouder moet worden gemeld.
- RTS inzake Incidentrapportage: legt vast welke informatie instellingen in elke fase van een groot ICT‑incident moeten aanleveren en hoe vrijwillige dreigingsmeldingen verlopen.
Testen van digitale operationele weerbaarheid;
Om zwakheden in de beveiliging op te sporen, moeten entiteiten hun systemen en personeel regelmatig testen op kwestbaarheden. Het testniveau is afhankelijk van de grote en belangrijkheid van de instelling en het risicoprofiel wat ermee gepaard gaat;
- RTS inzake TLPT‑testen: geeft regels voor de opzet, uitvoering en opvolging van threat‑led penetratietesten bij belangrijke instellingen.
Het beheer van risico’s rond derden en uitbesteding;
Er zijn strikte regels voor het beheersen van risico's die ontstaan door de afhankelijkheid van externe ICT-leveranciers. Er gelden strikte eisen voor contractuele overeenkomsten, zoals het contractueel vastleggen van auditrechten en het hebben van een exit strategie. Daarnaast wordt er een specifiek oversightkader ingesteld voor aanbieders die als "kritiek" worden aangemerkt.
- RTS inzake sub-uitbesteding: stelt eisen aan voorwaarden en controles als ICT‑dienstverleners delen van kritieke of belangrijke diensten weer door uitbesteden.
- RTS inzake kritieke ICT‑dienstverleners: harmoniseert hoe Europese toezichthouders gezamenlijk toezicht uitoefenen op als “kritiek” aangewezen ICT‑dienstverleners.
Informatie-uitwisseling
Financiële entiteiten worden aangemoedigd om op vrijwillige basis, informatie en inlichtingen over cyberdreigingen uit te wisselen binnen vertrouwensgemeenschappen. Door tactieken, technieken en waarschuwingen te delen, kunnen instellingen de verspreiding van dreigingen beperken en hun collectieve defensiecapaciteiten versterken.
ICT‑risicobeheerkader en inventarisatie
Onder DORA draagt het bestuur volledige verantwoordelijkheid voor het beheer van ICT‑risico’s. Bestuurders moeten beleid voor ICT‑bedrijfscontinuïteit, respons‑ en herstelplannen goedkeuren, periodiek laten evalueren en actief toezicht houden op de uitvoering. Ook moeten zij aantonen dat er voldoende budget en deskundig personeel beschikbaar is om aan alle vereisten te voldoen.
Bestuursleden hebben bovendien een wettelijke plicht om hun kennis van ICT‑risico’s op peil te houden via specifieke opleidingen. Dat maakt digitale weerbaarheid expliciet een bestuursverantwoordelijkheid en geen exclusief IT‑dossier meer. In de praktijk betekent dit dat bijvoorbeeld een middelgrote bank niet kan volstaan met een Chief Information Security Officer (CISO)‑rapportage eens per jaar, maar dat bestuurders concrete vragen moeten kunnen stellen en beantwoorden over patchbeheer, IT- back‑upstrategieën en afhankelijkheden van eventuele Cloud‑providers. DORA specificeert niet wat het minimumniveau is van deze kennis, of hoe vaak regelmatig is. Moet een bestuurder technisch kunnen meepraten over encryptie, of volstaat een algemeen begrip van cyberrisico's? Deze open normen zullen door in de praktijk ingevuld moeten worden.
Elke financiële instelling moet beschikken over een solide, alomvattend en gedocumenteerd ICT‑risicobeheerkader. Er moet een verantwoordelijke persoon worden aangewezen voor het beheer en toezicht op het ICT‑risicobeleid, met voldoende onafhankelijkheid om belangenconflicten te voorkomen. Dit kader wordt periodiek onderworpen aan interne audits, waarbij frequentie en diepgang zijn afgestemd op het risicoprofiel van de onderneming.
Een belangrijke stap binnen dit kader is de inventarisatie van functies en activa. Instellingen moeten alle ICT‑ondersteunde functies, processen, informatie‑ en ICT‑activa in kaart brengen, inclusief onderlinge afhankelijkheden. Daarbij hoort expliciet de identificatie van kritieke of belangrijke functies en de derde partijen waarvan men daarvoor afhankelijk is. Een functie is kritiek als een storing "wezenlijk afbreuk" zou doen aan de financiële prestaties of continuïteit. Instellingen moeten zelf de drempel bepalen waarop een proces "kritiek" wordt, of wat wordt verstaan onder een wezenlijke afbreuk. Van een betaaldienstverlener die transacties afwikkelt via een datacenter kan wel gezegd worden dat er een storing in dit datacenter kan leiden tot een wezenlijke afbreuk van een kritiek proces van deze financiële instelling. Of dit ook geldt voor data-analyses die draaien op clouddiensten van Google is nog maar de vraag. Steeds zal de financiële instelling een afweging moeten maken wat kritiek is en wat niet is. Beide afhankelijkheden zullen uiteindelijk duidelijk worden vastgelegd en gecategoriseerd.
Beveiliging, continuïteit, incidenten en testen
DORA verlangt een consistent informatiebeveiligingsbeleid dat de beschikbaarheid, integriteit en vertrouwelijkheid van data waarborgt. Dit omvat preventieve maatregelen (logische en fysieke beveiliging, toegangsbeheer, patchbeleid), detectiemechanismen voor afwijkingen en incidenten en een uitgewerkt ICT‑continuïteitsbeleid met concrete respons‑ en herstelplannen. Financiële instellingen moeten processen opstellen waarmee ze ICT incidenten kunnen classificeren en vastleggen. Ernstige IT gerelateerde incidenten zullen volgens een voorgeschreven proces bij de bevoegde autoriteiten moeten worden gerapporteerd. Voor bepaalde entiteiten (o.a. kredietinstellingen, betaalinstellingen) vallen ook betalingsgerelateerde operationele of beveiligingsincidenten onder deze meldplicht, zelfs als deze niet direct ICT-gerelateerd zijn.
Daarnaast verplicht DORA tot periodieke tests van de digitale operationele weerbaarheid, in elk geval voor alle kritieke en belangrijke ICT‑systemen. Voor de meeste instellingen volstaan reguliere tests zoals kwetsbaarheidsscans, scenariotests en fail‑over‑tests. Instellingen die als systemisch relevant of zeer ICT‑intensief worden beschouwd, moeten ten minste elke drie jaar geavanceerde dreiging gestuurde penetratietests (Threat‑Led Penetration Testing, TLPT) uitvoeren. Dit kan bijvoorbeeld betekenen dat een grote bank haar Cloud‑omgeving bij Microsoft of Amazon door een gesimuleerde aanval laat testen, inclusief de responscapaciteit van interne teams.
Derden, uitbesteding en CTPP’s
Derden en uitbesteding in het algemeen
Instellingen moeten een duidelijke strategie en beleid hebben voor het inzetten van externe ICT-leveranciers, vooral bij kritieke of belangrijke functies. Alle contracten hiervoor komen in een intern register, waarin onder meer is vastgelegd of de dienst een kritieke of belangrijke functie ondersteunt.
Een ICT-dienstverlener mag niet zomaar aan iedereen uitbesteden. Er zal in het contract een aantal minimumeisen moeten worden opgenomen waarmee de ICT-dienstverlener kan aantonen dat de partij aan wie ze hebben uitbesteed voldoende kennis en kunde in huis heeft. Bijvoorbeeld bij het uitbesteden van ICT-functionaliteiten die als kritiek of belangrijk kunnen worden aangemerkt zal de ICT-dienstverlener contractueel moeten vastleggen dat de dienstverlener zelf maar ook, de financiële entiteit en de bevoegde autoriteit onbeperkte toegang hebben voor het inspecteren van de dienstverlening. Dit kan zelfs inhouden dat men ter plekke op locatie langskomt om de uitbestede dienstverlening te controleren. Dit roept natuurlijk vragen op over de onderhandelingspositie van financiële instellingen ten op zichten van de grote spelers. Het is onduidelijk hoe een instelling aan deze harde wettelijke eis kan voldoen als de aanbieder weigert af te wijken van zijn standaardcontract.
Wat is een CTPP?
Een Critical Third‑Party Provider (CTPP) is een externe ICT‑dienstverlener die door de Europese toezichthoudende autoriteiten als kritiek is aangewezen. Deze aanwijzing gebeurt op basis van criteria zoals de potentiële systemische impact van een storing, de mate afhankelijkheid van financiële instellingen van de aanbieder, en de vervangbaarheid van de verleende dienst. Hoe moeilijker het is om over te stappen naar een alternatief, hoe eerder een aanbieder als kritisch wordt gezien.
De eerste aanwijzing was op 18 november 2025. Deze lijst met CTPP’s omvat onder andere Accenture, Amazon Web Services, Google Cloud, Microsoft Ireland Operations, SAP SE, Equinix B.V. en Kyndryl Inc. In de praktijk betekent dit dat een groot deel van de Europese financiële sector voor Cloud, data‑analyse, kernbanksystemen en infrastructuur leunt op een beperkt aantal spelers. Een storing of beveiligingsincident bij bijvoorbeeld Microsoft of Amazon kan daarmee direct effecten hebben op duizenden banken, verzekeraars en betaalinstellingen tegelijk.
CTPP’s voelen de regeldruk
CTPP’s voelen regeldruk onder DORA om een aantal redenen. Ten eerste concentreren zich bij hen de risico’s van de hele sector: als Cloud‑platform of datacenterleverancier voor een groot aantal systeemrelevante instellingen dragen zij een disproportioneel deel van het operationele risico. Een incident bij een CTPP als Google Cloud, Microsoft of Equinix raakt in één klap honderden of duizenden klanten, wat de kans op ingrijpen door de Lead Overseer (een Europese toezichthouder) en nationale toezichthouders vergroot.
Ten tweede worden CTPP’s niet alleen via contractuele eisen van hun financiële klanten aangesproken, maar ook rechtstreeks door Europese toezichthouders. Zij moeten intensief rapporteren, uitgebreide documentatie aanleveren, meewerken aan on‑site inspecties, sub‑outsourcingstructuren blootleggen en aanbevelingen opvolgen die diep ingrijpen in hun technische architectuur en businessmodel.
Ten derde gaat het vaak om mondiale spelers met een uniforme infrastructuur; maatregelen die nodig zijn om te voldoen aan DORA kunnen domino‑ effecten hebben op dienstverlening in andere regio’s en tot aanzienlijke kosten leiden. Daarmee ervaren CTPP’s continue spanning tussen schaalvoordelen, commerciële belangen en het voldoen aan Europees toezicht dat hen als systeemkritiek aanmerkt heeft.
Oversight‑kader, verplichtingen en sancties
Voor CTPP’s geldt een specifiek Europees toezicht kader. Eén van de drie Europese toezichthouders (EBA, EIOPA of ESMA) treedt op als Lead Overseer en oefent direct toezicht uit op de CTPP. De CTPP moet alle gevraagde informatie verstrekken en meewerken aan inspecties, waaronder on‑site onderzoeken bij kantoren en datacenters, ook buiten de EU mits lokale autoriteiten instemmen.
Een CTPP die buiten de EU is gevestigd, moet binnen twaalf maanden na aanwijzing een dochteronderneming in de EU oprichten om diensten aan EU‑instellingen te mogen voortzetten. Behoort de CTPP tot een groep, dan moet één rechtspersoon als centraal aanspreekpunt voor de Lead Overseer worden aangewezen. De CTPP betaalt een vergoeding die de toezichtkosten dekt en moet te goeder trouw meewerken aan alle onderzoeken en verzoeken.
Bij ernstige of aanhoudende niet‑naleving kan de Lead Overseer zware maatregelen opleggen. Mogelijkheden zijn het opleggen van dwangsommen tot 1% van de wereldwijde gemiddelde dagomzet, openbaarmaking van de overtreding en de identiteit van de aanbieder en – als uiterste middel – het laten beëindigen of tijdelijk stopzetten van contracten door nationale toezichthouders. Stel dat structurele tekortkomingen bij een wereldwijde cloud‑provider als Amazon of Microsoft niet tijdig worden opgelost; in dat scenario kan een toezichthouder financiële instellingen verplichten hun afhankelijkheid versneld af te bouwen of zelfs dwingen om al dan niet tijdelijk contracten op te zeggen.
De eerste ronde van rapportages over kritieke derde partijen vindt plaats in de eerste maanden van 2026. Als daaruit blijkt dat er nog andere ICT‑aanbieders verantwoordelijk zijn voor een groot deel van de kritieke systemen van ondernemingen binnen de EU, dan is de kans groot dat óók deze partijen in de toekomst als Critical Third‑Party Provider worden aangewezen, met alle gevolgen van dien.
Informatie-uitwisseling
DORA stimuleert financiële entiteiten om vrijwillig cyberdreigingsinformatie te delen, zoals IOC's (Indicators of Compromise, IOC), tactieken, technieken, procedures, waarschuwingen en configuratiehulpmiddelen. Dit versterkt de digitale operationele weerbaarheid doordat dreigingen sneller kunnen worden gedetecteerd, hun verspreiding kan worden beperkt en defensiecapaciteiten kunnen worden verbeterd. De uitwisseling verloopt binnen vertrouwensgemeenschappen van financiële entiteiten, met strikte waarborgen voor vertrouwelijkheid, dataprotectie conform de Algemene Verordening Gegevensbescherming (AVG) en naleving van mededingingsregels. Deelnemende financiële entiteiten stellen gezamenlijk vrijwillige afspraken, protocollen of overeenkomsten op, waarin de deelnamevoorwaarden worden vastgelegd – inclusief eventuele rollen voor overheidsinstanties of ICT-dienstverleners. Financiële entiteiten moeten hun bevoegde toezichthouders, zoals de AFM of DNB, onverwijld informeren zodra de vertrouwensgemeenschap hun aanvraag voor deelname heeft goedgekeurd, na een interne beoordelingsprocedure. Ook bij beëindiging van de deelname geldt deze meldingsplicht.
Wat betekent DORA voor micro‑ondernemingen?
DORA kent een expliciet vereenvoudigd kader voor micro‑ondernemingen. Dit zijn financiële entiteiten met minder dan 10 werknemers en een jaaromzet of balanstotaal van maximaal 2 miljoen euro. Uitgangspunt blijft dat het bestuur eindverantwoordelijk is voor ICT‑risico’s.
Micro‑ondernemingen moeten een ICT‑risicobeheerkader hebben, maar hoeven dit niet jaarlijks te evalueren, een periodieke evaluatie volstaat. Zij zijn vrijgesteld van uitgebreide interne audits op het kader en hoeven geen aparte functie aan te wijzen voor toezicht op derdencontracten. Wel blijven incidentmeldingen verplicht, maar drempelwaarden en informatievereisten moeten proportioneel zijn. Bovendien zijn micro‑ondernemingen volledig vrijgesteld van TLPT. Wel zijn ze verplicht om reguliere tests uit te voeren (zoals bijvoorbeeld scans of vragenlijsten), maar mogen ze de frequentie en het type test zelf bepalen op basis van hun risicoprofiel en beschikbare middelen. Zij moeten dus een "goede afweging" maken tussen een hoge weerbaarheid en hun beschikbare middelen bij het testen. Dit is een uiterst subjectieve balans die pas achteraf door een toezichthouder getoetst wordt.
In de praktijk betekent dit dat een kleine FinTech‑ start‑up die bijvoorbeeld gebruikmaakt van clouddiensten van Google of Microsoft vanaf dag één een basis ICT‑risicobeheerkader moet kunnen laten zien bij een vergunningaanvraag. Tegelijk krijgen zij ademruimte door lichtere audit‑ en testvereisten, mits zij hun afhankelijkheid van grote CTPP’s goed begrijpen en beheersen.
Cyberbeveiligingswet voor niet‑DORA‑bedrijven
Voor organisaties die niet onder DORA vallen, vormt de Nederlandse Cyberbeveiligingswet (Cbw) – de implementatie van de NIS2‑richtlijn – het algemene kader voor digitale veiligheid. De wet geldt voor middelgrote en grote ondernemingen in vitale sectoren zoals energie, vervoer, gezondheidszorg, drinkwater, digitale infrastructuur (waaronder datacentra en cloud‑aanbieders), afvalwater, post‑ en koeriersdiensten, chemie, voedselketen, ruimtevaart, onderzoek en diverse industrieën. In de regel gaat het om ondernemingen met meer dan 50 werknemers en een jaaromzet of balanstotaal van meer dan 10 miljoen euro, al vallen bepaalde entiteiten altijd onder de wet ongeacht hun omvang.
De Cyberbeveiligingswet kent drie zware verplichtingen: een zorgplicht voor passende beveiligingsmaatregelen, een strikte meldplicht voor significante incidenten en expliciete bestuursverantwoordelijkheid. Incidenten moeten worden gemeld bij de toezichthouder en het Computer Security Incident Response Team (CSIRT), met termijnen van 24 uur voor een vroege waarschuwing, 72 uur voor een volledige melding en een eindverslag binnen een maand. Bestuurders moeten zich laten trainen in cyberrisico’s en kunnen in bepaalde gevallen persoonlijk aansprakelijk zijn bij ernstige nalatigheid. Bij niet‑naleving kunnen boetes oplopen tot 10 miljoen euro of 2% van de wereldwijde jaaromzet voor essentiële entiteiten en 7 miljoen euro of 1,4% voor belangrijke entiteiten. Een datacenter‑exploitant die geen financiële entiteit is, maar wel kritieke infrastructuur levert aan banken en verzekeraars, kan dus onder de Cyberbeveiligingswet vallen, terwijl zijn klanten onder DORA vallen.
Conclusie
DORA en de Cyberbeveiligingswet vormen samen de nieuwe digitale onderlaag van het Europese financiële stelsel: continuïteit, incidentbestendigheid en het beheersen van afhankelijkheden van derden zijn vaste onderdelen van prudent ondernemingsbestuur geworden. Voor financiële entiteiten betekent dit dat governance, ICT‑risicobeheer, incidentprocessen, testen van de ICT-weerbaarheid en hoe om te gaan met kritieke derde aanbieders van ICT-diensten niet langer losstaande, technische thema’s zijn, maar nauw met elkaar verweven pijlers die aantoonbaar op orde moeten zijn. DORA bevordert hierbij vrijwillige informatie-uitwisseling over cyberdreigingen binnen vertrouwensgemeenschappen om de sector brede digitale weerbaarheid te versterken, met strikte waarborgen voor vertrouwelijkheid, AVG en mededinging; deelnemende entiteiten leggen deelnamevoorwaarden vast in gezamenlijke afspraken en moeten goedkeuring of beëindiging direct melden aan toezichthouders zoals AFM of DNB.
Micro‑ondernemingen krijgen een vereenvoudigd kader, maar blijven gebonden aan dezelfde kernprincipes: het bestuur blijft eindverantwoordelijk, er moet een basis‑ICT‑risicokader zijn en incidenten moeten worden gemeld, zij het op proportionele wijze. Daarmee is DORA niet alleen bedoeld voor grote systeembanken, maar een raamwerk dat de hele breedte van de financiële sector raakt – van fintech‑start‑up tot gevestigde instelling.
Critical Third‑Party Providers bevinden zich in een uitzonderlijke positie, omdat zij tegelijk de digitale ruggengraat van de sector vormen, rechtstreeks onder Europees toezicht staan en vaak wereldwijd actief zijn. Maatregelen die nodig zijn om te voldoen aan DORA kunnen domino‑effecten hebben op dienstverlening in andere regio’s en tot aanzienlijke kosten leiden. Ook zullen ze via allerlei contractuele relaties met de DORA te maken krijgen nu financiële instellingen verplicht zijn om hun contracten DORA-proof te maken. Deze grote spelers krijgen te maken met de meeste regeldruk.
DORA laat zich uiteindelijk het beste lezen als een principe‑gebaseerd raamwerk in plaats van een dichtgetimmerd handboek. De verordening biedt structuur en minima, maar blijft op cruciale punten niet heel duidelijk en gebruikt veel subjectieve begrippen, zoals “kritieke of belangrijke functies”, “passende” maatregelen en “proportionele” eisen, zelfs na vaststelling van de technische standaarden. Organisaties zullen die open normen zelf moeten concretiseren. De praktijkervaring en dialoog met de toezichthouders zal uitwijzen wat als ‘voldoende’ geldt. Wie doet aan serieus governance, risicobeheer in samenwerking met ICT‑dienstverleners, zal niet snel problemen ondervinden van de toezichthouders. Daarnaast werkt een financiële instelling aan een robuust fundament voor de operationele weerbaarheid van de instelling. Operationele weerbaarheid blijven zo niet alleen IT-issues, maar vormen de kern van goed ondernemerschap en systeembescherming binnen de EU.
Heeft u hier juridische hulp bij nodig? Klik dan hieronder om in contact te komen.
