DORA gap assessment: checklist, evidence and Excel template.

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.

Set the scope before scoring controls

Start with the entity’s authorisation, activities and exclusions under DORA Article 2. Record how Article 4 proportionality affects the assessment. Then establish whether the full ICT risk-management framework or the simplified framework under Article 16 applies. Article 16 covers specified categories of entities; being a microenterprise does not, by itself, select that framework.

1. Define the perimeter. List legal entities, ICT-supported functions, systems and providers, and record exclusions with their rationale.
2. Build the source inventory. Map applicable articles and technical standards to that perimeter. Keep the source version and review date.
3. Test design and operation separately. Compare the written control with evidence from the assessed period, including exceptions and emergency activity.
4. Write a finding that can be acted on. State the missing requirement, affected function, risk, accountable owner and agreed target date.
5. Close through review and retesting. Preserve the revised control, fresh operating evidence, reviewer decision and any remaining limitation.

The downloadable workbook is a starter for recording those decisions, not an exhaustive inventory of legal obligations. Extend its source rows for your scope using the technical-standards map below. Keep links to controlled evidence repositories rather than copying sensitive operational records into a widely shared spreadsheet.

How to evidence IT change control for DORA

For an entity using the full ICT risk-management framework, Article 17 of Delegated Regulation (EU) 2024/1774 covers changes to software, hardware, firmware, systems and security parameters. Test security requirements, independent approval, controlled testing, documented change details, fallback arrangements and emergency-change safeguards. Emergency changes also need subsequent documentation, reassessment and approval.

The following fictional example shows how to record a finding for a bank’s payment service. It is an assessment method, not a regulatory sample-size rule or evidence about a Sia client.

For an entity within Article 16, assess the simplified framework, including Article 38 of 2024/1774, rather than assuming that the full-framework Article 17 mapping applies unchanged. The DORA framework reference provides the wider context; RegMatcher supports linking source requirements to controls and review decisions.

Example: separate continuity policy, testing and recovery evidence

Keep these requirements distinct in the assessment. DORA Article 11(1) covers the ICT business continuity policy; Article 11(6) covers continuity and response/recovery testing; Article 12(6) addresses recovery time and recovery point objectives. Article 6(1) establishes the wider ICT risk management framework.

For a practical evidence pack, link the approved policy to its business impact analysis, the dated test results to remediation decisions, and each recovery objective to the function it supports. These are suggested assessment records, not a substitute for the complete applicable requirements.

DORA maturity scale

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

This 0–3 scale is an editorial assessment aid, not a regulator-issued rating or compliance certification. 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.

Test both incident-reporting clocks

Article 5 of Delegated Regulation (EU) 2025/301 requires the initial notification as early as possible, within four hours of classifying the incident as major and no later than 24 hours after awareness. If classification as major occurs more than 24 hours after awareness, Article 5(2) requires notification within four hours of that classification. Preserve both timestamps and the classification rationale.

For example, awareness at 09:00 and major classification at 11:00 on the same day gives a 15:00 outer limit under the four-hour rule; the 24-hour clock does not grant extra time. This is a worked deadline example, not a reason to delay notification until the limit.

• Submit the intermediate report within 72 hours of the initial notification, even if the situation has not changed. Update it without undue delay and when regular activities have been recovered.
• Submit the final report within one month of the intermediate report or the latest updated intermediate report.
• Check the weekend and bank-holiday provisions carefully. The deferral in Article 5(4) does not apply to initial or intermediate reports from credit institutions, central counterparties, trading venues or the NIS2 essential/important entities specified in Article 5(5).
• Use the forms and instructions in Implementing Regulation (EU) 2025/302. In a tabletop exercise, preserve the timestamps, draft reporting fields, escalation decisions and evidence that the reporting team can meet the applicable deadlines.

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

Sources checked on 19 October 2026. Publication dates below refer to the Official Journal where stated; they are not all application dates.

• Regulation (EU) 2022/2554 — adopted 14 December 2022; applies from 17 January 2025
• Delegated Regulation (EU) 2024/1774 — published 25 June 2024; Articles 17 and 38 on change management
• Delegated Regulation (EU) 2025/301 — published 20 February 2025; reporting content and Article 5 time limits
• Implementing Regulation (EU) 2025/302 — published 20 February 2025; reporting forms and procedures
• Delegated Regulation (EU) 2025/532 — published 2 July 2025; ICT subcontracting
• Delegated Regulation (EU) 2025/1190 — published 18 June 2025; TLPT technical standards
• Implementing Regulation (EU) 2024/2956 — adopted 29 November 2024; register templates
• EBA — preparation for DORA application and register-of-information resources
• European Commission — implementing and delegated acts under DORA

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