Compliance checklistEU financial sector

EU DORA Compliance Checklist

Use this checklist to test whether a financial entity has the core DORA operating records in place: accountable governance, a documented ICT risk management framework, incident reporting, resilience testing, TLPT scoping, third-party contracts, and the register of information.

The checks are grounded in DORA and related EU technical standards for ICT incident classification, major-incident reporting, register templates, ICT third-party contractual arrangements, and threat-led penetration testing.

Back to main artifactReview sources
Author
Sorena AI
Published
May 9, 2026
Updated
May 9, 2026
Sections
5

Structured answer sets in this page tree.

Primary sources
7

Cited legal and guidance references.

Publication metadata
Sorena AI
Published May 9, 2026
Updated May 9, 2026
Overview

DORA compliance is not a single policy exercise. A useful checklist should show whether the financial entity can prove who is accountable, which ICT assets and critical or important functions are in scope, how incidents are classified and reported, how resilience is tested, and how ICT third-party dependencies are contracted, monitored, and recorded.

Section 1

1. Governance and ICT risk management framework

Start with the management-body and framework checks. DORA makes the management body responsible for defining, approving, overseeing, and being responsible for the implementation of ICT risk management arrangements. The checklist should therefore verify governance evidence before looking at tool configuration.

For entities outside the simplified framework, the ICT risk management framework should also be documented, reviewed at least yearly, improved after major incidents, testing, audit, or supervisory findings, and subject to internal audit in line with the audit plan.

  • Management body approval record for the ICT risk management framework, digital operational resilience strategy, ICT business continuity policy, ICT response and recovery plans, ICT internal audit plans, and ICT third-party service policy.
  • Named responsibility for managing and overseeing ICT risk, with segregation between ICT risk management, control functions, and internal audit where DORA requires it.
  • Documented risk tolerance for ICT risk, information security objectives, key performance indicators, key risk metrics, and communication strategy for disclosable ICT-related incidents.
  • Inventory of ICT-supported business functions, roles, responsibilities, information assets, ICT assets, dependencies, remote sites, network resources, hardware, and ICT third-party interconnections.
  • Annual or event-driven review record showing lessons from implementation, monitoring, major ICT-related incidents, resilience testing, audits, and supervisory instructions.
Sources for this answer
Regulation (EU) 2022/2554 (DORA)
Supports management-body responsibility, ICT risk management framework content, yearly review, audit, digital resilience strategy, and asset/function identification checks.
Section 2

2. Incident classification and major-incident reporting

The incident checklist should separate classification from reporting. First classify the ICT-related incident using DORA's criteria and materiality thresholds; then prepare the initial notification, intermediate report, and final report using the reporting content and template rules.

Do not rely on severity labels from an internal ticketing tool unless they map to the DORA criteria. The evidence record should show the data used for each criterion and whether the incident affected critical services.

  • Classification fields: clients, financial counterparts and transactions affected; reputational impact; duration and service downtime; geographical spread; data losses; critical services affected; and economic impact.
  • Critical-service check: record whether ICT services or network and information systems supporting critical or important functions, or financial services requiring authorisation, were affected.
  • Recurring-incident check: assess recurring non-major incidents monthly and record whether similar apparent root cause means they are major collectively.
  • Initial notification fields: entity identity, LEI where required, incident reference code, detection and classification timestamps, description, classification criteria, impacted Member States, discovery method, origin where available, temporary recovery measures, and indicators of compromise where applicable.
  • Reporting clock evidence: initial notification as early as possible and within four hours from major classification, no later than 24 hours from awareness; intermediate report within 72 hours from initial notification; final report no later than one month after the intermediate or latest updated intermediate report.
Sources for this answer
Delegated Regulation (EU) 2024/1772 on ICT incident classification
Supports the DORA incident classification criteria, critical-service treatment, recurring incident assessment, and materiality checks.
Delegated Regulation (EU) 2025/301 on incident report content and time limits
Supports the required content and time limits for initial notifications, intermediate reports, final reports, and voluntary significant cyber-threat notifications.
Implementing Regulation (EU) 2025/302 on incident reporting templates
Supports use of standard forms, templates, and procedures for major ICT-related incident reporting and significant cyber-threat notification.
Section 3

3. Resilience testing and TLPT readiness

The testing part of the checklist should prove that testing is risk-based, covers ICT systems and applications supporting critical or important functions, and produces remediated findings rather than only test reports.

