DORA TLPT: 2026 Guide to Threat-Led Penetration…

In this article ↓

Short answer
TLPT at a glance
DORA testing vs TLPT
Who is in TLPT scope?
What competent authorities look at
TLPT roles and responsibilities
TLPT lifecycle
Evidence pack for TLPT readiness
TLPT and ICT third-party providers
What not to claim
30-day TLPT readiness plan
FAQ
Does every DORA entity need TLPT?
How often is TLPT required?
Can a normal penetration test replace TLPT?
Should a small EMI prepare for TLPT?
Who chooses the TLPT provider?
Can ICT suppliers block TLPT?
Related reading
Primary sources
Bottom line

Last reviewed: 1 May 2026

Short answer

Threat-led penetration testing (TLPT) under DORA is advanced resilience testing for financial entities identified by competent authorities. It is not mandatory for every financial entity.

Every DORA in-scope financial entity needs a proportionate digital operational resilience testing programme. Only selected entities need TLPT under Article 26.

The practical 2026 question is:

Has the entity confirmed whether TLPT applies, and if not, can it show a proportionate testing programme with evidence of remediation?

TLPT at a glance

Question	Practical answer
Is TLPT required for every fintech?	No. It applies to financial entities identified by competent authorities under DORA Article 26 and related criteria.
Is TLPT the same as a penetration test?	No. TLPT is threat-led, intelligence-based, scoped around critical or important functions and run under a formal framework.
Is TLPT the same as annual DORA testing?	No. Article 25 requires a broader risk-based testing programme. TLPT under Article 26 is advanced testing for identified entities.
How often does TLPT run?	At least every three years for identified entities.
Who should own TLPT internally?	Senior ICT risk / security owner with management-body oversight, legal/compliance support and technical service owners.
What should smaller firms do?	Document why TLPT is not in scope, then maintain proportionate testing evidence: vulnerability testing, BCDR tests, tabletops and remediation.

DORA testing vs TLPT

DORA separates general digital operational resilience testing from threat-led penetration testing.

Area	Article 25 testing programme	Article 26 TLPT
Applies to	All financial entities in scope, proportionate to risk	Financial entities identified by competent authorities
Purpose	Test resilience, controls, recovery and remediation	Test live production resilience against realistic threat scenarios
Frequency	Regular risk-based programme	At least every three years for identified entities
Scope	ICT systems, tools, processes, controls and continuity	Critical or important functions and supporting systems
Methods	Vulnerability assessments, scans, open-source reviews, network security assessments, gap analysis, BCDR tests, source-code reviews, scenario tests and others	Threat intelligence, red team test, blue team interaction, control-team governance, closure
Evidence	Test plan, results, findings, remediation tracker	TLPT scope, threat intelligence, test plan, reports, remediation and authority interaction
Common mistake	Treating annual testing as a checklist	Treating TLPT as a normal pen test or claiming it applies to everyone

DORA Article 26 says financial entities identified by competent authorities must carry out TLPT. Identification is based on criteria set by the regulatory technical standards and applied by the competent authority.

That means a financial entity should not self-declare “TLPT required” only because it is important, regulated or cloud-dependent. The correct position is:

confirm whether the competent authority has identified the entity for TLPT;
keep a record of the scope decision;
monitor for supervisory communication or changes in scale, complexity or criticality;
maintain proportionate Article 25 testing evidence even if TLPT does not apply.

Entity situation	TLPT stance
Small EMI with limited services and no authority identification	TLPT likely not required; maintain proportionate testing evidence
Payment institution with high transaction volume and critical infrastructure dependencies	Confirm competent-authority position and prepare a TLPT readiness file
CASP using custody / key-management infrastructure	Do not assume TLPT; assess critical functions, authority expectations and advanced testing needs
Bank, trading venue or infrastructure provider with systemic impact	More likely to face TLPT identification; maintain readiness for formal TLPT
Outsourced technology provider	Not the financial entity's TLPT owner, but may be in scope of the test as a supporting ICT provider

What competent authorities look at

The RTS on TLPT sets out criteria and methodology for identifying financial entities that must perform TLPT. The criteria focus on the entity's importance, ICT risk profile and potential systemic or market impact.

For implementation planning, the useful indicators are:

Indicator	Why it matters
Critical or important functions	TLPT tests the resilience of functions that matter to the financial entity and market
Scale and complexity	Larger or more complex entities are more likely to need advanced testing
ICT dependency	High dependency on digital channels, cloud, APIs or outsourced providers increases operational risk
Market or customer impact	Wider disruption potential raises supervisory interest
Cross-border activity	Multi-jurisdiction service delivery can increase complexity
Previous incidents or control weaknesses	Incident history may increase scrutiny
Interconnectedness	Dependencies on payment rails, market infrastructure or critical suppliers can matter

The entity should not turn this into a self-scoring game. Use it to prepare evidence and questions for the competent authority.

TLPT roles and responsibilities

TLPT involves more governance than a normal penetration test.

Role	Responsibility
Management body	Oversees risk appetite, approves material decisions and receives results at the right level
ICT risk / security owner	Owns TLPT readiness, internal coordination and remediation tracking
Control team	Coordinates the test, manages safety and preserves secrecy from the blue team where required
Threat intelligence provider	Produces threat intelligence and realistic threat scenarios
Red team provider	Executes the controlled attack scenarios
Blue team / defenders	Detects, responds and recovers during the test
Business function owners	Confirm critical services, impact tolerance and operational constraints
Legal / compliance	Supports authority interaction, contractual boundaries and evidence retention
ICT third-party providers	Support testing where services, systems or dependencies are in scope

