Wat is DORA en wat betekent de verordening voor uw organisatie?

Wat is DORA?

DORA, de Digital Operational Resilience Act, is Verordening (EU) 2022/2554. De verordening is op 14 december 2022 vastgesteld en sinds 17 januari 2025 van toepassing (artikel 64). Zij is verbindend in al haar onderdelen en rechtstreeks toepasselijk in elke EU-lidstaat; er is geen nationale omzettingswet voor nodig.

DORA bundelt de eisen aan hoe financiële ondernemingen met ICT-risico omgaan. Die eisen zijn verdeeld over vijf inhoudelijke hoofdstukken, in deze gids aangehouden als vijf pijlers: ICT-risicobeheer (hoofdstuk II), beheer en melding van ICT-incidenten (hoofdstuk III), het testen van digitale weerbaarheid (hoofdstuk IV), ICT-risico van derde aanbieders (hoofdstuk V) en informatie-uitwisseling over cyberdreigingen (hoofdstuk VI).

Twee principes lopen door de hele verordening heen. Het evenredigheidsbeginsel (artikel 4): de zwaarte van de invulling mag aansluiten bij de omvang, het risicoprofiel en de complexiteit van de organisatie. En het vereenvoudigde regime (artikel 16): voor bepaalde kleine of vrijgestelde entiteiten gelden de artikelen 5 tot en met 15 niet, maar een lichtere set eisen wél.

Vooraf: dit artikel is algemene informatie op basis van de verordeningstekst, geen juridisch advies. Een zelfbeoordeling of checklist is geen certificering en betekent niet dat uw organisatie aan DORA voldoet; de bevoegde autoriteit bepaalt uiteindelijk hoe de regels op uw organisatie van toepassing zijn.

Voor wie geldt DORA?

Artikel 2, lid 1 somt eenentwintig categorieën entiteiten op waarop de verordening van toepassing is. Daaronder vallen onder meer:

• kredietinstellingen (banken);
• betalingsinstellingen en instellingen voor elektronisch geld, óók als die zijn vrijgesteld, en aanbieders van rekeninginformatiediensten;
• beleggingsondernemingen en aanbieders van cryptoactivadiensten;
• verzekeraars en herverzekeraars, en hun tussenpersonen;
• instellingen voor bedrijfspensioenvoorziening;
• handelsplatformen en beheerders van beleggingsfondsen;
• aanbieders van crowdfundingdiensten;
• derde aanbieders van ICT-diensten (in deze gids kortweg: ICT-leveranciers).

De verordening vat de eerste twintig categorieën samen als financiële entiteiten (artikel 2, lid 2). Derde aanbieders van ICT-diensten vormen de eenentwintigste categorie: zij krijgen geen eigen zelfbeoordelingsplichten, maar de verordening bereikt hen via de contracten met hun financiële klanten en, voor aanbieders die als kritiek worden aangewezen, via een Europees oversightkader (zie pijler 4).

Er zijn uitzonderingen. Artikel 2, lid 3 zondert onder meer pensioeninstellingen uit met regelingen met in totaal ten hoogste vijftien deelnemers, en verzekeringstussenpersonen die micro-, kleine of middelgrote ondernemingen zijn. Daarnaast kent de verordening op veel plaatsen lichtere eisen voor micro-ondernemingen, en geldt voor de entiteiten van artikel 16, lid 1 (waaronder kleine en niet-verweven beleggingsondernemingen, vrijgestelde betalingsinstellingen en instellingen voor elektronisch geld, en kleine instellingen voor bedrijfspensioenvoorziening) het vereenvoudigde regime.

Pijler 1: wat eist DORA van het ICT-risicobeheer? (hoofdstuk II)

Hoofdstuk II (artikelen 5 tot en met 16) is het breedste deel van de verordening en legt de eindverantwoordelijkheid nadrukkelijk bij het bestuur: dat stelt het ICT-risicobeheerkader vast, keurt het goed en houdt er toezicht op (artikel 5). Het kader moet gedocumenteerd zijn en minstens jaarlijks én na ernstige ICT-incidenten worden geëvalueerd (artikel 6). De hoofdlijnen:

• actuele en betrouwbare ICT-systemen met voldoende capaciteit, ook bij pieken (artikel 7);
• een actuele inventaris van bedrijfsfuncties, informatie- en ICT-middelen en hun onderlinge afhankelijkheden, ook die bij ICT-leveranciers (artikel 8);
• beveiligingsbeleid, doorlopende monitoring en bescherming van de beschikbaarheid, authenticiteit, integriteit en vertrouwelijkheid van gegevens (artikel 9);
• snelle detectie van afwijkende activiteiten, met alarmdrempels en automatische waarschuwing van de mensen die moeten reageren (artikel 10);
• een continuïteitsbeleid met respons- en herstelplannen die minstens jaarlijks worden getest (artikel 11), plus een back-upbeleid met gescheiden herstelomgevingen en hersteldoelen per functie (artikel 12);
• leren van dreigingen, incidenten en tests, en verplichte opleiding in digitale weerbaarheid voor álle medewerkers en het senior management (artikel 13);
• crisiscommunicatieplannen met minstens één aangewezen woordvoerder (artikel 14).

