Wat is DORA en wat betekent het voor jouw financiële software?.

Wat is DORA precies?

De financiële sector draait volledig op software. Een storing in een betaalsysteem, een gehackte koppeling of een uitgevallen clouddienst raakt direct klanten, markten en vertrouwen. De Europese Unie heeft daarom met DORA — voluit de Digital Operational Resilience Act, verordening (EU) 2022/2554 — één gemeenschappelijk kader vastgesteld voor digitale operationele weerbaarheid. Sinds 17 januari 2025 is het van toepassing, en in Nederland houden De Nederlandsche Bank (DNB) en de AFM er toezicht op.

Het bijzondere aan DORA is de reikwijdte. De verordening kijkt niet alleen naar de financiële instellingen zelf, maar expliciet naar hun hele ICT-keten. En in die keten zit software: de maatwerkapplicaties, koppelingen en clouddiensten waarmee een financiële entiteit werkt. Daarmee raakt DORA ook ontwikkelaars en leveranciers die op het eerste gezicht buiten de financiële wereld staan.

Voor wie geldt DORA?

DORA heeft een brede werkingssfeer. De verordening noemt een twintigtal typen financiële entiteiten, plus een aparte categorie voor ICT-leveranciers.

Financiële entiteiten

• Banken en kredietinstellingen: van grootbanken tot kleinere kredietverstrekkers.
• Betaaldienstverleners en elektronischgeldinstellingen: payment service providers, e-money instellingen en betaalinstellingen.
• Beleggingsondernemingen en handelsplatformen: inclusief beheerders van handelsfaciliteiten.
• Verzekeraars en pensioenfondsen: verzekerings- en herverzekeringsondernemingen en bedrijfspensioenfondsen.
• Crypto-aanbieders: aanbieders van cryptoactiva-diensten onder MiCA.
• Overige: kredietbeoordelaars, crowdfundingdienstverleners, datarapportagediensten en meer.

ICT-derde-dienstverleners

Hier wordt het relevant voor de softwarewereld. Iedereen die ICT-diensten levert aan een financiële entiteit — clouddiensten, datacenters, softwareontwikkeling, beheer, koppelingen — is onder DORA een ICT-derde-dienstverlener. Je valt dan niet rechtstreeks onder het toezicht, maar wél onder het leveranciersbeheer van je financiële klant. En via die route gelden er concrete eisen aan jouw dienst en contract.

Een aparte categorie zijn de kritieke ICT-derde-dienstverleners (critical third-party providers). De Europese toezichthouders kunnen grote, systeemrelevante leveranciers — denk aan de grote cloudproviders — aanwijzen als kritiek, waarna die onder direct Europees toezicht komen te staan via een Lead Overseer.

De vijf pijlers van DORA

DORA bundelt regels die voorheen versnipperd waren in één samenhangend kader. Dat kader rust op vijf pijlers.

1. ICT-risicomanagement: elke entiteit moet een gedocumenteerd raamwerk hebben voor het identificeren, beschermen, detecteren en herstellen van ICT-risico's. De directie is eindverantwoordelijk — weerbaarheid is een bestuurszaak, geen IT-detail.
2. Incidentmelding: ICT-incidenten worden geclassificeerd en grote incidenten gemeld aan de toezichthouder, met vaste termijnen voor een eerste melding, een tussenrapportage en een eindrapport. Klanten moeten waar relevant geïnformeerd worden.
3. Weerbaarheidstesten: entiteiten testen hun digitale weerbaarheid periodiek. Voor de meest significante partijen geldt geavanceerd testen via Threat-Led Penetration Testing (TLPT), gebaseerd op het TIBER-EU-raamwerk.
4. Beheer van ICT-derde-risico's: de afhankelijkheid van leveranciers moet beheerst worden via contracten, een register van alle ICT-overeenkomsten en afspraken over audits, exit en concentratierisico.
5. Informatiedeling: entiteiten mogen onderling dreigingsinformatie uitwisselen om de hele sector weerbaarder te maken.

De eerste vier pijlers vertalen zich het sterkst naar concrete software-eisen. Pijler vier — leveranciersbeheer — is degene waar je als ontwikkelaar of leverancier het hardst mee te maken krijgt.

Wat DORA betekent als je software levert aan de financiële sector

Stel: je bouwt een maatwerkapplicatie of API-koppeling voor een betaaldienst of verzekeraar. Dan ben je een ICT-derde-dienstverlener, en moet je financiële klant jouw dienst inbedden in haar DORA-verplichtingen. Dat vertaalt zich in eisen die direct in jullie samenwerking landen.

Contractuele eisen (Artikel 30)

