DORA: wat de verordening eist van financiële instellingen

DORA, de Digital Operational Resilience Act, is sinds 17 januari 2025 van toepassing. Dat het om een verordening gaat en niet om een richtlijn is meer dan een juridisch detail. Verordening (EU) 2022/2554 werkt rechtstreeks in alle lidstaten, in dezelfde bewoordingen, zonder tussenkomst van de Nederlandse wetgever. Voor instellingen die gewend waren aan de open normen en good practices van DNB is dat een omslag: de verordening en de bijbehorende technische normen schrijven op veel punten letterlijk voor wat er moet gebeuren en binnen welke termijn.

Voor wie geldt DORA

De verordening somt de entiteiten op die eronder vallen, en die lijst is langer dan de meeste organisaties bij eerste lezing aannemen. Banken, verzekeraars en herverzekeraars, beleggingsondernemingen, betaalinstellingen, elektronischgeldinstellingen, pensioenfondsen, beheerders van beleggingsinstellingen, handelsplatformen, aanbieders van cryptoactivadiensten, kredietbeoordelingsbureaus en aanbieders van crowdfundingdiensten staan er allemaal in. Ook een kleine betaalinstelling of een pensioenfonds met een uitbesteed bestuursbureau valt eronder.

Niet iedereen krijgt hetzelfde pakket. DORA kent een vereenvoudigd kader voor ICT-risicobeheer voor onder meer kleine en niet-verweven beleggingsondernemingen en kleine pensioenfondsen. Proportionaliteit zit dus in de verordening zelf, maar de onderbouwing van welk regime van toepassing is, moet de instelling leveren. Dat is een van de eerste dingen die een toezichthouder wil zien.

ICT-dienstverleners vallen niet rechtstreeks onder de meeste verplichtingen, maar merken DORA wel degelijk. Hun financiële klanten zijn verplicht bepaalde afspraken in het contract op te nemen, en een aangewezen groep grote aanbieders komt onder direct toezicht van de Europese toezichthoudende autoriteiten te staan. Wat dat concreet betekent staat in DORA als ICT-leverancier van financiële instellingen.

Pijler 1: ICT-risicobeheer

De eerste pijler vraagt om een kader voor ICT-risicobeheer dat de hele cyclus dekt: identificeren, beschermen, detecteren, reageren en herstellen. Concreet gaat het om een actuele inventarisatie van informatiemiddelen en de bedrijfsfuncties die ze ondersteunen, om beleid en maatregelen die daarop aansluiten, om detectiecapaciteit, en om continuïteits- en herstelplannen die zijn getest.

Het kader wordt ten minste jaarlijks herzien, en daarnaast na een ernstig incident of naar aanleiding van toezichtbevindingen. Twee eisen worden vaak onderschat. De eerste is de scheiding tussen uitvoering en controle: de verantwoordelijkheid voor het beheersen en bewaken van ICT-risico moet bij een controlefunctie liggen die voldoende onafhankelijk is. De tweede is de rol van het leidinggevend orgaan, dat het kader vaststelt, goedkeurt en erop toeziet, en dat zijn eigen kennis over ICT-risico op peil moet houden.

Pijler 2: incidenten classificeren en melden

Ernstige ICT-gerelateerde incidenten moeten in drie stappen bij de toezichthouder worden gemeld. Een eerste melding volgt uiterlijk vier uur na de classificatie als ernstig, en in elk geval binnen 24 uur nadat de instelling van het incident op de hoogte raakte. Daarna een tussentijds rapport binnen 72 uur en een eindrapport binnen een maand.

De klok begint dus te lopen bij de classificatie, en juist daar zit het werk. De criteria voor wat als ernstig geldt, staan in de technische reguleringsnormen: aantal geraakte klanten en transacties, duur en uitval, geografische spreiding, verlies aan data, kritikaliteit van de geraakte dienst en economische impact. Organisaties die deze criteria niet vooraf hebben vertaald naar hun eigen dienstverlening, verliezen de eerste uren aan discussie over de vraag of dit nu een ernstig incident is. Het loont om de classificatie in het incident response plan op te nemen als beslisboom, inclusief wie hem mag toepassen buiten kantooruren.

Naast de meldplicht voor incidenten bestaat de mogelijkheid om ernstige cyberdreigingen vrijwillig te melden. Dat is geen verplichting, maar wel iets om in het escalatieproces een plek te geven.

