EU DORA Testing and TLPT readiness

DORA requires financial entities other than microenterprises to establish, maintain, and review a digital operational resilience testing programme as part of the ICT risk management framework. Financial entities must use the programme to assess preparedness for ICT-related incidents, identify weaknesses, deficiencies, and gaps, and promptly implement corrective measures.

Microenterprises do not have the Article 24 programme duty, but Article 25(3) still requires them to perform appropriate ICT tests using a risk-based approach and strategic planning that balances resources, urgency, risk, and the criticality of information assets and services.

Financial entities must conduct the testing programme using a risk-based approach that reflects the entity's ICT risk profile, critical information assets, criticality of services, and the evolving ICT risk landscape. DORA lists examples of appropriate tests, including vulnerability assessments and scans, open source analyses, network security assessments, gap analyses, physical security reviews, questionnaires, scanning software solutions, source code reviews where feasible, scenario-based tests, compatibility testing, performance testing, end-to-end testing, and penetration testing.

DORA and Delegated Regulation 2025/1190 are binding. The readiness inventories and evidence packs below are practical implementation records; they do not replace an authority's identification decision, scope validation, or attestation.

TLPT is not a label for every penetration test. DORA reserves advanced testing by means of threat-led penetration testing for financial entities identified under Article 26 and the TLPT regulatory technical standard. Microenterprises and the financial entities covered by Article 16(1) are outside this TLPT requirement. For other entities, the authority assessment considers impact, systemic character, financial-stability concerns, ICT risk profile, ICT maturity, technology features, critical services, interconnectedness, substitutability, and dependence on ICT systems and third-party or intra-group ICT services.

For readiness, keep a TLPT eligibility file even before a formal authority notification. It should explain whether the entity falls into a category that may be assessed for TLPT, which critical or important functions could be in scope, which live production systems support those functions, and which outsourced or contracted ICT services would need provider participation.

A financial entity identified for TLPT initiates the test after notification from the TLPT authority. Readiness should therefore focus on the documents and approvals that the authority or test managers will validate, not on a generic internal testing calendar.

The TLPT process relies on a control team lead, a control team, test managers, a threat intelligence provider, testers, a blue team that remains unaware of the test, and authority involvement in each phase. The financial entity should be ready to preserve secrecy while still informing the management body of progress and associated risks.

The financial entity must submit the initiation information listed in Article 9 of Delegated Regulation 2025/1190 within three months after receiving the TLPT authority's notification. That filing starts the formal preparation record; it does not replace later validation of the control team, approval of the scope specification, targeted threat intelligence report, and red team test plan, or authority review of provider evidence.

DORA testing evidence should lead to corrective action. For the general testing programme, keep procedures for prioritising, classifying, remedying, and validating issues found during tests. For TLPT, the evidence set is more structured because the closure phase produces red team, blue team, summary, remediation, and attestation records.

The TLPT remediation plan should be usable by accountable technology, security, resilience, and risk owners. For each finding, it must describe the shortcoming, proposed remediation measures, prioritisation and expected completion, root cause analysis, responsible staff or functions, and risks associated with not implementing and, where relevant, implementing the measures.

This checklist helps review whether the page's evidence set would make sense to a supervisor, auditor, or management body. It deliberately avoids unsupported dates and invented thresholds: use DORA's testing requirements, the TLPT authority's identification and notification, and the TLPT RTS process records as the anchors.

The strongest readiness file shows the difference between routine resilience testing, penetration testing, and authority-supervised TLPT, then connects every finding to ownership, remediation, and validation.