Learn
If you want to know whether threat-led penetration testing applies to you, what it involves, who runs it, and how the rules are structured, this guide walks through it against the regulation itself.
Threat-led penetration testing, or TLPT, is the advanced resilience test set out in Articles 26 and 27 of Regulation (EU) 2022/2554, the Digital Operational Resilience Act (DORA), which applies from 17 January 2025. The detailed methodology sits in a dedicated regulatory technical standard, Commission Delegated Regulation (EU) 2025/1190, and the whole exercise is built on the European Central Bank's TIBER-EU framework. It is not required of every financial entity. It is required of those a competent authority identifies, and for them it is one of the most demanding obligations in the whole regulation.
Below: what TLPT is, what Articles 26 and 27 require, who gets designated, how the RTS structures the engagement, and how to plan even before designation. First, the facts at a glance.
| Governing law | Regulation (EU) 2022/2554 (DORA), Articles 26 and 27. Applies from 17 January 2025. |
| Detailed rules | Commission Delegated Regulation (EU) 2025/1190 (RTS on TLPT), published in the Official Journal on 18 June 2025. |
| Who must test | Financial entities identified by their competent authority (Article 26(8)), on a risk-based assessment of impact, systemic character and ICT risk profile. Not all financial entities. |
| Frequency | At least every 3 years (Article 26(1)). A competent authority may require a different frequency where necessary. |
| Scope | Several or all critical or important functions, performed on live production systems (Article 26(2)). |
| Methodology | In accordance with the ECB's TIBER-EU framework (Article 26(11)). |
What TLPT actually is
There is a meaningful difference between a standard penetration test and a threat-led penetration test, and the two are often conflated.
A standard penetration test is a point-in-time exercise. A firm scans your systems, tries to break in using known techniques, and reports what it found. Useful, but generic and based on off-the-shelf attack scenarios.
A threat-led penetration test starts from intelligence. Specialists first analyse the actual threats facing your specific institution: which threat actors are likely to target you, what their tactics, techniques and procedures look like, and where your real attack surface lies. A separate red team then uses that intelligence to simulate a realistic attack against your live production systems, while most of your staff do not know the test is running.
The point is realism. A standard test tells you which vulnerabilities exist. A TLPT tells you how a plausible, capable adversary would actually get in, how far they would move, and whether your defenders would notice. That is more expensive, more disruptive and more revealing, which is why DORA reserves it for a subset of entities rather than mandating it for all.
What DORA Articles 26 and 27 require
The legal framework in plain language.
In plain terms:
Frequency. Under Article 26(1), identified financial entities carry out advanced testing by means of TLPT at least every 3 years. A competent authority may, based on the entity's risk profile and operational circumstances, request a different frequency where necessary. It is an obligation, not a best-effort exercise.
Scope and live systems. Article 26(2) requires each test to cover several or all critical or important functions, and to be performed on live production systems supporting those functions. Not a staging copy, not the marketing website. This is what makes many CISOs nervous, because the risk of disruption during the test is real and has to be managed.
ICT third-party providers. Article 26 requires that where ICT third-party service providers are in scope, the financial entity ensures their participation and retains full responsibility for compliance. You cannot test your own systems and pretend the platform they run on does not exist. The same article also provides for pooled testing: where several financial entities rely on the same ICT third-party provider, they may agree in writing to a single pooled TLPT run under one designated entity, so the provider is not red-teamed repeatedly.
Mutual recognition. Article 26 provides for an attestation confirming the test was performed in line with the requirements, so results can be recognised by competent authorities across Member States. A cross-border group is not meant to repeat the same test for every national regulator.
Testers. Article 27 sets requirements for who may run a TLPT. Testers must be of the highest suitability and reputability, demonstrate specific expertise in threat intelligence, penetration testing and red team testing, be certified by an accreditation body in a Member State or adhere to formal codes of conduct or ethical frameworks, provide independent assurance or an audit report, and carry professional indemnity insurance. Internal testers may be used only under conditions: the competent authority must approve their use, be satisfied that the entity has sufficient dedicated resources and has managed conflicts of interest, and in that case the threat intelligence provider must be external to the entity. Article 26 adds that an entity using internal testers must contract external testers every three tests.
Will you be designated?
DORA does not give a clean checklist. Article 26(8) puts the decision with competent authorities, which identify the entities required to perform TLPT taking into account the criteria in Article 4(2) and an assessment of three things:
Impact-related factors. How far the services provided and activities undertaken by the entity impact the financial sector. The greater the impact, the more likely designation.
Financial stability concerns. Possible systemic implications, including the systemic character of the entity. Market infrastructure and entities whose failure would ripple outward sit high on this axis.
ICT risk profile and maturity. The specific ICT risk profile and level of ICT maturity of the entity. A complex ICT estate with heavy third-party reliance widens the attack surface the assessment weighs.
Two things follow from that. First, the criteria are qualitative and applied by your competent authority, so there is no fixed asset threshold or safe harbour in the text. Second, proportionality runs through DORA generally, so smaller entities with simpler ICT environments and no systemic footprint are less likely to be identified, but that is a judgement your authority makes, not a line you can self-certify past.
If your business is systemically important, sits under enhanced supervision, or runs critical market or payment infrastructure, plan on the assumption that TLPT is coming and confirm with your competent authority rather than waiting to be told.
The TIBER-EU connection and the RTS phases
Article 26(11) mandates that the technical rules for TLPT be developed in accordance with the TIBER-EU framework. TIBER-EU (Threat Intelligence-Based Ethical Red Teaming) is the ECB's framework for threat-led testing in the financial sector, and it is the methodological backbone of DORA TLPT. The detail is set out in Commission Delegated Regulation (EU) 2025/1190, the RTS on TLPT, which was published in the Official Journal on 18 June 2025.
The RTS structures a TLPT into distinct phases:
Preparation
Scoping and planning. Define which critical or important functions are in scope, agree the project documentation, engage the threat intelligence and testing providers, and set up the control team, the small group who know the test is happening. The competent authority is engaged from the outset.
Threat intelligence
The threat intelligence provider produces a bespoke analysis of the threats specific to your institution and the plausible attack scenarios that follow from them. This intelligence is what drives the red team's plan, which is why generic intelligence produces a generic, low-value test.
Red team testing
The red team executes the scenarios against live production systems, deploying a range of tactics, techniques and procedures. Depending on the intelligence, that can include social engineering, phishing, network intrusion, lateral movement and attempted data exfiltration, all under agreed safety boundaries managed by the control team.
Closure
Reporting, replay and a purple teaming exercise that brings the red team and your defenders together to walk each scenario: what happened, what was detected, what was missed and why. The entity produces a remediation plan, and the competent authority provides the attestation that supports mutual recognition.
A full TLPT is a multi-month programme rather than a single engagement, because preparation, a bespoke intelligence phase, live testing and closure each take real time. Treat it as a workstream that spans quarters, not a scan you slot into a sprint.
What drives the cost
Neither DORA nor the RTS sets a fee, and there is no official price. What the regulation does is drive the cost through its requirements, so it is worth being clear-eyed about the drivers before a budget conversation.
The main ones are scope, the use of external specialists, and duration. Scope is set by how many critical or important functions you have to cover. Article 27 requires testers of high suitability carrying professional indemnity insurance, and, for internal testers, a separate external threat intelligence provider, so a compliant TLPT draws on scarcer and more senior people than a routine scan. And because the engagement runs across preparation, intelligence, live testing and closure, the internal time of your control team, defenders and remediation owners is a real line item too.
The practical consequence is supply. Qualified threat intelligence and red team providers are in limited supply relative to the population of entities DORA brings into scope. If you wait for the designation letter to start looking, you may wait again for a place on a provider's schedule.
Common mistakes in TLPT planning
Mistake 1: treating the annual pen test as a TLPT
A standard vulnerability assessment or network penetration test does not satisfy the TLPT requirement. TLPT needs bespoke threat intelligence, testing against live systems, a threat intelligence provider that is separate from the red team, and competent authority oversight. A routine scan is not this.
Mistake 2: scoping too narrowly
Article 26(2) says several or all critical or important functions. Testing one convenient function and calling it done invites your competent authority to push back on the scope. Start from a comprehensive mapping of critical or important functions, then justify what is in and out.
Mistake 3: leaving out critical ICT providers
If a critical function runs on a third-party platform, that provider should be in the test. DORA is explicit, and coordinating a red team exercise that touches a major cloud or SaaS provider is a months-long negotiation. The pooled testing route exists precisely because these providers cannot be tested in isolation for every customer. Start the conversation early.
Mistake 4: treating remediation as optional
The findings are not just an informational report. The remediation plan goes to your competent authority and becomes a supervisory expectation. Closing the loop is part of the obligation, not an afterthought.
Mistake 5: waiting for designation before preparing
A TLPT is a multi-month programme, and sourcing qualified providers adds more time on top. If your competent authority identifies you and expects a completed test within the cycle, the clock is already running. Having a provider shortlist and a preliminary scope ready before designation saves months you will not otherwise have.
Not designated for TLPT? You still have to test
A point often lost in the TLPT conversation: DORA requires digital operational resilience testing of all financial entities, not only those designated for TLPT.
Articles 24 and 25 set out a general testing programme every entity must maintain. Article 25(1) lists the methods it can draw on:
- Vulnerability assessments and scans
- Open source analyses
- Network security assessments
- Gap analyses
- Physical security reviews
- Questionnaires and scanning software solutions
- Source code reviews where feasible
- Scenario-based tests
- Compatibility testing
- Performance testing
- End-to-end testing
- Penetration testing (standard, not threat-led)
That is a menu applied proportionately, not a box to tick once. Smaller entities can run simpler versions, but the expectation is that testing is systematic, documented and drives remediation.
The trap is relief. Firms glad not to be designated for TLPT sometimes forget they still owe a real testing programme. Your competent authority will ask about it during supervisory assessments regardless of TLPT status.
A practical planning sequence
Whether you have been designated or think you might be, the sequence below is an illustrative way to approach a first DORA TLPT. Durations vary by scope and provider, so treat it as an order of operations rather than a fixed schedule.
Readiness assessment. Map your critical or important functions and the systems that support them. Judge honestly whether your defenders are mature enough to get value from a red team exercise. If basic alerting struggles, the purple teaming phase will be painful.
Provider selection. Identify qualified threat intelligence and red team providers and get on their calendars. Remember the threat intelligence provider and the red team must be separate, and request proposals from more than one of each.
Authority engagement. Talk to your competent authority about scope and planning. This is not a surprise test: the regulator knows it is happening. What stays confidential is the specific attack scenarios the red team will run.
Threat intelligence. The provider produces the bespoke intelligence that drives the scenarios. Review it hard, because generic intelligence yields a generic test.
Red team testing. The red team executes against live systems while your defenders respond without knowing the specifics, and the control team keeps the exercise inside its safety boundaries.
Closure. Purple team workshop, reports, remediation plan, attestation and submission, lessons learned.
The bigger picture
TLPT under DORA is not a compliance checkbox. It is among the most realistic tests of operational resilience an institution will undergo, and done well it surfaces blind spots that policy writing and paper risk assessments cannot. The trade-off is that the cost is significant and the disruption is real, so the value depends on approaching it as a learning exercise rather than a formality.
The rest of a DORA programme sits around that test: the Register of Information, ICT risk management, incident classification and reporting, and the general testing programme under Articles 24 and 25. DORA is one of several EU regimes a financial entity has to run in parallel, and the work overlaps, so the goal is to manage the whole picture without rebuilding the same evidence for each obligation.
Frequently Asked Questions
Does every financial entity have to perform TLPT?
No. TLPT applies only to financial entities that a competent authority identifies under Article 26(8), based on a risk-based assessment of their impact on the sector, systemic character, and ICT risk profile and maturity. Entities that are not identified still have to run the general resilience testing programme under Articles 24 and 25, but not a full threat-led test.
How often is a DORA TLPT required?
At least every 3 years under Article 26(1). Based on an entity's risk profile and operational circumstances, its competent authority may require the frequency to be different where necessary.
What is the difference between TLPT and a standard penetration test?
A standard penetration test uses generic techniques at a point in time. A TLPT begins with bespoke threat intelligence about your specific institution, then a separate red team uses that intelligence to attack your live production systems while most staff are unaware. It follows the TIBER-EU framework and is far more realistic, and more demanding, than a routine scan.
Can we use our own internal team as testers?
Only under conditions. Article 27 allows internal testers where the competent authority has approved their use and is satisfied the entity has sufficient dedicated resources and has managed conflicts of interest, and in that case the threat intelligence provider must be external. Article 26 also requires an entity that uses internal testers to contract external testers every three tests.
Where are the detailed TLPT rules written down?
The obligation is in Articles 26 and 27 of DORA, Regulation (EU) 2022/2554. The detailed methodology, including the phases, provider requirements and documentation, is in the regulatory technical standard, Commission Delegated Regulation (EU) 2025/1190, developed in accordance with the ECB's TIBER-EU framework.
Managing your DORA programme with Venvera
TLPT is one demanding piece of DORA, and the rest of the programme runs alongside it. The Venvera DORA module keeps the Register of Information, ICT risk assessments, incident classification and your testing evidence in one auditable place, so the general Article 24 and 25 programme and any TLPT remediation actions are tracked rather than scattered across spreadsheets.
Because DORA overlaps with other regimes you may already run, the crosswalk engine lets you reuse controls and evidence across NIS2, ISO 27001 and DORA rather than starting each from zero. If you want a fast read on where you stand, run a free compliance check.
Get the rest of your DORA programme under control
Register of Information, ICT risk assessments, incident classification and testing evidence, kept audit-ready and reusable across your other obligations.
Book a demo →Primary sources
This guide is drawn from the regulation and official EU materials. Always confirm the current text before relying on a specific paragraph or date.
- Regulation (EU) 2022/2554 (DORA) - Articles 24, 25, 26 and 27, and the application date of 17 January 2025.
- Commission Delegated Regulation (EU) 2025/1190 - the RTS specifying the TLPT criteria, provider requirements, scope, phases and methodology.
- ECB TIBER-EU framework - the threat intelligence-based ethical red teaming framework the RTS is built on.
Last updated: July 2026. This article is general information, not legal advice. Consult your competent authority for jurisdiction-specific TLPT guidance.
