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. The programme should assess preparedness for ICT-related incidents, identify weaknesses, deficiencies, and gaps, and support prompt corrective measures.

The testing programme should be risk-based and reflect 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.

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 DORA Article 26 and the TLPT regulatory technical standard. 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.

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 must be usable by accountable technology, security, resilience, and risk owners. For each finding, it should describe the shortcoming, proposed remediation measures, prioritisation and expected completion, root cause analysis, responsible staff or functions, and risks associated with implementing or not implementing the measures.

Use this checklist to 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.