Checklist

DORA Compliance Checklist for 2026: 50 Requirements Every Financial Entity Must Meet

Rui Tanitkan
February 14, 2026
18 min read

How to Use This Checklist

DORA (Digital Operational Resilience Act) became fully applicable on January 17, 2025. If you're a financial entity or crypto-asset service provider in the EU, you should already be compliant. If you're not, you have a problem.

This checklist breaks down DORA's requirements into practical, assessable items. Use it to:

  • Audit your current compliance status
  • Identify gaps requiring immediate attention
  • Prioritize remediation efforts
  • Prepare for regulatory examinations

Each section corresponds to a pillar of DORA. Check off items you've completed, note items in progress, and flag items that need work.

---

Pillar 1: ICT Risk Management Framework

The foundation of DORA compliance is a comprehensive ICT risk management framework. This isn't about having documents on a shelf. It's about operational practices.

Governance and Organization

**Management body has defined and approved ICT risk strategy**

DORA Article 5 places ultimate responsibility on the management body. They must approve the ICT risk management framework and bear responsibility for its implementation.

**ICT risk management function is established and independent**

A dedicated function responsible for ICT risk management, with appropriate independence from ICT operations. Smaller entities may combine this with other control functions.

**Roles and responsibilities for ICT risk are clearly defined**

Documented assignment of ICT risk responsibilities across the organization, including clear escalation paths.

**Regular ICT risk reporting to management body**

At least annual reporting on ICT risk status, though most entities need quarterly or more frequent updates.

**Adequate budget allocated for ICT risk management**

Resources sufficient to achieve digital operational resilience, including investments in security, training, and testing.

**ICT risk management policy is documented and approved**

A comprehensive policy covering all aspects of ICT risk management, approved by management body, reviewed at least annually.

Risk Identification and Assessment

**Complete inventory of all ICT assets maintained**

Hardware, software, systems, networks, and data assets. Include cloud services and third-party provided ICT.

**ICT-supported business functions identified and classified**

Which business processes depend on which ICT systems? Classification by criticality and sensitivity.

**ICT risks identified and documented**

Systematic identification of threats and vulnerabilities affecting your ICT assets and business functions.

**Risk assessment completed and documented**

Assessment of likelihood and impact for identified risks. Include scenario analysis.

**ICT risk tolerance defined by management body**

What level of ICT risk is acceptable? Documented thresholds that trigger escalation.

**Dependencies on ICT third-party providers mapped**

Clear understanding of reliance on external providers, including substitutability assessments.

**Risk assessment updated at least annually**

Or more frequently when significant changes occur to systems, threats, or business functions.

Protection and Prevention

**Information security policies established**

Comprehensive policies covering data classification, access control, encryption, and security standards.

**Access control and identity management implemented**

Least privilege access, strong authentication (MFA for critical systems), regular access reviews.

**Network security measures in place**

Segmentation, firewalls, intrusion detection/prevention, monitoring.

**Encryption standards defined and implemented**

Encryption of data at rest and in transit for sensitive information. Key management procedures.

**Physical security controls for ICT assets**

Server rooms, data centers, critical infrastructure protected against physical threats.

**Patch management process operational**

Timely application of security patches. Documented procedures for testing and deployment.

**Secure development practices for in-house software**

Secure coding standards, code review, security testing before deployment.

**Malware protection deployed across all systems**

Antivirus/antimalware on endpoints and servers, regular updates, monitoring.

**Data backup procedures implemented**

Regular backups of critical data and systems. Offsite/offline copies for ransomware resilience.

Detection

**Continuous monitoring of ICT systems operational**

Security information and event management (SIEM), log collection and analysis, alerting.

**Anomaly detection mechanisms in place**

Behavioral analytics, baseline monitoring, detection of unusual activities.

**Vulnerability scanning performed regularly**

At least quarterly scanning of external-facing systems, more frequent for critical assets.

**Threat intelligence integrated into detection**

Information on current threats, attack techniques, and indicators of compromise.

**Monitoring coverage verified for all critical systems**

Gaps in monitoring identified and addressed.

Response and Recovery

**ICT incident response procedure documented**

Clear steps for responding to incidents, including roles, communications, and escalation.

**Incident response team identified and trained**

Named individuals with defined responsibilities, regular training and exercises.

**Communication plan for ICT incidents**

Internal notifications, regulatory reporting, client communications, media handling.

**ICT business continuity policy established**

Approved by management body, covering all critical functions.

**Recovery time objectives (RTO) defined for critical functions**

