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). Everyone else waits to be identified rather than self-declaring.

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.

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. Under Article 27(2)(c) it must be external to the financial entity whenever internal testers are used.
• 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 is why a credible TLPT usually starts at the human perimeter rather than at an exotic zero-day.

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 other customers, 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. One test, properly run and documented, does not have to be repeated jurisdiction by jurisdiction.

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.