DORA Compliance Checklist: ICT Risk Management for Financial Entities
DORA Compliance Checklist: Requirements, Evidence, and Implementation Priorities
The Digital Operational Resilience Act, Regulation (EU) 2022/2554, known as DORA, is the EU’s dedicated operational resilience framework for the financial sector. It entered into force on 16 January 2023 and has applied since 17 January 2025.
DORA applies directly across EU Member States as an EU regulation. However, national rules remain relevant for supervision, competent authority powers, administrative penalties, and related sector-specific implementation measures.
DORA establishes a harmonised framework for digital operational resilience. Its purpose is to ensure that financial entities can withstand, respond to, and recover from ICT-related disruptions, including cyberattacks, technology failures, third-party outages, data integrity issues, and incidents affecting critical or important functions.
This checklist covers the five core pillars of DORA:
ICT risk management
ICT-related incident management and reporting
Digital operational resilience testing
ICT third-party risk management
Information sharing arrangements
A proportionality principle applies: microenterprises (fewer than 10 employees and under €2M turnover) are subject to a simplified ICT risk management framework.
Source: DORA Regulation, Article 2
DORA applies to a broad range of regulated financial entities in the EU, including:
credit institutions and banks
payment institutions
electronic money institutions
account information service providers
investment firms
crypto-asset service providers
central securities depositories
central counterparties
trading venues
trade repositories
managers of alternative investment funds
UCITS management companies
insurance and reinsurance undertakings
insurance intermediaries, reinsurance intermediaries, and ancillary insurance intermediaries, subject to relevant exclusions
institutions for occupational retirement provision
credit rating agencies
administrators of critical benchmarks
crowdfunding service providers
securitisation repositories
data reporting service providers
DORA also establishes an EU-level oversight framework for critical ICT third-party service providers, known as CTPPs.
These are ICT providers designated by the European Supervisory Authorities because of their systemic importance to the EU financial sector.
The regulation applies proportionately. Smaller and less complex entities may be subject to simplified or proportionate requirements, while larger, more complex, or systemically important entities face more demanding expectations, including advanced resilience testing.
Pillar 1: ICT Risk Management Framework
DORA requires financial entities to establish, maintain, and continuously improve a comprehensive ICT risk management framework. This framework must be documented, approved, monitored, and integrated into the entity’s overall risk management system.
The ICT risk management framework should cover governance, asset management, risk identification, protection and prevention, detection, response and recovery, learning and improvement, and communication.
Management Body Responsibilities
DORA places clear accountability on the management body. Senior leadership must:
define, approve, oversee, and remain accountable for the ICT risk management framework
set the entity’s risk tolerance for ICT risk
approve and periodically review ICT business continuity policies and ICT disaster recovery plans
allocate adequate budget, resources, and capabilities for digital operational resilience
approve and review arrangements with ICT third-party service providers supporting critical or important functions
receive regular reporting on ICT risk, incidents, testing results, and remediation status
maintain sufficient knowledge and skills to understand and assess ICT risk
This makes DORA a board-level governance obligation, not a purely technical IT project.
Required ICT Risk Management Elements
Requirement | Practical actions | Evidence |
|---|---|---|
ICT risk management strategy | Define governance, ICT risk appetite, roles, responsibilities, and risk ownership | ICT risk strategy, board minutes, governance model |
ICT asset identification | Maintain an inventory of ICT assets, information assets, systems, dependencies, and critical or important functions | Asset register, CMDB, dependency maps |
ICT risk assessment | Identify, classify, and assess ICT risks on a continuous basis | Risk register, assessment reports, treatment plans |
Protection and prevention | Implement proportionate controls, including access controls, encryption, network security, endpoint protection, backup, logging, and vulnerability management | Control documentation, configuration records, security policies |
Detection | Monitor anomalous activity, service degradation, unauthorised access, and potential compromise | SIEM records, monitoring alerts, detection use cases |
Response and recovery | Maintain ICT incident response, business continuity, and disaster recovery plans | IR plans, BCP/DRP documents, recovery procedures |
Learning and improvement | Capture lessons learned after incidents, tests, audits, and control failures | Post-incident reviews, remediation logs |
Communication | Define internal and external communication procedures for ICT incidents and crises | Communication plans, escalation matrix, contact lists |
Pillar 2: ICT-Related Incident Management and Reporting
DORA requires financial entities to establish a process for detecting, managing, classifying, recording, and reporting ICT-related incidents. All ICT-related incidents should be recorded internally. Major ICT-related incidents must be reported to the competent authority in line with DORA and the applicable technical standards.
Incident Classification
Financial entities must classify ICT-related incidents using criteria defined under DORA and the relevant Regulatory Technical Standards. Key classification criteria include:
number and relevance of clients, financial counterparts, and transactions affected
duration of the incident
geographical spread
data losses affecting availability, authenticity, integrity, or confidentiality
criticality of affected services
economic impact
reputational impact, where relevant
Reporting Timelines for Major ICT-Related Incidents
Stage | Deadline | Content |
|---|---|---|
Initial notification | As early as possible, and in any case within 4 hours from classification as major, but no later than 24 hours from becoming aware of the incident | Basic incident information, affected services, initial impact, known facts |
Intermediate report | No later than 72 hours from submission of the initial notification | Updated assessment, impact, mitigation progress, current status |
Updated intermediate report | Without undue delay after regular activities have recovered, where applicable | Recovery status and additional information |
Final report | No later than one month after the intermediate report or updated intermediate report | Root cause analysis, final impact assessment, remediation, lessons learned |
DORA’s reporting framework is more prescriptive than the general NIS2 reporting model for the financial sector. The 4-hour initial notification window starts from classification of the incident as major, while the outer limit is 24 hours from awareness of the incident.
Practical Actions
Financial entities should:
implement incident classification procedures aligned with DORA and the applicable RTS
define ownership for classification, escalation, notification, and regulatory communications
build automated deadline tracking for 4-hour, 72-hour, and final-report obligations
maintain secure communication channels with the competent authority
keep an internal incident register covering all ICT-related incidents
conduct post-incident reviews and track remediation to closure
define procedures for voluntary notification of significant cyber threats, where relevant
Pillar 3: Digital Operational Resilience Testing
DORA requires financial entities to test their digital operational resilience regularly. Testing must be risk-based and proportionate to the entity’s size, risk profile, ICT maturity, and operational complexity.
Financial entities, other than microenterprises, must establish and maintain a digital operational resilience testing programme.
General Testing Requirements
The testing programme should include, where appropriate:
vulnerability assessments and scans
open-source analysis
network security assessments
physical security reviews
gap analysis
source code reviews, where feasible
scenario-based testing
compatibility testing
performance testing
end-to-end testing
penetration testing
ICT systems and applications supporting critical or important functions should be tested at least annually.
Threat-Led Penetration Testing
DORA introduces advanced testing through Threat-Led Penetration Testing, or TLPT. TLPT applies to financial entities identified by competent authorities based on criteria such as systemic importance, ICT risk profile, ICT maturity, and relevance to the financial system. Entities in scope for TLPT must generally perform these tests at least every three years. TLPT covers several or all critical or important functions and is carried out under strict governance and supervisory expectations.
Practical Actions
Financial entities should:
define an annual digital operational resilience testing programme
identify systems supporting critical or important functions
document test scope, methodology, responsibilities, and independence requirements
prioritise and remediate findings
validate remediation effectiveness
prepare for TLPT if the entity may be designated by the competent authority
retain test reports, remediation evidence, and management reporting records
Pillar 4: ICT Third-Party Risk Management
DORA significantly strengthens ICT third-party risk management across the financial sector. Financial entities remain responsible for compliance even when ICT services are provided by external suppliers.
This pillar is especially important for organisations relying on cloud services, managed security providers, core banking systems, data platforms, software vendors, and outsourced operational technology.
Contractual Requirements
Contracts with ICT third-party service providers must include clear and enforceable provisions. Depending on the nature and criticality of the service, agreements should cover:
clear description of ICT services and service levels
locations where data is processed and stored
data protection and confidentiality obligations
availability, authenticity, integrity, and confidentiality requirements
access, audit, and inspection rights
incident notification obligations
business continuity and disaster recovery commitments
subcontracting conditions
termination rights
exit strategies and transition support
cooperation with competent authorities and resolution authorities, where relevant
For ICT services supporting critical or important functions, DORA requires more detailed contractual safeguards.
Register of Information
Financial entities must maintain a register of information covering contractual arrangements with ICT third-party service providers.
The register should include, among other elements:
service provider identification
type of ICT services provided
contractual dates and renewal details
criticality assessment
functions supported
data locations
subcontracting arrangements
group-level and entity-level relationship data
This register must be available to competent authorities and prepared in line with the applicable implementing technical standards.
Critical ICT Third-Party Providers
DORA establishes an EU-level oversight framework for critical ICT third-party service providers. The European Supervisory Authorities designate CTPPs and assign Lead Overseers. These Lead Overseers may assess governance, risk management, security, continuity, and resilience measures of designated providers.
On 18 November 2025, the European Supervisory Authorities published the first list of designated critical ICT third-party service providers at Union level.
Financial entities should consider CTPP oversight outcomes, concentration risks, recommendations, and dependencies in their own ICT third-party risk management.
Practical Actions
Financial entities should:
maintain a complete ICT third-party register
classify ICT providers by criticality and supported functions
review existing contracts against DORA Article 30 requirements
implement exit strategies for critical or important ICT services
monitor subcontracting chains
assess concentration risk across cloud, infrastructure, security, software, and data providers
integrate third-party risk into the ICT risk management framework
prepare evidence for supervisory review
Pillar 5: Information Sharing
DORA encourages financial entities to exchange cyber threat information and intelligence. This may include:
indicators of compromise
tactics, techniques, and procedures
cyber threat alerts
vulnerabilities
defensive measures and mitigation techniques
Information sharing should take place within trusted communities and must respect confidentiality, competition law, data protection, and business secrecy requirements.
For most financial entities, information sharing is encouraged rather than mandatory. However, participation can improve early warning, threat detection, and sector-level resilience.
Practical Actions
Financial entities should:
evaluate participation in financial sector information sharing communities, such as FS-ISAC, national CERTs, sectoral ISACs, or supervisory initiatives
define internal rules for receiving, validating, sharing, and acting on threat intelligence
document confidentiality safeguards
record participation and threat intelligence actions
integrate threat intelligence into detection, testing, and risk assessment processes
DORA vs NIS2: How They Relate
Financial entities often need to assess the relationship between DORA and NIS2.
NIS2 includes a lex specialis principle. Where a sector-specific EU legal act imposes cybersecurity requirements that are at least equivalent in effect, that sector-specific act takes precedence for the relevant obligations. For financial entities, DORA is the primary framework for ICT risk management, ICT incident reporting, digital operational resilience testing, and ICT third-party risk management.
This does not mean that financial entities should disregard NIS2 entirely. They should verify whether any national NIS2 obligations apply outside the areas fully covered by DORA.
Aspect | DORA | NIS2 |
|---|---|---|
Scope | Financial sector entities and critical ICT third-party providers | Essential and important entities across multiple sectors |
Legal form | EU regulation, directly applicable | EU directive, transposed into national law |
Primary focus | Digital operational resilience in financial services | Cybersecurity risk management across critical sectors |
Incident reporting | Initial notification within 4 hours from major classification, no later than 24 hours from awareness; intermediate report within 72 hours; final report after intermediate or updated intermediate report | Early warning within 24 hours; incident notification within 72 hours; final report generally within one month |
Testing | Mandatory digital operational resilience testing, including TLPT for selected entities | Effectiveness assessment of cybersecurity risk management measures |
Third-party risk | Detailed ICT third-party risk framework and direct ESA oversight of CTPPs | Supply chain security requirements |
Relationship | Sector-specific framework for finance | General cybersecurity framework |
Practical implication: if an organisation is a financial entity within DORA’s scope, DORA should be treated as the primary compliance framework for digital operational resilience. NIS2 should still be assessed for residual or national obligations not fully covered by DORA.
Implementation Timeline
Date | Milestone |
|---|---|
14 December 2022 | DORA adopted as Regulation (EU) 2022/2554 |
16 January 2023 | DORA entered into force |
17 January 2025 | DORA became applicable; in-scope entities required to comply |
2024–2025 | Key technical standards adopted and published, including standards on ICT risk management, incident classification, incident reporting, and register of information templates |
18 November 2025 | European Supervisory Authorities published the first list of designated critical ICT third-party service providers |
2025–2026 | Supervisory implementation, register collection, CTPP oversight, and regulatory clarification continue |
Ongoing | Competent authorities conduct supervision, reviews, inspections, and enforcement activities |
DORA is already applicable. Financial entities that have not implemented the required governance, risk management, incident reporting, testing, and third-party controls may be exposed to supervisory action.
Penalties and Supervisory Measures
DORA gives competent authorities supervisory, investigatory, and sanctioning powers. Member States define administrative penalties and remedial measures, which must be effective, proportionate, and dissuasive.
Competent authorities may require remediation, impose administrative measures, conduct inspections, request information, and take further supervisory action.
For critical ICT third-party providers, DORA includes a specific periodic penalty mechanism. A Lead Overseer may impose periodic penalty payments of up to 1% of the provider’s average daily worldwide turnover in the preceding business year, calculated daily for up to six months, in cases of non-compliance with relevant oversight measures.
How Quantifier Supports DORA Compliance
Quantifier.ai helps financial organisations manage DORA compliance alongside other frameworks such as NIS2, ISO 27001, SOC 2, GDPR, and ESG-related requirements.
Key capabilities include:
ICT risk management framework: centralised risk register, ownership, control mapping, and DORA-specific risk taxonomy
Incident management workflows: classification, escalation, evidence capture, and deadline tracking for DORA reporting
ICT third-party register: provider inventory, risk scoring, contract tracking, criticality assessment, and subcontracting visibility
Multi-framework mapping: alignment of DORA requirements with ISO 27001, NIS2, SOC 2, and internal control frameworks
Resilience testing tracking: scheduling, documenting, and remediating results from vulnerability assessments, penetration tests, scenario tests, and TLPT readiness activities
Audit-ready documentation: evidence packages for supervisory reviews, internal audits, and external assessments
Management reporting: dashboards for control status, risk exposure, remediation progress, and board-level oversight
Book a demo to see how Quantifier supports DORA readiness, evidence management, and ongoing compliance monitoring.
Frequently Asked Questions
When did DORA compliance start?
DORA entered into force on 16 January 2023 and became applicable on 17 January 2025. In-scope financial entities must comply with the regulation now.
Does DORA replace NIS2 for financial entities?
DORA acts as lex specialis for financial entities in areas where it imposes equivalent or more specific cybersecurity and digital resilience requirements. In practice, financial entities should treat DORA as the primary framework for ICT risk management, incident reporting, resilience testing, and ICT third-party risk management. They should still check whether any residual national NIS2 obligations remain applicable.
What are the penalties for DORA non-compliance?
For financial entities, competent authorities may impose administrative penalties and remedial measures under national rules. DORA requires those penalties to be effective, proportionate, and dissuasive.
For critical ICT third-party providers, the Lead Overseer may impose periodic penalty payments of up to 1% of average daily worldwide turnover for certain oversight non-compliance.
Does DORA apply to ICT vendors that serve banks?
DORA applies directly to financial entities. ICT vendors are affected through contractual, due diligence, audit, reporting, and exit requirements imposed on financial entities.
ICT providers designated as critical ICT third-party service providers are also subject to direct EU-level oversight by the European Supervisory Authorities.
Is ISO 27001 sufficient for DORA?
ISO 27001 provides a strong foundation for information security governance, risk management, controls, and continual improvement. However, DORA includes legal and operational requirements that go beyond ISO 27001, including major ICT incident reporting timelines, register of information requirements, DORA-specific ICT third-party contractual clauses, management body accountability, supervisory reporting, and TLPT obligations for selected entities.
Does DORA require annual testing?
For financial entities other than microenterprises, DORA requires a digital operational resilience testing programme. ICT systems and applications supporting critical or important functions should be tested at least yearly. More advanced TLPT applies to selected financial entities identified by competent authorities.