DORA TLPT Deep-Dive

DORA Article 26. Threat-Led Penetration Testing, in full.

Scope, requirements, and practice. Anchored to primary EU sources: Regulation (EU) 2022/2554, Commission Delegated Regulation (EU) 2025/1190, and ECB TIBER-EU 2025 guidance.

3 years
Maximum TLPT cycle for designated entities: Article 26(1)
≥ 12 weeks
Minimum active red team testing on live production: RTS 2025/1190
4 weeks
Red team report due after active testing ends: RTS 2025/1190
10 weeks
Window for mandatory purple teaming and blue team report: RTS 2025/1190
On this page
  1. 1. What TLPT is
  2. 2. Article 26: full breakdown
  3. 3. Article 27: testers
  4. 4. The TLPT RTS (2025/1190)
  5. 5. TIBER-EU lineage
  6. 6. CBEST and global frameworks
  7. 7. Internal vs external testers
  8. 8. Confidentiality & mutual recognition
  9. 9. Primary sources

1. What TLPT is

Threat-Led Penetration Testing is the most demanding operational-resilience test under DORA. Unlike a standard penetration test, which follows a predefined scope and uses generic attack scenarios, a TLPT uses real, current threat intelligence specific to the financial entity's threat landscape to design scenarios that replicate how genuine adversaries would target the entity's critical systems.

Testing is conducted on live production systems, not sandboxes or replicas. The active red team phase must last at least 12 weeks. The Blue Team is unaware that testing is taking place. Once the red team phase concludes, mandatory purple teaming brings both teams through a structured replay of the attack. The output is a prioritised remediation plan, a summary of findings to the competent authority, and a formal attestation enabling mutual recognition across EU jurisdictions.

2. Article 26: full breakdown

Article 26 of Regulation (EU) 2022/2554 sets the substantive TLPT obligation.

(1) Frequency

Designated financial entities, excluding those in the Article 16 lighter regime and microenterprises, must carry out advanced testing by means of TLPT at least every three years.

(2) Scope

The scope must cover several or all critical or important functions and must be performed on live production systems. Entities must identify all underlying ICT systems and technologies, including those outsourced or contracted to ICT third-party providers.

(3) Frequency adjustment

The competent authority may reduce or increase the three-year frequency based on the entity's risk profile and operational circumstances.

(4) Pooled testing

Where an ICT third-party provider's participation would adversely affect service quality or confidentiality for entities outside DORA's scope, financial entities and the provider may agree a pooled TLPT covering multiple participating entities.

(5) Group testing

Where multiple group entities are designated, a group-level TLPT may satisfy the obligation for all of them, subject to relevant competent authority conditions.

(6) Responsibility

The financial entity retains full responsibility for compliance, including where third-party providers are in scope.

(7) Attestation

At the conclusion of testing, the competent authority issues a formal attestation confirming the test was performed in accordance with DORA. This attestation underpins mutual recognition between EU competent authorities.

(8) Designation criteria

The competent authority identifies which entities must perform TLPT based on:

  • impact-related factors: the extent to which the entity's services affect the financial sector;
  • financial stability concerns: systemic character at Union or national level;
  • the entity's specific ICT risk profile, level of ICT maturity, and technology features.

(9)–(11) Authority designation and joint RTS

Member States designate a single public TLPT authority (the ECB carries the function for SSM significant institutions). The ESAs were mandated to develop joint Regulatory Technical Standards specifying the operational detail; those RTS were adopted as Commission Delegated Regulation (EU) 2025/1190 (see §4).

3. Article 27: Requirements for testers

Article 27 prescribes the standards every TLPT tester (internal or external) must meet. Financial entities may only use testers that:

  • (a) are of the highest suitability and reputability;
  • (b) possess technical and organisational capability and demonstrable expertise in threat intelligence, penetration testing and red team testing;
  • (c) are certified by an accreditation body in a Member State or adhere to formal codes of conduct or ethical frameworks verified by a national body;
  • (d) provide independent assurance, or an audit report, that risks associated with TLPT are soundly managed, including protection of the entity's confidential information;
  • (e) are fully covered by relevant professional indemnity insurance, including for misconduct and negligence.

In addition: the threat intelligence provider must always be external. There are no exceptions, including for entities permitted to use internal red teams. Contracts with external testers must require sound management of results, including generation, storage, aggregation, reporting, and destruction of data. The competent authority must verify dedicated resources and the absence of conflicts of interest.

Significant credit institutions under SSM supervision (classified as significant under Article 6(4) of Regulation (EU) No 1024/2013) must always use external testers. There is no internal option.

4. The TLPT RTS: Commission Delegated Regulation (EU) 2025/1190

The European Supervisory Authorities (EBA, ESMA, EIOPA) published a joint final report on draft RTS (JC 2024-29) in July 2024. The European Commission adopted the delegated regulation, which was published in the Official Journal as Commission Delegated Regulation (EU) 2025/1190 on 18 June 2025 and became directly applicable on 8 July 2025.