• Volledige dienstbeschrijving: een heldere omschrijving van de geleverde ICT-diensten en serviceniveaus.
• Datalocatie: waar data wordt verwerkt en opgeslagen — relevant voor EU-hosting en datasoevereiniteit.
• Toegang, inspectie en audit: de financiële entiteit en de toezichthouder moeten je systemen en processen kunnen controleren.
• Incidentondersteuning: afspraken over hoe je assisteert bij een ICT-incident, zonder meerkosten als drempel.
• Onderaanneming: voorwaarden voor het inschakelen van sub-leveranciers (denk aan jouw eigen cloudprovider of dependencies).
• Exitstrategie: een uitgewerkt plan om de dienst te beëindigen of over te dragen zonder de continuïteit te schaden.

Register van informatie

Financiële entiteiten houden een register van alle ICT-overeenkomsten bij en rapporteren dat aan de toezichthouder. Concreet betekent dat: je klant heeft van jou nauwkeurige gegevens nodig over welke diensten je levert, op welke locaties data staat, en welke onderaannemers in de keten zitten. Lever die informatie gestructureerd aan, dan ben je een prettige partij om mee te werken.

DORA verschuift de vraag van "is onze software veilig?" naar "kunnen we aantonen dat onze hele ICT-keten weerbaar is?" — en die bewijslast loopt door tot bij de leverancier.

Exit en concentratierisico

DORA hecht groot belang aan het vermijden van lock-in. Een financiële entiteit moet kunnen wisselen van leverancier zonder dat de continuïteit in gevaar komt. Voor jou als bouwer betekent dat: ontwerp voor overdraagbaarheid. Heldere documentatie, dataportabiliteit, geen onnodige afhankelijkheid van één gesloten platform. Dat is precies waarom vendor lock-in bij low-code platformen in deze context een serieus risico is.

DORA, NIS2 en de andere EU-wetten

DORA staat niet op zichzelf. Het is onderdeel van een golf EU-wetgeving rond digitale weerbaarheid. De belangrijkste samenhang:

• NIS2: DORA is lex specialis voor de financiële sector. Waar DORA van toepassing is, gaat het vóór op NIS2 voor het ICT-risicobeheer. Een bank volgt dus DORA, een ziekenhuis of energiebedrijf volgt NIS2.
• Cyber Resilience Act: de CRA regelt de beveiliging van digitale producten met digitale elementen — een productbenadering, naast DORA's organisatiebenadering.
• AVG: DORA gaat over weerbaarheid en continuïteit, de AVG over de bescherming van persoonsgegevens. Beide gelden naast elkaar.

Praktische stappen om DORA-proof te bouwen

Bouw of beheer je software voor de financiële sector, dan maak je het jezelf en je klant makkelijker door deze zaken op orde te hebben:

1. Documenteer je dienst en keten: leg vast welke diensten je levert, waar data staat en welke onderaannemers en dependencies je gebruikt — dat voedt direct het register van je klant.
2. Maak incidentafspraken concreet: meldtermijnen, contactlijnen en een responsible-disclosure-beleid. Sluit aan op de meldketen van je klant.
3. Bouw weerbaarheid en monitoring in: logging, alerting, back-ups en herstelprocedures die aantoonbaar werken — niet alleen op papier.
4. Ontwerp voor overdraagbaarheid: dataexport, heldere documentatie en een realistische exitstrategie vanaf dag één.
5. Faciliteer audits: zorg dat je systemen, processen en beveiliging controleerbaar zijn voor je klant en de toezichthouder.

Mijn kijk op DORA

DORA oogt op het eerste gezicht als zware regeldruk voor een sector die al strikt gereguleerd is. Maar als ik door de juridische tekst heen kijk, zie ik vooral een lijst met dingen die je sowieso goed wilt regelen: weet waar je data staat, weet wie er in je keten zit, kun je herstellen na een incident, en kun je weg bij een leverancier als het moet. Dat is geen financiële bijzonderheid — dat is gewoon volwassen software bouwen.

Wat ik in de praktijk zie: organisaties schrikken van de bewijslast. Niet omdat hun software onveilig is, maar omdat ze het nooit hebben vastgelegd. De documentatie, de exitstrategie, het register — dat is het werk dat altijd vooruitgeschoven wordt. DORA dwingt het naar voren, en dat is eerlijk gezegd geen slechte zaak.

Mijn advies aan leveranciers die voor de financiële sector werken: wacht niet tot een klant met een DORA-vragenlijst komt. Zet je documentatie, je incidentproces en je overdraagbaarheid nu op orde. Dan ben je niet de leverancier die compliance vertraagt, maar de leverancier die het makkelijk maakt.

— Jasper

Zo helpt Coding Agency hierbij

Wij bouwen maatwerksoftware en API-koppelingen met weerbaarheid, monitoring en overdraagbaarheid als uitgangspunt — precies de eigenschappen die DORA van een ICT-leverancier verwacht. Lever je diensten aan een bank, verzekeraar of betaaldienst, dan zorgen we dat je software de audit-, incident- en exiteisen aankan zonder dat compliance je project ophoudt.

Twijfel je of je huidige software of leverancier klaar is voor de eisen van je financiële klanten? Neem contact op voor een vrijblijvend gesprek.

Bron: Verordening (EU) 2022/2554 (DORA), EUR-Lex en De Nederlandsche Bank — DORA.