Smaller firms that are not identified for TLPT do not need to build this full structure. They should still use the role model to improve ordinary resilience testing.

TLPT lifecycle

Phase	Output
Scope confirmation	TLPT applicability decision and authority communication record
Preparation	Critical function map, systems, providers, constraints and risk acceptance
Provider selection	Threat intelligence and red team provider due diligence
Threat intelligence	Threat profile and scenarios linked to the entity's services
Test planning	Approved plan, rules of engagement, safety controls and escalation paths
Execution	Controlled red team activity and blue team response evidence
Closure	Reports, findings, severity, remediation plan and lessons learned
Retest / remediation	Closure evidence and management-body reporting

The lifecycle should be planned months in advance. A rushed TLPT is more likely to create operational risk and weak evidence.

Evidence pack for TLPT readiness

Even before an entity is formally identified, it can maintain a readiness pack.

Evidence artefact	Why it matters
TLPT scope decision record	Shows the entity has assessed whether Article 26 applies
Critical or important function map	Defines what could be in test scope
ICT asset and service dependency map	Connects business functions to systems and providers
Testing programme	Shows Article 25 testing is already operating
Prior penetration test / vulnerability results	Gives baseline technical findings and remediation history
BCDR and incident tabletop records	Shows recovery and response evidence
Supplier contract clauses	Confirms whether providers can support advanced testing
Authority contact route	Shows who handles supervisory communication
Remediation tracker	Shows findings are owned and closed
Board reporting record	Shows management-body oversight of testing and resilience

This pack is useful even when TLPT is not required. It proves that the entity treats testing as an operating discipline.

TLPT and ICT third-party providers

Many financial entities cannot test critical functions without touching ICT providers: cloud, core banking, payment processing, KYC, fraud tools, custody infrastructure, managed security or SaaS platforms.

Provider issue	What to check
Contract permission	Does the contract allow security testing or coordinated TLPT activity?
Notification rules	Does the provider require advance notice or approval?
Subcontractors	Could testing affect subcontracted systems or shared infrastructure?
Safety constraints	What systems, times, data or techniques are prohibited?
Logging and evidence	Will the provider share logs, alerts and response evidence?
Incident confusion	How will the provider distinguish test activity from real incidents?
Exit / concentration	Could findings expose dependency or concentration risk?

If contracts do not support testing, that is itself a DORA third-party risk issue.

What not to claim

TLPT language is easy to overstate. Avoid these claims:

Unsafe claim	Safer wording
“All DORA firms must do TLPT.”	“All DORA firms need proportionate resilience testing; TLPT applies to entities identified by competent authorities.”
“A penetration test satisfies TLPT.”	“Penetration tests may support the testing programme, but TLPT is a specific threat-led framework.”
“TLPT is only a technical red-team exercise.”	“TLPT includes governance, threat intelligence, scoped execution, safety controls, reporting and remediation.”
“The provider owns TLPT compliance.”	“External providers can perform parts of TLPT, but responsibility remains with the financial entity.”
“If TLPT is not required, testing is optional.”	“Article 25 testing still applies proportionately even when TLPT does not.”

This is important for SEO and sales copy as well as compliance. Overclaiming TLPT may make the content look more dramatic, but it is factually weaker.

30-day TLPT readiness plan

Week	Action	Output
Week 1	Confirm DORA Article 26 position and authority route	TLPT applicability note
Week 1	Map critical or important functions	Function and service map
Week 2	Map systems and ICT third-party providers supporting those functions	Dependency map
Week 2	Review testing history and current Article 25 programme	Testing evidence gap list
Week 3	Review supplier testing permissions and notification constraints	Contract gap tracker
Week 3	Define internal TLPT governance roles if ever identified	Role and escalation map
Week 4	Update board reporting	TLPT status, testing plan and remediation overview
Week 4	Build readiness evidence index	Owner, location, review cadence and next action

This plan does not mean every entity needs TLPT. It means every entity should be able to explain the testing model and TLPT applicability position.

FAQ

Does every DORA entity need TLPT?

No. Every DORA entity needs proportionate digital operational resilience testing. TLPT under Article 26 applies to financial entities identified by competent authorities.

How often is TLPT required?

For identified entities, DORA Article 26 requires TLPT at least every three years.

Can a normal penetration test replace TLPT?

No. A normal penetration test can support the broader Article 25 testing programme, but TLPT has a specific threat-led methodology, scope, governance and reporting model.

Should a small EMI prepare for TLPT?

It should not overbuild a TLPT programme unless identified. It should keep a clear TLPT applicability note and maintain proportionate testing evidence: BCDR tests, incident tabletops, vulnerability assessments, supplier testing and remediation records.

Who chooses the TLPT provider?

The financial entity is responsible for provider selection and governance, subject to the TLPT framework, authority expectations and independence / quality requirements.

Can ICT suppliers block TLPT?

Supplier constraints can affect scope and safety, but they should be managed through contracts and planning. If a critical supplier cannot support testing, that is a third-party risk and resilience issue.

Primary sources

Bottom line

TLPT is one of the most misunderstood parts of DORA.

The correct 2026 position is simple: all in-scope financial entities need proportionate resilience testing, but TLPT is for entities identified by competent authorities. A smaller fintech should not claim TLPT readiness unless the scope is clear. It should be able to show why TLPT does or does not apply, what testing it does perform and how findings are remediated.

DORA TLPT: 2026 Guide to Threat-Led Penetration Testing