Threat-led penetration testing is a separate advanced-testing track. DORA requires TLPT for financial entities identified under the TLPT criteria, and the TLPT scope should cover several or all critical or important functions and relevant underlying ICT systems, processes, technologies, and ICT services.

  • Digital operational resilience testing programme exists, is maintained and reviewed, and uses a risk-based approach tied to the ICT risk management framework.
  • Annual testing evidence for ICT systems and applications supporting critical or important functions, including the test type, test owner, independent tester status, systems covered, findings, risk rating, remediation action, and validation status.
  • Testing methods considered where relevant: vulnerability assessments and scans, open-source analyses, network security assessments, gap analyses, physical security reviews, questionnaires, scanning tools, source code reviews where feasible, scenario-based tests, compatibility testing, performance testing, end-to-end testing, and penetration testing.
  • TLPT applicability record showing whether the entity has been identified for advanced testing, the competent authority validation of scope, critical or important functions selected, production systems in scope, ICT third-party services included, and safeguards for provider participation.
  • TLPT evidence pack: control team lead, authority contacts, threat intelligence provider, testers, agreed scope, risk-management measures, test documentation, remediation plan, and lessons learned.
Sources for this answer
Regulation (EU) 2022/2554 (DORA)
Supports resilience testing programme requirements, annual testing of critical or important systems, and DORA Article 26 TLPT scope and responsibility rules.
Delegated Regulation (EU) 2025/1190 on TLPT criteria
Supports the criteria used by TLPT authorities to identify financial entities required to perform threat-led penetration testing and the organisational arrangements for TLPT.
Section 4

4. ICT third-party contracts and register of information

DORA treats ICT third-party risk as part of the ICT risk management framework. The checklist should verify both the contract clauses and the register-of-information record, because supervisors can request the full register or specified sections.

Use one evidence row per ICT service arrangement, distinguishing ICT services supporting critical or important functions from other ICT services. For critical or important functions, the contract and monitoring record should be more detailed.

  • Before signing: documented business need, ex-ante risk assessment, due diligence, approval process, data-location review, concentration and transferability assessment, and subcontracting-chain assessment where subcontracting is allowed.
  • Core contract clauses: complete service description, subcontracting permission and conditions, service and data-processing locations, data availability/authenticity/integrity/confidentiality protections, data access/recovery/return on insolvency or termination, service levels, incident assistance, cooperation with competent and resolution authorities, termination rights, and provider participation in awareness or resilience training where applicable.
  • Critical or important function clauses: precise quantitative and qualitative service levels, monitoring rights, audit and access rights for the financial entity and competent authorities, reporting obligations, business continuity measures, exit planning, and termination process.
  • Monitoring evidence: periodic service reports, incident reports, service delivery reports, ICT security reports, business continuity testing reports, key performance indicators, key control indicators, audits, self-certifications, independent reviews, shortcomings, remediation actions, and defined timeframes.
  • Register-of-information fields: contractual arrangement reference number, financial entity and provider identifiers, function identifier, type of ICT services, annual expense or estimated cost, branch records where applicable, intra-group service-provider links, subcontractors that underpin critical or important functions, and links between templates using the required keys.
Sources for this answer
Regulation (EU) 2022/2554 (DORA)
Supports the requirement to manage ICT third-party risk within the ICT risk management framework and to maintain and update a register of information for ICT service contracts.
Delegated Regulation (EU) 2024/1773 on ICT third-party contract policy
Supports the policy, governance, due diligence, monitoring, contract lifecycle, audit, access, and exit-plan checks for ICT services supporting critical or important functions.
Implementing Regulation (EU) 2024/2956 on register templates
Supports the standard register-of-information templates, keys, identifiers, contractual arrangement records, and subcontractor data needed for DORA supervisory reporting.
Section 5

5. Evidence records to keep with the checklist

The checklist is only useful if every completed item leaves an auditable record. Keep the evidence close to the obligation, not buried in project notes. A reviewer should be able to trace each item to a DORA requirement, an owner, a system or supplier, and a current artifact.

Use this section as the minimum record set for recurring DORA reviews, management-body updates, internal audit, supplier governance meetings, and supervisory requests.

  • Governance evidence: management-body agendas, approvals, risk tolerance decisions, budget reviews, training evidence, reporting-channel design, and records of major ICT-related incidents escalated to senior management.
  • Framework evidence: documented ICT risk management framework, digital operational resilience strategy, business function and asset inventories, dependency maps, legacy-system risk assessments, review reports, internal audit findings, and remediation follow-up.
  • Incident evidence: incident classification worksheet, criterion-by-criterion assessment, timestamps, affected services, impacted Member States, client or counterparty impact analysis, reports submitted, authority acknowledgements, root-cause analysis, costs and losses, and recurring-incident assessment.
  • Testing evidence: annual testing plan, systems and applications covered, independent tester confirmation, test results, weakness register, remediation validation, TLPT scoping records, authority validations, provider participation records, and lessons learned.
  • Third-party evidence: contract inventory, register-of-information export, contract clauses, due diligence, risk assessment, service reports, audit reports, subcontractor reviews, location and data-processing records, exit plans, tested exit evidence, and management reporting.
Sources for this answer
Regulation (EU) 2022/2554 (DORA)
Supports the governance, framework, incident, testing, and third-party records that DORA requires financial entities to maintain or provide to competent authorities.
Implementing Regulation (EU) 2024/2956 on register templates
Supports the register-of-information export and linked data fields used as evidence for ICT third-party dependencies.
Recommended next step

Use the checklist to expose gaps in DORA operating evidence

Sorena can help convert these DORA checks into cited research notes, owner assignments, supplier evidence requests, incident-reporting fields, and register-of-information review tasks.

Research workflow
Open Research Copilot for EU DORA

Ask source-linked questions about DORA governance, incident reporting, ICT third-party risk, register fields, testing, and TLPT using the sources on this page.

Explore next step
Talk to Sorena
Review DORA implementation evidence

Discuss gaps in your DORA checklist, supplier records, incident reporting process, or register-of-information evidence.

Explore next step
Primary sources

References and citations

Delegated Regulation (EU) 2025/1190 on TLPT criteria
eur-lex.europa.eu
Referenced sections
  • Supports the criteria used by TLPT authorities to identify financial entities required to perform threat-led penetration testing and the organisational arrangements for TLPT.
"criteria used for identifying financial entities"
Regulation (EU) 2022/2554 (DORA)
eur-lex.europa.eu
Referenced sections
  • Supports the governance, framework, incident, testing, and third-party records that DORA requires financial entities to maintain or provide to competent authorities.
"provide complete and updated information"
Related guides

Explore more topics

