DORA Gap Analysis Checklist (2026): Control Mapping, Evidence Matrix & Scoring.

What a useful DORA gap analysis should produce

The Digital Operational Resilience Act, Regulation (EU) 2022/2554, has applied since 17 January 2025. A gap analysis performed in 2026 should therefore test the operating effectiveness and evidence of the control environment, not only whether a policy has been drafted.

A useful assessment produces six outputs:

1. A confirmed inventory of applicable DORA requirements.
2. A requirement-to-control map.
3. An evidence record for each control conclusion.
4. A named owner and reviewer.
5. A prioritised remediation backlog.
6. A traceable decision for requirements considered not applicable.

The assessment should include the applicable delegated and implementing acts, national competent-authority expectations and relevant Q&As—not only the Level 1 Regulation.

DORA maturity scale

Use a simple four-level scale. Avoid false precision from a percentage that is not supported by evidence.

Every score should include an evidence link, owner, reviewer, assessment date and explanatory note.

DORA gap analysis checklist

1. ICT risk management

DORA Articles 5–16 establish governance and ICT risk-management requirements. Assess whether the framework is both documented and used in decision-making.

• The management body has defined, approved and oversees the ICT risk-management framework.
• ICT roles, responsibilities, reporting lines and segregation of duties are documented.
• The organisation maintains a current inventory of ICT-supported business functions, information assets and ICT assets.
• Critical or important functions are identified using a documented methodology.
• ICT risks are identified, assessed, monitored and reported using defined criteria.
• Protection and prevention controls are aligned to the asset and risk inventory.
• Detection mechanisms and alert ownership are defined and tested.
• ICT business-continuity, response and recovery plans are maintained and exercised.
• Backup, restoration and recovery procedures have evidence of testing.
• Post-incident reviews and lessons learned result in owned control improvements.
• The framework is reviewed at least as required and following material change.

Evidence examples: approved framework, management-body minutes, asset inventory, risk assessments, criticality methodology, continuity plans, test results, metrics and remediation records.

2. ICT incident management and reporting

DORA Articles 17–23 require a process for managing, classifying and reporting ICT-related incidents.

• A documented process covers detection, management, recording and notification of ICT-related incidents.
• Incident-classification criteria reflect the applicable DORA technical standards.
• Roles and escalation paths are defined across technology, security, risk, legal, compliance and communications.
• Major incidents can be reported within the applicable format and timeline.
• The organisation can produce initial, intermediate and final reporting information when required.
• Records preserve the classification rationale, decisions, submitted information and follow-up actions.
• Significant cyber threats are assessed under the applicable voluntary notification process.

Evidence examples: incident policy, severity matrix, reporting playbook, contact lists, simulation results, submitted reports and decision logs.

3. Digital operational resilience testing

DORA Articles 24–27 establish testing requirements, including advanced threat-led penetration testing for entities that meet the relevant criteria.

• A risk-based digital operational resilience testing programme is approved and maintained.
• The programme covers relevant ICT systems and applications supporting critical or important functions.
• Test types, frequency, independence and remediation expectations are defined.
• Findings are risk-rated, assigned, tracked and retested before closure.
• The organisation has assessed whether it is in scope for threat-led penetration testing.
• Where TLPT applies, scope, testers, production-system safeguards and authority interaction are governed.

Evidence examples: testing strategy, annual plan, scope inventory, reports, remediation tickets, retest results and TLPT applicability assessment.

4. ICT third-party risk management

DORA Articles 28–44 require financial entities to manage ICT third-party risk throughout the relationship lifecycle.

• All contractual arrangements for ICT services are captured in the Register of Information.
• The register follows the applicable templates under Commission Implementing Regulation (EU) 2024/2956.
• ICT services supporting critical or important functions are identified consistently.
• Pre-contract risk assessments cover concentration, substitutability, location, data and subcontracting risk.
• Contracts include the applicable DORA access, audit, incident, security, data, cooperation, termination and exit provisions.
• Subcontracting chains and material changes are monitored.
• Service performance and risk are reviewed throughout the relationship.
• Exit strategies are documented, proportionate and tested where appropriate.
• The organisation can provide the register and supporting information to its competent authority.

Evidence examples: Register of Information, due-diligence records, contract clause matrix, risk assessments, service reviews, audit reports, exit plans and concentration-risk analysis.

5. Information-sharing arrangements

DORA Article 45 permits financial entities to exchange cyber-threat information and intelligence through appropriate trusted arrangements.

• Participation decisions are approved and documented.
• The arrangement protects confidentiality, personal data and commercially sensitive information.
• Roles for receiving, assessing and acting on shared intelligence are defined.
• Notifications to competent authorities are made where applicable.
• Shared intelligence is connected to threat monitoring and risk decisions.

Evidence examples: participation agreement, legal assessment, information-handling procedure, approval record and threat-action log.

Prioritise gaps by risk, not by article count

Do not rank remediation solely by the number of failed checklist items. Assign priority using at least:

• Regulatory significance and reporting deadline.
• Connection to a critical or important function.
• Customer, market and financial impact.
• Known threat or incident history.
• Control-design versus operating-effectiveness gap.
• Dependency on a third party or major technology programme.
• Effort, sequencing and availability of compensating controls.

A high-risk missing incident-reporting capability may be more urgent than several documentation issues. Record the basis for that decision.

Recommended workbook structure

A useful assessment file should contain the following sections.

1. Scope and methodology

Legal entities, competent authorities, exclusions, source hierarchy, scoring method, assessors, reviewers and assessment date.

2. Requirements inventory

3. Control map

Map each control once and connect it to every DORA requirement it genuinely supports. Do not mark a requirement compliant merely because a broadly related policy exists.

4. Remediation plan

Include action, dependency, accountable owner, target date, risk acceptance, status, closure evidence and reviewer.

5. Management summary

Show maturity by DORA area, high-risk gaps, overdue actions, critical-function exposure and decisions required from the management body.

RTS and ITS mapping for the assessment

This is not a complete inventory of DORA technical acts. Confirm the current EBA, EIOPA, ESMA and Official Journal materials applicable to the entity and assessment scope.

Public product view

Move from gap analysis to continuous evidence

A spreadsheet is useful for establishing a baseline. It becomes difficult to maintain when the regulation, technical standards, systems, providers, controls or evidence change.

RegReview monitors the DORA source set, preserves successive versions and routes changed obligations for review. RegMatcher then connects approved requirements to policies, controls, owners and evidence so the assessment can be repeated without losing its earlier rationale.

Together, the workflows help teams:

• Preserve the regulatory source and version behind each requirement.
• Review changes and identify affected obligations.
• Match obligations to policies, controls, owners and evidence.
• Highlight missing or weak mappings.
• Assign remediation and retain approval history.
• Reuse evidence across requirements only where the mapping is valid.
• Export a traceable record for management, audit or supervisory review.

Frequently asked questions

Start with a source-linked DORA baseline

Use the assessment structure above as a baseline, or see how Sia RegAI connects DORA sources to requirements, controls, owners, evidence and remediation.

Primary sources

• Regulation (EU) 2022/2554
• EBA operational-resilience policy and technical standards
• EBA Register of Information standards
• EIOPA legal framework and regulation

Informational content only; it is not legal, cybersecurity or supervisory advice.