Pijler 3: testen van digitale weerbaarheid

De derde pijler vraagt om een testprogramma dat jaarlijks alle ICT-systemen raakt die kritieke of belangrijke functies ondersteunen. Dat gaat verder dan een pentest: kwetsbaarheidsscans, broncodeanalyse, scenariotests, prestatietests en tests van continuïteits- en herstelplannen horen er allemaal bij.

Voor instellingen die daarvoor door de toezichthouder worden aangewezen komt daar threat-led penetration testing bij, gebaseerd op het TIBER-EU-kader, ten minste elke drie jaar. Bij zo'n test wordt gewerkt met dreigingsinformatie over de eigen organisatie en wordt de levende productieomgeving aangevallen, zonder dat het verdedigende team weet dat het een oefening is. Dat vraagt een aanzienlijke voorbereiding en de betrokkenheid van leveranciers wanneer kritieke functies bij hen draaien.

Pijler 4: beheersing van ICT-derdenrisico

De vierde pijler is voor de meeste instellingen de zwaarste. DORA vraagt om een informatieregister van alle contractuele afspraken over ICT-diensten, met per afspraak gegevens over de dienstverlener, de ondersteunde functie, de kritikaliteit daarvan, de datalocatie en de keten van onderaannemers. Dat register wordt periodiek bij de toezichthouder aangeleverd.

Daarnaast schrijft DORA voor welke bepalingen in het contract moeten staan wanneer een dienst een kritieke of belangrijke functie ondersteunt: toegangs- en auditrechten, meldingstermijnen bij incidenten, voorwaarden voor onderuitbesteding, servicebeschrijvingen met meetbare doelen en een exitstrategie die daadwerkelijk uitvoerbaar is. Ook concentratierisico moet worden beoordeeld, dus de vraag wat er gebeurt als één cloudplatform of één kernbankleverancier uitvalt. De praktische kant daarvan, van leveranciersregister tot het lezen van assurance-rapporten, staat in third-party risk management.

Pijler 5: informatie-uitwisseling

De vijfde pijler is de lichtste. Financiële entiteiten mogen onderling informatie over cyberdreigingen en kwetsbaarheden delen binnen vertrouwde gemeenschappen, mits dat gebeurt binnen afspraken die de vertrouwelijkheid en de bescherming van persoonsgegevens waarborgen. Verplicht is het niet.

De verhouding tot NIS2, ISO 27001 en de DNB-kaders

Voor financiële entiteiten gaat DORA voor op de NIS2-richtlijn op de onderwerpen die DORA regelt. Een bank richt ICT-risicobeheer en incidentmelding dus niet twee keer in.

Een bestaand ISMS helpt, maar dekt DORA niet af. ISO 27001 levert governance, risicoanalyse en een groot deel van de maatregelen, en organisaties die daarmee werken hebben een reële voorsprong. Wat ISO 27001 niet levert, zijn de meldtermijnen, het informatieregister, de verplichte contractbepalingen en het testprogramma op kritieke functies. Hetzelfde geldt voor instellingen die de DNB Good Practice Informatiebeveiliging volgen: de basis staat, de DORA-specifieke artikelen moeten er nog bovenop.

Waar implementaties in de praktijk vastlopen

Vier patronen komen steeds terug. Het informatieregister is niet af, meestal omdat niemand alle contracten centraal had. De contracten met bestaande leveranciers zijn niet heronderhandeld, waardoor audit- en exitbepalingen ontbreken bij precies de partijen die kritieke functies draaien. Het testprogramma bestaat wel, maar is niet herleidbaar tot de lijst van kritieke en belangrijke functies. En de incidentclassificatie is beschreven in beleid zonder dat iemand hem ooit op een echt incident heeft toegepast.

Alle vier zijn te vinden met een gerichte gap-analyse waarin je per artikel vaststelt welk bewijs er is, wie eigenaar is en wat er ontbreekt. Begin bij het register en bij de lijst van kritieke en belangrijke functies, want die twee bepalen de scope van bijna alles wat daarna komt.

Secure Audit voert DORA-gapanalyses en readinessbeoordelingen uit voor financiële instellingen en toetst of het ICT-risicokader aantoonbaar werkt in plaats van alleen beschreven te zijn. Meer daarover staat op onze pagina over compliance. Neem contact op om te bespreken waar jullie nu staan.