DORA Threat-Led Penetration Testing: Who Must Test, How Often, and the Pooled-Testing Workaround

Under Article 26 of DORA, financial entities identified by their authority must run a threat-led penetration test (TLPT) on live production systems at least every 3 years. Commission Delegated Regulation (EU) 2025/1190, published in the Official Journal on 18 June 2025, sets out who is identified (for example, payment institutions above EUR 150 billion of payment transactions in each of the 2 preceding calendar years) and how each test runs. When including an ICT provider would put its non-financial customers at risk, DORA allows a pooled TLPT contracted directly by the provider. Here is the regime as it stands in October 2026.

What TLPT is, and how often it happens

DORA Article 3(17) defines TLPT as a framework that mimics the tactics, techniques and procedures of real-life threat actors, delivering a controlled, bespoke, intelligence-led (red team) test of the financial entity's critical live production systems. Recital 1 of RTS 2025/1190 says the RTS was drafted in accordance with the TIBER-EU framework, and entities may apply TIBER-EU or a national implementation insofar as it is consistent with DORA Articles 26 and 27 and the RTS.

• Frequency: at least every 3 years; the competent authority may ask an entity to reduce or increase the frequency based on its risk profile and operational circumstances (Article 26(1)).
• Scope: several or all critical or important functions, on live production systems, including functions outsourced to ICT third-party providers (Article 26(2)). The authority validates the scope.
• Who is excluded: microenterprises and entities under the Article 16(1) simplified framework.
• Distinct from basic testing: every financial entity other than a microenterprise must also test all ICT systems and applications supporting critical or important functions at least yearly (Article 24(6)).

Who must perform TLPT

The TLPT authority identifies entities based on impact, systemic character and ICT risk profile (Article 2(1) of the RTS). Article 2(2) then lists entities that must be required to test, unless the assessment shows TLPT is not justified:

For a US group, the test applies entity by entity in the EU: it is the EU-authorized bank, payment institution or insurer that is identified. Where several group entities share ICT systems or the same intra-group ICT provider, authorities decide whether individual testing is relevant and may prefer a joint TLPT (Articles 2(3) and 16(2) of the RTS).

How a TLPT unfolds, step by step

At the end, the authority issues an attestation that the test met the requirements, which supports mutual recognition between authorities (DORA Article 26(7)).

Testers: what the rules demand

Article 27 of DORA requires testers of the highest suitability and reputability, with expertise in threat intelligence, penetration testing and red teaming, who are certified by an accreditation body in a Member State or adhere to formal codes of conduct or ethical frameworks, provide independent assurance on risk management, and hold professional indemnity insurance. RTS Article 7 adds specifics: external red teams need a manager with at least 5 years of experience plus at least two testers with at least 2 years each, and at least five references; threat intelligence teams need a manager with at least 5 years of experience and at least three references. Internal testers are possible with authority approval, but entities must use external testers every three tests, and significant credit institutions must use external testers only (Article 26(8)).

The pooled-testing workaround for ICT providers

This is the provision US cloud and SaaS providers most need to know. Under Article 26(3), when an ICT provider is in scope, the financial entity must ensure its participation. Article 30(3)(d) makes it a contractual term: contracts for ICT services supporting critical or important functions must include the provider's obligation to participate and fully cooperate in the entity's TLPT.

Article 26(4) then offers a way out of one-on-one testing. Where the provider's participation is reasonably expected to adversely affect the quality or security of services delivered to customers outside DORA's scope, or the confidentiality of their data:

1. the financial entity and the provider may agree in writing that the provider directly contracts an external tester;
2. the test is conducted under the direction of one designated financial entity, as a pooled TLPT involving several financial entities that use the provider;
3. it covers the relevant range of ICT services supporting critical or important functions, and counts as TLPT for each participating entity;
4. the number of participants is calibrated to the complexity and types of services.

RTS Article 16(5) has the TLPT authorities agree which entity is designated, and Article 10(4) requires that at least one scenario in a pooled TLPT include the provider's relevant underlying ICT systems, processes and technologies. External testers must still meet Article 27. A US provider facing many TLPT requests from EU banks can therefore propose a pooled test rather than host each client's red team separately.

Common mistakes

• Confusing the yearly testing duty (Article 24(6)) with the 3-year TLPT cycle.
• Missing the TLPT cooperation clause in contracts for critical or important functions.
• Applying the EUR 150 billion threshold to one year only.
• Assuming an internal red team can run every test.
• Underestimating the calendar: 6 months to scope, 12 weeks minimum of active testing, then reports and remediation.

To check a specific point, ask the DORA knowledge base, for example: "Our cloud provider is worried that including it in our TLPT could expose its other, non-financial clients. Is there a workaround?"

This explainer is not legal advice. Official text: RTS 2025/1190 on EUR-Lex and DORA on EUR-Lex. Also visit the Kopik catalog for other regulatory knowledge bases.