DORA has applied since 17 January 2025, so "are we ready?" isn't really the question any more. What DNB and the AFM are now looking at is whether your ICT risk controls, incident process, testing and third-party arrangements actually work in practice, and whether you can prove it.
We help you find that out first. You get an independent DORA audit or compliance assessment of your controls and evidence, and then, if you want it, a DORA consultant working alongside your team to close the gaps.
21+ years in security audit and compliance · CREST-accredited penetration testing · PCI QSA firm · ISO 27001 certified
The Dutch picture in 2026
DORA is an EU regulation, so it applies directly in the Netherlands without being transposed into Dutch law. What the Netherlands did add is the enforcement layer: Bijlage 35 of the Besluit EU-verordeningen Wft names the competent authority for each type of financial entity and sets out which DORA articles can be enforced with a bestuurlijke boete (administrative fine) or a last onder dwangsom (order subject to penalty).
Depending on the type of financial entity, DORA supervision in the Netherlands sits with DNB or the AFM, and for significant banks with the ECB. Where supervision of an entity is shared, DORA generally follows the authority that granted the licence. Central securities depositories are the stated exception: DNB supervises their DORA compliance.
DNB has said DORA replaced its Good Practice Informatiebeveiliging for in-scope institutions from 17 January 2025, and that it continues its existing, risk-based supervision through information requests, risk-identifying conversations and on-site examinations. The AFM has gone further in describing what it now checks: in 2026 it said its reviews look less at policies on paper and more at whether measures work in practice.
That's the shift this page is built around. Most Dutch financial entities finished a DORA programme in 2025. Fewer have tested whether it holds up.
| Supervisor | Examples of entity types it supervises for DORA (Bijlage 35, Besluit EU-verordeningen Wft) |
|---|---|
| De Nederlandsche Bank (DNB) | Banks (unless the ECB supervises them directly), payment service providers, electronic money institutions, insurers, pension funds and premium pension institutions (PPIs), central securities depositories, central counterparties, issuers of asset-referenced tokens |
| Autoriteit Financiële Markten (AFM) | Investment firms, managers of investment funds and UCITS management companies, trading venues, data reporting service providers, crypto-asset service providers, crowdfunding service providers, administrators of critical benchmarks, insurance and reinsurance intermediaries (including advisers and authorised agents) |
| European Central Bank (ECB) | Significant banks under direct ECB supervision, which for example submit their Register of Information to the ECB rather than DNB |
Allocation summarised from Bijlage 35 of the Besluit EU-verordeningen Wft (Stb. 2024, 379). Always confirm against your own licence. Sources: DNB DORA page, Staatsblad 2024, 379.
Scope
DORA doesn't cover every Dutch company, and it doesn't treat every ICT supplier the same way. It helps to think of it in three layers.
Layer 1 · Directly in scope
Layer 2 · Indirectly affected
Layer 3 · Direct EU oversight
DORA audit
A DORA audit is an independent check of whether your DORA controls are designed properly, implemented, and operating the way your documents claim. It's the service most Dutch financial entities ask us about, and it's also the one most often misunderstood, so let's be precise about what it is.
When we run a DORA compliance audit, we don't stop at reading your ICT risk management framework. We pick a sample of incidents and trace them from detection to classification to report. We check whether the backup restore test really restored the system that supports your critical function. We compare your Register of Information against your contract inventory. We look at whether access reviews happened on the dates the policy says. That's the difference between a document review and an audit.
What you get is a findings report: each finding rated, tied to the DORA article or RTS it relates to, with the evidence we looked at, the business impact and a practical remediation action. It gives your management body something concrete to act on under Article 5, and it gives your second and third lines a baseline.
| DORA gap assessment | DORA compliance assessment | DORA compliance audit | Internal audit (Art. 6(6)) | |
|---|---|---|---|---|
| Main question | Where are we short of DORA? | How mature and complete is our DORA implementation? | Do our controls operate effectively, and is there evidence? | Is the ICT risk management framework audited under our own audit plan? |
| Typical depth | Design review, interviews, document review | Design plus selected walkthroughs | Design and operating effectiveness, sample testing, evidence inspection | Set by your audit charter and plan |
| Best timing | Early, or after major change | Periodically, before supervisory review | Once controls have run for a while | Regularly, as DORA requires for non-micro entities |
| Output | Gap register and roadmap | Maturity view, gaps, roadmap | Findings report with ratings and remediation actions | Internal audit report to the management body |
| Who performs it | VISTA | VISTA | VISTA as independent reviewer | Your internal audit function, which VISTA can support or co-source |
If your programme is only just finished, an audit may be premature: controls need to have run long enough to produce evidence. In that case a compliance assessment is usually the better first step, with an audit twelve months later.
DORA consultant
An audit tells you what's wrong. Consulting is how it gets fixed. When you bring in a DORA consultant from VISTA Infosec, you get a named person who works with your CISO, risk and compliance teams on the specific gaps, not a generic framework dropped on your desk.
Our DORA consulting work in the Netherlands usually starts from findings, either ours or your own internal audit's, and turns them into changes people can operate. We keep consulting and audit roles separate where independence matters: if we've designed a control, we'll say so before anyone asks us to audit it.
Already certified to ISO 27001 or holding a SOC 2 report? A lot of that evidence can be reused. Our DORA to ISO 27001 and SOC 2 mapping guide shows where the overlap is and where it isn't.
Talk to a DORA ConsultantConfirm which DORA regime applies to each legal entity, including simplified-framework eligibility and group structures.
Test your framework against Articles 5–16 and the ICT risk management RTS, then fix what doesn't fit how you operate.
Separate policy from procedure (the AFM flagged this), fill the gaps and get documents ready for formal approval.
If you rely on group-level ICT policies, check they cover every DORA requirement for your Dutch licensee.
Classification logic, escalation paths, reporting playbooks and templates that fit DNB's or the AFM's channels.
Due diligence, Article 30 contract clauses, subcontracting, concentration risk and exit plans.
Data model, ownership, quality checks and a maintenance routine so next year's submission isn't a scramble.
A risk-based digital operational resilience testing programme, with findings actually tracked to closure.
Build the evidence trail and the management-body reporting that shows oversight, not just activity.
Assessment
A DORA gap assessment is the fastest way to get an honest baseline. A DORA compliance assessment goes one step further and checks maturity and a sample of operation. Both follow the same nine-step method; the difference is how deep we go at steps 4 and 5. (If you want the long version, here's how to run a DORA gap assessment properly.)
1
Confirm scope
2
Map DORA requirements
3
Review current framework
4
Assess controls
5
Review evidence
6
Identify gaps
7
Prioritise findings
8
Build remediation roadmap
9
Validate improvements
ICT risk management
Chapter II of DORA is where most of the day-to-day work sits. The framework has to be documented, reviewed at least once a year (and after major incidents), and subject to internal audit for non-micro entities. The AFM's 2025 supervision focused here, and it found that while most firms can detect disruption, preventive measures lag behind, with logical access management and patch and vulnerability management called out specifically.
01
Management body defines, approves and oversees the framework, and is accountable for it (Art. 5).
02
ICT assets, information assets, dependencies and the functions they support (Art. 8).
03
Access control, patching, change management, network security, encryption (Art. 9).
04
Monitoring and detection of anomalous activity, with thresholds that trigger response (Art. 10).
05
ICT business continuity policy, response and recovery plans, tested (Art. 11).
06
Backup policies, restoration procedures and checks that restores actually work (Art. 12).
07
Post-incident reviews, lessons learned and training feeding back into the framework (Art. 13).
08
Crisis communication plans for staff, clients and the public (Art. 14).
In a DORA assessment we test these areas with real records: access review logs, patch compliance data, restore test results. Where technical validation helps, our vulnerability assessment and configuration reviews give you evidence rather than opinion.
Incidents
DORA asks for one process that detects, logs, classifies and follows up ICT-related incidents, and reports the major ones to the supervisor in staged reports (initial, intermediate, final). The classification criteria are set in Delegated Regulation (EU) 2024/1772; content, time limits and templates in Delegated Regulation (EU) 2025/301 and Implementing Regulation (EU) 2025/302. The two steps that go wrong most often are classification and reporting, so those are the ones we test hardest.
A low number of reports isn't automatically good news. If your classification thresholds, or the people applying them, never trigger a major incident, we'll want to see why.
Testing
Applies to all non-micro entities
Every in-scope entity outside the microenterprise category needs a sound, comprehensive testing programme, and ICT systems supporting critical or important functions must be tested at least yearly. Article 25 lists the kinds of tests that fit: vulnerability assessments and scans, network security assessments, gap analyses, physical security reviews, scenario-based tests, compatibility and performance testing, end-to-end testing and penetration testing.
Only for identified entities
TLPT is advanced, intelligence-led red teaming on live production systems, at least every three years, for entities the supervisor identifies. It follows the TLPT RTS (Delegated Regulation (EU) 2025/1190) and, in the Netherlands, the TIBER-EU framework.
Most DORA entities will never be asked to do TLPT. All of them still need the programme on the left.
TLPT in the Netherlands
DNB's TIBER Cyber Team (TCT-DNB) identifies DNB-licensed financial institutions (and applicants) that meet DORA's qualitative and quantitative criteria, and tells them by letter. The test then runs under the TIBER-EU framework: initiation and scoping, a Generic Threat Landscape from TCT-DNB, targeted threat intelligence, red-team testing on production, and a test summary and remediation plan. Done properly, TCT-DNB issues an attestation that the test met the requirements.
Where a financial group holds both DNB and AFM licences and is identified for TLPT, DNB has said the two supervisors will work together on the best set-up. DNB also runs the Advanced Red Teaming (ART) framework, which is open to institutions that aren't required to do TLPT but want a structured test.
How we help: preparing you for the process rather than replacing it. That means mapping critical or important functions for the scope, getting your control team and procurement ready, tightening detection before the red team arrives, and then fixing and retesting what the test finds. For wider adversary simulation outside TLPT, see our red team assessment services.
Third parties
Third-party risk is where Dutch supervisors have been most specific. DNB's own sector survey found only about a third of insurers and pension funds had brought every ICT contract supporting a critical or important function in line with DORA. Contracts, subcontracting chains and exit plans take time, and supervisors know it.
You're subject to EU oversight by a Lead Overseer, with recommendations that your financial-entity clients' supervisors can follow up on. That's a different regime from ordinary client-driven requirements, and it's outside what DNB or the AFM supervise directly.
We run vendor and third-party risk assessments of individual ICT providers as well as reviewing the programme around them.
Informatieregister
Article 28(3) requires every financial entity to keep a Register of Information on all contractual arrangements for ICT services from third parties, at entity and, where relevant, sub-consolidated and consolidated level. The templates are set in Implementing Regulation (EU) 2024/2956. In the Netherlands it's collected once a year and passed on to the European Supervisory Authorities, which use it, among other things, to designate critical ICT third-party providers.
The second collection went far better than the first. But a register that passes validation isn't necessarily a register that's right. The things that still trip people up are provider identifiers (LEI or EUID), linking services to the functions they support, subcontracting chains, and the group structure tab.
Register of Information review
We reconcile your register against contracts, your vendor inventory and your critical-function mapping.
You get a list of data-quality issues, missing arrangements and linkage errors to fix before the next collection, and a maintenance process so it stays current.
Review My Register| DNB | AFM | |
|---|---|---|
| 2026 channel | Mijn DNB › Dienst Rapportages (xBRL-CSV; DNB also offered a standardised Excel template as an alternative route) | AFM Portal reporting obligation, xBRL-CSV as a zip file only |
| 2026 timing | Open from 2 March 2026; deadline 20 March 2026; reference date 31 December 2025 | First submission by 31 March 2026 (extended by one week); an improved version could follow until 30 April 2026 |
| Checks | ESA technical and data-quality validation; extra 2026 checks on the consolidation structure (B_01.02) and ICT providers (B_05.01); errors lead to resubmission | Forwarded to the EBA for validation; feedback in the AFM Portal normally within one working day |
| What we saw | Majority of registers accepted after the first round; data quality remains the focus | EBA-approved registers rose from 40% in 2025 to 94% in 2026 |
Banks under direct ECB supervision submit to the ECB. Dates above are for the 2026 cycle; check DNB and the AFM for the next one.
Operating effectiveness
If you read the 2026 AFM publications side by side, one message comes through: having the documents is the starting line, not the finish. The AFM found gap analyses that were too broad, policies that weren't clearly separated from procedures, and group documents nobody had checked against the Dutch licensee's obligations. It also said it now looks increasingly at whether measures are applied in practice and actually contribute to resilience.
Most DORA programmes we see are strong on the first two steps of the ladder and thin on the rest. That's normal after an implementation project. It's also exactly where a supervisor's sample will land.
A useful test: pick one control that matters, say quarterly access reviews for the systems behind your payments function, and try to show us the last four completed reviews, who signed them off, and what happened to the exceptions. If that takes a day to assemble, it's worth fixing now.
Test My Control EffectivenessRoadmap
Whether you're closing gaps from 2025 or rebuilding after an acquisition, the sequence is broadly the same. We usually run steps 1–9 as the assessment, then support 10–13 as consulting or a follow-up audit.
Understand
Assess
Close
Sustain
Evidence
This is the kind of evidence a DORA audit or supervisory review may ask for. Not everything applies to every entity; a small AFM-licensed investment firm on the simplified framework won't have the same file as a DNB-supervised insurer. Scoping tells us which parts matter for you.
Requirements
A quick way to see where you stand. If you can't answer the third column confidently for a row, that's where to look first.
| DORA area | What it covers | Questions to ask | Potential evidence | How VISTA can support |
|---|---|---|---|---|
| Governance | Management body responsibility and oversight (Art. 5) | Has the board approved the framework and accepted residual risk formally? | Minutes, approvals, training records | Governance review, board reporting design |
| ICT risk management | Framework, identification, protection, detection, response, recovery (Art. 6–16) | Do preventive controls work as well as detection does? | Access reviews, patch data, restore tests | Framework review, control testing, technical validation |
| Incident management | Process, classification, reporting (Art. 17–19) | Would our thresholds classify last year's worst incident as major? | Incident log, classification records, reports | Process audit, playbooks, tabletop exercises |
| Resilience testing | Testing programme (Art. 24–25) | Is every critical system tested yearly, and are findings closed? | Test plans, results, retest evidence | Programme design, CREST-accredited pen testing, VA |
| TLPT | Threat-led testing for identified entities (Art. 26–27) | Have we been identified? Are we ready for the TIBER process? | TCT-DNB letter, scope, remediation plan | Readiness, scoping support, remediation and retest |
| Third-party ICT risk | Strategy, due diligence, contracts, exit (Art. 28–30) | Are all critical-function contracts DORA-aligned? | Contracts, due diligence, exit plans | TPRM review, contract gap analysis, vendor assessments |
| Register of Information | Record of all ICT arrangements (Art. 28(3), ITS 2024/2956) | Would it pass validation and match our contracts? | RoI file, validation output, source data | Reconciliation, data-quality review, process design |
| Audit & review | Annual framework review and internal audit (Art. 6(5)–(6)) | Does internal audit cover ICT risk with the right skills? | Audit plan, reports, review records | Independent DORA audit, co-sourced audit support |
| Remediation | Follow-up of findings (Art. 6(7) and testing articles) | Can we show critical findings were verified as fixed? | Tracker, closure evidence, retests | Roadmap, validation of fixes, follow-up audit |
Where we work
We work with financial entities and ICT providers across the Netherlands, from fintechs and payment institutions in Amsterdam to insurers, pension administrators and asset managers in Rotterdam, The Hague, Utrecht and Eindhoven. Most assessment and consulting work runs remotely; interviews, walkthroughs and workshops can be held on-site by agreement.
To be clear about how we're set up: VISTA Infosec doesn't have an office in the Netherlands. EU engagements are contracted through Zulon Audits OÜ, our European practice registered in Tallinn, Estonia, and delivered by our EU and global teams. If your evidence needs to stay in the EU, we can arrange EU-region processing.
Our deliverables are in English, which is how most Dutch financial-sector DORA work is run. We work with Dutch source material (DNB and AFM publications, Wft references, your internal documents) and use the Dutch terms your supervisors use.
Who we support
We work with organisations on both sides of DORA: the financial entities that carry the obligations, and the ICT providers they depend on. Grouped here by who usually supervises them.
Why VISTA Infosec
Cost
It depends on scope, and we'd rather not quote a number before we understand yours. A single-entity gap assessment for an AFM-licensed investment firm is a very different job from a full DORA audit of a DNB-supervised insurance group. These are the factors that move the price:
Fill in the form and we'll send a short scoping questionnaire. Once it's back, we'll review the scope and share the proposed approach, timelines and commercials.
Request a DORA AssessmentFAQ
The questions we hear most often from Dutch CISOs, risk managers and compliance teams.
A DORA audit is an independent review of whether your controls for the Digital Operational Resilience Act are designed properly, implemented and operating effectively, supported by evidence. It covers areas such as governance, ICT risk management, incident handling, resilience testing, ICT third-party risk and the Register of Information. It results in a findings report with remediation actions, not a certificate.
A DORA consultant helps you interpret the requirements for your type of entity, assess where you stand and close the gaps. In practice that means reviewing your ICT risk framework, writing or fixing policies and procedures, designing incident and third-party processes, improving the Register of Information, and preparing evidence and management reporting.
A DORA gap assessment compares your current framework with DORA and its technical standards and lists what's missing. A DORA compliance assessment goes further: it looks at maturity and checks a sample of controls in operation. Both end with a prioritised remediation roadmap. A DORA compliance audit goes further still and tests operating effectiveness in depth.
Yes. DORA is Regulation (EU) 2022/2554 and has applied directly in every EU member state, including the Netherlands, since 17 January 2025. It applies to the financial entities listed in Article 2, such as banks, payment and e-money institutions, investment firms, insurers, pension funds and crypto-asset service providers, subject to certain exclusions and proportionality.
It depends on the type of financial entity. Under Bijlage 35 of the Besluit EU-verordeningen Wft, DNB supervises entities such as banks (unless the ECB supervises them directly), payment and e-money institutions, insurers and pension institutions. The AFM supervises entities such as investment firms, fund managers, trading venues, crypto-asset service providers, crowdfunding platforms and insurance intermediaries. Significant banks are supervised by the ECB.
No. DORA does not include a certification scheme, so no firm can certify an organisation as DORA compliant, and neither DNB nor the AFM approves consultants. What you can get is an independent assessment or audit report showing how your controls perform against the requirements.
Yes, for entities other than microenterprises. Article 6 requires the ICT risk management framework to be subject to internal audit by auditors on a regular basis, in line with the entity's audit plan, with a formal follow-up process for critical findings. An external DORA audit can support this, but it does not replace your own internal audit obligation.
The Register of Information, or informatieregister, is a structured record of all contractual arrangements for ICT services provided by third parties, required by Article 28(3) of DORA. In the Netherlands it is collected annually by DNB, the AFM or the ECB, depending on your supervisor, in xBRL-CSV format, and shared with the European Supervisory Authorities.
No. Threat-led penetration testing is only required for financial entities identified by the competent authority based on criteria in DORA and the TLPT technical standard. In the Netherlands, DNB informs identified institutions by letter and the test follows the TIBER-EU framework. All other non-micro entities still need a risk-based digital operational resilience testing programme.
Not directly in most cases. ICT third-party service providers are affected through their financial-entity clients, which must include DORA contract terms, audit rights and exit arrangements. Only providers designated as critical ICT third-party providers by the European Supervisory Authorities fall under direct EU oversight.
The cost depends on the number of legal entities, the type of entity, the size of your ICT environment, the number of ICT providers, your current maturity and whether you need a gap assessment, a compliance assessment or a full DORA audit. VISTA Infosec provides a fixed-fee proposal once scope has been confirmed through a short questionnaire.
It depends on scope and on how quickly evidence can be made available. A focused gap assessment of a single entity is shorter than a full DORA audit of a group with many ICT providers. We confirm the timeline in the proposal, after scoping, rather than quoting a standard duration.
Expert Auditors. Faster Certification.
European Operations
European engagements are delivered through Zulon Audits OÜ, the European practice of VISTA InfoSec.
Visit Zulon Audits →
VISTA InfoSec LLC,347 Fifth Ave,
Suite 1402-526, New York, NY 10016
© Copyright 2026. VISTA InfoSec. All Rights Reserved. | Disclosure Policy | Privacy Policy | Sitemap
Enquire Now
WhatsApp us