What is TLPT? Threat-led penetration testing explained

What TLPT is

Threat-led penetration testing (TLPT) is advanced security testing in which testers emulate the tactics, techniques and procedures of real threat actors, using intelligence about the adversaries that actually target the organisation. Under DORA it is a defined regulatory exercise: Article 26(2) requires each test to cover several or all of a financial entity’s critical or important functions, and to run on live production systems supporting them.

Three documents define it. Regulation (EU) 2022/2554 (DORA) sets the obligation and the tester requirements in Articles 26 and 27. Commission Delegated Regulation (EU) 2025/1190, adopted on 13 February 2025, turns it into a process with deadlines. The ECB’s TIBER-EU framework – first published in 2018, current edition January 2025 – is the operational playbook, and states that entities completing a test under a national or European-level implementation of it will be DORA TLPT-compliant, assuming they meet the formal requirements set by competent authorities.

What “threat-led” actually means

The intelligence comes first, as a distinct deliverable produced by the threat intelligence provider. Under TIBER-EU the targeted threat intelligence report must contain at least three end-to-end threat scenarios – plausible chains from initial access to an objective that would genuinely hurt. Delegated Regulation (EU) 2025/1190 records that, on TIBER-EU experience, threat intelligence gathering typically lasts approximately four weeks; the framework gives an indicative four to six.

Scenarios must be grounded in observed behaviour rather than a tester’s habits. The ENISA Threat Landscape 2025 analysed 4,875 incidents between 1 July 2024 and 30 June 2025 and found phishing behind roughly 60% of observed intrusion cases and exploitation of vulnerabilities behind 21.3%, with campaigns rapidly weaponising vulnerabilities within days of their disclosure. Verizon’s 2026 DBIR points the same way from confirmed breaches: exploitation of vulnerabilities is now the most common initial access vector at 31%, ahead of phishing at 16% and credential abuse at 13%.

Flags and leg-ups

Two definitions in Delegated Regulation (EU) 2025/1190 carry more weight than their length suggests. Flags, under Article 1(14), are “key objectives in the ICT systems supporting critical or important functions of a financial entity that the testers try to achieve through the test” – agreed in advance, not declared afterwards.

A leg-up, under Article 1(12), is “the assistance or information provided by the control team to the testers to enable the testers to continue the execution of an attack path where they are not able to advance on their own, and where no other reasonable alternative exists”. In practice: three weeks in, the phishing has not landed, and the clock is about to go on an entry problem rather than on the question the test exists to answer – whether you detect and respond once an attacker is inside. The control team places the testers on a workstation, and every leg-up is recorded, so the report separates what the testers achieved from what they were handed.

The five teams

TIBER-EU splits a test across five parties, and the split is a legal design feature rather than an org chart. Article 1(3) of Delegated Regulation (EU) 2025/1190 defines the blue team as staff defending the entity’s systems “that is not aware of the TLPT”; Article 4(1) requires the entity to appoint a control team lead, defined at Article 1(2) as the staff member responsible for the conduct of all TLPT-related activities.

The five parties to a TLPT

Team	Who they are	What they do
Control team	A small internal team managing the test; knowledge is restricted to authorised parties on a need-to-know basis	Directs the test under a control team lead the entity must appoint (Art 4(1); both terms defined at Art 1(1)–(2)); grants leg-ups; contains the escalation if staff detect the test (Art 4(2)(c))
Threat intelligence provider	External by definition – external to the entity and to any ICT intra-group service provider (Reg. 2025/1190 Art 1(10)); DORA Art 27(2)(c) repeats it where internal testers are used	Produces the targeted threat intelligence report with at least three end-to-end scenarios
Red team testers	Internal or external testers meeting DORA Art 27(1)(a)–(e)	Execute the scenarios against live production for at least 12 weeks (Reg. 2025/1190 Art 11(5))
Blue team	The entity’s own defenders – deliberately not told (Art 1(3))	Defend as on any other day; afterwards produce the blue team report (Art 12(4)) and take part in the replay
TLPT authority	The competent or designated authority, working through its TLPT cyber team and named test managers (Art 1(8)–(9))	Validate the scope (DORA Art 26(2)) and oversee the test; the authority – the lead authority where several are involved – provides the attestation (Reg. 2025/1190 Art 14)

Testers may be internal, but not indefinitely: DORA Article 26(8) requires entities using internal testers to “contract external testers every three tests”, and Article 27(2) adds authority approval, verified absence of conflicts of interest, and an external threat intelligence provider. Credit institutions classified as significant in accordance with Article 6(4) of Regulation (EU) No 1024/2013 shall only use external testers.

Who has to run one, and who decides

Article 26(1) requires financial entities identified by the competent authority – excluding those referred to in Article 16(1), first subparagraph, and microenterprises – to carry out advanced testing by means of TLPT at least every three years. Based on the entity’s risk profile and operational circumstances, the competent authority may, where necessary, request that this frequency be reduced or increased.

