DORA TLPT: What Designated Entities Must Prepare Now

ByOfficer

Last updated: May 2026

Why DORA TLPT Changes the Testing Conversation

Get your DORA TLPT scoping wrong and the consequences hit from two directions. Your competent authority expects a completed test cycle. Your ICT third-party service providers need to cooperate. Your board needs to sign off on a remediation plan that lands on the supervisor’s desk. And the testing itself runs against live production systems, not a sandboxed replica.

Before DORA, threat-led penetration testing across the EU was voluntary. National frameworks existed under the TIBER-EU umbrella, but participation depended on the jurisdiction and the entity’s willingness to engage. Regulation (EU) 2022/2554 changed that. Articles 26 and 27 of DORA make TLPT mandatory for designated financial entities, backed by a Commission Delegated Regulation specifying identification criteria, testing methodology, and tester requirements. This is the first EU-wide legally binding TLPT framework.

I have been through TIBER-EU cycles and ordinary penetration tests. The operational difference between TLPT under DORA and standard vulnerability assessments is substantial. This article walks through what designated entities actually need to prepare.

Related reading: DORA ICT Incident Reporting: Requirements and Timelines

Legal Basis: DORA Articles 26 and 27

TLPT sits in Chapter IV, Section II of DORA (Regulation (EU) 2022/2554). Article 26 covers the general requirements for threat-led penetration testing. Article 27 sets out requirements for testers performing the tests.

Article 26(1) establishes the core obligation: financial entities identified by competent authorities shall carry out threat-led penetration testing at least every three years. This is not a one-off exercise. It is a recurring cycle, and under Article 26(2) each test must cover several or all of the entity’s critical or important functions.

Article 26(2) specifies that TLPT must be performed on live production systems supporting critical or important functions. This is where TLPT diverges sharply from conventional penetration testing. Standard pen tests typically run in controlled environments. TLPT under DORA requires testing against the real operational environment, with all the risk management that entails.

Article 26(11) mandated the ESAs to develop, through the Joint Committee, regulatory technical standards specifying TLPT elements and methodology. The mandate required alignment with the TIBER-EU framework. The ESAs consulted on the draft RTS (JC 2023/72) and submitted the final report to the European Commission by 17 July 2024. The Commission adopted the TLPT RTS as Commission Delegated Regulation (EU) 2025/1190 of 13 February 2025, published in the Official Journal on 18 June 2025 and applicable from 8 July 2025.

DORA TLPT Designation: Who Gets Identified

Not every financial entity in scope of DORA is required to perform TLPT. Article 26(8) of DORA gives competent authorities the power to identify which entities must conduct threat-led penetration testing. The identification considers three categories of factors.

The first category is impact-related and systemic nature. Competent authorities assess the size of the financial entity, comparing its market share at national and EU level, the range of activities it offers, and the scope of services it provides. They look at interconnectedness with other financial entities, cross-border activity, substitutability of the entity’s functions, and complexity.

The second category is ICT-specific. This covers the entity’s ICT risk profile, the ICT threat environment it faces, the complexity of its ICT architecture, and its dependency on ICT third-party service providers. An entity relying heavily on a small number of critical ICT providers for core functions will score differently than one with distributed ICT arrangements.

The third category is the overall ICT maturity of the entity, including its technology features. Competent authorities have discretion to opt entities in or out based on proportionality considerations specific to the financial services sector the entity operates in.

Where a TLPT authority determines that a financial entity is required to perform TLPT, it must inform the entity without undue delay and provide the reasoning, including which factors contributed to the decision. The entity then has to relay that decision to any ICT third-party service providers proposed to be involved in its TLPT.

I see teams assume that because their entity is not a G-SII or O-SII, TLPT will not apply. That is a common misunderstanding. The DORA identification criteria are broader than systemic-importance buffers. A mid-sized payment institution processing high transaction volumes, or a CSD with concentrated ICT dependencies, could be designated. The criteria measure operational criticality and ICT risk, not just balance sheet size.

How TLPT Differs from Ordinary Penetration Testing

Standard penetration tests assess known vulnerabilities. They typically follow a defined scope agreed with the entity, operate with the knowledge of the security team, and run in test environments or with heavily constrained access to production.

DORA TLPT is a different exercise entirely. Here are the operational distinctions.

TLPT tests against live production systems. The entity’s defensive team (the blue team) does not know the test is happening until the closure phase. The red team operates covertly, simulating real threat actors. The threat intelligence phase produces a bespoke threat scenario based on the entity’s actual threat environment, not generic vulnerability scanning.

The scope must cover critical or important functions as defined under DORA Article 3(22). The competent authority, acting as the TLPT authority, oversees the process throughout. This is not an internal audit exercise that stays within the entity. The TLPT authority is involved from scoping through to the remediation plan review.

Purple teaming is a mandatory component under the RTS. After the red team testing phase concludes, the red team and blue team work together in a structured purple team exercise. The purpose is collaborative learning: the blue team sees how the red team penetrated defenses, the red team sees where defenses held, and both sides produce findings that feed the remediation plan. This requirement was debated during the ESAs consultation, with some industry respondents arguing that mandatory purple teaming goes beyond what TIBER-EU guidance requires. The final RTS retained the obligation.

An entity that approaches TLPT like an expanded pen test will underestimate the governance, procurement, and timeline requirements by a wide margin.

TLPT Phases and Timeline

The RTS structures TLPT into distinct phases. Each has specific deliverables and authority interaction points.

The preparation phase covers engagement between the financial entity and the TLPT authority. The entity’s control team is established. The control team is a small group of senior staff who manage the TLPT on the entity’s side, maintain secrecy, and serve as the interface with the TLPT authority, the threat intelligence provider, and the red team. The control team conducts a risk assessment of testing live production systems, including potential impacts on the financial sector and financial stability. The TLPT authority reviews this risk assessment and may object if it does not adequately address identified risks.

During the preparation phase, the entity also procures external testers and threat intelligence providers. Article 27 of DORA and the RTS set requirements for both. External testers must demonstrate a track record of threat intelligence-led red team testing, hold professional indemnity insurance, and comply with confidentiality requirements. Where internal testers are used, their use must be approved by the TLPT authority under Article 27(2)(a) of DORA, and the financial entity must meet the competency, resourcing, and conflict-of-interest conditions for internal testers set out in the TLPT RTS. Even when internal testers are permitted, an external threat intelligence provider is still required.

The threat intelligence phase produces a targeted threat intelligence report. The threat intelligence provider analyses the entity’s attack surface, identifies realistic threat scenarios, and produces a threat intelligence report that drives the scope and scenarios for the red team testing. The report must be tailored to the entity, not a generic threat environment document.

The testing phase is the active red team engagement. The red team attempts to compromise the entity’s critical or important functions using the scenarios identified in the threat intelligence phase. The blue team is unaware of the test. The control team monitors for safety triggers and coordinates with the TLPT authority. If the blue team detects the test, the control team manages the situation to maintain secrecy where possible. The TLPT RTS sets a binding minimum: the active red team testing phase must in any case last at least 12 weeks. The duration scales up from that floor in proportion to the scope, scale, and complexity of the test and the number of entities and providers involved, as agreed between the entity, the TLPT authority, and the testers.

The closure phase includes the mandatory purple team exercise, the production of the red team test report, the blue team report, and the summary report. The entity must produce a remediation plan addressing all findings. The summary report and remediation plan are submitted to the competent authority. The TLPT authority reviews the remediation plan and may require amendments.

From scoping through to remediation plan submission, a complete TLPT cycle typically runs 12 to 18 months. Some industry respondents during the ESAs consultation noted that complex tests with significant findings can push remediation timelines beyond a year, particularly when root cause analysis and compensating controls are needed before permanent fixes.

Governance and the Control Team

The control team is the single most important governance element in a TLPT. Its composition and authority determine whether the test runs smoothly or collapses into operational chaos.

