7 DORA Compliance Mistakes EU Financial Firms Still Need to Fix in 2026
Seven practical DORA compliance mistakes that still create supervisory risk in 2026: weak ownership, stale evidence, incident gaps and third-party blind spots.
In this article ↓
- The seven mistakes at a glance
- Quick diagnostic: documented or operating?
- Mistake 1: treating DORA as a legal policy exercise
- What to check
- Mistake 2: keeping policies current, but not evidence
- Mistake 3: building an incident plan without classification discipline
- Mistake 4: testing technology, but not the service chain
- Service-chain test example
- Mistake 5: treating third-party ICT risk as procurement paperwork
- Supplier evidence that should not be missing
- Mistake 6: rebuilding the Register of Information only when asked
- Mistake 7: giving the board status updates instead of oversight material
- Board pack minimum
- Evidence pack that survives review
- A 30-day cleanup plan
- One-page self-test
- FAQ
- Is having DORA policies enough?
- What is the most common DORA evidence gap?
- Should smaller fintechs implement the same DORA model as banks?
- Which mistake creates the highest incident reporting risk?
- How often should the Register of Information be updated?
- Bottom line
- Related reading
- Primary sources
Last reviewed: 29 April 2026
Key takeaways
- Most DORA mistakes come from treating compliance as documents instead of an operating evidence system.
- Weak programmes miss ownership, incident timelines, supplier mapping, testing evidence or board reporting.
- Supervisors and partners ask for current records and remediation, not generic policy packs.
- Fastest path: find evidence gaps -> assign owners -> test workflows -> keep a remediation log.
DORA has applied since 17 January 2025. In 2026 the biggest compliance failures are rarely caused by not knowing that DORA exists. They are caused by the gap between written documents and operating evidence.
A financial entity can have a DORA policy set and still fail a practical review if:
- nobody can explain who owns ICT risk;
- incident classification is improvised;
- recovery tests do not prove restoration;
- supplier records are stale;
- the Register of Information is rebuilt manually;
- board reporting is too generic;
- remediation actions are not tracked to closure.
This guide is written for EU fintechs, EMIs, payment institutions, CASPs and other financial entities that need to check whether their DORA programme actually operates.
The seven mistakes at a glance
| Mistake | What it looks like | Supervisory risk | Practical fix |
|---|---|---|---|
| Treating DORA as a legal policy exercise | Policies exist, but operations do not follow them | Framework exists on paper only | Assign accountable owners and evidence |
| Keeping policies current, but not evidence | Documents are approved, artefacts are stale | Controls cannot be proven | Create evidence owners and review cadence |
| Weak incident classification | Technical teams handle incidents before compliance sees them | Late or inconsistent major-incident reporting | Build one classification workflow |
| Testing components, not service chains | Backups or scans are tested in isolation | Critical function recovery is unproven | Test end-to-end services |
| Treating third-party risk as procurement paperwork | Supplier review stops after contract signature | Dependencies and exit risk are unmanaged | Run lifecycle ICT third-party oversight |
| Rebuilding the Register of Information only when asked | RoI is recreated from contracts and invoices | Data quality and submission readiness fail | Maintain RoI as a live artefact |
| Giving the board status updates instead of oversight material | Board sees "green" project status | Management body cannot challenge risk | Report risks, decisions and evidence gaps |
Quick diagnostic: documented or operating?
Use this table before an audit, partner-bank review or board update. The goal is not to score maturity for its own sake. The goal is to find where evidence would fail under questioning.
| Area | Documented-only signal | Operating signal |
|---|---|---|
| ICT risk | Policy says risks are reviewed | Risk register has owner, treatment, due date and latest review |
| Incidents | Incident response plan exists | Classification log shows timestamps, decisions and escalation |
| BCDR | Business continuity document exists | Restore or recovery test has objective, result, gap and closure |
| Suppliers | Vendor list exists | Criticality, contract gaps, monitoring and exit assumptions are tracked |
| Register of Information | Spreadsheet can be assembled | RoI is maintained as suppliers and services change |
| Board oversight | Board receives project status | Board sees risk decisions, acceptances, evidence gaps and remediation |
| Remediation | Findings are listed | Each finding has owner, target date, status and closure evidence |
If most answers sit in the documented-only column, the DORA programme is fragile even if the policy library looks complete.
Mistake 1: treating DORA as a legal policy exercise
Legal and compliance teams are essential, but DORA cannot be operated by legal alone. The ICT risk framework touches technology, operations, security, procurement, vendor management, incident response, business continuity and the management body.
| Weak pattern | Better pattern |
|---|---|
| Legal drafts the policy and sends it for approval | Legal maps obligations; security and technology map controls; owners maintain evidence |
| IT owns systems but not ICT risk | ICT risk owner maintains the risk register and control evidence |
| Procurement owns supplier records | Vendor owners and security maintain third-party risk evidence |
| Compliance owns regulator correspondence only | Compliance also verifies that evidence is current before supervisory contact |
| Board approves documents once per year | Board receives current ICT risk, incident, supplier and remediation evidence |
The fix is not another generic committee. The fix is ownership: ICT risk, incident classification, BCDR, testing, Register of Information, supplier oversight and board reporting each need named owners.
What to check
| Check | Evidence |
|---|---|
| Is there one accountable owner per DORA workstream? | Owner matrix or RACI |
| Does each owner control evidence, not just policy text? | Evidence index with owners and review dates |
| Can management challenge unresolved risk? | Board pack and decision log |
| Are technology, operations, compliance and procurement connected? | Standing review cadence and action tracker |
Mistake 2: keeping policies current, but not evidence
Approving a policy is not the same as operating a control. Under DORA, evidence should show that controls are active, reviewed and improved.
| Policy says | Evidence should show |
|---|---|
| ICT risks are assessed regularly | Current risk register with owners, treatment and review dates |
| Incidents are classified | Classification log with timestamps and decision rationale |
| Backups are maintained | Restore test report and remediation actions |
| Suppliers are monitored | Supplier review records, incidents, contract checks and exit assumptions |
| Board oversees ICT risk | Board pack with risks, decisions, open issues and follow-up |
| Controls are reviewed | Review record showing changes, exceptions and approvals |
The common failure is evidence scattered across folders, tickets and inboxes. A better model gives each artefact an owner, source, update frequency and review trigger.
Mistake 3: building an incident plan without classification discipline
DORA incident reporting depends on classification. If the team cannot classify an ICT-related incident quickly and consistently, the reporting timeline becomes fragile.
| Incident capability | Weak evidence | Strong evidence |
|---|---|---|
| Classification | Severity labels only | DORA major-incident criteria and decision log |
| Timeline | Narrative after the fact | Detection, classification, escalation and restoration timestamps |
| Escalation | "Notify compliance if needed" | Named roles, backup contacts and escalation thresholds |
| Third-party incident intake | Supplier emails handled ad hoc | Supplier notification path and dependency owner |
| Reporting readiness | Blank templates | Known data fields, authority route and report owner |
| Post-incident closure | Lessons learned note only | Root cause, control update, owner and retest where relevant |
The operating model should define before an incident:
- who performs first classification;
- what evidence is needed;
- who escalates to management;
- how supplier incidents enter the process;
- where the decision log is stored;
- who can submit to the competent authority if the primary owner is unavailable.
For the detailed reporting workflow, see DORA Incident Reporting 2026.
Want to know which DORA mistakes are most exposed in your setup?
A 15-minute call can identify the few gaps most likely to fail partner or supervisory review.
Book a free 15-min call →Mistake 4: testing technology, but not the service chain
Many firms test individual controls: vulnerability scans, backup checks, penetration tests or tabletop exercises. These are useful, but they may not prove that a critical or important function can recover.
| Test type | Common gap | Better DORA evidence |
|---|---|---|
| Backup check | Backup exists but restore not proven | Restore test with objective, result and remediation |
| Penetration test | Narrow technical scope only | Findings mapped to critical services and risk treatment |
| Tabletop | Discussion with no action log | Decisions, timestamps, gaps, owners and closure dates |
| Vendor exercise | Supplier excluded | Scenario includes cloud, processor, outsourced support or key SaaS |
| BCDR test | RTO/RPO stated but not measured | Actual recovery time and data loss measured |
| Communications test | Customer and regulator messages drafted later | Pre-agreed escalation and communication path tested |
The test should follow the service chain: customer-facing process, core system, data dependency, cloud provider, outsourced service, communication path and management escalation.
Service-chain test example
| Layer | Example question |
|---|---|
| Business function | Which critical or important function is affected? |
| System | Which application, API, database or identity component is required? |
| Data | What data must be restored and how much loss is tolerable? |
| Supplier | Which cloud, payment, KYC, fraud or SaaS provider is needed? |
| People | Who can make recovery, communication and risk decisions? |
| Evidence | Where are timestamps, decisions, results and remediation stored? |
For a deeper roadmap, see DORA Business Continuity and Disaster Recovery.
Mistake 5: treating third-party ICT risk as procurement paperwork
DORA third-party risk does not end when the contract is signed. It covers due diligence, contract clauses, monitoring, incident support, subcontracting, concentration risk and exit planning.
| Lifecycle stage | Mistake | Evidence to maintain |
|---|---|---|
| Due diligence | Same checklist for every supplier | Risk-based review by service criticality |
| Contracting | Security clauses are generic | Article 30 clauses where applicable |
| Monitoring | Annual supplier review only | Incidents, service performance, assurance and material changes |
| Subcontracting | Subcontractors not visible | Subcontractor disclosure and change notification |
| Exit | No realistic transition path | Exit plan for critical or important functions |
| Register | Vendor list not reconciled | RoI linked to contract and service inventory |
| Concentration | Cloud and SaaS dependencies treated separately | Concentration note across functions, suppliers and geography |
The mistake is splitting supplier facts across procurement, legal, security and business owners without one operational view of dependency.
Supplier evidence that should not be missing
| Evidence | Why it matters |
|---|---|
| Supplier criticality assessment | Shows which providers support critical or important functions |
| Contract clause tracker | Shows whether DORA-relevant terms are present or need remediation |
| Incident notification route | Makes third-party incidents reportable within internal timelines |
| Subcontractor visibility | Reduces hidden dependency and concentration risk |
| Exit assumption | Shows whether the entity can move or recover service if needed |
| Monitoring record | Shows supplier oversight after contract signature |
Mistake 6: rebuilding the Register of Information only when asked
The Register of Information is not a one-off filing artefact. It is the structured view of contractual arrangements with ICT third-party service providers.
| Trigger | RoI action |
|---|---|
| New ICT supplier | Add arrangement and owner |
| Contract renewal | Validate fields, service scope and criticality |
| Material service change | Update function mapping and dependency information |
| Supplier incident | Check whether incident evidence and supplier role are reflected |
| Subcontractor change | Update subcontractor information where required |
| Exit or termination | Update status and retention/exit evidence |
| New product or jurisdiction | Check whether critical functions and authority mapping change |
Submission timing and channels may vary by competent authority. The discipline should not vary: maintain the register continuously so it is not reconstructed under pressure.
For the full artefact structure, see DORA Register of Information.
Mistake 7: giving the board status updates instead of oversight material
DORA places responsibility on the management body for the ICT risk management framework. A board pack that says "DORA is on track" does not support oversight.
| Weak board reporting | Strong board reporting |
|---|---|
| Green/amber/red project status | Top ICT risks, decisions required and changes since last report |
| List of policies approved | Evidence gaps and control maturity |
| Count of incidents only | Incident impact, lessons learned and remediation |
| Supplier list | Critical dependencies, concentration and exit risk |
| Testing completed | Test results, failures, remediation and retest date |
| No explicit decisions | Risk acceptances, funding decisions and escalations |
| No trend view | Changes in risk, incidents, supplier exposure and overdue remediation |
Boards do not need every technical detail. They do need enough information to challenge risk treatment and understand whether resilience is improving.
Board pack minimum
| Section | What it should contain |
|---|---|
| Top ICT risks | Risk, owner, treatment, target date and change since last meeting |
| Incidents | Significant events, classification decisions, lessons learned and closure status |
| Suppliers | Critical provider changes, contract gaps, incidents and exit risk |
| Testing | Tests performed, failures, remediation and next tests |
| Evidence gaps | Missing or stale artefacts requiring management attention |
| Decisions required | Approvals, risk acceptances, budget or ownership decisions |
For governance detail, see DORA Board Responsibilities 2026.
Evidence pack that survives review
If you need a compact evidence pack for audit, partner-bank due diligence or supervisory preparation, start here.
| Evidence artefact | Owner | Refresh trigger |
|---|---|---|
| DORA scope note | Compliance / legal | Licence, product, jurisdiction or group change |
| ICT risk framework | ICT risk owner | Annual review or material change |
| ICT risk register | Risk / security / technology | Quarterly or material risk change |
| Incident workflow and log | Incident manager / compliance | Per incident and tabletop |
| BCDR and test records | Operations / technology | Annual test or material service change |
| Register of Information | Supplier / compliance owner | Supplier, contract or service change |
| Contract gap tracker | Legal / procurement / risk | Contract renewal or new supplier |
| Board pack and decision log | CEO / COO / risk owner | Each management-body review |
| Remediation tracker | Control owners | Weekly or monthly until closure |
This pack does not replace the full DORA programme. It gives the entity a practical review file that connects obligations, controls, owners and evidence.
A 30-day cleanup plan
| Week | Action | Output |
|---|---|---|
| Week 1 | Map accountable owners | Owner map for ICT risk, incidents, BCDR, testing, RoI, suppliers and board reporting |
| Week 1 | Select five evidence artefacts | Incident log, recovery test, supplier register, risk tracker, board pack |
| Week 2 | Check policy-to-evidence traceability | Requirement-control-evidence mapping |
| Week 2 | Reconcile suppliers | RoI, vendor list, contracts and critical-function map aligned |
| Week 3 | Run one realistic scenario | Decisions, timing, gaps and remediation |
| Week 3 | Review stale evidence | Evidence ageing report with owners |
| Week 4 | Update management reporting | Board pack with risks, owners, evidence gaps and decisions |
| Week 4 | Agree next-quarter cadence | Review calendar, evidence refresh dates and escalation route |
This is not the full DORA programme. It is a fast way to test whether the programme is operating or merely documented.
One-page self-test
| Question | If the answer is no |
|---|---|
| Can we name the owner of each DORA control area? | Ownership gap |
| Can we show the latest incident classification decision? | Reporting gap |
| Can we prove restoration, not just backup completion? | BCDR gap |
| Can we identify suppliers supporting critical or important functions? | Third-party risk gap |
| Can we generate a current Register of Information extract? | RoI governance gap |
| Can the board see open ICT risks and decisions needed? | Oversight gap |
| Can we show remediation closure evidence? | Evidence quality gap |
| Can we explain why a control is proportionate? | Proportionality evidence gap |
| Can we show local competent-authority reporting route? | Submission readiness gap |
For jurisdiction-specific authority routing, use the DORA National Competent Authorities selected-jurisdiction hub.
FAQ
Is having DORA policies enough?
No. Policies are necessary, but DORA readiness depends on operating evidence: owners, logs, test results, supplier records, board decisions and remediation closure.
What is the most common DORA evidence gap?
The most common gap is stale or scattered evidence. Many firms can explain what the policy says, but cannot quickly show the latest risk review, incident classification decision, supplier change or board action.
Should smaller fintechs implement the same DORA model as banks?
No. Smaller entities can apply proportionality, but simplification should be documented and approved. The control objective still needs to work. See DORA Proportionality Principle.
Which mistake creates the highest incident reporting risk?
Weak classification discipline. If detection, classification, escalation and decision timestamps are unclear, reporting becomes hard to defend under pressure.
How often should the Register of Information be updated?
It should be maintained when suppliers, contracts, services, criticality, subcontractors or exits change. Waiting until a submission request creates avoidable data-quality risk.
Bottom line
The biggest DORA compliance mistake in 2026 is assuming that completed documents equal resilience.
Supervisors, partner banks and internal auditors will ask how the model works: who owns it, where the evidence sits, how incidents are classified, how suppliers are controlled, how recovery is tested and what the management body sees.
The firms that handle DORA well will not be the ones with the largest policy library. They will be the ones that can show a current, tested and owned operating model.
Related reading
- DORA Requirements in 2026: Operating Controls and Evidence Checklist
- DORA Business Continuity and Disaster Recovery: Articles 11-12 Roadmap for 2026
- DORA Incident Reporting 2026: Initial Notification, Intermediate Report and Final Report Timeline
- DORA Register of Information: 2026 Guide for ICT Third-Party Risk
- DORA Board Responsibilities 2026
- DORA Compliance Guide for European Fintech SMBs