Maximum acceptable downtime for each critical function, aligned with business requirements.

**Recovery point objectives (RPO) defined for critical data**

Maximum acceptable data loss, informing backup frequency requirements.

**Disaster recovery plans documented and tested**

Technical procedures for recovering systems and data following disruptive events.

**Crisis management procedures in place**

Decision-making during major incidents, including authority to invoke business continuity plans.

**Backup restoration tested successfully**

Not just backup procedures, but verified ability to restore from backups.

---

Pillar 2: ICT Incident Management and Reporting

DORA creates a harmonized incident reporting framework across the EU financial sector.

Incident Detection and Classification

**ICT incident detection capability operational**

Systems and processes to detect ICT incidents, including security events.

**Incident classification criteria defined per DORA requirements**

Classification based on: clients affected, duration, geographic spread, data losses, economic impact, criticality of services.

**Process to determine if incident is "major" documented**

Clear criteria aligned with DORA and regulatory technical standards for identifying reportable incidents.

**Incident logging system in place**

All ICT incidents recorded with sufficient detail for analysis and reporting.

Incident Reporting

**Regulatory reporting procedure documented**

Steps for notifying competent authority of major incidents within required timeframes.

**Initial notification capability within 24 hours**

Ability to submit initial notification to competent authority within one business day of classifying incident as major.

**Intermediate report process within 72 hours**

Procedures for submitting intermediate reports with updated information.

**Final report process within one month**

Procedures for comprehensive final reports including root cause analysis.

**Templates and channels for regulatory reporting established**

Correct forms, submission portals, and contact details ready.

**Voluntary cyber threat reporting procedure defined**

Process for reporting significant cyber threats even if they don't result in incidents.

Post-Incident Analysis

**Root cause analysis conducted for major incidents**

Systematic analysis to understand why incidents occurred and how to prevent recurrence.

**Lessons learned process implemented**

Insights from incidents fed back into risk management and control improvements.

**Incident statistics tracked and reported to management**

Trends in incidents, response effectiveness, recovery times.

---

Pillar 3: Digital Operational Resilience Testing

DORA mandates testing of ICT systems to verify resilience.

Basic Testing (All Entities)

**Testing program established and documented**

Documented program covering all required testing activities with schedules.

**Vulnerability assessments performed at least annually**

Systematic identification of vulnerabilities in systems and configurations.

**Penetration testing conducted at least annually**

Active testing by qualified testers to identify exploitable vulnerabilities.

**Network security assessments completed**

Testing of network segmentation, firewall rules, and network security controls.

**Gap analysis against ICT security standards performed**

Assessment of compliance with applicable security frameworks and standards.

**Source code reviews conducted for critical applications**

Where feasible, review of in-house developed software for security issues.

**Scenario-based testing completed**

Testing against realistic scenarios including cyber attacks and system failures.

**Performance testing under stress conditions conducted**

Verification that systems can handle peak loads and adverse conditions.

**Compatibility testing performed**

Testing that systems work together correctly, especially after changes.

**End-to-end testing of critical business processes completed**

Testing complete processes from initiation to completion.

**Physical security testing performed**

Assessment of physical controls protecting ICT assets.

Advanced Testing (Significant Entities)

If your entity meets DORA's significance criteria, additional requirements apply:

**Threat-led penetration testing (TLPT) program established**

Program for TLPT at least every three years.

**TLPT scope covers all critical functions**

Testing scope includes live production environments supporting critical functions.

**TLPT conducted by qualified independent testers**

Internal or external testers meeting DORA qualification requirements.

**TLPT follows TIBER-EU framework**

Testing methodology aligned with the EU's threat intelligence-based testing framework.

**TLPT results reported to competent authority**

Summary results shared with your supervisory authority.

**Attestation received confirming compliant TLPT**

Formal attestation that testing met DORA requirements.

Testing Documentation

**Testing results documented and tracked**

Records of all testing activities, findings, and remediation.

**Remediation of testing findings tracked to completion**

Identified issues addressed within defined timeframes.

**Testing reported to management body**

Regular updates on testing activities and findings.

---

Pillar 4: ICT Third-Party Risk Management

DORA imposes extensive requirements for managing risk from ICT service providers.

Register of ICT Third-Party Providers

**Complete register of all ICT third-party providers maintained**

All providers of ICT services, not just "critical" ones.

**Register includes information required by DORA Article 28**

For each provider: services provided, locations, subcontracting, contractual dates.

**Register updated promptly when arrangements change**

New providers added, terminated providers removed, changes documented.

**Register available for competent authority inspection**

