The DORA Regulation has been officially in application since January 17, 2025. For financial entities, 2026 represents the year of operational maturity, where it is no longer enough to have designed processes; you must demonstrate their effectiveness through solid documentary evidence. Compliance is not a static milestone: authorities require a continuous cycle of testing, remediation, and governance review. This guide provides an exhaustive DORA testing checklist to verify if your organization is ready for an internal audit or an inspection by supervisory authorities.

Governance Checklist

• The management body has formally approved the ICT risk management framework and the third-party risk strategy.
• The annual report on the review of the ICT risk management framework has been drafted and submitted to the authorities.
• Clear and approved ICT risk tolerance levels have been defined.
• A framework review procedure is in place, triggered by significant changes in the threat landscape or ICT assets.

Asset and Scoping Checklist

• A Register of Information (RoI) is present, complete with all contractual agreements with third-party ICT providers.
• All critical or important functions (CIFs) have been identified and mapped to the relevant ICT assets and providers.
• Every ICT asset has a clearly identified “owner” and a documented criticality classification.
• Interdependencies between assets, functions, and providers (including material subcontractors) have been mapped.

Vulnerability Management Checklist

• Vulnerability scans on assets supporting critical functions (CIFs) are performed at least weekly.
• An automated procedure exists for vulnerability detection across all ICT assets.
• The use of third-party libraries (including open source) is tracked and monitored for updates and patches.
• Patches are prioritized based on vulnerability criticality and the asset’s risk profile.
• A documented register exists that tracks the entire vulnerability lifecycle, from discovery to closure verification.

Penetration Testing Checklist

• The testing program includes appropriate security checks for systems exposed to the Internet.
• For entities subject to TLPT, tests are conducted on real “live production systems.”
• Testers (internal or external) meet the requirements for suitability, reputation, certification, and insurance coverage.
• Test results include a root cause analysis and a detailed remediation plan.

Business Continuity Checklist

• ICT business continuity plans are tested at least annually or after significant changes.
• Tests are based on severe but plausible scenarios, including cyberattacks and critical provider failure.
• Tests demonstrate the achievement of defined Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO).
• The program includes switchover tests to secondary sites or disaster recovery environments for a representative period.

Third-Party Checklist

• Due diligence has been performed on all ICT providers supporting critical functions before contract execution.
• Contracts with ICT providers include explicit clauses regarding audit rights and participation in security tests.
• Providers report critical vulnerabilities and risk statistics related to the services provided in a timely manner.
• The entity has visibility into material sub-providers involved in the CIF supply chain.

Audit Evidence Pack Checklist

• Policies and procedures: Asset management, vulnerabilities, incidents, and business continuity.
• Test reports: Weekly scan logs, pentest reports, and TLPT reports.
• Remediation plans: Documentation of corrective actions, deadlines, and closure verifications (retests).
• Certifications and CVs: Evidence of the skills and independence of the testers involved.
• Register of information: Template updated according to ITS standards.
• Incident management reports: Initial notifications, interim reports, and final reports on major ICT incidents.

FAQ

• What documents must the company be able to present?
• In addition to approved policies, technical test reports, signed remediation plans, vulnerability registers, and evidence of third-party provider monitoring are vital.
• How to demonstrate that testing is risk-based?
• Through the documentation of the Business Impact Analysis (BIA) and asset classification, which justify why certain systems are tested more frequently or with more invasive methodologies.
• What is most often missing in DORA programs?
• The most common shortcomings concern the lack of remediation verification (retests), the absence of visibility into material sub-providers, and insufficient frequency (not weekly) of scans on critical systems.

Ensure your compliance for 2026: request a DORA Audit Readiness Assessment today to identify gaps in your testing program and secure your cybersecurity evidence.