Wat is DORA en wanneer is het in werking getreden?
DORA is de Digital Operational Resilience Act, een Europese verordening die op 17 januari 2025 in werking is getreden. De verordening vraagt van financiële entiteiten dat zij hun digitale operationele weerbaarheid op orde hebben. DORA rust op vijf pijlers: ICT-risk-management, ICT-incident-management en rapportage, digital-operational-resilience-testing, ICT-third-party-risk en informatie-uitwisseling. DNB en AFM houden in Nederland toezicht op de meeste entiteiten; voor kritische derden — denk aan grote cloudleveranciers — is er een aparte toezichts-route op Europees niveau.
Voor wie geldt DORA?
DORA geldt voor vrijwel elke financiële entiteit in de EU: banken, verzekeraars, beleggingsondernemingen, pensioenfondsen, betaalinstellingen, kredietbeoordelaars, vermogensbeheerders, beheerders van alternatieve beleggingsinstellingen, kredietregistratie-bureaus en crypto-asset-service-providers (CASP's onder MiCA). Ook critical ICT third-party service providers vallen er via een aparte route onder. Voor kleinere entiteiten gelden proportionaliteits-uitzonderingen op delen van de verordening; we brengen die in de gap-analyse in beeld.
Vervangen jullie OneTrust, ServiceNow GRC of ProcessUnity?
Nee. Voor enterprise-GRC zijn ProcessUnity, OneTrust, ServiceNow GRC, MetricStream, Diligent, LogicGate en Archer sterke producten — daar zitten wij niet tussen, en we adviseren u dat ook niet als overstap-traject. Wat we wel bouwen is de maatwerklaag die uw bestaande GRC-platform niet voor uw situatie oplost: de branche-specifieke DORA-flows, de diepe integratie met uw core-banking of polis-systeem, de eigen risico-classificatie en de aansluiting op uw inkoop-, contract- en security-systemen. Soms is maatwerk juist de enige optie omdat geen GRC-suite aanwezig is en de licentiekosten voor uw schaal niet passen.
Hoe werkt de vier-uurs-melding-flow in het systeem?
Wanneer een incident door uw security-operations als major ICT-related incident wordt geclassificeerd, ontstaat in het case-management een notification-concept met alle relevante velden voorgevuld: aard, impact op cliënten, geografische spreiding, duur, dataverlies, betrokken kritische functies en getroffen ICT-assets. Het systeem toetst aan de DORA-classificatiecriteria en bewaakt automatisch de termijnen voor de initial notification (richting de bevoegde autoriteit binnen het vereiste venster), de intermediate notification en de final report. Uw CISO of een delegated officer beoordeelt, vult de open velden aan en submit. De volledige trail — versies, beoordelaars, vrijgave en eventuele aanvullende vragen van DNB of AFM — wordt vastgelegd conform de DORA-bewaarvereisten.
Hoe verhoudt DORA zich tot de AVG en de NIS2-richtlijn?
DORA, AVG en NIS2 overlappen op onderdelen maar verschillen op scope, juridische basis en sanctie-regime. AVG raakt persoonsgegevens en is breder dan financiële diensten. NIS2 raakt essentiële en belangrijke entiteiten in een breder scala aan sectoren. DORA is sector-specifiek voor financiële entiteiten en gaat dieper op ICT-resilience en third-party-risk. Een goed ingerichte DORA-omgeving levert vaak ook NIS2-relevante data en kan AVG-gerelateerde audit-trails voeden. We bouwen het systeem zo dat de overlap actief wordt benut, in plaats van drie separate registers te onderhouden. Voor de AVG-kant doen we standaard een DPIA bij elk groot traject.
Hoe werkt het ICT third-party-register voor onze cloudleveranciers?
Het register houdt per uitbestede ICT-dienst de leverancier, het contract, de sub-uitbesteders, de data-flow, de locatie van verwerking, de exit-strategie en de criticality-rating bij. Voor critical of important functions vraagt DORA om aanvullende contractbepalingen — onder andere over locatie, audit-rechten, sub-uitbesteding, exit en informatieverstrekking — die wij in het register expliciet bijhouden zodat u kunt zien waar contracten nog moeten worden bijgewerkt. Doorlopende SLA-monitoring koppelt de gemeten beschikbaarheid aan het afgesproken niveau en signaleert wanneer een vendor systematisch onder norm presteert. Voor kritische derden zoals AWS, Microsoft Azure of Google Cloud documenteren we ook de exit-route en de uitwijk-mogelijkheid.
Hoe gaat resilience-testing er in software-vorm uit zien?
DORA vereist regelmatige digital-operational-resilience-testing en — voor entiteiten die voldoen aan bepaalde criteria — driejaarlijkse Threat-Led Penetration Testing op kritische functies. De software ondersteunt de planning, scoping en rapportage van die testen: welke kritische functie wordt wanneer getest, welke scope is met de bevoegde autoriteit afgestemd, welke red-team-partij voert het uit, welke bevindingen zijn open en wat is de remediation-status. We voeren de pen-test zelf niet uit — daar werken we met gespecialiseerde red-team-bureaus — maar we maken de cyclus aantoonbaar en beheerbaar.
Wat als wij een critical ICT third-party service provider zijn?
Als uw organisatie door de Europese toezichthouders als kritisch derde wordt aangewezen, vallen delen van uw activiteit direct onder Europees toezicht, met aparte rapportage-eisen en de mogelijkheid van een Joint Examination Team. Dat raakt vooral grote cloudleveranciers en gespecialiseerde ICT-dienstverleners die diepe afhankelijkheden creëren bij financiële entiteiten. Voor deze rol bouwen we een spiegel-omgeving: een register dat aansluit op de specifieke informatieverzoeken die ESA's kunnen indienen, plus de geautomatiseerde rapportage-flow richting Frankfurt of Parijs in plaats van DNB.
Wat bepaalt de kosten van een DORA-traject?
Vier dingen: de breedte van de scope (één pijler versus alle vijf), het aantal koppelingen met externe en interne systemen (core-banking, polis-administratie, uw GRC-suite, SIEM, inkoop), de zwaarte van uw toezichtregime en de complexiteit van uw ICT-landschap, en of u monitoring en doorontwikkeling bij ons onderbrengt of zelf intern oppakt. We schetsen de bandbreedte in het eerste gesprek en leveren altijd een vaste sprintprijs zodat u niet voor verrassingen komt te staan. Voor context over hoe wij prijzen opbouwen, zie onze pagina over
insurance software laten maken en de bredere kennisbank.
Bouwen jullie ook voor pensioenfondsen, betaalinstellingen en crypto-asset-providers?
Ja. Voor pensioenfondsen ligt de focus vaak op het third-party-register en de incident-flow rondom de pensioenadministrateur. Voor betaalinstellingen op de incident-rapportage gekoppeld aan PSD2-storingsmeldingen en de ICT-risk-classificatie van de betaal-keten. Voor crypto-asset-service-providers — die onder MiCA én DORA vallen — bouwen we vaak een gecombineerde omgeving waarin DORA-pijlers naast MiCA-vereisten zoals safekeeping-controles en marktmisbruik-detectie staan. Voor verwante AI-governance-vraagstukken bij dezelfde instelling, zie onze pagina over
AI Act compliance software.
Hoe gaat de overgang vanaf onze huidige Excel-trackers en SharePoint?
In fases. We laten uw bestaande registers, gedeelde drives en SharePoint-mappen een tijd parallel lopen aan het nieuwe systeem, zodat het team kan wennen en we eventuele tekortkomingen vroeg signaleren. Datamigratie doen we met scripts die we voor uw situatie schrijven — ICT-assets, kritische functies, leveranciers, historische incidenten en risk-acceptances worden gecontroleerd overgezet, met een terugrol-optie als er iets misgaat. Pas als het team comfortabel is en de eerste interne audit succesvol is verlopen, worden de oude registers gearchiveerd.