Ability to provide register to regulators on request.

Pre-Contractual Assessment

**Due diligence process for ICT providers documented**

Standard assessment before engaging new ICT providers.

**Risk assessment conducted for each ICT provider**

Assessment of risks associated with using each provider.

**Concentration risk assessed**

Evaluation of over-reliance on individual providers or provider characteristics.

**Critical or important functions identified**

Clear determination of which functions supported by third parties are critical or important.

Contractual Requirements

**ICT contracts reviewed against DORA Article 30 requirements**

Existing contracts assessed for compliance with mandatory contractual provisions.

**Service level agreements in place for ICT services**

Clear, measurable service levels for availability, performance, and security.

**Audit rights included in ICT contracts**

Right to audit provider or access audit reports.

**Exit strategy provisions in ICT contracts**

Provisions for transitioning away from provider, including data portability.

**Incident notification obligations in ICT contracts**

Requirement for provider to notify you of incidents affecting your services.

**Data protection provisions in ICT contracts**

Compliance with GDPR requirements for data processing.

**Subcontracting limitations in ICT contracts**

Controls on provider's ability to subcontract, notification requirements.

**Security requirements in ICT contracts**

Provider obligations for security measures, including specific standards.

Ongoing Monitoring

**Performance monitoring of ICT providers operational**

Regular assessment of provider service delivery against SLAs.

**Security monitoring of ICT providers operational**

Assessment of provider security posture, including review of certifications and audit reports.

**Annual review of critical ICT provider arrangements**

Comprehensive review of arrangements supporting critical functions.

**Exit plans for critical ICT providers tested**

Verification that exit strategies are viable.

---

Pillar 5: Information Sharing

DORA encourages voluntary information sharing about cyber threats.

**Decision made on participation in information sharing arrangements**

Management decision on whether to participate in threat sharing communities.

**If participating, confidentiality protections in place**

Appropriate protections for shared information.

**Process for contributing threat intelligence established**

If participating, procedure for sharing relevant threat information.

**Process for consuming shared intelligence established**

If participating, how shared intelligence feeds into your detection and response.

---

Additional Requirements for Specific Entities

Crypto-Asset Service Providers (CASPs)

If you're a CASP authorized under MiCA, DORA applies in full. Additional considerations:

**MiCA Article 68 ICT requirements addressed**

MiCA-specific ICT security requirements integrated with DORA framework.

**Crypto custody security measures implemented**

Enhanced security for systems holding crypto-assets.

**Wallet security procedures documented**

Hot/cold wallet policies, key management, transaction controls.

Trading Platforms and Exchanges

**Market abuse prevention integrated with ICT monitoring**

Detection of manipulation and abuse attempts through ICT systems.

**Trading system resilience tested**

Performance under extreme conditions, circuit breakers, failover.

---

Compliance Verification

Documentation

**All required policies documented and approved**

Policies listed in this checklist exist, are approved by appropriate authority, and are current.

**Evidence of control implementation available**

Documentation demonstrating controls are actually operating, not just documented.

**Training records maintained**

Records of staff training on ICT security and resilience procedures.

Self-Assessment

**Gap analysis against DORA requirements completed**

Systematic comparison of your practices against all DORA requirements.

**Remediation plan for identified gaps developed**

Prioritized plan to address compliance gaps with timelines and resources.

**Management body aware of compliance status**

Board/management informed of DORA compliance status and any gaps.

---

What Happens If You Fail?

Non-compliance with DORA isn't theoretical risk. Competent authorities have powers to:

  • Issue administrative sanctions and fines
  • Require remediation within defined timeframes
  • Restrict business activities until compliance achieved
  • Withdraw authorizations in severe cases

Beyond regulatory action, DORA non-compliance creates operational risk. The requirements exist because ICT failures and cyber attacks can destroy financial entities.

How FinlexPro Supports Your DORA Compliance

DORA contains 64 articles, but that's just the beginning. Compliance requires understanding:

  • Regulatory Technical Standards (RTS) on ICT risk management
  • Implementing Technical Standards (ITS) on incident reporting
  • RTS on threat-led penetration testing
  • RTS on ICT third-party register
  • Supervisory guidance from ESAs

FinlexPro indexes all of these documents. You can:

  • Search specific DORA requirements
  • Get AI explanations of technical provisions
  • Cross-reference with related regulations (MiCA, PSD2)
  • Access direct links to official sources

Turn this checklist into action with comprehensive regulatory research on FinlexPro.

Search Related Regulations

Use FinlexPro to find specific articles mentioned in this post.

Start Searching