DORA TLPT Requirements: Who Needs Testing, and When

Threat-led penetration testing (TLPT) is DORA's most demanding resilience test: a live, intelligence-driven simulated attack on an entity's critical systems, required under Articles 26 and 27 for financial entities the competent authority identifies as systemically important. The scope, tester rules, and mutual-recognition process are set out in Commission Delegated Regulation (EU) 2025/1190, applicable since 8 July 2025. Here is who is in scope, how the test runs, and what to prepare before a notification arrives.

What makes TLPT different from routine testing

DORA's resilience-testing pillar sets a proportionate testing programme for every in-scope entity: vulnerability assessments, scenario-based tests, and open-source analysis under Article 25 apply broadly. TLPT sits above that baseline. It is not a scheduled audit against a checklist; it is a red-team exercise, built on the EU's TIBER-EU framework, in which testers use current threat intelligence to emulate how a real adversary would attack the entity's critical or important functions, on live production systems, under controlled rules of engagement.

Because the test runs on production infrastructure and follows real attacker tradecraft rather than a fixed script, it surfaces gaps that a conventional penetration test, run against a defined scope with advance notice to defenders, typically will not. That is also why it is reserved for the entities whose failure would do the most systemic damage, not applied universally.

Who has to run it

DORA does not require every financial entity to perform TLPT. Under Article 26 and Article 2 of the RTS, the competent authority (or, for cross-border groups, the relevant testing authorities acting jointly) identifies entities based on objective, risk-based criteria: systemic importance, contribution to financial stability, and the criticality of the ICT services and functions involved. In practice, significant banks, core market infrastructures, and other entities the authority judges could destabilise the financial system if compromised are the natural candidates, not community lenders or low-criticality fintechs.

Authorities notify identified entities directly. Being outside the initial identification round does not mean TLPT is irrelevant: national authorities retain discretion to bring additional entities into scope as risk profiles change, and even entities never designated still benefit from running their resilience-testing programme as if a TLPT-style review were coming, since the underlying control gaps are the same ones any serious attacker would look for.

How the test runs

TLPT follows the TIBER-EU lifecycle in four broad stages:

1. Preparation. The entity, its testing authority, and a threat intelligence provider scope the exercise, agreeing which critical or important functions are in play and the rules of engagement.
2. Threat intelligence. A dedicated threat intelligence provider builds realistic attack scenarios based on actual threat actors known to target the entity's sector and geography.
3. Red team testing. Testers execute the scenarios against live production systems, attempting to achieve the same objectives a real attacker would (data exfiltration, service disruption, unauthorised access) without a defined, advance-notice scope.
4. Closure and remediation. Findings are consolidated into a report, shared with the testing authority, and fed back into the entity's ICT risk-management framework as tracked remediation items.

Because critical functions are frequently outsourced, ICT third-party providers supporting the test scope may need to participate, and their cooperation is one of the things a testing authority checks before the exercise closes out.

Requirements for testers

Article 27 sets a high bar for anyone conducting a TLPT. Testers, whether internal staff or an external firm, must demonstrate technical and organisational capability in threat intelligence, penetration testing, and red-team methodology; hold relevant certification or adhere to a recognised code of conduct; provide independent assurance or an audit report on how they manage the risks of the engagement, including protection of the entity's confidential information; and carry professional indemnity insurance covering misconduct and negligence.

Entities may use internal testers for the red-team role, but the threat intelligence function must always sit with a provider external to the entity. Firms offering DORA-aligned penetration testing are typically built around exactly this split, an accredited red team paired with an independent threat intelligence capability, because the regulation does not allow a single in-house team to cover both roles.

Frequency, notification, and mutual recognition

Identified entities must run TLPT at least once every three years, though a testing authority can require it more often based on risk. The RTS also builds in mutual recognition: once a test is completed to standard, the testing authority issues an attestation, and other competent authorities across the EU are expected to accept it rather than demand a duplicate exercise. For groups operating across multiple member states, this is meant to prevent the same critical infrastructure being tested repeatedly under slightly different national processes.

Getting ready before the notification arrives

Entities that expect to be, or already have been, identified for TLPT should not wait for the formal scoping call to start preparing:

• Confirm your critical and important functions are current. TLPT scope is built around them, so an out-of-date functions inventory means an inaccurate test scope.
• Check your ICT third-party contracts allow it. Providers supporting in-scope functions need contractual terms that permit their systems to be included in a live test, not just standard security clauses.
• Line up threat intelligence and red-team capability early. Accredited providers with DORA-specific TLPT experience are in limited supply across the EU; procurement should start well before a notification, not after.
• Treat findings as a management-body issue. Article 27 remediation tracking is not a technical backlog item; it belongs on the same governance track as any other material ICT risk finding.

A broader view of where your resilience-testing programme stands, alongside the other four pillars, is available through the DORA Readiness Score.

Sources

• European Banking Authority, Joint RTS specifying elements related to threat-led penetration tests.
• Commission Delegated Regulation (EU) 2025/1190 of 13 February 2025, EUR-Lex, applicable since 8 July 2025.
• Regulation (EU) 2022/2554 (DORA), Articles 26-27, EUR-Lex.

Last updated: 13 July 2026.