The control team manages secrecy. Only the control team, the TLPT authority, and the testers know the TLPT is happening. The rest of the entity, including the security operations centre, incident response team, and blue team, must be kept unaware until the purple team phase.

The control team leads the risk management process. Testing live production systems creates genuine operational risk. If the red team compromises a system that processes real transactions, the control team must be able to intervene without blowing the test’s cover. The RTS requires the control team to establish safety controls, escalation procedures, and abort criteria before testing begins.

In my experience, the entities that struggle most with TLPT are the ones that treat the control team as a part-time coordination role. It is a full commitment for the testing period. The control team lead needs direct authority to halt testing, manage incidents, and communicate with the TLPT authority in real time.

Board-level involvement matters too. Under Article 26(6) of DORA, the summary of findings, the remediation plans, and the supporting documentation are provided to the TLPT authority at the end of the testing. Separately, DORA places ultimate responsibility for ICT risk management, including oversight of resilience testing, on the management body, so sign-off on the outcome and remediation plan sits with the board or senior management body, not at CISO level.

ICT Third-Party Service Providers in TLPT

DORA explicitly brings ICT third-party service providers into the TLPT scope. Article 26(3) requires that the TLPT scope include ICT services provided by third parties that support the entity’s critical or important functions. Article 30(3)(d) requires ICT third-party service providers to participate and fully cooperate in the financial entity’s TLPT.

This creates practical challenges. The third-party provider may serve multiple financial entities across multiple jurisdictions. A red team testing against the provider’s infrastructure could inadvertently affect other clients.

Article 26(4) addresses this through pooled testing. Where the TLPT involves an ICT third-party service provider, the financial entity may arrange for the test to be performed as a pooled test involving multiple financial entities that use the same provider. Pooled testing reduces duplication and manages the risk of multi-client disruption. However, pooled tests are operationally complex. The control teams, TLPT authorities, and testers must coordinate across multiple entities, each with their own critical functions and risk tolerances.

Where the entity cannot include the ICT third-party service provider directly in the live test, it may need to adopt a proof-of-pathway approach: the red team demonstrates the exploitation path up to the boundary of the provider’s systems, with the control team validating that the pathway represents a viable attack vector. The provider’s participation remains mandatory under DORA, but the practical implementation may require structured alternatives where direct testing poses unacceptable risk to other clients.

Mutual Recognition Across Member States

Article 26(7) of DORA provides for an attestation that enables mutual recognition of TLPT between competent authorities, and the supervisory cooperation framework for entities operating in more than one Member State is developed under Article 26(11), point (d), and the TLPT RTS.

The TLPT authority of the home Member State determines which host TLPT authorities should be involved, based on whether critical or important functions are operated in or shared across host Member States. The summary report produced at the end of the TLPT can be used for mutual recognition purposes, reducing the need for duplicative testing in each Member State where the entity operates.

This is a significant improvement over the pre-DORA framework, where TIBER tests in one jurisdiction carried no formal recognition in another. Under DORA, a properly scoped and executed TLPT that covers the entity’s EU-wide critical functions should satisfy obligations across the relevant Member States.

What Teams Commonly Get Wrong

Three areas generate the most operational errors in TLPT preparation.

First, scoping. Teams treat TLPT scope like a standard pen test scope. They list systems rather than functions. DORA requires the scope to be defined in terms of critical or important functions under Article 3(22). The ICT systems, processes, and third-party services that support those functions then fall within the test boundary. Starting from the function, not the system, is the correct approach.

Second, procurement timelines. External threat intelligence providers and red team testers who meet the RTS requirements are in limited supply. The RTS sets experience thresholds: external testers must demonstrate a combined participation in previous assignments related to threat intelligence-led red team testing, with appropriate professional knowledge covering reconnaissance, exploit development, social engineering, and vulnerability analysis. Multiple consultation respondents flagged the risk of provider shortages as TLPT becomes mandatory across the EU. Starting procurement early is not optional.

