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:

1. define, approve, oversee, and remain accountable for the ICT risk management framework
2. set the entity’s risk tolerance for ICT risk
3. approve and periodically review ICT business continuity policies and ICT disaster recovery plans
4. allocate adequate budget, resources, and capabilities for digital operational resilience
5. approve and review arrangements with ICT third-party service providers supporting critical or important functions
6. receive regular reporting on ICT risk, incidents, testing results, and remediation status
7. maintain sufficient knowledge and skills to understand and assess ICT risk
8. This makes DORA a board-level governance obligation, not a purely technical IT project.

Required ICT Risk Management Elements

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

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.

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

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.

Related Articles

• NIS2 Directive: Compliance Requirements & Implementation Guide — DORA and NIS2 share incident-reporting obligations; learn how they align.
• NIS2 vs ISO 27001: Control Mapping Guide — Map DORA controls alongside NIS2 and ISO 27001.
• Audit Evidence Automation — Automate evidence collection across DORA, NIS2, and SOC 2 frameworks.