DORA Gap Analysis: A Practical Guide for EU Fintechs

In this article ↓

1. Short answer
2. What does a DORA gap analysis cover?
3. Pillar 1: ICT risk management
4. Pillar 2: ICT-related incident reporting
5. Pillar 3: Digital operational resilience testing
6. Pillar 4: ICT third-party risk management
7. Pillar 5: Information and intelligence sharing
8. Who needs a DORA gap analysis?
9. How long does a DORA gap analysis take?
10. What does a DORA gap analysis deliver?
11. How is a DORA gap analysis different from an audit?
12. What drives scope and cost?
13. How does proportionality apply?
14. How it looks in practice

Last reviewed: 1 June 2026

Looking for what a 30-day sprint delivers specifically? See DORA gap analysis in 30 days →.

Short answer

A DORA gap analysis is a structured assessment that compares what a financial entity currently has against what Regulation (EU) 2022/2554 requires across five pillars: ICT risk management, incident reporting, resilience testing, third-party ICT risk, and information sharing.

The output is not a maturity score. The output is a clear view of which obligations have current evidence, which have gaps, which gaps carry supervisory or partner risk, and what the remediation priorities are — in a form the management body, partners and supervisors can use.

This page is the hub for CyAdviso's DORA gap analysis content. Each section links to detailed pages on individual pillars, case studies and templates.

What does a DORA gap analysis cover?

A thorough gap analysis covers five pillars drawn from DORA's chapter structure.

Pillar 1: ICT risk management

DORA Chapter II (Articles 5–16) requires an ICT risk management framework: asset and dependency identification, risk assessment, protection, detection, response, recovery, backup and continuity procedures, and regular ICT risk reporting to the management body. Article 5 places accountability for approval and oversight firmly with the management body; Article 16 provides a simplified framework for specific categories of smaller or exempt entities.

The gap analysis checks whether each element is in place, approved by the board, and evidenced through current records — not just policy documents.

Pillar 2: ICT-related incident reporting

Chapter III (Articles 17–23) requires classification of ICT-related incidents against defined thresholds and reporting of major incidents to the competent authority within regulatory deadlines. The classification criteria in Article 18 cover duration, service impact, data loss, geographic spread, criticality of affected services and economic impact.

The gap analysis checks whether the classification scheme is in use, whether internal incident records capture the timestamps and context required for a major incident report, and whether reporting channels are documented and owned.

Pillar 3: Digital operational resilience testing

Chapter IV (Articles 24–27) requires a testing programme proportionate to the entity's ICT risk profile. Threat-Led Penetration Testing (TLPT) under Article 26 applies only to financial entities identified by competent authorities based on DORA criteria and the entity's risk profile. The gap analysis checks whether a documented testing programme exists, whether findings are tracked with owners and remediation deadlines, and whether TLPT applicability has been assessed rather than assumed.

Pillar 4: ICT third-party risk management

Chapter V (Articles 28–30) imposes a structured third-party ICT risk regime: an ICT third-party risk strategy, a Register of Information, pre-contract risk assessment, ICT concentration risk monitoring, and mandatory contractual provisions for arrangements supporting critical or important functions. The gap analysis checks Register completeness, Article 30 clause coverage, concentration risk assessment status and exit strategy documentation.

For a full treatment of this pillar, see DORA Articles 28–30: Third-Party ICT Risk Management Framework.

Pillar 5: Information and intelligence sharing

Chapter VI (Article 45) provides a voluntary framework for sharing cyber threat information between financial entities. The gap analysis checks whether participation has been considered, whether the entity is aware of relevant information-sharing arrangements in its sector, and whether ICT-related intelligence is integrated into the risk management process.

Who needs a DORA gap analysis?

DORA applies to financial entities listed in Article 2(1). A gap analysis is most useful:

• at initial DORA readiness — when an entity is newly in scope or preparing for licence;
• ahead of supervisory review, partner-bank due diligence or investor ICT assessment;
• after a major operational or commercial change that affects ICT dependencies;
• at scope change — new licence category, cross-border expansion or M&A.

Common entity types include:

• electronic money institutions;
• payment institutions;
• crypto-asset service providers authorised under MiCA;
• investment firms;
• fintech groups with multiple regulated entities across jurisdictions.

DORA defines "microenterprise" in Article 3(60). Separately, Article 16 provides a simplified ICT risk management framework for specific categories of financial entities, including small and non-interconnected investment firms, exempt payment institutions, exempt electronic money institutions and small institutions for occupational retirement provision. Microenterprise status affects the application of some DORA requirements, but should not be treated as a universal Article 16 shortcut.

How long does a DORA gap analysis take?

Timeline depends on entity scope and ICT complexity, not on the size of the output document.

For a single-entity EU fintech (one EMI or PI licence, 20–200 employees):

A 30-day engagement should move the entity from "we are working on DORA" to "we know the gaps, owners, evidence and next decisions". For a detailed look at what 30 days should produce, see DORA Gap Analysis for Fintechs: What Should Be Delivered in 30 Days.

For a multi-entity fintech group or a CASP running MiCA authorisation concurrently, the engagement typically runs 60–90 days to cover cross-entity scope, additional asset categories and intersecting regulatory workstreams.

What does a DORA gap analysis deliver?

A useful gap analysis ends with a working set of deliverables, not a single report.

For a template to organise and maintain this evidence set after the assessment, see DORA Evidence Index Template for EU Fintechs.

How is a DORA gap analysis different from an audit?

A gap analysis is an assessment: it compares current state against regulatory requirements, identifies gaps and defines what needs to be done. It is forward-looking and typically carried out by or for the entity itself — often with an experienced vCISO or ICT risk adviser.

An audit is an independent verification: it examines whether controls exist and are operating effectively over a defined period. Supervisory inspection by a competent authority (NCA) is closer to an audit: the NCA checks that obligations are met and requests evidence of operation across a defined timeframe.

A gap analysis and subsequent remediation prepare the entity for supervisory review. They are not a substitute for it.

What drives scope and cost?

A DORA gap analysis is not a standardised product. The factors that most affect scope and effort are:

• Number of entities in scope. A single-licence fintech has a narrower scope than a group with three regulated subsidiaries across two jurisdictions.
• Licence complexity. A CASP with custody and trading services has more ICT-dependent functions than a small PI with a single payment product.
• ICT dependency map. Entities with complex cloud infrastructure, many critical ICT providers or undocumented legacy systems require more time to inventory and assess.
• Existing evidence quality. Clean, centralised documentation shortens the assessment phase. Scattered or missing evidence lengthens it.
• TLPT applicability. If Article 26 TLPT may apply, scope confirmation and planning adds time before the main assessment begins.
• Concurrent regulatory workstreams. Running MiCA authorisation or a PCI DSS renewal alongside a DORA gap analysis requires coordination to avoid duplicated effort and conflicting remediation priorities.

How does proportionality apply?

DORA Article 4 requires that obligations be applied proportionately, reflecting the size, nature, scale and complexity of the financial entity's ICT risk. In practice:

• A small EMI with limited ICT dependencies and no critical outsourced services will have a smaller gap register and a faster remediation path than a multi-licence fintech group with complex infrastructure.
• Article 16 may change the expected ICT risk management baseline for the specific smaller or exempt entities it covers; do not assume every small fintech automatically falls into that simplified framework.
• Supervisors apply proportionality in review, but still expect current operating evidence for every pillar that applies to the entity.

Proportionality does not remove any pillar. It adjusts the expected depth, documentary complexity and testing rigour within each pillar.

How it looks in practice

These anonymised case studies show how the gap analysis process runs for different EU-licensed financial entities:

• Case Study: 90-Day DORA Gap Analysis for an EU-Licensed EMI — scope-to-operating-model, evidence baseline and board-ready remediation plan for a licensed electronic money institution.
• Case Study: MiCA and DORA Readiness for a CASP — connecting MiCA authorisation and DORA operational resilience as a shared evidence model, not separate projects.
• Case Study: DORA Incident Reporting and Register Cleanup for a Payment Institution — incident classification evidence and Register of Information quality resolved in parallel for a licensed payment institution.