Third, the remediation plan. This is not a findings list with a “fix by” column. The remediation plan must link vulnerabilities to root causes, prioritise corrective actions, and be validated by the management body. Competent authorities review it. I have seen entities treat remediation as an appendix to the test report. Under DORA, it is a standalone deliverable that your supervisor will track.

TIBER-EU Alignment and What Remains Different

DORA Article 26(11) required the ESAs to develop the TLPT RTS in accordance with the TIBER-EU framework. The TIBER-EU framework, maintained by the ECB, provides guidance on threat intelligence-based ethical red teaming for the financial sector. Many EU Member States had already implemented national TIBER programmes before DORA.

The DORA TLPT framework aligns with TIBER-EU on the core methodology: threat intelligence-driven scoping, red team testing against live production systems, and structured closure. Where DORA diverges is in legal force and certain specific requirements.

TIBER-EU tests were voluntary and operated under national discretion. DORA TLPT is a binding regulatory requirement for designated entities. The RTS introduces mandatory purple teaming, which TIBER-EU encouraged but did not require. The identification criteria in the RTS are more prescriptive than TIBER-EU’s guidance on selecting entities for testing.

For jurisdictions that already run national TIBER programmes, the ESAs clarified that any jurisdiction wishing to continue its TIBER implementation can do so, incorporating the DORA TLPT requirements into its existing framework. The DORA requirements prevail as the legally binding standard, but operational alignment means entities with TIBER experience are better positioned for the transition.

Preparing for the First TLPT Cycle

If your entity has been designated or expects designation, the preparation work should already be underway. Here is what the first cycle requires.

Map your critical or important functions. This must align with the function identification you have already performed under DORA Article 3(22) and reported in your register of information. The TLPT scope derives directly from this mapping.

Establish the control team. Identify who will lead it, what authority they have, and how secrecy will be maintained. The control team lead needs a direct reporting line to senior management and the ability to halt testing.

Begin procurement. Identify external threat intelligence providers and red team testers. Evaluate them against the RTS requirements. Build in time for contract negotiation, security clearance, and onboarding. The consultation feedback consistently highlighted procurement as a bottleneck.

Engage your ICT third-party service providers early. If a critical provider supports functions within scope, they must cooperate. Work through the contractual and operational arrangements for their participation, whether through direct testing, pooled testing, or proof-of-pathway approaches.

Brief the management body. The board must understand TLPT before the test starts, not after. They need to know what will be tested, the risks of testing live systems, the expected timeline, and their role in validating the remediation plan. Management body ownership of ICT risk and resilience testing flows from DORA’s governance requirements.

Coordinate with the TLPT authority. The competent authority is not a passive observer. They review the scope, risk assessment, test plans, and remediation. Establishing the working relationship early avoids delays during the test cycle.

Document your ICT incident reporting process alongside TLPT preparation. If the red team triggers a genuine security event during testing, the control team must know whether an incident report is required and how to manage the response without compromising the test.

Frequently Asked Questions

Which financial entities must perform DORA TLPT?

Competent authorities designate entities based on Article 26(8) of DORA and the criteria in the RTS. The assessment considers the entity’s systemic importance, market share, interconnectedness, ICT risk profile, ICT maturity, and dependency on third-party ICT providers. Designation is not limited to banks or G-SIIs. Payment institutions, trading venues, CCPs, CSDs, insurance undertakings, and other DORA-scope entities can be designated if they meet the criteria. Microenterprises are excluded from TLPT.

How often must TLPT be conducted?

Article 26(1) requires designated financial entities to carry out TLPT at least every three years. The TLPT authority may adjust the frequency based on the entity’s risk profile and operational circumstances. Some consultation respondents argued for flexibility beyond the three-year minimum where significant findings require extended remediation periods.

Can internal testers be used instead of external providers?

Article 27(2)(a) permits the use of internal testers, but only with the approval of the TLPT authority and subject to conditions. The financial entity must also satisfy the competency, resourcing, and independence conditions for internal testers set out in the TLPT RTS. Even when internal testers are approved, the financial entity must still use an external threat intelligence provider. Under Article 26(8) of DORA, where a financial entity uses internal testers it must contract external testers for every third test. Internal testers may therefore be used for up to two consecutive cycles before an external-tester cycle is required. In addition, credit institutions classified as significant must always use external testers.

