Who needs TLPT under DORA? Mapping the technical criteria

This article is for informational purposes only and does not constitute legal advice. Consult a qualified legal professional for advice specific to your situation.

The distinction the regulation draws

DORA’s testing pillar is structured in two tiers. The first tier applies to every in-scope financial entity: basic testing covering vulnerability assessments, network security reviews, and gap analyses conducted at least annually. The second tier, threat-led penetration testing, applies only to entities that their national competent authority designates for it.

That distinction matters. TLPT is substantially more demanding than basic testing in scope, cost, and operational complexity. It requires engagement with accredited external testers, coordination with the competent authority throughout the process, and coverage of live production systems rather than isolated test environments. It is not a more intense version of an annual penetration test. It is a red-team exercise designed to simulate the full tactics, techniques, and procedures of advanced threat actors operating against the firm’s actual infrastructure.

Understanding the designation criteria is therefore not an academic exercise. A firm that incorrectly assumes it will not be designated and has not prepared for the TLPT process faces a significant operational challenge when it receives formal notification. A firm that correctly anticipates likely designation can begin building the organisational capability well before the notification arrives.

The legal instruments that govern TLPT under DORA

The DORA framework regulation (Regulation (EU) 2022/2554, CELEX: 32022R2554) establishes the TLPT obligation at Articles 26 and 27. The operational detail, including the designation criteria, the tester accreditation requirements, and the conduct of the test, is specified in the RTS on TLPT developed by the Joint Committee of the European Supervisory Authorities under the mandate at Article 26(11) of the regulation.

Article 26(11) required the ESAs to submit those draft RTS to the Commission by 17 July 2024. The Commission adopted the TLPT RTS on 13 February 2025, published as Commission Delegated Regulation (EU) 2025/1190 (CELEX: 32025R1190). That adopted instrument is the operative document for any firm seeking to understand whether it meets the designation criteria and what a compliant TLPT looks like in practice. References to the TIBER-EU framework in DORA and in the RTS are references to the methodology developed by the European Central Bank, which the RTS adopts and adapts for the DORA context.

The designation criteria in the final RTS

The RTS does not establish a bright-line threshold that automatically designates any entity meeting a specific size or revenue figure. It establishes a set of criteria that competent authorities must consider, alongside a process for notifying designated entities and an expectation that designations are reviewed on a rolling basis.

The three primary criteria are systemic importance, operational profile, and ICT risk exposure.

Systemic importance is assessed in terms of the entity’s role in the financial system of the relevant member state and, where relevant, at EU level. Indicators include the entity’s balance sheet size, its market share in critical financial services, its role in payment and settlement infrastructure, and whether its disruption would have material spillover effects on other financial entities or on market functioning. Central counterparties, central securities depositories, and systemically important credit institutions are the clearest cases. Payment institutions and investment firms at the smaller end of the market are the clearest non-cases. The middle of the distribution requires a more granular assessment.

Operational profile captures the nature of the entity’s ICT reliance rather than its size alone. An entity that depends on a small number of highly critical ICT systems for functions with no manual fallback has a higher-risk operational profile than a comparably sized entity with more diversified systems and operational continuity options. The assessment considers whether the entity provides services that other financial entities rely on, whether it operates infrastructure that connects to payment systems or clearing networks, and whether its ICT failure would immediately affect end clients at scale.

ICT risk exposure looks at the firm’s external threat surface. Factors include the sensitivity of the data the entity holds, the degree to which the entity’s systems are internet-facing or connected to third-party networks, the entity’s known threat profile based on supervisory awareness of incidents and near-misses, and the sophistication of threat actors assessed as likely to target firms of this type.

Competent authorities weight these criteria based on their national supervisory priorities and the risk profile of the financial sector under their supervision. The RTS requires them to document the basis for designation decisions and to notify entities in advance of the three-year testing window.

What size signals but does not determine

Size is a relevant factor in the designation assessment, but it is not the sole or even necessarily primary determinant. A mid-sized payment institution processing a high volume of retail payments may be designated because of its operational profile, even though its balance sheet does not reach thresholds associated with systemic importance. A large insurance undertaking may not be designated if its ICT operations are primarily administrative and its failure would not produce immediate contagion risk.

The RTS also addresses the position of subsidiaries and branches of groups operating across multiple member states. Where a group is subject to TLPT requirements across multiple jurisdictions, the competent authorities involved are expected to coordinate to avoid requiring substantially identical tests to be conducted separately in each jurisdiction. The cross-border recognition mechanism allows a test conducted in one member state, using the methodology required under the RTS, to satisfy the requirement in another member state where the same entity or group entity is in scope.

For EU subsidiaries of non-EU parent groups, the TLPT requirement applies to the EU entity in scope. The non-EU parent’s own testing programmes, even where they are sophisticated and well-documented, do not substitute for a DORA-compliant TLPT unless the competent authority explicitly accepts them through the cross-border recognition process.

The scope of the test: production systems and third parties

A DORA TLPT must be conducted against live production systems that support the critical or important functions identified in the entity’s ICT risk management framework. This is not optional. The methodology requires testing in the production environment precisely because that environment has characteristics, including specific integrations, data flows, and system configurations, that test environments do not replicate.

