Threat-led penetration testing is the most demanding technical obligation in DORA, and it applies to a minority of entities. Those it applies to cannot avoid it, and those it does not apply to often benefit from borrowing its method.
Who Is In Scope
TLPT applies to financial entities identified by competent authorities as required to perform it, based on an assessment of ICT risk profile, systemic character, and specific circumstances. Designation typically captures the larger and more systemically relevant institutions — significant credit institutions, major payment infrastructures, large insurers.
Designated entities must carry out advanced testing by means of TLPT at least every three years. The framework is aligned with TIBER-EU, the European framework for threat intelligence-based ethical red teaming, and national competent authorities generally run their implementation through the corresponding national TIBER scheme.
What Makes It Different
Ordinary penetration testing scopes a system and asks whether it can be broken. TLPT scopes a *function* and asks whether a realistic adversary, using current threat intelligence about actors who actually target this institution, can compromise it — on live production systems, without the defenders knowing.
Three features drive the difference:
Threat intelligence leads the scenario. A targeted threat intelligence report profiles the entity's attack surface and the specific threat actors plausibly interested in it, and the red team's scenarios derive from that report rather than from a generic attack library.
Testing is on live production. DORA is explicit that TLPT covers live production systems supporting critical or important functions. Testing a staging replica does not satisfy it. This is the requirement that generates the most internal resistance and the most genuine insight.
The blue team is not informed. Only a small control group knows the test is running. The detection and response capability being tested is the real one, operating under real assumptions.
The Engagement Structure
A TLPT runs in three phases, typically over several months:
| Phase | Activity | Output |
|---|---|---|
| Preparation | Scoping, control group formation, provider procurement, regulator engagement | Scope specification, risk management plan |
| Testing | Threat intelligence, red team execution against live systems | Threat intelligence report, red team report |
| Closure | Blue team report, purple teaming, remediation planning, attestation | Test summary, remediation plan, attestation to authority |
Scope must cover several critical or important functions and must be validated by the competent authority or the designated TLPT authority. Testers must meet requirements on reputation, capability, technical skills, independence and certification, and where internal testers are used, specific additional conditions apply — including the use of an external threat intelligence provider.
Where the Value Actually Is
The red team report is the artefact everyone anticipates. The purple team workshop is where the institution learns.
In the purple phase, red and blue teams walk the attack path together: here is where we moved laterally, here is the alert your platform generated, here is why nobody actioned it. The recurring finding across the industry is not that detection was absent — it is that the alert fired, was triaged, and was closed as benign. That is a process and staffing finding, not a technology finding, and it only surfaces when the two teams are in the same room.
Institutions that treat TLPT as an audit to survive get a report. Institutions that treat it as a training exercise get a measurably better detection function.
Managing the Risk of the Test
Testing production carries real risk of causing the incident it is meant to prevent. The controls that matter:
- A documented risk management plan agreed before execution, with explicit stop conditions.
- A named control group with round-the-clock reachability and authority to halt the test immediately.
- Legal authorisation and clear scope boundaries, particularly where shared infrastructure or third-party providers are touched.
- Provider notification and consent where the scope reaches into outsourced services — which connects TLPT scoping to the register of information.
- A pre-agreed protocol for what happens if the red team achieves an objective that would, in a real attack, cause material harm.
For Entities Not Designated
Most firms will never be required to run a TLPT. The method is still instructive at a fraction of the cost: commission a short threat intelligence profile, derive two realistic scenarios from it, run them as a tabletop with the blue team uninformed of the date, and hold a purple session afterwards. That is a week of effort and it exercises the same weakness — the gap between an alert firing and someone acting on it — that full TLPT exposes.
Key Takeaways
- TLPT applies to designated entities at least every three years, on live production systems, aligned with TIBER-EU.
- Threat intelligence drives the scenarios; generic attack libraries do not satisfy the standard.
- The purple team phase generates most of the learning; the red team report alone rarely changes behaviour.
- A documented risk management plan with stop conditions and an empowered control group is mandatory in practice.
- Non-designated firms can borrow the method cheaply and get most of the detection insight.
Frequently Asked Questions
Can internal staff run the red team? Yes, subject to additional conditions, including regulator approval and the mandatory use of an external threat intelligence provider. Even where permitted, most institutions rotate in an external red team periodically to avoid the internal team optimising against its own known gaps.
How long does a TLPT take end to end? Typically six to twelve months from scoping to attestation, with the active red team window a much smaller part of that. Procurement, scope validation and remediation planning consume most of the calendar.
Does the test have to cover third-party providers? Where critical or important functions are delivered through providers, the scope must reach them, which requires contractual cooperation. This is one of the reasons DORA prescribes audit, access and cooperation clauses in ICT contracts.
About the author
Jonas Mohamed Osman Abdelghafour is a risk and compliance expert advising banks, insurers, payment institutions and asset managers on operational resilience, ICT and third-party risk, financial crime and enterprise governance across EU and UK regimes. He works at the point where digital operational resilience obligations meet the evidence a board and a supervisor actually ask for. See qualifications and services, or get in touch to discuss an engagement.
*This article discusses regulatory frameworks in general terms and is not legal advice. Jurisdictional interpretation should be confirmed with qualified counsel.*
Frequently asked questions
Who Is In Scope?
TLPT applies to financial entities identified by competent authorities as required to perform it, based on an assessment of ICT risk profile, systemic character, and specific circumstances. Designation typically captures the larger and more systemically relevant institutions — significant credit institutions, major payment infrastructures, large insurers.
What Makes It Different?
Ordinary penetration testing scopes a system and asks whether it can be broken. TLPT scopes a *function* and asks whether a realistic adversary, using current threat intelligence about actors who actually target this institution, can compromise it — on live production systems, without the defenders knowing.
What should risk leaders know about the Engagement Structure?
A TLPT runs in three phases, typically over several months:
Where the Value Actually Is?
The red team report is the artefact everyone anticipates. The purple team workshop is where the institution learns.
What should risk leaders know about managing the Risk of the Test?
Testing production carries real risk of causing the incident it is meant to prevent. The controls that matter: