DORA has applied since 17 January 2025 to the financial entities listed in Regulation (EU) 2022/2554. Compliance means operating—not merely designing—an ICT risk-management framework, major-incident process, resilience-testing programme, ICT third-party-risk controls, and register of contractual arrangements.
As of 8 August 2026, there is no general “readiness” phase left. Financial entities should be able to show current governance, tested procedures, complete evidence, and remediation. ICT providers may face demanding contracts and information requests, but being a supplier to a financial entity does not by itself make the supplier a DORA financial entity.
Quick answer
| Question | Answer |
|---|---|
| Who is directly in scope? | The categories of financial entity in DORA Article 2, subject to its exclusions and proportionality rules |
| Who is accountable? | The management body defines, approves, oversees, and is responsible for the ICT risk-management framework |
| Can ICT risk be outsourced? | Services can be outsourced; the financial entity remains fully responsible for compliance |
| What evidence is central? | Framework and policies, inventories, testing, incident records, contracts, due diligence, concentration-risk analysis, and the register of information |
| Is TLPT required for everyone? | No. Threat-led penetration testing applies to financial entities identified under Article 26 and the related technical standards |
| Where can support begin? | A DORA and financial-compliance assessment can map entities, critical functions, controls, contracts, and evidence gaps |
Confirm scope before applying the checklist
DORA Article 2 lists a broad set of regulated financial entities, including credit and payment institutions, electronic-money institutions, investment firms, central securities depositories, central counterparties, trading venues, insurers and intermediaries, pension institutions, crypto-asset service providers, crowdfunding providers, and certain other financial-market participants.
The list has qualifications and exclusions. Proportionality affects how requirements are implemented, and some smaller entities use a simplified ICT risk-management framework. Record:
- the regulated entity and authorisation;
- the relevant Article 2 category;
- any exclusion or simplified-framework basis;
- competent authorities;
- group and cross-border arrangements; and
- interaction with sectoral rules.
For financial entities, DORA is the sector-specific Union act for the NIS2 cybersecurity-risk-management and incident-reporting relationship described in DORA and NIS2. That does not erase other NIS2 obligations for entities that fall within its scope for other reasons.
Governance and accountability
The management body must define, approve, oversee, and remain responsible for the ICT risk-management framework. Evidence should show more than a policy signature:
- defined roles and segregation of duties;
- current knowledge and training;
- risk appetite and tolerance for ICT disruption;
- approval and review of continuity and response plans;
- oversight of audit findings and remediation;
- allocation of resources; and
- documented decisions concerning ICT third-party risk.
Operational teams can prepare dashboards and recommendations. The management body needs information that supports challenge and decisions, not a long list of unprioritised controls.
ICT risk-management framework
The framework should connect assets and services to business functions and risks. A workable evidence chain is:
- identify information and ICT assets, dependencies, configurations, and owners;
- classify supported functions and information;
- protect systems and data using proportionate controls;
- detect anomalous activity and incidents;
- respond, contain, communicate, and preserve evidence;
- recover services and reconcile data; and
- learn from incidents and tests, then update the framework.
Keep inventories aligned. A service missing from the asset inventory, business-impact analysis, vendor register, or recovery plan can make otherwise polished documents unreliable.
ICT-related incident management and reporting
Maintain one process that can:
- detect and log ICT-related incidents;
- classify them using the applicable DORA criteria;
- escalate major incidents;
- produce the required initial, intermediate, and final reports in the prescribed forms and timelines;
- coordinate customer, data-protection, law-enforcement, and other notifications where applicable; and
- document decisions when an event is not reportable.
Commission Implementing Regulation (EU) 2025/302 supplies the standard forms, templates, and procedures for major-incident reports and significant-cyber-threat notifications. Teams should use the competent authority's current submission channel and retain proof of submission.
Delegated Regulation (EU) 2025/301 sets the main reporting clocks. The initial notification is due as soon as possible and, in any event, within four hours after classification as major and no later than 24 hours after awareness; where classification occurs after 24 hours, the initial notification is due within four hours after classification. The intermediate report is due within 72 hours after the initial notification, and the final report within one month after the intermediate report or latest updated intermediate report. Apply the regulation's detailed rules for delays, weekends, updates, and reclassification.
A GDPR personal-data-breach assessment and a DORA major-incident assessment answer different legal tests. Run them in parallel when the facts engage both regimes.
Digital operational resilience testing
The testing programme should be risk-based and cover relevant systems supporting critical or important functions. Depending on risk and applicability, it can include:
- vulnerability assessments and scans;
- secure configuration reviews;
- scenario and tabletop exercises;
- end-to-end and recovery testing;
- source-code review where appropriate;
- penetration testing; and
- remediation validation.
Threat-led penetration testing is a separate advanced requirement for entities selected under Article 26. Selection, scope, testers, authorities, and mutual recognition are governed by DORA and its technical standards. Do not market an ordinary penetration test as DORA TLPT.
ICT third-party risk
Inventory and due diligence
Before contracting, identify the service, data, locations, subcontracting, supported functions, availability needs, security, exit constraints, and concentration risk. Classify whether the arrangement supports a critical or important function.
Contract requirements
Article 30 requires specified contractual provisions. Depending on the service, the agreement should address:
- services and service levels;
- locations of processing and storage;
- availability, authenticity, integrity, and confidentiality;
- access, recovery, and return of data;
- assistance during ICT incidents;
- cooperation with authorities;
- termination;
- training or awareness where relevant;
- reporting, audit, access, and inspection rights; and
- exit and transition for critical or important functions.
An ICT provider's NIS2 status does not remove the financial entity's DORA Articles 28–30 duties. The ESAs have expressly addressed that point in their Q&A material.
Concentration and exit
Assess substitutability, geographic and group concentration, common subcontractors, migration complexity, data portability, and the feasibility of exit. An exit plan should name triggers, owners, dependencies, data steps, testing, timing assumptions, and fallback arrangements.
Register of information
Financial entities must maintain a comprehensive register of contractual arrangements for ICT services at entity, sub-consolidated, and consolidated levels as applicable. The register supports internal risk management, supervision, and the ESAs' critical-provider designation process.
Treat it as a controlled data product:
- reconcile it to procurement, accounts payable, architecture, and vendor inventories;
- validate identifiers and hierarchy;
- connect contracts to functions and entities;
- document data-quality checks; and
- update it when arrangements change.
The 30 April 2025 date was the deadline for competent authorities to transmit collected register information to the ESAs for the first designation exercise. It was not a universal entity-to-authority annual filing date; follow the current request and channel of the relevant competent authority.
Critical ICT third-party providers
In November 2025, the European Supervisory Authorities published the first Union list of designated critical ICT third-party providers. Designation creates an EU oversight relationship for the provider. It does not transfer a financial entity's responsibility or replace its due diligence, contractual controls, monitoring, or exit planning.
Evidence checklist
- scope memo and entity mapping;
- management-body approvals, training, minutes, and challenge;
- current ICT risk framework and policies;
- asset, service, data, dependency, and function inventories;
- incident logs, classifications, submissions, and lessons learned;
- test plan, results, remediation, and retesting;
- ICT-provider due diligence and concentration analysis;
- Article 30 contract mapping and deviations;
- reconciled register of information;
- continuity, recovery, backup, and restore-test evidence; and
- open-risk decisions with owners and dates.
Frequently asked questions
Does DORA apply directly to every SaaS or cloud provider serving finance?
No. Direct DORA financial-entity scope comes from Article 2. Certain ICT providers can be designated as critical and overseen at Union level, while other providers are principally affected through customer due diligence and contracts.
Can an ISO 27001 certificate prove DORA compliance?
No. Certification can support evidence for some controls, but DORA contains governance, incident, testing, register, contractual, and supervisory requirements that need their own assessment.
Is a register spreadsheet enough?
The format must follow applicable templates, but completeness, reconciliation, governance, and update processes matter as much as the file. A structurally valid register can still be materially wrong.
Who approves residual ICT risk?
Follow the entity's governance and risk-appetite framework while preserving the management body's DORA accountability. High or accepted exceptions should be visible to the appropriate decision-maker.
Sources and review
This guide was substantively reviewed on 8 August 2026 against the DORA legal text and current ESA implementation material.
- Regulation (EU) 2022/2554 — Digital Operational Resilience Act
- Delegated Regulation (EU) 2024/1772 — incident-classification criteria
- Delegated Regulation (EU) 2025/301 — incident-reporting timelines and content
- Commission Implementing Regulation (EU) 2025/302 — incident-reporting forms and procedures
- Commission Implementing Regulation (EU) 2024/2956 — register-of-information templates
- Delegated Regulation (EU) 2025/1190 — threat-led penetration testing
- ESMA — DORA policy products and implementation resources
- EBA — preparations for DORA registers of information
- EBA — ESAs designate critical ICT third-party providers
- EIOPA — Joint ESA Q&A DORA 286 on ICT providers also subject to NIS2
For entity scoping, register validation, contract remediation, control testing, and management evidence, see Vision Compliance's financial compliance service.
Robert Lozo, mag. iur., is a Partner at Vision Compliance specializing in EU regulatory compliance. He advises organizations on GDPR, NIS2, AI Act, and financial regulation, delivering audit-ready documentation and compliance roadmaps across regulated industries.