The production system requirement creates a tension that the pre-test phase is designed to manage. The test is conducted without prior warning to the operational and security teams who manage those systems, because the value of the exercise depends on observing how the entity actually responds to a realistic attack. The competent authority, the senior management team responsible for authorising the test, and the external testers have full knowledge. The operational teams being tested do not, until the TLPT formally concludes.

The third-party dimension is significant. DORA explicitly permits competent authorities to require that critical ICT third-party service providers be included within the scope of a TLPT. Where a critical function depends substantially on a third-party provider, excluding that provider from the test scope would leave a material gap in the resilience assessment. The RTS sets out the conditions under which this can be required and the cooperation obligations that the ICT third-party provider must meet.

This has direct implications for contract management. Firms that anticipate TLPT designation should ensure that their contracts with critical ICT third-party providers include explicit cooperation obligations for TLPT purposes. DORA’s minimum contractual provisions for critical function contracts include audit rights and incident cooperation obligations, but the TLPT cooperation requirement is more specific. Contracts that do not address TLPT explicitly may require renegotiation before a test can be scoped to include the relevant third-party systems.

Tester accreditation requirements

TLPT under DORA must be conducted by external testers who meet the accreditation criteria set out in the RTS. Internal resources cannot conduct a TLPT unassisted, though they may participate in specific elements of the test under the supervision of accredited external testers.

The accreditation criteria cover technical capability, independence, and professional standing. External testers must demonstrate relevant technical experience with advanced persistent threat simulations, knowledge of the TIBER-EU methodology, and the absence of conflicts of interest with the entity being tested.

The practical scarcity of accredited TLPT providers is a constraint that firms approaching their first test cycle should account for. The market for TIBER-EU accredited testers is not large relative to the number of designated entities across the EU. Lead times for engaging a provider and completing the pre-test preparation phases are substantial, given the scarcity of accredited providers and the requirements of the preparation phase. A firm that receives designation notification and begins looking for a tester immediately is already behind schedule relative to the testing window.

The three phases of a DORA-compliant TLPT

The TLPT methodology is structured in three phases, each with defined deliverables and governance requirements.

The preparation phase covers threat intelligence gathering, scoping, and the appointment of the test team. The external testers commission a threat intelligence report from a specialist provider, which profiles the advanced threat actors most likely to target the entity, the tactics and techniques they use, and the specific systems and functions they would seek to exploit. The scoping exercise then identifies which production systems and critical functions will be covered by the test, and the senior management authorisation is obtained.

The testing phase is the red-team exercise itself. The external testers execute attack scenarios derived from the threat intelligence, targeting the identified systems and functions. The entity’s operational and security teams respond to the attack as they would to a real incident, without knowledge that it is a test. This phase can run for several weeks in complex engagements.

The closure phase covers the formal handover of results, the remediation planning process, and the reporting to the competent authority. DORA requires that a completion certificate be issued by the competent authority following a satisfactory TLPT. That certificate is the mechanism through which cross-border recognition operates: a certificate issued in one member state can be presented to competent authorities in other member states as evidence of compliance with their TLPT requirement for the same entity.

What the results require

The TLPT produces a findings report that identifies vulnerabilities, gaps in detection capability, and weaknesses in the entity’s incident response. The RTS requires that the entity develop a remediation plan for findings assessed as material, and that the plan be submitted to the competent authority along with the test results.

Remediation is not an optional response to the findings. The test exists precisely to identify vulnerabilities in production systems. An entity that conducts a TLPT and does not act on the findings has satisfied the letter of the requirement while undermining its purpose. Competent authorities reviewing TLPT results will assess not only whether the test was conducted but whether the remediation process is credible.

The findings and remediation plan must also feed back into the entity’s ICT risk management framework. Vulnerabilities identified in TLPT are evidence of gaps in the risk identification and protection components of the framework. An entity that updates its TLPT remediation tracker without updating its risk framework has missed the connection that DORA’s testing pillar is designed to create.

Firms that are not designated

For DORA-subject financial entities that receive no designation notification from their competent authority, the testing obligation remains, but it is satisfied through the basic testing programme: annual vulnerability assessments and network security reviews, gap analyses, and scenario-based exercises. These do not require external tester accreditation, do not need to be conducted against production systems in the same way, and do not trigger the same reporting obligations to the competent authority.

Non-designated firms should nonetheless document the basis on which they assessed their TLPT designation status, particularly if they are at the upper end of the size or systemic importance range where designation is more likely. The absence of a designation notification is not the same as a formal confirmation that designation is not required. Maintaining a documented assessment reduces the risk of a compliance gap if the supervisory landscape evolves or if the firm’s operational profile changes in ways that bring it closer to the designation criteria.

For a full account of DORA’s testing pillar in context, including the basic testing requirements and the interaction with the ICT risk management framework, see DORA compliance checklist for financial entities.

Forseti monitors DORA implementing guidance, supervisory developments, and RTS updates continuously, anchored to verified official sources with full CELEX traceability. Start for free.

See also: What are regulatory technical standards and why do they matter more than the regulation itself? and DORA ICT third-party risk: what the contractual requirements actually require.