# DORA Gap Analysis for Fintechs: What Should Be Delivered in 30 Days

Source: https://www.cyadviso.com/dora-gap-analysis-30-days-fintech
Last reviewed: 2026-05-05
Tags: DORA, vCISO, Case Study

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.

---

**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 →](/dora-gap-analysis).

**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.

## 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](/dora-gap-analysis) — methodology, five pillars, assessor selection
- [Case Study: 90-Day DORA Gap Analysis for an EU-Licensed EMI](/emi-dora-gap-analysis-90-days-case-study) — a real-world engagement across 90 days
- [DORA Compliance Guide for EU Fintech SMBs: 2026 Evidence Roadmap](/comprehensive-guide-dora-compliance-fintech-smb)
- [DORA Compliance Checklist 2026: Practical Implementation Guide](/dora-compliance-guide)
- [DORA ICT Risk Register Template: 2026 Guide for Financial Entities](/dora-compliant-ict-risk-register)
- [DORA National Competent Authorities: Selected Jurisdiction Guides for EU Fintechs](/dora-national-competent-authorities)

## 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](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554)
- [European Banking Authority — Digital Operational Resilience Act](https://www.eba.europa.eu/activities/direct-supervision-and-oversight/digital-operational-resilience-act)
- [EBA — Joint Technical Standards on major incident reporting](https://www.eba.europa.eu/activities/single-rulebook/regulatory-activities/operational-resilience/joint-technical-standards-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.

---

Authored by Andrey Gubarev — CISO for EU fintechs (CISM, CDPSE, SABSA).
CyAdviso · DORA / ICT risk / vCISO programmes for EU-licensed fintechs.
Canonical HTML: https://www.cyadviso.com/dora-gap-analysis-30-days-fintech