DORA Critical or Important Functions: mapping ICT dependencies and evidence
How DORA critical or important functions affect ICT service mapping, third-party contracts, register-of-information records, incidents, testing, and evidence.
DORA deadlines and compliance calendar for financial entities
Calendar the grounded DORA dates and recurring evidence: 17 January 2025 application, incident reporting clocks, register updates, annual reporting, TLPT cadence, and CTPP oversight milestones.
DORA ICT Third-Party Contract Remediation Workflow
A DORA workflow for remediating ICT third-party contracts covering critical or important functions, subcontracting, audit rights, exits, register updates, and evidence.
DORA ICT Third-Party Contracts FAQ
What DORA requires in ICT third-party contracts, including critical or important functions, audit and access rights, termination, exit, subcontracting, register updates, and evidence.
DORA ICT third-party risk and contract clauses guide
Source-grounded DORA guide for financial entities in scope, ICT third-party risk, contract clauses, subcontracting controls, register evidence, audit rights, exit planning, and oversight.
DORA incident classification forms: criteria, fields, and reporting clocks
Grounded guide to DORA ICT incident classification forms: major-incident criteria, significant cyber-threat notifications, report fields, time limits, evidence, and reclassification records.
DORA incident clock workflow: classification, reports, deadlines, and evidence
Grounded DORA workflow for starting the major-incident reporting clock, classifying ICT incidents, submitting initial, intermediate, and final reports, and preserving authority evidence.
DORA major ICT incident reporting: classification, reports, and timing
Source-grounded DORA guide to major ICT-related incident classification, initial notifications, intermediate and final reports, competent authority routing, and significant cyber threat notifications.
DORA major ICT incident thresholds: what triggers reporting?
FAQ on DORA major ICT-related incident classification thresholds, recurring incidents, reporting triggers, and evidence inputs grounded in EU DORA RTS and ITS texts.
DORA Register of Information FAQ: ICT Third-Party Arrangements
FAQ on the DORA register of information: who maintains it, which ICT third-party arrangements it covers, template fields, critical functions, reporting, data quality, and evidence.
DORA Register of Information Import and Build Workflow
Build a DORA register of information from procurement, vendor, contract, service, function, and subcontractor data using the official register templates and validation checks.
DORA Register of Information Template: ICT Provider Fields and Evidence
A grounded DORA register of information template for ICT third-party contracts, provider hierarchy, critical functions, dates, statuses, reporting, and evidence.
DORA TLPT selection: who can be required to test?
FAQ on DORA threat-led penetration testing selection: who identifies financial entities, what criteria are used, what the TLPT authority validates, and what evidence to keep.
DORA vs EBA outsourcing guidelines: ICT third-party risk comparison
Compare binding DORA ICT third-party risk duties with the EBA/ESA outsourcing baseline for registers, critical functions, contracts, subcontracting, exit, incident reporting, and evidence.
DORA vs ISO 22301: ICT resilience and business continuity compared
Compare DORA's binding ICT operational resilience duties for financial entities with ISO 22301's business continuity management system requirements.
DORA vs ISO/IEC 27001: legal ICT resilience obligations and ISMS controls
Compare EU DORA and ISO/IEC 27001 across scope, governance, incident reporting, testing, ICT third-party risk, certification, evidence, overlap, and gaps.
DORA vs NIS2: financial-sector obligations, overlap, and evidence
Compare DORA and NIS2 for financial entities, ICT providers, incident reporting, management accountability, third-party risk, supervisory routes, and reusable evidence.
DORA vs PSD2 incident reporting: major ICT and payment incidents
Compare DORA major ICT-related incident reporting with PSD2 major operational or security payment incident reporting, including scope, triggers, report stages, recipients, and evidence.
EU DORA Applicability Test for Financial Entities and ICT Providers
A source-grounded DORA applicability test for financial-entity scope, ICT third-party services, critical or important functions, exclusions, proportionality, and evidence.
EU DORA Compliance Obligations and Evidence Guide
A source-grounded DORA compliance guide covering ICT risk management, incident reporting, resilience testing, TLPT, ICT third-party risk, registers, governance, oversight, and evidence.
EU DORA FAQ: scope, incidents, ICT contracts, testing, and evidence
Concise DORA FAQ covering who is in scope, proportionality, ICT third-party contracts, register-of-information records, major ICT incident thresholds and reporting, TLPT, testing, enforcement, and evidence.
EU DORA ICT risk management control baseline
A source-grounded DORA control baseline for ICT risk governance, asset and dependency mapping, protection, detection, response, recovery, testing, third-party risk, and evidence.
EU DORA ICT subcontracting chain controls for critical functions
DORA guide to ICT subcontracting chains for critical or important functions: prior assessment, contract conditions, register fields, monitoring, exit rights, and evidence.
EU DORA penalties and fines: enforcement powers and limits
Grounded guide to DORA enforcement: competent-authority powers, administrative penalties, remedial measures, publication rules, and Lead Overseer penalty payments for critical ICT third-party providers.
EU DORA Register of Information Data Model: templates, fields, and evidence
Field-level guide to the EU DORA register of information data model: templates B_01 to B_07, provider identifiers, contract links, subcontracting chains, critical-function assessments, dates, and export evidence.
EU DORA Requirements Overview: ICT risk, incidents, testing, and third-party risk
A grounded overview of the main EU DORA requirements for financial entities: governance, ICT risk management, incident reporting, resilience testing, TLPT, ICT third-party risk, register of information, oversight, proportionality, and evidence.
EU DORA Scope and Covered Entities: financial entities and ICT providers
Classify whether DORA applies to a financial entity, ICT third-party provider, group arrangement, branch, or critical ICT service dependency.
EU DORA Scope and Proportionality Workflow
Classify DORA covered entities, simplified-framework status, critical or important functions, ICT dependencies, evidence records, and governance approvals.
EU DORA testing and TLPT readiness guide
A grounded DORA guide for resilience testing, TLPT eligibility, authority interaction, test evidence, remediation plans, and avoiding unsupported testing cadence.
EU DORA TLPT eligibility workflow for financial entities
Check how DORA TLPT authorities identify financial entities for threat-led penetration testing and what evidence supports scope, readiness, providers, and governance.
EU DORA TLPT Runbook: scope, providers, reports, and remediation
Build a DORA threat-led penetration testing runbook around authority coordination, scope validation, provider controls, active testing, closure reports, remediation, and attestation.
How does proportionality work under EU DORA?
A grounded FAQ on DORA proportionality: what can be scaled, who may use the simplified ICT risk framework, what evidence supports the decision, and which duties cannot be waived.
How to build a DORA register of information
Build a DORA register of information from contracts, ICT services, providers, functions, subcontractors, risk assessments, audit evidence, exit plans, and export checks.