Wat is DORA?
DORA is de Digital Operational Resilience Act, Verordening (EU) 2022/2554. De verordening verplicht financiële instellingen om hun digitale weerbaarheid aantoonbaar op orde te hebben en is sinds 17 januari 2025 van toepassing, zonder overgangsperiode. Anders dan een norm is DORA rechtstreeks werkende wetgeving: er is geen Nederlandse implementatiewet nodig en er valt niets vrijwillig aan. In Nederland houden De Nederlandsche Bank en de Autoriteit Financiële Markten toezicht.
Voor wie DORA geldt en wat de verordening vraagt
Wetgeving, geen norm
Het woord DORA valt vaak in hetzelfde rijtje als ISO 27001 en NEN 7510, maar dat is misleidend. Die laatste twee zijn normen waarvan je zelf kiest of je ze gebruikt. DORA is een Europese verordening en daarmee direct bindend recht in alle lidstaten. Er is geen keuze, geen certificaat en geen overgangsperiode: sinds 17 januari 2025 moet je eraan voldoen. Wat DORA wel met normen deelt is de inhoud. De maatregelen die de verordening vraagt lijken sterk op wat ISO 27001 van een managementsysteem verlangt, alleen zijn ze concreter uitgeschreven en zijn de termijnen en formats voorgeschreven in plaats van vrij te bepalen.
Voor wie geldt het?
DORA geldt voor een brede groep financiële entiteiten: banken, verzekeraars en herverzekeraars, beleggingsondernemingen, betaalinstellingen en elektronischgeldinstellingen, beheerders van beleggingsinstellingen, pensioenfondsen, handelsplatformen, centrale tegenpartijen, centrale effectenbewaarinstellingen, kredietbeoordelaars, aanbieders van crowdfundingdiensten en aanbieders van cryptoactivadiensten. Daarnaast raakt de verordening partijen die zelf geen financiële instelling zijn: ICT-dienstverleners die voor de sector werken. Die krijgen contractuele eisen doorgelegd, en een klein aantal wordt door de Europese toezichthouders aangewezen als kritieke derde ICT-aanbieder en komt dan zelf onder Europees toezicht te staan. Ben je softwareleverancier of hostingpartij voor financiële klanten, dan merk je DORA dus in je contracten, ook zonder dat de verordening rechtstreeks op jou van toepassing is.
De verhouding met NIS2
Dit veroorzaakt in de praktijk veel verwarring. Voor financiële entiteiten is DORA de bijzondere regeling die voorgaat op de algemene: waar DORA geldt, treden de eisen rond risicobeheer en incidentrapportage uit NIS2 terug. Je hoeft dus niet twee keer hetzelfde dossier op te bouwen. Dat betekent niet dat de Cyberbeveiligingswet voor jou nooit relevant is: het hangt af van welke entiteiten binnen je groep vallen en van andere activiteiten. Het verschil in karakter is dat NIS2 zich richt op maatschappelijke kritikaliteit en DORA op financiële stabiliteit, en dat DORA daarom veel strakker voorschrijft wat je moet doen en binnen welke termijn.
De vijf pijlers
DORA is opgebouwd rond vijf onderwerpen. Het eerste is ICT-risicobeheer: een governancekader waarin de directie eindverantwoordelijk is, met beleid, risicobeoordeling, beveiligingsmaatregelen, continuïteit en herstel. Het tweede is beheer en rapportage van ICT-incidenten, met classificatie en vaste meldtermijnen. Het derde is het testen van digitale weerbaarheid, van periodieke tests tot dreigingsgestuurde penetratietests voor de grootste partijen. Het vierde is beheersing van risico’s bij derde ICT-aanbieders, met contracteisen, exitstrategieën en een verplicht register van informatie. Het vijfde is het uitwisselen van informatie over dreigingen tussen instellingen, wat vrijwillig is maar wel expliciet mogelijk wordt gemaakt. De eerste vier zijn verplichtingen, het vijfde is een uitnodiging.
De vijf pijlers uitgewerkt
DORA legt de eindverantwoordelijkheid expliciet bij het leidinggevend orgaan. Dat moet het kader vaststellen, kennis op peil houden en er aantoonbaar op sturen. Inhoudelijk vraagt de verordening wat je van een volwassen managementsysteem verwacht: inventarisatie van bedrijfsfuncties en ondersteunende ICT-middelen, risicobeoordeling, beveiligingsmaatregelen, detectie, en plannen voor continuïteit en herstel met vastgestelde hersteldoelen. Werk je al volgens ISO 27001, dan heb je hiervoor een goede basis, maar DORA vraagt op onderdelen meer detail, bijvoorbeeld rond het in kaart brengen van kritieke of belangrijke functies.
Je moet ICT-incidenten registreren, classificeren en de ernstige incidenten melden aan je toezichthouder. De termijnen zijn strak en dit is waar DORA duidelijk verder gaat dan NIS2. De initiële melding moet binnen 4 uur na classificatie als ernstig en in ieder geval binnen 24 uur nadat je op de hoogte bent. Een tussentijdse rapportage volgt binnen 72 uur na de initiële melding. Het eindrapport moet binnen een maand na de laatste tussentijdse rapportage. Kleine instellingen zijn vrijgesteld van de termijn van 4 uur, maar niet van die van 24 uur. Het startpunt van de klok is het moment van classificatie, niet van detectie, en daarom is je classificatieproces net zo belangrijk als je meldproces.
Alle instellingen testen periodiek, met kwetsbaarhedenanalyses, scans, scenariotests en tests van continuïteitsplannen. Voor grote en systeemrelevante instellingen komt daar dreigingsgestuurde penetratietesten bovenop, in het Engels threat-led penetration testing of TLPT, gebaseerd op het Europese TIBER-raamwerk. Dat is een intensieve vorm van testen waarbij op basis van actuele dreigingsinformatie een realistische aanval op productiesystemen wordt uitgevoerd. Voor de meeste instellingen is een reguliere pentest het passende instrument, maar de scope en frequentie moet je onderbouwen.
Dit is de pijler waar de meeste instellingen tijd op verliezen. Je moet al je contractuele afspraken met ICT-dienstverleners beoordelen, vastleggen welke functies kritiek of belangrijk zijn, en dat alles vastleggen in een register van informatie dat je aan je toezichthouder aanlevert. Contracten moeten bepalingen bevatten over onder andere toegang, audit, subuitbesteding, locatie van gegevensverwerking en beëindiging, en je moet een exitstrategie hebben voor kritieke diensten. In de praktijk blijkt vaak dat bestaande contracten die bepalingen niet hebben en dat heronderhandelen maanden kost.
DORA moedigt instellingen aan om onderling informatie over cyberdreigingen te delen binnen vertrouwde kringen, en regelt expliciet dat dit mag binnen de kaders van mededinging en privacy. Dit is de enige pijler zonder harde verplichting. Wel verwachten toezichthouders dat je een bewuste keuze maakt en die kunt uitleggen, dus niets doen zonder afweging is geen sterk antwoord.
In Nederland houden DNB en de AFM toezicht, afhankelijk van het type instelling. Zij kunnen documentatie opvragen, waaronder het register van informatie en de resultaten van tests, en beschikken over handhavingsinstrumenten. Kritieke derde ICT-aanbieders worden aangewezen en gecontroleerd door de Europese toezichthoudende autoriteiten zelf. Belangrijk om te weten: het niet tijdig melden van een ernstig incident is zelf een overtreding, los van het incident.
De inhoudelijke overlap is groot: governance, risicobeoordeling, maatregelen, incidentproces, continuïteit, leveranciersbeheer en een verbetercyclus. Een werkend ISMS volgens ISO 27001 dekt daarmee een flink deel van pijler 1. De verschillen zitten in het dwingende karakter, in de voorgeschreven meldtermijnen en formats, in het register van informatie dat ISO 27001 niet kent, en in de eis van dreigingsgestuurd testen voor de grootste partijen. Certificering tegen ISO 27001 is dus nuttig maar nooit voldoende om DORA-compliant te zijn.
Waarom kiezen voor BOEM?
- Uitleg zonder verkoopverhaal: deze pagina legt uit wat de verordening van je vraagt. Wil je daarna hulp, dan zijn we er.
- DORA en NIS2 in samenhang: wij bepalen eerst welke entiteiten in je groep onder welk regime vallen, zodat je niet twee keer hetzelfde dossier bouwt.
- Techniek en governance in een hand: van risicobeoordeling en contracteisen tot pentesten waarmee je pijler 3 onderbouwt.
- Focus op waar het echt vastloopt: het register van informatie en de contractbepalingen bij leveranciers, want daar verliezen instellingen de meeste tijd.
- Eerste stap zonder kosten: een gratis vooronderzoek, daarna een GAP-analyse met een vaste prijs.
Wat kost het om aan DORA te voldoen?
Eerst bepalen wat er ontbreekt
Bij DORA is de vraag zelden of je iets hebt, maar of het aan de voorgeschreven vorm voldoet. De eerste stap kost niets: met het gratis digitaal vooronderzoek krijg je een beeld van je externe aanvalsoppervlak. Wil je weten hoe je ervoor staat op alle vijf de pijlers, dan doen we een GAP-analyse voor een vaste prijs van 2.500 euro, met bijzondere aandacht voor het register van informatie en je contracten, want daar zit meestal het grootste gat.
Wat het werk daarna kost
De omvang hangt sterk af van hoeveel ICT je hebt uitbesteed en of je al volgens een norm werkt. Wij werken met een dagtarief van 1.200 euro, zodat je per onderdeel kunt bijsturen en zelf bepaalt wat je intern oppakt. Werk je al volgens ISO 27001, dan is pijler 1 grotendeels gedekt en gaat het werk vooral naar incidentclassificatie, het register en de contracten. Een pentest om pijler 3 te onderbouwen loopt van 5.000 tot 50.000 euro, afhankelijk van scope en diepgang. Wil je de rol van verantwoordelijke intern niet zelf beleggen, dan is CISO-as-a-Service een optie.
Of je pakt het binnen het Security Partner-model
Het inrichten van je DORA-kader hoeft geen los project te zijn. Het valt ook binnen ons Security Partner-model van 1.500 euro per maand. Dan bouwen we het managementsysteem en de maatregelen op als onderdeel van het abonnement en houden we het daarna ook bij: risicoregister, interne audits, directiebeoordeling, GRC-tooling en elk kwartaal een technische controle door een ethisch hacker. Voor organisaties zonder eigen securityteam is dat vaak de rustigere route, omdat je een vast bedrag per maand hebt in plaats van een projectbegroting vooraf. In een intake bepalen we samen welke van de twee routes bij je past.
Sinds 17 januari 2025, zonder overgangsperiode. De verordening is op 16 januari 2023 in werking getreden en gaf de sector twee jaar voorbereidingstijd. Die tijd is verstreken, dus wie nu nog niet voldoet is niet in voorbereiding maar in overtreding.
Voor een brede groep financiële entiteiten, waaronder banken, verzekeraars, beleggingsondernemingen, betaalinstellingen, elektronischgeldinstellingen, pensioenfondsen, fondsbeheerders, handelsplatformen, kredietbeoordelaars, aanbieders van crowdfundingdiensten en aanbieders van cryptoactivadiensten. Daarnaast worden ICT-dienstverleners voor de sector geraakt via contracteisen, en een klein aantal wordt aangewezen als kritieke derde ICT-aanbieder onder direct Europees toezicht.
ICT-risicobeheer, beheer en rapportage van ICT-incidenten, testen van digitale operationele weerbaarheid, beheersing van risico’s bij derde ICT-aanbieders, en het uitwisselen van informatie over dreigingen. De eerste vier zijn harde verplichtingen, de vijfde is vrijwillig maar wordt expliciet gefaciliteerd.
De initiële melding moet binnen 4 uur na classificatie als ernstig incident en in ieder geval binnen 24 uur nadat je ervan op de hoogte bent. De tussentijdse rapportage volgt binnen 72 uur na de initiële melding, en het eindrapport binnen een maand na de laatste tussentijdse rapportage. Kleine instellingen zijn vrijgesteld van de termijn van 4 uur maar niet van die van 24 uur. Let op dat de klok begint bij classificatie en niet bij detectie, dus je classificatieproces moet snel en navolgbaar zijn.
Een verplicht overzicht van alle contractuele afspraken met derde ICT-aanbieders, waarin per afspraak onder andere staat welke functie wordt ondersteund, of die functie kritiek of belangrijk is, wie de aanbieder is en waar de gegevens worden verwerkt. Je levert dat register aan je toezichthouder aan in een voorgeschreven vorm. Dit is voor veel instellingen het meest onderschatte onderdeel, omdat het niet alleen administratie is: het legt bloot welke contracten de vereiste bepalingen missen.
TLPT staat voor threat-led penetration testing, dreigingsgestuurd penetratietesten op basis van het Europese TIBER-raamwerk. Het is verplicht voor grote en systeemrelevante instellingen die daarvoor door de toezichthouder worden aangewezen, en het gaat aanzienlijk verder dan een gewone pentest omdat er op basis van actuele dreigingsinformatie een realistische aanval op productiesystemen wordt uitgevoerd. Val je er niet onder, dan moet je nog steeds periodiek testen, en dan moet je kunnen onderbouwen waarom je scope en frequentie passend zijn.
Voor financiële entiteiten geldt DORA als bijzondere regeling die voorgaat op de algemene, dus de eisen rond risicobeheer en incidentrapportage uit NIS2 treden terug waar DORA van toepassing is. Je bouwt dus niet twee keer hetzelfde dossier. Of de Cyberbeveiligingswet daarnaast nog relevant is, hangt af van de samenstelling van je groep en van andere activiteiten. Dat is het eerste dat we in een intake uitzoeken.
Nee, maar het helpt aanzienlijk. Een werkend managementsysteem volgens ISO 27001 dekt een groot deel van de eerste pijler over ICT-risicobeheer. Wat je daarnaast moet regelen zijn de voorgeschreven incidentclassificatie en meldtermijnen, het register van informatie, de specifieke contractbepalingen bij leveranciers, exitstrategieën en het testprogramma. Certificering is dus nuttig als basis en nooit een bewijs van naleving.
Plan vandaag nog een vrijblijvende telefonische intake
In een vrijblijvend gesprek bepalen we of jouw entiteiten onder DORA vallen, hoe DORA en de Cyberbeveiligingswet zich in jouw groep tot elkaar verhouden, en waar je grootste gat zit.
BOEM Cybersecurity als partner, verhalen uit de praktijk
Wij zijn trots op onze klanten. Lees hier meer over deze klanten en hun succesverhalen.