DORA's TLPT Requirements: Scoping Your First Threat-Led Penetration Testing Cycle

Threat-Led Penetration Testing (TLPT) sits at the demanding end of DORA's testing regime. It is not an annual vulnerability scan with a new label. This piece explains what TLPT actually is under DORA Chapter IV, who is in scope, what an engagement involves, and the readiness gaps financial entities are hitting in their first cycles.

TLPT is not a standard penetration test

DORA's Chapter IV (Articles 24–27) sets a tiered testing regime: Article 24 establishes the general requirements for the testing programme, Article 25 covers testing of ICT tools and systems, Article 26 introduces advanced testing through TLPT, and Article 27 sets requirements for the testers. Most in-scope entities run the general programme under Articles 24–25 — vulnerability assessments, scans, and periodic testing of ICT tools and systems.

Article 26 raises the bar for a designated subset. TLPT is intelligence-led red-teaming conducted against live production systems, covering several or all of the entity's critical or important functions (Art. 26(2)). The differences that matter:

• It uses real threat intelligence about adversaries targeting the financial sector, not a generic test plan.
• It runs against production, against the functions that actually matter.
• It is supervised, with a defined role for competent authorities and structured attestation at the close (Art. 26(6)–(7)).

A note on framing you will see elsewhere: TLPT is widely described as "modelled on TIBER-EU." That is accurate as background, but the operative text of Article 26 does not itself name TIBER-EU — the anchor is Art. 26(11), which requires the European Supervisory Authorities to develop the regulatory technical standards on TLPT taking into account the ECB's TIBER-EU framework (delivered as the ESAs' final RTS on TLPT). In short: DORA's RTS aligns TLPT to TIBER-EU; Article 26 does not say "TIBER-EU" in so many words.

In plain terms: TLPT tests whether a realistic, intelligence-led attacker could compromise the functions that matter — not whether a checklist of vulnerabilities exists.

Are you in scope?

Not every financial entity must perform TLPT. Under Article 26(8), competent authorities identify the entities required to carry it out, based on risk factors including their size, risk profile, and the impact of their failure on the financial sector and overall stability. Key parameters:

• Frequency: designated entities must conduct TLPT at least every three years (Art. 26(1)); a competent authority may, where necessary, request the entity to reduce or increase that frequency.
• Scope: the test must cover several or all critical or important functions and be performed on live production systems (Art. 26(2)).
• Testers: Article 27 sets requirements for who may conduct the test — suitability, certification or adherence to a code of conduct, and the conditions under which internal testers may be used.

If your competent authority has designated you, the three-year clock is already running for your first cycle.

Anatomy of a TLPT engagement

A TLPT cycle is a structured, multi-phase programme, not a single test window. Aligned with TIBER-EU and the DORA RTS on TLPT, an engagement broadly runs through four phases (these are the framework's operating model rather than a verbatim Article 26 enumeration):

1. Scoping — agreeing the critical/important functions and systems in scope with the control team and the authority.
2. Threat intelligence — a provider builds a sector-specific threat profile and realistic attack scenarios.
3. Red-team execution — testers attempt to compromise the in-scope functions against live production (Art. 26(2)), under control-team oversight.
4. Closure and remediation — findings are documented, remediation is planned and tracked, and the entity produces attestation for the authority (Art. 26(6)–(7)).

Three roles run throughout: the control team (a small internal group that manages the test discreetly), the testers/threat-intelligence providers, and the competent authority.

ICT third-party providers are in the test scope

A defining feature of DORA: TLPT can reach into your supply chain. Where critical or important functions are delivered through ICT third-party service providers, those providers are brought within the test scope (Art. 26(2)–(3)). DORA also enables pooled testing (Art. 26(4)), so a provider serving multiple financial entities can be tested jointly rather than repeatedly.

For compliance and risk leads, this changes contracting and coordination: your TLPT obligations now have to be reflected in third-party agreements and operational planning, not just your own environment.

Readiness gaps entities are hitting

In first cycles, the same gaps recur:

• Threat-intelligence maturity. Many entities have never commissioned sector-specific, scenario-driven intelligence and underestimate the lead time.
• Remediation tracking. Findings are easy to log and hard to close on a defensible timeline — and the authority expects evidence of closure.
• Mapping findings back to the wider framework. TLPT does not stand alone; results must feed the broader ICT risk-management framework under DORA Chapter II (Arts 5–16).
• Third-party coordination. Securing provider participation and aligning pooled-testing logistics takes longer than a single-entity test.

The entities handling their first cycle well treat TLPT as a programme that connects threat intelligence, live testing, and remediation into their existing resilience framework — not as a procurement exercise.

Where CORTEX AI fits

The hard part of a TLPT cycle is rarely the test itself — it is mapping your Chapter IV obligations to your critical functions and tracking remediation to a closure the authority will accept. See how CORTEX AI approaches DORA Chapter IV resilience-testing obligations — explore the approach.