DORA Resilience Testing: TLPT and Operational Resilience

Article 24 requires all financial entities — except microenterprises operating under the simplified framework of Article 16 — to establish, maintain, and review a sound and comprehensive digital operational resilience testing programme. This programme must be an integral part of the ICT risk management framework and is designed to assess the preparedness of the entity to handle ICT-related incidents, identify weaknesses, deficiencies, and gaps, and promptly implement corrective measures.

The testing programme must be proportionate to the size and overall risk profile of the financial entity, and to the nature, scale, and complexity of its services, activities, and operations. Article 24(2) requires entities to adopt a risk-based approach to testing, prioritising ICT systems and applications that support critical or important functions. The programme must include a range of tests and assessments, from basic vulnerability scanning to advanced scenario-based testing.

Article 24(6) specifies that financial entities must ensure that tests are undertaken by independent parties — whether internal or external. Where internal testers are used, the entity must ensure that they have sufficient resources, are free from conflicts of interest, and that the results are subject to independent validation. All significant findings must be reported to the management body and remediated in a timely manner, with the remediation process tracked and verified.

Article 25 sets out the range of tests that must form part of every financial entity's digital operational resilience testing programme. These basic testing requirements apply to all in-scope entities (with proportionality adjustments for smaller entities) and must be conducted at least annually for ICT systems and applications supporting critical or important functions.

The tests and assessments enumerated in Article 25(1) include: vulnerability assessments and scans, open-source software analysis, network security assessments, gap analyses against relevant standards and guidelines, physical security reviews, questionnaires and scanning software solutions, source code reviews where feasible, scenario-based tests including stress testing and simulations, compatibility testing, performance testing, end-to-end testing, and penetration testing.

Article 25(2) clarifies that not all listed tests must be performed every year on every system — entities must apply a risk-based approach, prioritising systems that support critical or important functions and rotating through less critical systems over multi-year cycles. However, ICT systems that support critical or important functions must be tested annually. Article 25(3) requires financial entities to implement procedures and policies to prioritise, classify, and address all issues revealed during the testing, including by establishing internal validation methodologies to ascertain that all identified weaknesses, deficiencies, or gaps are fully remediated.

Article 26 introduces the most rigorous testing requirement under DORA: threat-led penetration testing (TLPT). Unlike basic testing, TLPT is not required of all financial entities — it is mandatory only for entities identified by competent authorities based on criteria including systemic importance, the criticality of their ICT-supported functions, and the specific ICT risk profile of the entity.

TLPT must be carried out at least every three years and must cover several or all critical or important functions of the financial entity, as determined in agreement with the competent authority. The testing must be performed on live production systems — not test environments — to provide a realistic assessment of the entity's ability to withstand advanced persistent threats. Article 26(3) specifies that each TLPT must cover the entity's critical or important functions and must be performed using the TIBER-EU framework (Threat Intelligence-Based Ethical Red-Teaming) or an equivalent national framework recognised by the competent authority.

A key requirement of Article 26(8) is that TLPT must involve external testers for the red-team execution phase. Financial entities may use internal testers only for the threat intelligence phase and only where specific conditions are met — including the absence of conflicts of interest and the competent authority's approval. The scope, methodology, and results of each TLPT must be validated by the competent authority, and the financial entity must provide evidence that all critical findings have been remediated.

Article 27 establishes qualifications and independence requirements for testers conducting digital operational resilience tests, with particularly stringent requirements for TLPT testers. These requirements ensure that testing produces reliable, credible results that can support regulatory and management body decision-making.

For TLPT, Article 27(1) requires that external testers are used for the red-team execution phase. These external testers must: be of the highest suitability and reputability, possess technical and organisational capabilities specific to threat-led penetration testing, hold professional certifications (such as CREST, OSCP, or equivalent), be covered by professional indemnity insurance, and be free from conflicts of interest — including not having provided ICT audit, consulting, or development services to the financial entity within the previous two years.

For basic testing under Article 25, financial entities may use internal testers provided they have sufficient resources, there are no conflicts of interest, and the testing methodology meets recognised standards. Article 27(3) requires that whether internal or external testers are used, the competent authority must be satisfied that the tester is qualified. Article 27(5) addresses the specific case of TLPT for entities that use internal testers for the threat intelligence gathering phase: such use is permitted only with the competent authority's prior approval and only where the internal resources possess the necessary expertise.

Article 26(4) establishes a mutual recognition mechanism for TLPT results across EU jurisdictions. Where a financial entity operates in multiple member states, the TLPT results validated by the competent authority in one member state are recognised by competent authorities in other member states where the entity operates. This prevents financial groups from being required to conduct redundant, duplicative testing across each jurisdiction.

The mutual recognition principle is essential for the efficiency of the TLPT regime. Without it, a cross-border banking group might need to conduct separate TLPTs for each national entity — an exercise that would be prohibitively expensive and would not necessarily yield better security outcomes than a well-designed group-level test. Article 26(4) enables pooled testing: a financial group can coordinate a single TLPT covering the group's critical or important functions and have the results recognised across all jurisdictions where group entities operate.

The mutual recognition mechanism operates subject to conditions: the competent authorities of the jurisdictions concerned must agree on the scope and methodology of the pooled test, and the financial entity must ensure that the testing adequately covers the local specificities of each jurisdiction (such as locally deployed ICT systems or locally applicable regulatory requirements). Where competent authorities disagree on the adequacy of a pooled test, they may require additional testing for their jurisdiction-specific concerns.