DORA TLPT explained: threat-led penetration testing

What TLPT is

Threat-led penetration testing simulates the tactics, techniques and procedures of real threat actors against an entity’s own environment. Article 26(2) of Regulation (EU) 2022/2554 fixes two things that make it different from ordinary penetration testing: it covers several or all critical or important functions, and it is performed on live production systems. The scoping assessment is not yours to settle alone either – the same paragraph has it validated by the competent authorities.

So TLPT does not measure a system, it measures an organisation. A vulnerability assessment asks whether a flaw exists; a TLPT asks whether your defenders notice an adversary using it, how long that takes and whether the response holds. The baseline programme in Articles 24 and 25 stays in place underneath: TLPT is added on top, never instead.

Who is actually in scope

DORA has no category called “significant entities”. The phrase is market shorthand, and treating it as a legal class leads to the wrong scoping conclusion. Article 26(8) has competent authorities identify the entities required to perform TLPT, using the Article 4(2) criteria and an assessment of:

• impact-related factors;
• possible financial stability concerns, including the systemic character of the entity;
• the specific ICT risk profile, level of ICT maturity or technology features involved.

The one place “significant” is a term of art is narrow: credit institutions classified as significant in accordance with Article 6(4) of Regulation (EU) No 1024/2013 may use only external testers. Two groups are excluded outright – microenterprises, and entities under the simplified ICT risk management framework in Article 16(1). Note what that second exclusion does not do: Article 16(1) disapplies Articles 5 to 15, so those entities keep the whole Article 24 programme and the Article 24(6) yearly test. TLPT is the only Chapter IV duty they escape.

The Article 2(2) list

Waiting to be identified is the right posture, but it is not the same as having no idea. Article 2(2) of Commission Delegated Regulation (EU) 2025/1190 tells TLPT authorities to require all of the following entities to test, “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 held by the authority, not a self-declaration – but if your class is on this list, planning on the annual programme alone is a bet against the default.

Article 2(2): the classes a TLPT authority must require to test

Entity class	Trigger in Article 2(2)
Credit institutions	Identified as a global systemically important institution (G-SII) or an other systemically important institution (O-SII) under Article 131 of Directive 2013/36/EU – or part of one
Payment institutions	Over EUR 150 billion in total value of payment transactions, in each of the 2 calendar years preceding the authority’s assessment
Electronic money institutions	Over EUR 150 billion in payment transactions, or over EUR 40 billion of outstanding electronic money, in each of the 2 calendar years preceding the assessment
Central securities depositories	Listed with no threshold at all – every CSD
Central counterparties	Listed with no threshold at all – every CCP
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 one of the listed instrument classes. For the Union test, a venue sharing ICT systems or an ICT intra-group service provider with its group counts the whole group’s Union turnover
Insurance and reinsurance undertakings	All three of: gross written premium above EUR 1.5 billion; technical provisions above EUR 10 billion; and – for undertakings pursuing life only, or both life and non-life – total assets above 3.5 % of the Member State total. Within that subset, TLPT is required of those also meeting any one of EUR 3 billion premium, EUR 30 billion provisions, or 10 % of Member State total assets

Two qualifications carry as much weight as the numbers. The Article 2(1) assessment runs in both directions – recital 2 lets an authority release a listed entity whose ICT risk profile and maturity do not justify a test, and recital 3 has authorities look beyond the list entirely, naming crypto-asset service providers authorised under Article 59 of Regulation (EU) 2023/1114 as the case in point. And under Article 2(3), where several entities of one group share ICT systems, or several use the same ICT intra-group service provider, their TLPT authorities decide together whether testing each of them individually is relevant, consulting the parent’s authority where that differs.

Frequency

Under Article 26(1), identified entities carry out TLPT at least every three years. The competent authority may require a lower or a higher frequency depending on the entity’s risk profile and operational circumstances, so three years is a default, not an entitlement.

The phases and their statutory clocks

Commission Delegated Regulation (EU) 2025/1190, adopted on 13 February 2025, is where the timings live. They are worth planning against early, because most of them run from an event rather than from a date you choose.

DORA TLPT phases and the deadlines attached to them

Phase	What happens	Clock
Preparation	Initiation information to the authority; scope specification document approved by the management body	3 months and 6 months – RTS Art 9(2), 9(6); preparation no longer than six months under TIBER-EU
Threat intelligence	Bespoke threat scenarios built for the entity and its sector	No statutory clock – it sets the red team brief
Red teaming	Active testing against live production systems	At least 12 weeks – RTS Art 11(5)
Closure	Red team report; blue team report, replay and purple teaming	4 weeks and no later than 10 weeks – RTS Art 12(2), 12(4), 12(5)
Reporting and remediation	Summary of findings; remediation plans	Within the same 8 weeks after the authority’s report-assessment notification – RTS Art 12(7), 13(1)
Attestation	Authority issues the attestation enabling mutual recognition	RTS Art 14; DORA Art 26(7)