Is purple teaming mandatory under DORA TLPT?

Yes. The RTS requires a mandatory purple team exercise as part of the closure phase. After the red team testing concludes, the red team and blue team work together in a structured session to review findings, share methodologies, and identify defensive improvements. During the ESAs consultation, some respondents argued this exceeds the TIBER-EU standard, which encouraged but did not mandate purple teaming. The ESAs retained the requirement in the final RTS.

What happens to the test results?

The financial entity produces a summary report covering the TLPT scope, findings, and a high-level remediation plan. This is submitted to the TLPT authority under Article 26(6). DORA places ultimate responsibility for ICT risk management on the management body, so the board or senior management body is expected to sign off on the outcome and the remediation plan. Competent authorities also take TLPT outcomes into account when evaluating an entity’s ICT risk management as part of their ongoing supervisory review. For entities subject to the SREP, this feeds into the supervisory assessment of operational and ICT risk.

How does DORA TLPT interact with existing TIBER national programmes?

DORA TLPT is the legally binding standard. Where a Member State runs a national TIBER programme (such as TIBER-DE, TIBER-NL, or TIBER-LU), the DORA TLPT requirements apply to designated entities and prevail over the voluntary TIBER framework. Jurisdictions can continue their national TIBER programmes alongside DORA, provided the mandatory DORA requirements are incorporated. Entities with prior TIBER experience will find the transition operationally smoother, as the methodology is aligned.

What role do ICT third-party service providers play in TLPT?

Article 26(3) and Article 30(3)(d) of DORA require ICT third-party service providers to participate and cooperate in the financial entity’s TLPT where they provide services supporting critical or important functions. This may involve direct testing of the provider’s systems, pooled testing with multiple financial entities using the same provider, or proof-of-pathway approaches where direct testing poses unacceptable risk to other clients. The provider’s contractual arrangements must reflect this cooperation obligation.

Related Articles

Key Takeaways

  • DORA Articles 26-27 create the first EU-wide legally binding TLPT framework, replacing voluntary TIBER-EU programmes for designated financial entities.
  • Competent authorities designate entities based on systemic importance, ICT risk profile, ICT maturity, and third-party dependencies. Designation is not limited to the largest banks.
  • TLPT must be performed at least every three years against live production systems supporting critical or important functions.
  • The TLPT RTS (Commission Delegated Regulation (EU) 2025/1190) mandates purple teaming as part of the closure phase and sets a binding minimum of 12 weeks for the active red team testing phase.
  • ICT third-party service providers must cooperate in TLPT. Pooled testing is available where direct testing poses risk to other clients.
  • The control team governs the entire TLPT. Its composition, authority, and secrecy management are critical success factors.
  • Procurement of qualified external testers and threat intelligence providers is a known bottleneck. Start early.
  • The remediation plan is a standalone deliverable reviewed by the competent authority and validated by the management body. It is not an appendix to the test report.

Sources and References

  • Regulation (EU) 2022/2554 of 14 December 2022 on digital operational resilience for the financial sector (DORA), Articles 26-27 – EUR-Lex
  • ESAs Joint Committee Consultation Paper on draft RTS on TLPT (JC 2023/72), 8 December 2023 – ESMA
  • ESAs Final Report on draft RTS on TLPT (JC 2024-29), submitted to the European Commission on 17 July 2024
  • Commission Delegated Regulation (EU) 2025/1190 of 13 February 2025 (TLPT RTS), OJ L, 18 June 2025, applicable from 8 July 2025 – EUR-Lex
  • ECB TIBER-EU Framework – ECB

Disclaimer: The information on RegReportingDesk.com is for educational and informational purposes only. It does not constitute legal, regulatory, tax, or compliance advice. Always consult your compliance officer, legal counsel, or the relevant supervisory authority for guidance specific to your institution.

Similar Posts