Voor de entiteiten onder het vereenvoudigde regime vervangt artikel 16 dit alles door een lichtere set: systemen beschermen en doorlopend bewaken, risicobronnen en incidenten snel opsporen en afhandelen, de belangrijkste afhankelijkheden van ICT-leveranciers kennen, de continuïteit van kritieke of belangrijke functies borgen met geteste plannen, en zorgen voor beveiligingsbewustzijn en opleiding.

Pijler 2: hoe moet u ICT-incidenten beheren en melden? (hoofdstuk III)

Elke financiële entiteit moet een vastgesteld proces hebben om ICT-incidenten te detecteren, te beheren en te melden, álle ICT-incidenten en significante cyberdreigingen registreren, en de onderliggende oorzaken opsporen en wegnemen (artikel 17). Incidenten worden geclassificeerd op criteria als het aantal getroffen klanten, tegenpartijen en transacties, reputatieschade, duur en uitvaltijd, geografische spreiding, gegevensverlies en economische gevolgen (artikel 18).

Ernstige ICT-incidenten meldt u aan de bevoegde autoriteit in drie stappen: een eerste kennisgeving, een tussentijds verslag bij relevante wijzigingen en een eindverslag na afronding van de oorzaakanalyse (artikel 19, lid 4). Raakt een ernstig incident de financiële belangen van klanten, dan informeert u die onverwijld, inclusief de maatregelen die u neemt om de gevolgen te beperken (artikel 19, lid 3). Kredietinstellingen, betalingsinstellingen, aanbieders van rekeninginformatiediensten en instellingen voor elektronisch geld passen deze regels ook toe op betalingsgerelateerde operationele en beveiligingsincidenten (artikel 23).

Pijler 3: wat moet u testen? (hoofdstuk IV)

Testen is onder DORA geen los project maar een vast programma binnen het ICT-risicobeheerkader (artikel 24); alleen micro-ondernemingen zijn van die programmaplicht uitgezonderd. Het programma volgt een risicogebaseerde aanpak en test minstens eenmaal per jaar alle ICT-systemen en applicaties die kritieke of belangrijke functies ondersteunen. Artikel 25 noemt de passende testsoorten, van kwetsbaarheidsbeoordelingen en scans tot scenariogebaseerde tests en penetratietests.

De zwaarste vorm, dreigingsgestuurde penetratietests (TLPT), geldt alleen voor entiteiten die de bevoegde autoriteit daarvoor aanwijst (artikel 26, lid 8): minstens elke drie jaar, op live systemen die kritieke of belangrijke functies ondersteunen, met strenge eisen aan de geschiktheid en onafhankelijkheid van de testers (artikel 27). ICT-leveranciers die binnen de reikwijdte van zo'n test vallen, moeten daadwerkelijk deelnemen (artikel 26, lid 3).

Pijler 4: wat eist DORA rond ICT-leveranciers? (hoofdstuk V)

Het uitgangspunt van hoofdstuk V staat in artikel 28, lid 1: de financiële entiteit blijft te allen tijde volledig verantwoordelijk voor de naleving, ook voor uitbestede ICT-diensten. Uitbesteden is onder DORA dus nooit het uitbesteden van verantwoordelijkheid. Daaromheen bouwt afdeling I concrete plichten:

• een actueel informatieregister van álle contracten met ICT-leveranciers, met minstens jaarlijkse rapportage aan de toezichthouder en tijdige melding van voorgenomen contracten voor kritieke of belangrijke functies (artikel 28, lid 3);
• beoordeling en due diligence vóór het sluiten van elk ICT-contract, met extra aandacht voor beveiligingsnormen bij kritieke of belangrijke functies (artikel 28, lid 4 en 5);
• vooraf bepaalde, risicogebaseerde audits en inspecties bij leveranciers (artikel 28, lid 6);
• contracten die beëindigd kunnen worden in de omstandigheden die de verordening noemt, zoals aantoonbare zwakheden in het ICT-risicobeheer van de leverancier (artikel 28, lid 7);
• gedocumenteerde en voldoende geteste exitstrategieën voor ICT-diensten die kritieke of belangrijke functies ondersteunen (artikel 28, lid 8);
• een afweging van concentratierisico en van de risico's van onderaannemingsketens, ook buiten de EU (artikel 29).