Two of these deserve attention when you budget. The scope specification document under Article 9(6) has to be approved by the management body, which means a board slot, not an ICT sign-off. And active red team testing runs for at least twelve weeks under Article 11(5) – a floor on duration, so a test compressed into a fortnight is not a TLPT.

Who is in the room

TIBER-EU, the ECB framework the DORA process is built on and whose current edition dates from January 2025, names five teams. Getting these roles wrong is the most common way a test loses its value:

• Control team – the small internal group that knows the test is happening and manages risk to production throughout.
• Threat intelligence provider – builds the scenarios. External by definition, on every test: Article 1(10) of the RTS defines the role as experts contracted for each TLPT and “external to the financial entity and to ICT intra-group service providers if any”. DORA’s Article 27(2)(c) repeats the requirement for the internal-tester case; it does not create it.
• Red team – executes the scenarios against live systems.
• Blue team – the defenders, who under Article 1(3) of the RTS are not aware of the TLPT. That unawareness is the measurement.
• TLPT authority (the TIBER cyber team) – validates scope, oversees the test and issues the attestation.

Tester quality is regulated, not left to procurement. Article 27(1) requires testers of the highest suitability and reputability; demonstrated expertise in threat intelligence, penetration testing and red team testing; certification by an accreditation body in a Member State or adherence to formal codes of conduct or ethical frameworks; independent assurance on sound risk management; and professional indemnity insurance, including against misconduct and negligence. Where internal testers are used, Article 26(8) requires external testers every three tests.

Scenarios, third parties and pooled testing

Good scenarios are built from what actually happens to entities like yours. ENISA analysed 4,875 incidents between 1 July 2024 and 30 June 2025 and found phishing behind roughly 60% of observed intrusion cases, with exploitation of vulnerabilities at 21.3% – which highlights relevant entry routes without prescribing the scenarios for a particular entity. Select scenarios using targeted intelligence, exposed services and the agreed objectives.

Scope frequently reaches beyond your own estate, because critical or important functions frequently do. Where an ICT third-party provider is involved and its participation in a single entity’s test would have an adverse effect on the quality or security of services to customers outside DORA scope, or the confidentiality of related data, Article 26(4) allows pooled testing – several financial entities testing the shared provider together, with the provider’s agreement.

Closure: not a pass or fail

The closure phase is where the value is created, and it is deliberately collaborative. The red team report goes out within four weeks of the end of active testing; the blue team report, the replay of the attack path and the purple teaming session follow no later than ten weeks. The replay is the part defenders remember: both teams walk the same timeline side by side and establish where detection broke.

The outcome is not a pass or fail.– European Central Bank, TIBER-EU

That framing is not softness. A test whose purpose is a certificate creates pressure to keep the scope small and the scenario polite – the opposite of what Article 26(2) asks for. The output is a picture of detection and response quality, and a list of things to fix.

Attestation, mutual recognition and what stays yours

Under Article 26(6) and (7), the entity provides the authority with a summary of relevant findings, remediation plans and documentation evidencing that the TLPT was conducted in accordance with the requirements; the authority then issues an attestation, and that attestation enables mutual recognition of the test between competent authorities. The attestation supports recognition between the relevant competent authorities; coordinate the participating entities, scope and supervisory arrangements in advance.

What does not transfer is responsibility. The financial entity remains fully responsible for the impact of the tests on live production systems – the control team, the rules of engagement and the risk management around the test are yours, whoever holds the keyboard.

TIBER-EU states that DORA’s TLPT requirements “are included in the detailed TIBER-EU testing process, so that financial entities completing a test under a national or European-level implementation of the TIBER-EU framework will be DORA TLPT-compliant, assuming they fulfil the formal TLPT-related requirements set by the competent authorities”. If your jurisdiction runs a TIBER implementation, that is the path of least resistance.

How to prepare

Preparation is mostly not technical. Confirm whether your authority has identified you, and if it has not, keep the baseline programme demonstrably in order. Map the critical or important functions you would put in scope and the third-party dependencies inside them. Get the management body used to seeing testing decisions, because Article 9(6) of the RTS will require its approval of the scope. The entities that find TLPT painful are the ones whose Article 24 programme was thin to begin with.