The RTS adds operational detail to Articles 26 and 27, including:

  • criteria for identifying entities required to perform TLPT;
  • testing scope, methodology and documentation requirements;
  • requirements and standards for internal testers (the 2-in-3 rule; see §7);
  • rules on supervisory cooperation and mutual recognition;
  • binding timelines for deliverables at each phase (12-week minimum active testing, 4-week red team report, 10-week purple teaming and blue team report);
  • purple teaming as mandatory: this was not required under the pre-2025 TIBER-EU framework, only encouraged;
  • a requirement that attack scenarios cover all three components of the CIA triad (Confidentiality, Integrity, Availability).

5. TIBER-EU lineage and alignment

DORA TLPT is descended directly from the ECB's TIBER-EU framework (Threat Intelligence-Based Ethical Red Teaming for the European Union), which the ECB and National Central Banks developed in 2018 and have operated since 2019. More than 100 tests had been conducted under TIBER-EU before DORA came into force. The ESAs explicitly structured the RTS to distil the mandatory elements of the TIBER-EU testing process into binding regulatory text.

On 11 February 2025 the ECB published the updated TIBER-EU framework aligned with the DORA RTS, and in November 2025 published an SSM Supervisory Guide for implementation across significant institutions under the Single Supervisory Mechanism.

The most significant changes from the pre-2025 TIBER-EU framework: purple teaming became mandatory; the role formerly called "White Team" was renamed Control Team; scenarios must address the full CIA triad; and delivery timelines were codified in the RTS rather than left to guidance. Function scope is now "Critical or Important Function" (CIF) per DORA Article 3(22).

6. CBEST and global frameworks

The TLPT concept originated with the Bank of England's CBEST framework, launched in 2013 for critical UK financial market infrastructure. TIBER-EU was modelled on CBEST; DORA TLPT mandates the TIBER-EU methodology in EU law. Post-Brexit, CBEST remains the UK-specific framework operated by the PRA and FCA.

DORA mutual recognition does not extend to CBEST results. An entity that has conducted a CBEST test cannot present it to an EU competent authority as satisfying its DORA TLPT obligation. (No formal bilateral UK-EU recognition arrangement had been identified in primary sources as of June 2026. Entities with dual obligations should verify with their EU NCA.)

Other peer frameworks worldwide share the same intelligence-led methodology but are not mutually recognised under DORA:

  • iCAST: Hong Kong Monetary Authority's Intelligence-led Cyber Attack Simulation Testing;
  • AASE: Association of Banks in Singapore framework (2018);
  • CORIE: Australia's Council of Financial Regulators framework;
  • FEER: Financial Entity Ethical Red Teaming (various jurisdictions).

7. Internal vs external testers: the 2-in-3 rule

Subject to the conditions in the RTS, financial entities may use internal red team testers, with constraints:

Cycle 1
Internal red team permitted
TI provider still external
Cycle 2
Internal red team permitted
TI provider still external
Cycle 3
External red team required
The sequence then resets
  • 2-in-3 rule: when an entity uses internal testers, the third test in any three-test sequence must use an external provider. Two consecutive cycles may use an internal red team; the third must be external.
  • Internal testers must meet the same capability and independence requirements as external testers; the competent authority must verify the absence of conflicts of interest.
  • SSM significant credit institutions must always use external testers; no internal option.
  • The threat intelligence provider must always be external, for all entities, in all cycles.
Practitioner note

On how to read Article 27 in a procurement: see Choosing a DORA TLPT provider →

8. Confidentiality & mutual recognition

Under Article 26(7), the entity submits to the competent authority:

  • a summary of relevant findings, not the full technical report;
  • the remediation plan;
  • documentation evidencing DORA-compliant execution.

The full technical report (containing live vulnerability detail, attack paths, and specific architecture weaknesses) is retained by the entity. It is not published, not shared with peer institutions, and is typically accessible only to the Control Team, senior management, and the Audit/Risk Committee on a need-to-know basis.

Mutual recognition. An attestation issued by one EU competent authority is recognised by other EU competent authorities. This is particularly relevant for cross-border financial groups with entities supervised in multiple Member States.

The attestation chain

For audit and governance purposes, the chain of attestation runs as follows:

  1. 1

    Financial entity completes TLPT and submits summary findings plus remediation plan to its NCA.

  2. 2

    TLPT Cyber Team at the NCA reviews the deliverables and verifies RTS compliance.

  3. 3

    NCA issues a formal attestation confirming the test was conducted in accordance with DORA.

  4. 4

    The attestation is recognised by other EU competent authorities under Article 26(7) (mutual recognition).

  5. 5

    The management body of the financial entity oversees implementation of the remediation plan.

9. Primary sources

This page is anchored to the following primary EU sources. All are linked directly from the official publisher.

Next
The seven phases of a TLPT engagement, from notification letter to attestation.
See the journey