Threat-led penetration testing (TLPT)

Threat-led penetration testing is defined in law rather than by market practice. Article 3(17) of Regulation (EU) 2022/2554, DORA, describes it as a framework that mimics the tactics, techniques and procedures of real-life threat actors perceived as a genuine cyber threat, and that delivers a controlled, bespoke, intelligence-led (red team) test of the financial entity’s critical live production systems. The three features that separate it from any other test sit in that single sentence: intelligence on real threat actors, a red team, and live production.

The exercise splits the roles. A threat intelligence provider, external to the entity, builds the profile of who would attack and how. A red team, internal or external, runs the scenarios. A small group inside the entity, the control team, directs the test and is the only party that knows it is happening, while the blue team, the people who defend the systems, has no knowledge of the TLPT. That asymmetry is written into the definitions in Article 1 of Commission Delegated Regulation (EU) 2025/1190, the regulatory technical standards for TLPT, adopted on 13 February 2025, published on 18 June and in force since 8 July 2025, drafted, as its recital 1 states, in accordance with the TIBER-EU framework, whose methodology, process and structure they mirror.

The timetable is what gets underestimated. From the TLPT authority’s notification, the entity has three months to submit the initiation information and six for the scope specification document, which its management body approves. The control team lead selects at least three attack scenarios, and at most one of them may be something other than a real threat scenario. The active red team phase lasts at least twelve weeks in every case.

The failure a TLPT exposes is almost never a single vulnerability. It is the gap between what a firm believes its response looks like and what happens when nobody has been warned: the escalation path stalls, the on-call analyst treats a genuine alert as noise, or containment depends on someone who is on leave. An attacker’s advantage lies in the hours between the first detectable action and any coordinated response, and running the exercise without warning the defenders is the only way to measure them.

The second problem shows up in procurement. Article 27(1) of DORA requires testers of the highest suitability and reputability, with specific expertise in threat intelligence, penetration testing and red team testing, certified by an accreditation body in a member state or bound by formal codes of conduct or ethical frameworks, carrying independent assurance over their management of TLPT risk and covered by professional indemnity insurance including misconduct and negligence. The technical standards add years of experience per role and references from previous engagements, and require that intelligence and red team work be kept separate within the same provider.

The third is reading the attestation as a transfer of responsibility. On completion the entity gives the authority a summary of findings, the remediation plans and the documentation, and the authority issues an attestation enabling mutual recognition of the test between competent authorities. It evidences how the test was run: the entity remains fully responsible for its impact.

The three look alike from outside and answer different questions: what changes is who sets the scope, what it runs against, and who reads the result.

Neither absorbs the other: Article 24(6) requires yearly testing of all systems and applications supporting critical or important functions, and that is the penetration testing cycle; the TLPT cycle is three-yearly and lives in its own article. A private red team exercise looks similar in execution but lacks the three things that make it count with a supervisor: external intelligence, scope validated by the authority, and a final attestation. Hence the order that works: bounded penetration testing, detection engineering, purple team work to confirm that detections fire, and only then the threat-led exercise, which is worth doing only where there is a defence worth measuring.

Counting the annual test as compliance with Article 26. Penetration testing sits on the general programme list in Article 25(1); TLPT is a separate obligation on a separate cycle.

Buying the intelligence and the execution from the same team. The threat intelligence provider must be external to the entity, and within one provider the intelligence and red team functions have to be kept apart.

Counting the project from the first week of attack. Ahead of it lie up to six months of preparation with deliverables to the authority, and after it a closure phase with deadlines of its own.

Confusing TIBER-ES with mandatory TLPT. The Banco de España owns the TIBER-ES framework, developed with the CNMV and the DGSFP, and its website presents those tests as voluntary. The obligation comes from Article 26 of DORA.

Assuming the ENS asks for the same thing. Spain’s national security framework requires penetration testing as a reinforcement of its monitoring measure, and only on high category systems; its text mentions neither red teaming nor intelligence-led testing.

Find out whether the entity meets the identification criteria rather than inferring it. The technical standards oblige authorities to require TLPT, unless the qualitative assessment argues against it, from globally or otherwise systemically important credit institutions, from central securities depositories and central counterparties with no threshold at all, and from payment institutions above EUR 150 billion in payment transactions in each of the two preceding calendar years, with separate thresholds for electronic money, insurance and trading venues.

Decide early whether you will use internal testers, because that path is narrower: it needs the authority’s approval, its verification that dedicated resources exist and that conflicts of interest are avoided, and an external threat intelligence provider in every case. The internal policy has to require a test lead and at least two further members, employed by the entity or by an intragroup ICT provider for the preceding twelve months. Even then, external testers must be engaged every three tests, and significant credit institutions may only use external testers.

Put the scope approval into the governance calendar: the management body signs it, and it falls due six months after the notification. And if you operate in several member states, your authority will inform the host authorities, which have twenty working days to ask to take part as observers or to appoint a test manager.

The evidence from a TLPT is not one report but several, each with a deadline. Counted from the end of the active phase, the red team report is delivered within four weeks and the blue team report within ten at the latest, the same window that covers the replay of offensive and defensive actions and the purple teaming exercise. The summary of findings and the remediation plan are submitted within eight weeks of the corresponding notification. A supervisor reads the whole set.

We are explicit about what we provide and what we do not. We run the technical exercise and produce the evidence: the intelligence used, the scenarios, the detection and response timelines, the findings and the severity reasoning, written against the affected function rather than the technical asset. We do not determine regulatory scope and we do not file anything with authorities.

Where the exercise has to count formally, the requirements on testers and on process are confirmed with the competent authority before anything is scoped, because the final attestation depends on them. Article 26 points at adversary emulation run against production and against a live defence, which is the form of testing that answers the question the regulation asks.

How often is a TLPT required? At least every three years for the financial entities identified by their competent authority, which may require a higher or lower frequency depending on the risk profile. Microenterprises and entities under the simplified ICT risk management framework fall outside it.

Does our annual penetration test satisfy Article 26? No. It contributes to the general testing programme, where Article 24(6) already requires yearly testing of systems supporting critical or important functions. TLPT is a separate obligation: steered by external intelligence, run against live production, with scope validated by the authority.

Can we use our own red team? On three cumulative conditions: approval from the competent authority, its verification that dedicated resources exist and that conflicts of interest are avoided, and a threat intelligence provider external to the entity. External testers must still be engaged every three tests.

Are TIBER-EU and TLPT the same thing? No. TIBER-EU is the framework of the ECB and the national central banks, published in May 2018 and voluntary to adopt; the TLPT of Article 26 of DORA is mandatory for identified entities. The framework was updated on 11 February 2025 to align with the technical standards.

How long does a TLPT take? The rules set minimums and deadlines rather than a total duration: at least twelve weeks of active phase, up to six months of preparation from the notification, and several weeks of closure. Real duration depends on scope and on the calendar agreed with the authority.