Afdeling II van dit hoofdstuk (artikelen 31 tot en met 44) is het Europese oversightkader voor ICT-leveranciers die als kritiek worden aangewezen. Dat deel bevat verplichtingen voor toezichthouders en voor die aanbieders zelf, geen zelfbeoordelingsplichten voor financiële entiteiten.

Pijler 5: is informatie-uitwisseling over dreigingen verplicht? (hoofdstuk VI)

Nee. Artikel 45 maakt het uitwisselen van informatie en inlichtingen over cyberdreigingen tussen financiële entiteiten uitdrukkelijk mogelijk, onder voorwaarden: binnen vertrouwde gemeenschappen en via regelingen die de gevoeligheid van de informatie beschermen en die vertrouwelijkheid, gegevensbescherming en mededingingsregels respecteren (artikel 45, lid 1). Wie deelneemt, meldt dat aan de bevoegde autoriteit, net als de beëindiging van de deelname (artikel 45, lid 3). Niet deelnemen is geen tekortkoming.

Wat betekent DORA voor ICT-leveranciers?

DORA legt de zelfbeoordelings- en meldplichten bij de financiële entiteit, niet bij haar leveranciers. Maar de eisen bereiken de ICT-leverancier langs drie routes:

1. 01Via het contract, voor alle ICT-diensten. Artikel 30, lid 2 schrijft voor elk ICT-contract met een financiële entiteit minimuminhoud voor: een volledige dienstbeschrijving met voorwaarden voor onderuitbesteding, de locaties van dienstverlening en gegevensverwerking, bepalingen over gegevensbescherming en over toegang tot en teruggave van gegevens bij beëindiging of faillissement, dienstverleningsniveaus, bijstand bij incidenten, medewerking aan autoriteiten en opzegtermijnen. Waar relevant hoort daar ook deelname aan de beveiligingstrainingen van de klant bij (lid 2, punt i, gekoppeld aan artikel 13, lid 6).
2. 02Zwaarder bij kritieke of belangrijke functies. Ondersteunt de dienst een kritieke of belangrijke functie, dan komen daar aanvullende bepalingen bij (artikel 30, lid 3): volledige dienstverleningsniveaus met meetbare prestatiedoelen, meld- en rapportageplichten van de leverancier, verplichte noodplannen en beveiligingsmaatregelen, deelname aan de dreigingsgestuurde penetratietests van de klant, onbeperkte toegangs-, inspectie- en auditrechten voor de klant én diens toezichthouder, en exitbepalingen met een passende overgangsperiode.
3. 03Via register, due diligence en tests. Elke financiële klant neemt de leverancier op in zijn informatieregister (artikel 28, lid 3), voert vóór contractsluiting due diligence uit (artikel 28, lid 4 en 5) en bepaalt vooraf hoe vaak en waarop hij audit of inspecteert (artikel 28, lid 6). Valt de dienst binnen de reikwijdte van een TLPT, dan is deelname verplicht (artikel 26, lid 3).

Voor een ICT-leverancier betekent dit concreet: reken op deze bepalingen in nieuwe en heronderhandelde contracten met financiële klanten, en reken op vragen over beveiliging, continuïteit en exit die u met documentatie moet kunnen beantwoorden.

Hoe helpt een gestructureerde zelfbeoordeling?

Wie wil weten waar de organisatie staat, kan de verordening artikel voor artikel langslopen. Een gestructureerde zelfbeoordeling maakt dat behapbaar: per eis legt u vast of die van toepassing is (met reden als dat niet zo is), hoe volwassen de invulling is op een schaal van 0 (afwezig) tot 5 (geoptimaliseerd), en welke onderbouwing en welk bewijs daarbij horen. Het evenredigheidsbeginsel van artikel 4 hoort daarin zichtbaar te zijn: een lage score is niet per definitie een tekortkoming, de onderbouwing telt.

Novaro Compliance helpt de zelfbeoordeling te structureren. Het platform is in ontwikkeling en wordt gebouwd met launching partners; DORA staat er als framework op de roadmap. Eerlijk is eerlijk: een ingevulde zelfbeoordeling is geen certificering en betekent niet dat uw organisatie aan DORA voldoet. Wél geeft zij het bestuur een onderbouwd beeld van waar de organisatie staat en waar het werk zit.

Meer context: de dienst Cybersecurity & compliance beschrijft hoe Novaro beveiliging en aantoonbaarheid in de bredere omgeving aanpakt, en in de veelgestelde vragen leest u onder meer hoe het platform met uw gegevens omgaat.