Article · published 13 September 2026

DORA TLPT: what it is and who must perform it

Threat-led penetration testing (TLPT) is DORA’s most advanced testing layer. It is not an annual penetration test, a vulnerability scan or a requirement for every financial entity.

The short answer

TLPT is a controlled, intelligence-led test of critical or important functions on live production systems. Only financial entities formally identified by the relevant TLPT authority must perform it. For the others, the regular DORA testing duties remain the starting point.

Regular testing and TLPT are different obligations

QuestionRegular DORA testingTLPT
Legal basisArticles 24 and 25Articles 26 and 27 and Delegated Regulation (EU) 2025/1190
Who performs itFinancial entities under the applicable Article 24 and 25 rules; microenterprises follow the proportionate rule in Article 25(3)Entities formally identified by the TLPT authority; microenterprises and entities under the simplified framework listed in Article 16(1), first subparagraph, are excluded
PurposeFind weaknesses through a risk-based programme of assessments and testsTest whether critical or important functions can withstand the actions of realistic threat actors
EnvironmentDepends on the test and riskLive production systems supporting the functions in scope
FrequencyA continuing programme; systems supporting critical or important functions are tested at least yearly, except for microenterprisesAt least every three years, unless the authority adjusts the frequency based on risk and operational circumstances

What makes the test threat-led

A conventional penetration test asks what can be compromised within an agreed technical perimeter. TLPT starts with the threats that are relevant to the entity, translates them into realistic scenarios and tests whether the financial service can prevent, detect, respond and recover.

Critical functions, not a server list

The scope covers several or all critical or important functions and the ICT systems, processes and technologies that support them.

Live production systems

The test takes place against live systems. Risk controls, stopping conditions and protected communication are therefore part of the exercise.

Providers are included where relevant

Outsourced ICT services supporting the functions in scope must be considered. The financial entity remains responsible even when a provider participates or a pooled test is used.

The authority validates the scope

The entity assesses which functions should be tested, and the competent TLPT authority validates the precise scope.

Threat intelligence drives the scenarios

The scenarios must reflect the entity’s threat landscape rather than a generic list of vulnerabilities.

Who can be required to perform TLPT

An organisation does not designate itself. The relevant TLPT authority identifies entities using DORA’s proportionality criteria and the detailed rules in Delegated Regulation (EU) 2025/1190. The assessment considers sector impact, financial-stability concerns, systemic character, ICT risk profile and maturity.

Systemically important banks and relevant group entities

The detailed criteria include global or other systemically important institutions and specified entities within their groups.

Large payment and electronic-money institutions

The regulation uses payment-volume and outstanding-electronic-money thresholds, including a EUR 150 billion payment-volume criterion and a EUR 40 billion outstanding-electronic-money criterion in the circumstances it specifies.

Core market infrastructures

Central securities depositories and central counterparties are among the categories addressed.

Certain electronic trading venues

Identification depends on the electronic character of trading and the market-share tests in the delegated regulation.

Large insurers and reinsurers

The delegated regulation applies detailed premium, technical-provision and asset thresholds, followed by additional identification criteria.

The authority can depart from the usual criteria after an assessment and group structures can change whether testing is required individually or jointly. Use the delegated regulation for the complete tests rather than treating this summary as a threshold calculator.

How a TLPT engagement works

  1. Governance and scopeThe entity forms a control team, maps the critical or important functions and agrees risk controls, communication and the scope with the TLPT authority.
  2. Threat-intelligence phaseA threat-intelligence provider develops target-specific threat scenarios. Where internal testers are used, the threat-intelligence provider must be external.
  3. Red-team phaseThe red team executes the agreed scenarios against the live production environment while the control team manages safety and secrecy.
  4. Closure and purple teamingAttack and defence observations are reconciled, including the required purple-teaming activity, so that missed detections and response gaps become clear.
  5. Remediation and attestationThe entity prepares remediation plans and reports. The authority issues an attestation to support recognition by other competent authorities and avoid unnecessary repetition.

The roles must remain clear

TLPT authority and test managers

Oversee the test, validate the scope and confirm that the regulatory process has been followed.

Control team

A small group inside the entity that knows about the test and controls operational risk. It is distinct from the blue team being tested.

Threat-intelligence provider

Produces the intelligence and scenarios that make the exercise relevant to the entity.

Red team

Executes the adversarial scenarios.

Blue team

Defends, detects and responds in the ordinary operating environment, with knowledge restricted as the test design requires.

Who may perform the test

DORA Article 27 requires external testers to demonstrate high suitability and reputation, relevant threat-intelligence, penetration-testing and red-team capability, recognised certification or ethical frameworks, independent assurance over test risk and appropriate professional indemnity insurance. Significant credit institutions under the Single Supervisory Mechanism must use external testers. Other entities may use internal testers only under the conditions and approval set by DORA.

What TLPT is not

  • It is not the annual vulnerability assessment or an ordinary penetration test renamed for marketing.
  • It is not a tabletop exercise for management.
  • It is not an unsupervised red-team exercise with a scope chosen only by the supplier.
  • It does not prove NIS2 compliance and does not replace the ICT risk framework, supplier register or incident-reporting process.
  • Buying a service labelled “DORA TLPT” does not create regulatory TLPT status without formal identification and the required authority-led process.

What to do now

  1. Confirm whether you have been identifiedCheck the entity, licence, group, systemic role and any formal communication from the relevant TLPT authority.
  2. Maintain the regular testing programmeA mature Article 24 and 25 programme should find ordinary weaknesses before an advanced test is needed.
  3. Map critical or important functionsConnect each function to the live systems, processes, data and ICT providers that support it.
  4. Prepare governance before procurementDefine the control team, safety controls, conflicts, information handling and provider roles before selecting testers.
  5. Treat the reports as highly sensitiveThe test material can reveal paths to critical functions. Access, transfer, retention and destruction need explicit controls.

In one sentence

DORA TLPT is an authority-led, intelligence-driven red-team test of live systems supporting critical or important functions, required at least every three years for financial entities formally identified for it.

Read the DORA and NIS2 comparison → · DORA → · Regulatory reference →

This article provides general information, not a determination that a particular financial entity must perform TLPT. Identification and the precise requirements belong to the relevant TLPT authority under the applicable supervisory framework.

Primary sources

All articles →