Being in scope is not a self-assessment, and there is no DORA category called “significant entities” – that phrase is market shorthand, not a legal term. Article 26(8), third subparagraph, says competent authorities shall identify the entities required to perform TLPT, applying the Article 4(2) criteria plus an assessment of (a) impact-related factors, in particular how far the entity’s services impact the financial sector; (b) possible financial stability concerns, including systemic character at Union or national level; and (c) the ICT risk profile, level of ICT maturity, or technology features involved.

The delegated regulation then tells the authorities where to start. Article 2(2) of Delegated Regulation (EU) 2025/1190 requires TLPT authorities to put all of the following entities in scope “unless the assessment referred to in paragraph 1 … indicates that its impact, the financial stability concerns relating to that financial entity, or its ICT risk profile, does not justify the performance of a TLPT”. It is a rebuttable presumption, not a self-assessment – but it is the closest thing to a published answer to the question every entity in these sectors asks first.

Article 2(2): the entities authorities must require to test

Financial entity	Threshold in Article 2(2)
Credit institutions	Identified as a global systemically important institution (G-SII) or other systemically important institution (O-SII) under Article 131 of Directive 2013/36/EU, or part of one
Payment institutions	More than EUR 150 billion in total value of payment transactions in each of the 2 calendar years preceding the assessment
Electronic money institutions	More than EUR 150 billion in payment transactions, or more than EUR 40 billion of outstanding electronic money, in each of the 2 preceding calendar years
Central securities depositories	All of them – no threshold
Central counterparties	All of them – no threshold
Trading venues with an electronic trading system	The highest national market share by turnover, or more than 5 % of Union turnover, in each of the 2 preceding calendar years, in any of the listed instrument classes. Where the venue shares ICT systems or an ICT intra-group service provider with its group, the group’s turnover counts
Insurance and reinsurance undertakings	All of: gross written premium above EUR 1.5 billion; technical provisions above EUR 10 billion; and, for life or composite undertakings, total assets above 3.5 % of the Member State total. Within that subset, TLPT is required of those that also exceed any one of EUR 3 billion of premium, EUR 30 billion of provisions or 10 % of Member State assets

Two qualifications matter as much as the numbers. The Article 2(1) assessment works both ways: it can release an entity that clears a threshold, and it can pull in a type the list never mentions – recital 3 names crypto-asset service providers authorised under Article 59 of Regulation (EU) 2023/1114 as exactly that case. And under Article 2(3), where several entities of one group share ICT systems, or several entities use the same ICT intra-group service provider, their TLPT authorities decide together whether testing each of them individually is relevant at all, consulting the parent’s authority where that differs.

Live production, third parties and the risk you keep

The entity assesses which critical or important functions to cover, and that assessment determines the scope, which under Article 26(2) “shall be validated by the competent authorities”. Article 26(5) requires the entity, participating ICT third-party providers and the testers, though not the authorities, to apply effective risk-management controls against impact on data, damage to assets and disruption to critical functions. Article 26(7) is blunt about where responsibility lands: the entity “shall remain at all times fully responsible for the impact of the tests”.

Article 26(3) requires the entity to ensure the participation of any ICT third-party providers inside scope, while retaining full responsibility for compliance. Article 26(4) is the release valve: where a provider’s participation would adversely affect the security of services delivered to customers outside the scope of DORA, or the confidentiality of related data, the entity and the provider may agree in writing that the provider contracts an external tester directly, under the direction of one designated financial entity, for a pooled TLPT covering several entities.

What a TLPT produces

The outcome is not a pass or fail. Instead the test is intended to reveal the strengths and weaknesses of the cyber resilience measures put in place by the tested entity, with a focus on the learning effect of the test, and to enable the entity to reach a higher level of cyber maturity.– European Central Bank, TIBER-EU

Article 26(6) sets the paperwork: once the reports are agreed and the remediation plans produced, the entity – and the external testers where applicable – give the authority a summary of relevant findings, the remediation plans and documentation demonstrating compliance. Article 26(7) then requires an attestation confirming the test met the requirements, “in order to allow for mutual recognition of threat led penetration tests between competent authorities”.

Where TLPT sits in the rest of DORA

TLPT is the top of a stack, not the whole of it. Article 24(1) requires a digital operational resilience testing programme for every financial entity other than microenterprises; Article 24(4) requires tests by independent parties; Article 24(5) requires procedures to prioritise, classify and remedy every issue found; and Article 24(6) requires appropriate tests at least yearly on all ICT systems supporting critical or important functions, using the types Article 25(1) names. For the practical difference, see TLPT vs penetration testing; if you have been identified and need the deadlines, see how to prepare for a TLPT engagement.