A DORA gap analysis tells you exactly where your ICT risk management falls short of the EU's Digital Operational Resilience Act — before a regulator or a client audit tells you the hard way.
Why this matters
DORA isn't optional guidance. It's binding EU law that has applied since 17 January 2025, and it reaches UK financial services firms, fintechs, and their critical ICT suppliers if they serve EU entities.
A gap analysis is the first real step — not a policy rewrite, not a new tool purchase. You need to know precisely which of the five DORA pillars your organisation already covers and which ones are exposed before you spend a single pound on remediation.
Firms that skip this step end up patching controls reactively after a client questionnaire flags a hole. A structured dora compliance gap analysis flips that order: find the gap, fix it, then prove it.
What you'll need
- A current inventory of ICT systems, cloud services, and third-party vendors that support critical or important functions
- Copies of existing policies: incident response, business continuity, vendor risk, access control
- Named owners for each of the five DORA pillars (someone accountable, not just informed)
- 2-4 weeks of calendar time for a mid-size firm; longer if vendor contracts need reviewing
- A way to track evidence and remediation actions — a spreadsheet works for a first pass, but it breaks down fast once you're managing multiple frameworks at once
The steps
1. Map your scope against the five DORA pillars
DORA organises requirements into five areas: ICT risk management, incident reporting, digital operational resilience testing, third-party risk management, and information sharing. Write down which business functions and systems fall under each pillar.
This step accomplishes one thing: it stops you treating DORA as one monolithic checklist. Each pillar has different evidence requirements and different owners. Skip this and your gap analysis becomes a vague list nobody can act on.
Common mistake: treating DORA as an IT-only exercise. Incident reporting and third-party risk touch procurement, legal, and the board — not just security.
2. Inventory ICT third-party providers
List every vendor that supports a critical or important function — cloud hosting, payment processing, core banking software, even your compliance platform itself. For each one, capture the contract terms, exit provisions, and sub-outsourcing chains.
DORA's third-party risk pillar requires you to hold a register of information on all ICT third-party arrangements, and this is where most firms find their biggest gap. If your vendor contracts predate 2023, they almost certainly lack the audit and termination clauses DORA expects.
Use the same discipline you'd apply to any vendor risk assessment process: tier vendors by criticality, then work top-down.
Common mistake: stopping at direct vendors. DORA's concentration risk requirement expects visibility into sub-contractors too, especially cloud sub-processors.
3. Test your incident detection and reporting workflow
Walk through what actually happens if a major ICT incident hits tomorrow. Who gets notified, in what order, and how fast can you classify severity?
DORA sets tight reporting windows for major incidents — an initial notification, an intermediate report, and a final report to your competent authority. If your current process relies on someone remembering to raise a ticket, that's a gap, not a control.
Run a tabletop exercise if you haven't tested this in the last 12 months. Expected outcome: a documented timeline showing detection-to-notification in hours, not days.
Common mistake: confusing a general IT incident log with the classification criteria DORA requires for major incidents specifically.
4. Review your resilience testing programme
Check what testing you currently run: vulnerability scans, penetration tests, and — if you're a larger or more critical firm — threat-led penetration testing. DORA expects testing proportionate to your risk profile, done at least annually for most firms.
If your last penetration test is over 12 months old, or never touched the systems supporting critical functions, that's a documented gap you can close on a fixed timeline. Firms scoping this for the first time should look at how to scope a penetration test before you buy one to avoid paying for testing that misses the systems that actually matter.
Common mistake: relying on automated vulnerability scans alone and calling it resilience testing. DORA distinguishes between the two.
5. Check your information-sharing arrangements
DORA encourages (and in some member states expects) participation in threat intelligence sharing arrangements with peers and regulators. Confirm whether your firm has any formal arrangement in place, and whether your legal team has reviewed the data-sharing terms.
This pillar is usually the smallest gap for UK firms, but it's the one most commonly left off the register entirely because nobody owns it.
6. Score every gap and assign an owner
For each pillar, rate your current state as Compliant, Partial, or Not Started. Attach a named owner and a target date to every Partial or Not Started item. This is the actual deliverable of a gap analysis — not a report nobody reads, but a live action list.
Common mistake: producing a 40-page findings document and stopping there. The gap analysis only has value once it converts into remediation tickets with owners and dates.
7. Automate evidence collection before you present findings
Once gaps are scored, start collecting the evidence that proves closure — policy sign-offs, test reports, vendor contract amendments. Doing this manually across five pillars and dozens of vendors is where most compliance programmes stall in 2026.
Setting up automated evidence collection before your first audit conversation means you walk in with a live evidence trail instead of a folder you assembled the night before.
Troubleshooting
- You can't get a full vendor list from procurement. Pull invoices and SSO login records instead — shadow IT and forgotten SaaS subscriptions are usually the biggest gap.
- Incident response owners don't know DORA's reporting deadlines. Build the deadlines into your incident response plan directly, not as a separate reference document nobody opens mid-incident.
- Legal says vendor contracts can't be renegotiated quickly. Prioritise the vendors supporting critical functions first; DORA is proportionate, and lower-risk vendors can wait for their renewal cycle.
- The gap analysis keeps expanding scope. Freeze scope to critical and important functions only for the first pass. Everything else goes on a second-phase list.
- You're duplicating work across ISO 27001, SOC 2, and DORA. Most control evidence overlaps. A platform that maps controls once across frameworks avoids the duplicate audit fatigue described in how to reduce audit fatigue across multiple compliance frameworks.
Run your DORA gap analysis faster
OneClickComply automates evidence collection so gaps get tracked, not lost in a spreadsheet.
Tools and resources
- Vendor risk register template or a dedicated tool (see vendor risk assessment process for structure)
- Incident classification matrix aligned to DORA's major incident thresholds
- Annual penetration test scoped to critical function systems
- Evidence collection platform that maps controls once across ISO 27001, SOC 2, and DORA rather than three separate spreadsheets
- A comparison of dedicated platforms if you're evaluating options: best DORA compliance software for UK financial services firms
What to do next
Once the gap analysis is scored, the next move is building the remediation roadmap with fixed dates — not a general policy update, but a ticket-by-ticket plan tied to each pillar. If your firm is running multiple frameworks in parallel, read how firms structure that workload without adding headcount before you staff the remediation plan.
Frequently asked questions
One last thing
The gap analysis itself isn't the hard part — keeping the evidence current after you close a gap is where firms lose ground. A control that was compliant in March 2026 can drift out of scope by September if a vendor changes sub-processors and nobody updates the register. Build a quarterly re-check into the calendar now, while the gap analysis is still fresh, and DORA compliance stops being a once-a-year scramble.
Seriously Simple Cyber Compliance means the gap analysis feeds straight into ongoing evidence, not a report that ages out by the next audit cycle.