DORA Gap Analysis for Fintechs: What Should Be Delivered in 30 Days
DORA gap analysis in 30 days for EU fintechs: week-by-week structure, required deliverables, evidence quality scale and how to build a remediation roadmap.
In this article ↓
- Short answer
- Who this is for
- What a DORA gap analysis is not
- 30-day structure
- Inputs to collect before day 1
- Core assessment questions
- What the gap register should include
- Evidence quality scale
- 30/60/90-day remediation roadmap
- What the board should receive
- Common mistakes
- Mistake 1: Starting with templates
- Mistake 2: Ignoring NCA routing
- Mistake 3: Reviewing suppliers without mapping services
- Mistake 4: Treating incident reporting as a legal-only task
- Mistake 5: Producing findings without owners
- Related reading
- FAQ
- How long should a DORA gap analysis take?
- What should be delivered at the end of a DORA gap analysis?
- Is a DORA gap analysis the same as a legal review?
- Should the assessment include the Register of Information?
- Can a gap analysis prove DORA compliance?
- Who should participate in the assessment?
- Primary sources
- Bottom line
Last reviewed: 5 May 2026
This page covers the specific deliverables from a 30-day DORA gap analysis sprint. For an overview of what a gap analysis covers across all five DORA pillars, see DORA Gap Analysis: A Practical Guide →.
Key takeaways
- A 30-day DORA gap analysis should identify scope, evidence gaps and remediation priorities without pretending to finish the programme.
- DORA has applied since 17 January 2025, so the gap analysis must check operating evidence.
- Regulators and partners ask for current workflows, owners, records and open remediation.
- Fastest path: confirm scope -> test evidence -> rank gaps -> assign accountable remediation owners.
Short answer
A useful DORA gap analysis should not end with a generic maturity score.
For an EU fintech, the 30-day deliverable should be a practical evidence baseline:
| Deliverable | What it should answer |
|---|---|
| Scope note | Which legal entity, licence, service and NCA context is in scope? |
| Evidence inventory | Which DORA artefacts already exist and where are they? |
| Gap register | Which gaps create supervisory, operational or partner-bank risk? |
| ICT risk view | Which ICT risks, systems, functions and owners matter most? |
| Incident workflow review | Can the team classify and evidence major ICT-related incidents? |
| Third-party snapshot | Which ICT providers support critical or important functions? |
| Board summary | What decisions does the management body need to make? |
| Remediation roadmap | What should be fixed in 30, 60 and 90 days? |
The point is to move from "we are working on DORA" to "we know the gaps, owners, evidence and next decisions".
Who this is for
This guide is for EU fintech SMBs that already know DORA applies or is likely to apply to them, including:
- electronic money institutions;
- payment institutions;
- crypto-asset service providers authorised under MiCA;
- investment firms;
- fintech groups with several regulated entities;
- ICT-heavy financial entities preparing for partner-bank, investor or supervisory review.
It is also useful for founders, compliance officers and CTOs who need to understand what a DORA assessment should actually produce before buying a project.
What a DORA gap analysis is not
A DORA gap analysis is not:
- a legal memo only;
- a policy template pack;
- a one-hour questionnaire;
- a penetration test;
- a maturity score without evidence;
- a document dump that leaves remediation unclear.
DORA is an operational resilience regime. The assessment has to inspect whether ICT risk, incident reporting, resilience testing, third-party risk and governance evidence can operate in practice.
30-day structure
For a lean fintech, 30 days is enough to build a strong baseline if the work is focused.
| Week | Focus | Output |
|---|---|---|
| Week 1 | Scope and evidence collection | Entity scope note, NCA map, document inventory |
| Week 2 | Interviews and control review | ICT risk, incidents, suppliers, testing and governance gaps |
| Week 3 | Evidence validation | Gap register, evidence quality rating, missing artefact list |
| Week 4 | Roadmap and board pack | 30/60/90-day remediation plan and management summary |
This timeline assumes the client team can provide documents, join interviews and make decisions. If ownership is unclear or evidence is scattered across many systems, the assessment may need a short discovery phase before day 1.
Need a DORA gap analysis that produces actions, not a long report?
A 15-minute call can separate inspection-critical gaps from lower-risk cleanup - no pitch, just priorities.
Book a free 15-min call →Inputs to collect before day 1
The fastest DORA gap analyses start with a clean evidence request.
| Evidence area | Documents or records to request |
|---|---|
| Entity scope | Licence details, legal entity map, NCA context |
| Services | Product list, critical or important function assumptions |
| ICT risk | ICT risk framework, risk register, asset inventory |
| Incidents | Incident policy, logs, post-incident reviews, escalation records |
| Third parties | Supplier list, contracts, outsourcing register, due diligence records |
| Register of Information | Current RoI, data dictionary, owner list, known gaps |
| Testing | Vulnerability assessments, tabletop records, BCDR tests, remediation tracker |
| Governance | Board packs, minutes, risk acceptances, management reporting cadence |
If these artefacts do not exist, that is not a reason to stop. It is a finding. The gap analysis should distinguish "missing", "exists but stale", "exists but not evidenced" and "operating with current evidence".
Core assessment questions
The assessment should answer questions that a supervisor, partner bank or board member would ask.
| DORA area | Assessment question |
|---|---|
| Scope | Which financial entity and services are in scope? |
| Governance | Has the management body approved and challenged the ICT risk model? |
| ICT risk | Are ICT risks known, scored, owned and linked to functions? |
| Incidents | Can the team classify, escalate and evidence major ICT-related incidents? |
| Third parties | Are ICT providers mapped to services, contracts, criticality and exit risk? |
| Testing | Are resilience tests planned, recorded and remediated? |
| BCDR | Are recovery objectives, tests and failed assumptions evidenced? |
| Evidence | Could the team produce a coherent evidence pack within one week? |
These questions keep the assessment practical. They also prevent the common mistake of treating DORA as a policy-only exercise.
What the gap register should include
A weak gap register says "policy missing" or "process incomplete". A useful gap register supports decisions.
| Field | Why it matters |
|---|---|
| Gap statement | Describes the actual weakness |
| DORA area | Links the gap to ICT risk, incidents, testing, third parties or governance |
| Evidence status | Shows whether evidence is missing, stale or insufficient |
| Risk impact | Explains why the gap matters |
| Owner | Makes remediation assignable |
| Priority | Separates urgent evidence gaps from lower-value cleanup |
| Remediation action | Defines the next practical step |
| Due date | Creates management accountability |
| Board decision needed | Flags budget, risk acceptance or ownership questions |
For example, "incident policy missing" is too shallow. A stronger finding is:
Major ICT incident classification is not evidenced because incident records do not preserve detection time, classification time, decision owner and reporting rationale. This creates reporting-defensibility risk.
Evidence quality scale
Use a simple scale. Complex maturity models are often harder to defend than a clear evidence judgement.
| Rating | Meaning | Example |
|---|---|---|
| 0 | Missing | No incident classification workflow |
| 1 | Drafted | Policy exists but not approved or used |
| 2 | Approved | Document approved, but limited operating records |
| 3 | Operating | Records show the process is used |
| 4 | Reviewed | Evidence shows management review, testing and remediation |
The target after 30 days is not a perfect score. The target is to know which gaps block review readiness and which can be fixed through the next operating cycle.
30/60/90-day remediation roadmap
The final roadmap should be sequenced by risk and evidence value.
| Horizon | Remediation focus | Typical outputs |
|---|---|---|
| Days 1-30 after assessment | Close high-risk evidence gaps | Scope note, incident decision trail, risk owner map |
| Days 31-60 | Build operating artefacts | ICT risk register, supplier criticality map, testing plan |
| Days 61-90 | Validate and govern | Board pack, tabletop exercise, remediation closure evidence |
Do not make every finding "high priority". That destroys the usefulness of the roadmap. A fintech SMB needs a small number of board-visible decisions and a realistic backlog.
What the board should receive
The management body should not receive a 70-page technical annex as the main output.
A useful board pack includes:
| Section | Content |
|---|---|
| Executive summary | Current DORA posture and top risks |
| Scope | Entity, licence, NCA and critical-function view |
| Top gaps | Highest-risk gaps and why they matter |
| Decisions needed | Owners, budget, risk acceptance or timing |
| Roadmap | 30/60/90-day remediation sequence |
| Evidence index | Where supporting artefacts are kept |
The board pack should preserve challenge and decision evidence. If the management body only "notes" DORA work without decisions, the governance evidence is weaker.
Common mistakes
Mistake 1: Starting with templates
Templates can help, but they do not show whether the fintech's actual services, systems and suppliers are controlled.
Mistake 2: Ignoring NCA routing
DORA is EU law, but day-to-day incident reporting and supervisory engagement depend on the competent authority and entity type.
Mistake 3: Reviewing suppliers without mapping services
A vendor list is not a DORA Register of Information. The assessment needs to link ICT services to functions, contracts, locations, owners and criticality.
Mistake 4: Treating incident reporting as a legal-only task
Reporting depends on operational facts: detection time, classification time, impact, provider involvement, containment and remediation.
Mistake 5: Producing findings without owners
A gap without an owner is a comment. A gap with owner, due date and decision path is a remediation item.
Related reading
- DORA Gap Analysis: A Practical Guide for EU Fintechs — methodology, five pillars, assessor selection
- Case Study: 90-Day DORA Gap Analysis for an EU-Licensed EMI — a real-world engagement across 90 days
- DORA Compliance Guide for EU Fintech SMBs: 2026 Evidence Roadmap
- DORA Compliance Checklist 2026: Practical Implementation Guide
- DORA ICT Risk Register Template: 2026 Guide for Financial Entities
- DORA National Competent Authorities: Selected Jurisdiction Guides for EU Fintechs
FAQ
How long should a DORA gap analysis take?
For a fintech SMB with reasonable document access and available owners, 30 days is enough to build a practical evidence baseline and remediation roadmap. Larger or more complex groups may need more time.
What should be delivered at the end of a DORA gap analysis?
The core deliverables should be a scope note, evidence inventory, gap register, remediation roadmap, board summary and evidence index. For fintechs, incident reporting and supplier-risk evidence should be reviewed explicitly.
Is a DORA gap analysis the same as a legal review?
No. Legal review can confirm obligations and interpretation, but a DORA gap analysis should also inspect operating evidence: risks, incidents, suppliers, testing, governance and remediation records.
Should the assessment include the Register of Information?
Yes. The Register of Information is one of the most important DORA evidence artefacts because it links ICT third-party arrangements to services, functions, contracts and criticality.
Can a gap analysis prove DORA compliance?
No. It can show current posture, evidence quality and gaps. Compliance depends on whether the entity operates and maintains the required controls over time.
Who should participate in the assessment?
Compliance, risk, technology, security, operations, legal, procurement, product/service owners and management-body representatives should participate where relevant.
Primary sources
- Regulation (EU) 2022/2554 — DORA, EUR-Lex
- European Banking Authority — Digital Operational Resilience Act
- EBA — Joint Technical Standards on major incident reporting
Bottom line
A DORA gap analysis is useful only if it creates decisions.
The fintech should finish the assessment knowing:
- which entity and services are in scope;
- which evidence exists;
- which evidence is stale or missing;
- which gaps create real review risk;
- who owns remediation;
- what the board needs to approve;
- what should happen in the next 30, 60 and 90 days.
That is the difference between a DORA checklist and a DORA operating roadmap.