DORA Is No Longer a Preparation Exercise
When DORA became applicable on 17 January 2025, many financial institutions treated it as another compliance deadline to manage at the policy layer. Frameworks were written, board resolutions were passed, and gap assessments were filed.
What most institutions did not build was operational reality behind those documents. The ICT risk management framework required by Art. 5 exists as a policy — but the daily governance processes, escalation paths, and board-level oversight mechanisms are not in place. The Business Continuity Plan required by Art. 11 is a document — but it has never been tested against a realistic scenario.
AFM and DNB have made clear in their 2026 supervisory priorities that they are no longer interested in documentation. They are examining operational embedment — whether DORA requirements live in how an institution actually operates, not in how it describes itself on paper.
The gap regulators have found: 75% documented, fewer than 30% operational.
This is not a theoretical risk. It is the finding from supervisory assessments across European financial institutions. An inspection that reveals this gap can result in public corrective orders, material fines, and personal liability for C-suite executives under DORA Art. 5.
The Gap in Numbers
The DORA Readiness Gap
Source: Supervisory assessments across EU financial institutions, 2025–2026
The Three Bottlenecks Where Most Institutions Are Critically Exposed
In our experience working with financial institutions across the Netherlands, three DORA requirements consistently represent the largest operational gap between what is documented and what is real. These are also the three areas that supervisors have flagged most frequently in their 2026 inspection reports.
Register of Information (Art. 28)
ICT Third-Party RegisterDORA requires a complete, up-to-date Register of Information covering every ICT third-party arrangement — including cloud providers, SaaS vendors, and sub-processors. Most institutions have a contract register, not a Register of Information. The distinction is critical: DORA requires documented criticality assessments, exit strategies, and concentration risk analysis for each arrangement.
What most institutions have: a spreadsheet of vendor contracts. What DORA requires: a structured register with criticality classification, substitutability analysis, and ongoing monitoring evidence.
ICT Incident Reporting (Art. 17–23)
Three-Phase Notification ChainDORA's incident reporting regime requires a three-phase reporting structure: an initial notification within 4 hours of classifying a major incident, an intermediate report within 72 hours, and a final root-cause analysis report within one month. The classification criteria under Art. 17 are specific — and most institutions have not stress-tested their incident classification against DORA's thresholds.
What most institutions have: a generic incident management process. What DORA requires: a DORA-specific classification matrix, documented notification chains to AFM/DNB, and tested reporting templates for all three phases.
ICT Third-Party Risk Management (Art. 28–30)
Contractual Provisions & Ongoing MonitoringArt. 30 specifies mandatory contractual provisions that must be present in all ICT third-party arrangements — including service level specifications, audit rights, business continuity obligations, and exit provisions. Existing contracts predating DORA will almost certainly be missing these provisions. Re-papering at renewal is not fast enough for critical providers.
What most institutions have: legacy contracts with generic IT terms. What DORA requires: contracts with specific Art. 30 clauses, ongoing monitoring evidence, and documented exit strategy testing for critical providers.
Compliance Priority: Where to Focus Your Limited Resources
Not every DORA gap carries the same supervisory risk. The matrix below maps DORA requirements against two dimensions that determine where to focus first: supervisory attention (how likely is this to be examined?) and implementation complexity (how long will this realistically take?). Focus on the top-left quadrant — high supervisory attention, lower complexity — first.
- ICT incident classification matrix (Art. 17)
- Major incident notification templates (Art. 19)
- Board ICT risk reporting mechanism (Art. 5)
- Register of Information structure (Art. 28)
- Art. 30 contract re-papering for critical ICT providers
- Digital operational resilience testing (Art. 25)
- Concentration risk analysis & exit strategies
- TLPT threat-led penetration testing (Art. 26)
- ICT strategy documentation (Art. 6)
- BCP testing for non-critical systems
- Staff ICT security awareness training
- Subcontractor notification processes
- Full TLPT programme design (only if in scope)
- Advanced threat intelligence integration
- Cross-jurisdiction coordination for EU groups
- AI-assisted risk scenario modelling
Is Your DORA Programme Inspection-Ready?
We conduct a DORA Operational Readiness Assessment that maps your actual compliance posture against what AFM and DNB are examining in 2026 inspections — not just what the regulation says on paper.
Book a DORA Readiness AssessmentYour 90-Day Catch-Up Roadmap
For mid-sized financial institutions with limited internal DORA bandwidth, a structured 90-day programme can close the critical gaps that carry the highest supervisory risk. The sequence matters: you cannot embed operational controls without governance clarity, and you cannot produce credible evidence without working controls.
Outcome: Board-approved ICT risk management framework with documented roles, escalation paths, and reporting lines.
- 1Map current ICT risk governance against Art. 5 requirements
- 2Identify and document board-level ICT risk reporting mechanisms
- 3Define the ICT function with clear accountability under DORA
- 4Establish the ICT incident classification matrix per Art. 17 criteria
- 5Draft the Register of Information structure and begin population
Outcome: Tested incident reporting chain, initial resilience testing completed, critical vendor contracts reviewed.
- 1Build and test the three-phase incident notification chain (AFM/DNB templates)
- 2Conduct a desktop exercise against a realistic ICT disruption scenario
- 3Complete Art. 30 gap analysis for your top 10 critical ICT providers
- 4Document business continuity and disaster recovery for critical functions (Art. 11)
- 5Validate BCP/DRP against DORA recovery time objectives
Outcome: Inspection-ready evidence package covering all critical DORA requirements, with identified residual gaps and remediation timeline.
- 1Compile evidence package: governance decisions, test results, monitoring logs
- 2Complete Register of Information for all ICT third-party arrangements
- 3Initiate Art. 30 re-papering with critical providers at next renewal
- 4Conduct internal DORA self-assessment against ESA technical standards
- 5Document residual gaps with risk acceptance or remediation timeline
Three Questions Your DORA Auditor Will Ask
These are the questions that appear consistently in AFM and DNB inspection questionnaires. If your CISO or compliance team cannot answer all three without hesitation — and with documented evidence — you have a critical gap.
If a major ICT incident occurred today, who would notify AFM within 4 hours — and do they know that?
DORA Art. 19 requires initial notification within 4 hours of classifying an incident as major. Most institutions have an incident manager — but the DORA-specific notification process, classification criteria, and AFM/DNB contact details are not part of the on-call runbook. When an inspector asks for your notification playbook, they expect documented contact chains — not a policy that says "we will notify the regulator."
For your three most critical ICT providers, do you have documented exit strategies with tested recovery timelines?
DORA Art. 28 requires concentration risk analysis and documented exit strategies for critical ICT providers — including cloud providers (AWS, Azure, Google Cloud) and critical SaaS platforms. "We would find an alternative vendor" is not an exit strategy. A documented strategy includes a substitutability assessment, estimated re-platforming timeline, data portability mechanism, and a tested backup capability.
Has your board received a structured ICT risk report in the past 12 months that covers the DORA Art. 5 requirements?
DORA places personal accountability on management bodies, not just institutions. Art. 5 requires board-level oversight of ICT risk — meaning the board must receive regular, structured ICT risk reports and must be demonstrably involved in strategic ICT risk decisions. A board paper that mentions cybersecurity in passing is not sufficient. Inspectors will ask for board minutes and risk reports to verify active governance.
The Window to Close the Gap Is Narrow — But It Is Open
DORA is not a new framework. The requirements have been clear since the regulation was published. What is new is that the enforcement window has arrived, and supervisors are no longer accepting documentation as a proxy for operational readiness.
The institutions that will emerge from 2026 inspections without material findings are not the ones with the most sophisticated DORA frameworks on paper. They are the ones that invested in making their programmes operational — tested incident chains, populated Registers of Information, board-level governance that functions, and vendors with Art. 30-compliant contracts.
If your institution has a DORA framework but has not closed the gap between documentation and operation, the next 90 days are your window. Use them.
Enterprise GRC & Regulatory Compliance
DORA gap assessments, NIS2 implementation, and ongoing compliance management for financial institutions operating in the Netherlands and the EU.
View GRC ServicesThird Party Risk Management
DORA Art. 28–30 requires a structured ICT third-party risk management programme. Our TPRM service builds the Register of Information and monitoring framework your DORA compliance requires.
View TPRM Services