TLPT (threat-led penetration testing) is an advanced form of testing based on real-world attack scenarios, which DORA requires designated financial institutions to undergo at least once every three years. To prepare for these tests, an institution needs three things: an up-to-date map of systems supporting critical functions; a team and process capable of navigating all phases of TLPT (from threat intelligence to remediation); and compliance with the standards set out in Regulation 2025/1190 and the TIBER-EU framework. Below, we break this down into its constituent parts and highlight where institutions are most often unprepared.
TLPT versus ‘standard’ immunity tests – two levels
DORA distinguishes between two levels of testing. The basic level is set out in Articles 24–25: every regulated entity must operate a resilience testing programme, and all systems and applications supporting critical or essential functions must be tested at least once a year. The catalogue of methods includes, amongst other things, vulnerability assessments, source code reviews, network security tests and scenario-based tests.
The advanced level is TLPT (Articles 26–27). The detailed technical standards (EU Delegated Regulation 2025/1190) come into force on 8 July 2025 and are consistent with the TIBER-EU framework. TLPT is not just another, more in-depth vulnerability scan – it is a simulation of a real attack on live production systems, conducted on the basis of up-to-date threat intelligence relating to a specific organisation and its sector.
Who is subject to the TLPT requirement?
The TLPT does not apply to everyone. It is the national supervisory authority that designates the entities subject to the requirement, based on the criteria set out in Article 26(8) – including systemic importance, potential impact on financial stability, ICT risk profile and technological maturity. Designated entities must carry out a TLPT at least once every three years, although the supervisory authority may adjust this frequency to reflect the risk profile. It is worth bearing in mind that even entities outside the TLPT regime must meet basic testing requirements – and it is best to begin preparations for the TLPT before an official designation is made.
The stages of TLPT – what you actually need to go through
TLPT is a structured process, not a one-off test. It comprises several phases that the institution must go through.
Preparation and definition of the scope. The scope covers systems supporting critical or essential functions. On the organisation’s side, there is a small, trusted Control Team which is aware of the test – unlike the defence team.
Threat assessment. The assessment provider develops realistic attack scenarios tailored to the specific organisation and sector, so that the test reflects the threats the institution actually faces.
Active phase – red teaming. The attacking team (Red Team) attempts to achieve agreed objectives on live systems, whilst the defending team (Blue Team) is usually unaware that the test is taking place. Following the update to the TIBER-EU framework, purple teaming – that is, the two teams working together during part of the exercise – has become a mandatory element.
Closure and remediation. The test concludes with a report, an assessment and a remediation plan. This is a stage that must not be overlooked – the test alone, without remediation, does not improve resilience.
Added to this are the requirements relating to the testers themselves, including the terms and conditions for the use of internal and external testers.
Where institutions are most often unprepared
The biggest problems do not relate to the attack itself, but to the preparation. Firstly, the lack of a map of critical functions and dependencies – without this, it is impossible to sensibly define the scope of the test. The second issue is untestable legacy systems: on an undocumented system written in Delphi, VB6 or old Java EE, it is difficult to safely run test scenarios and assess the ‘scope’ of an attack. Thirdly, there is no remediation process – the organisation carries out the test, receives a list of issues, and has no way of systematically resolving them.
The common thread is the same as with the whole of DORA: it is not that the system is flawed, but that it lacks transparency. And it is impossible to design a robustness test reliably for something that nobody fully understands.
How to prepare
Preparation for TLPT starts with visibility, not with a penetration test. Process inventory and reconstruction of architecture documentation (S*. doc) provide a map of critical functions and dependencies—the basis for defining the scope. IT architecture audit helps identify and patch vulnerabilities before an attacker does. And DORA consulting, combined with testing, helps build a testing program commensurate with the risk profile and prepare the organization to go through the full TLPT cycle.
FAQ
What is TLPT under DORA?
Who is subject to the TLPT requirement?
How often should a TLPT be carried out?
How does TLPT differ from a standard penetration test?
Where should I start when preparing for the TLPT?
Are you expecting to be assigned to TLPT, or do you want to see if you can pass the DORA resilience tests? Let's talk—we'll start with the scope and the map of critical functions, rather than the attack itself.
