Threat-led penetration testing (TLPT) is the most operationally complex obligation in DORA. Articles 26 and 27 of Regulation (EU) 2022/2554 set the obligation, and Commission Delegated Regulation (EU) 2025/1190, the regulatory technical standards (RTS) on TLPT in force since 8 July 2025, sets the method. The RTS was drafted in accordance with the TIBER-EU framework, and entities may apply TIBER-EU or a national implementation in as much as it is consistent with DORA and the RTS (recital 1). Entities identified by their competent authority carry out a TLPT at least every three years (Art. 26(1)). There is no EU-wide date for a first TLPT: the test starts when the TLPT authority notifies the entity (RTS Art. 9(1)). The 17 January 2028 date that circulates as a deadline is the Commission review of DORA under Art. 58(1). This guide follows the RTS phase by phase.
What TLPT Is, and What It Is Not
TLPT is a controlled, intelligence-led red-team exercise conducted on the live production systems supporting an institution's critical or important functions (CIFs). It simulates the tactics, techniques and procedures (TTPs) of real adversary groups identified through targeted threat intelligence, with the objective of measuring detection and response capabilities under realistic attack conditions.
TLPT is not a vulnerability scan, not a standard penetration test, not a tabletop exercise and not a purple-team engagement. It is materially different in scope, methodology and regulatory weight.
| Attribute | Standard pentest | TLPT (DORA, RTS 2025/1190) |
|---|---|---|
| Target | Specific application or perimeter | Live production systems supporting several or all CIFs (Art. 26(2)) |
| Threat intel | Generic OWASP top 10 | Targeted threat intelligence on the entity (RTS Art. 10) |
| Awareness | Defenders are typically informed | The blue team is informed only after the active phase (RTS Art. 12(1)) |
| Authorisation | Internal sign-off | Control team, with validation or approval by the TLPT authority at each phase |
| Duration | Set by contract | Active red team phase of at least 12 weeks (RTS Art. 11(5)), inside deadlines counted from the notification |
| Output | Vulnerability report | Red and blue team reports, summary report, remediation plans, attestation (Art. 26(6)-(7)) |
Who Must Conduct TLPT
Competent authorities identify the financial entities required to perform TLPT, on impact-related factors, financial stability concerns and ICT risk profile (Art. 26(8), third subparagraph). Microenterprises and the entities under the simplified framework of Art. 16(1) are excluded (Art. 26(1)). RTS 2025/1190, Art. 2(2), lists the entities the TLPT authority shall require to perform TLPT, unless its assessment shows that it is not justified:
- Credit institutions identified as global or other systemically important institutions (G-SIIs, O-SIIs), or part of one
- Payment institutions above EUR 150 billion of payment transactions in each of the two preceding calendar years
- Electronic money institutions above the same threshold, or above EUR 40 billion of outstanding electronic money
- Central securities depositories and central counterparties
- Trading venues with an electronic trading system that meet national or Union market-share tests
- Insurance and reinsurance undertakings that meet thresholds on gross written premium, technical provisions and total assets
The authority can also identify other entities on the criteria of Art. 2(1), such as size, interconnectedness, substitutability and ICT maturity. Neither DORA nor the RTS gives a number of identified entities, and we do not publish an estimate we cannot source.
The 5 Phases of TLPT
The RTS structures a TLPT into a preparation phase, a testing phase split into threat intelligence and the red team test, and a closure phase, followed by remediation and attestation. Each step ends with a deliverable validated or approved by the TLPT authority, and several have deadlines in the text. Where the text sets no deadline, we give none.
Phase 1: Preparation (RTS Art. 9)
Starts with the notification from the TLPT authority that a TLPT is to be carried out. Deliverables:
- TLPT initiation information within 3 months of the notification: a project charter with a high-level plan, the contact details of the control team lead, the intended use of internal or external testers, the communication channels and a code name (Art. 9(2))
- A control team, set up once the initiation information is validated and validated in turn by the TLPT authority (Art. 9(4)-(5))
- Selection of the threat intelligence provider and the testers (Art. 9(4)(e)-(f))
- A scope specification document within 6 months of the notification, approved by the management body (Art. 9(6)), covering the CIFs selected on the criteria of Art. 9(7)
Phase 2: Threat intelligence (RTS Art. 10)
Once the TLPT authority approves the scope, the threat intelligence provider analyses generic and sector threats and gathers targeted intelligence on the entity. Recital 18 notes that, based on TIBER-EU practice, this typically lasts about four weeks; it is not a legal deadline. Deliverables:
- Proposed scenarios that differ by threat actor and TTPs and target each CIF in scope (Art. 10(2))
- At least three scenarios selected by the control team lead, of which at most one may be non-threat-led (Art. 10(3)-(4))
- A targeted threat intelligence report with the content of Annex III, approved by the TLPT authority (Art. 10(5)-(6))
Phase 3: Red team test (RTS Art. 11)
The testers prepare a red team test plan (Annex IV), approved by the control team and the TLPT authority (Art. 11(1)-(3)). They then run the active red team testing phase against live production systems. That phase is proportionate to the scope, the complexity and the number of entities and providers involved, and lasts at least 12 weeks (Art. 11(5)). The blue team is not told while it runs.
Phase 4: Closure (RTS Art. 12)
- The control team lead informs the blue team that a TLPT took place (Art. 12(1))
- Red team test report within 4 weeks of the end of the active phase (Art. 12(2))
- Blue team test report, and replay of the offensive and defensive actions with a purple teaming exercise, no later than 10 weeks after the end of the active phase (Art. 12(4)-(5))
- Summary report of the relevant findings within 8 weeks of the TLPT authority notification that both test reports are complete (Art. 12(7))
Phase 5: Remediation and attestation (RTS Art. 13-14)
Within the same 8 weeks, the entity sends its remediation plans and supporting documentation to the TLPT authority and, where different, to its competent authority (Art. 13(1)). Each finding gets a description, proposed measures with their priority and expected completion, a root cause analysis, owners, and the risks of not acting (Art. 13(2)). The authority then issues an attestation that the test was performed in accordance with the requirements (DORA Art. 26(7), RTS Art. 14), which allows mutual recognition between competent authorities.
Team Setup: Red Team, Blue Team, White Team, Purple Replay
Red Team
The testers. External testers must meet DORA Art. 27(1) and RTS Art. 7(1)(f): a manager with at least five years of penetration and red team testing experience, at least two further testers with at least two years each, at least five references, professional indemnity insurance, and separation from any staff of the same provider delivering threat intelligence for the test. Internal testers are allowed within limits (see the FAQ below).
Blue Team
The institution's in-house security operations function (SOC, incident response, threat hunting) plus any outsourced managed detection and response (MDR) providers. Operates blind during Phase 3.
White Team
The RTS calls it the control team. It is led by a control team lead with the mandate to guide every aspect of the test (recital 10), knows that the test is running, and takes the risk management decisions, including pausing a scenario. Keep it small enough to preserve confidentiality and senior enough to decide in real time. On the authority side, the TLPT authority designates a test manager and at least one alternate to oversee each test (RTS Art. 3).
Purple Replay (Phase 4)
Joint red and blue session replaying each attack path, completed by a purple teaming exercise on the vulnerabilities found (RTS Art. 12(5)). It is mandatory, and it is where the institution extracts most of the operational learning value from a TLPT.
Threat Intelligence Requirements
RTS Art. 10 governs the threat intelligence and Annex III sets the content of the report. The provider team needs a manager with at least five years of threat intelligence experience, a second member with at least two years, and at least three references (Art. 7(1)(c) and (e)). In practice the deliverable has three components:
- Targeted threat intelligence report. Identifies the threat actors most likely to target the institution given its sector, country, profile and recent industry incidents. Cites named adversary groups (APT clusters, financial crime groups, hacktivists) where the evidence supports it.
- Adversary capability mapping. Maps each identified actor's known TTPs to the MITRE ATT&CK® framework. This becomes the source for designing realistic attack scenarios.
- Attack scenario proposal. Scenarios that differ by threat actor and target each CIF in scope, from which the control team lead selects at least three (Art. 10(2)-(3)). Each specifies entry vector, lateral movement path, target objective and expected detection signal.
Vendor Selection
Selecting the testers and the threat intelligence provider is the single decision with the largest impact on TLPT quality. RTS Art. 7 turns most of the criteria into requirements:
- Qualifications. Testers are certified by an accreditation body in a Member State or adhere to formal codes of conduct or ethical frameworks (DORA Art. 27(1)(c)), and provide CVs and certifications appropriate under recognised market standards (RTS Art. 7(1)(a)).
- Team and experience. Threat intelligence: a manager with 5 years and a member with 2 years, 3 references. Red team: a manager with 5 years and two testers with 2 years each, 5 references (Art. 7(1)(c)-(f)).
- Independence. Threat intelligence staff perform no blue team tasks or other conflicting services for the entities involved, and threat intelligence and red team staff of the same provider are kept separate (Art. 7(1)(e)-(f)).
- Insurance. Professional indemnity cover, including against misconduct and negligence (Art. 7(1)(b); DORA Art. 27(1)(e)).
- Sector experience. Banking, insurance and payments have very different attack surface profiles. A provider with deep banking experience but no insurance expertise will design scenarios that miss insurance-specific risks.
- Capacity. An active phase of at least 12 weeks requires sustained senior consultant capacity. Boutique providers can be excellent but capacity-constrained.
The control team keeps the evidence on file (Art. 7(2)). Only in exceptional circumstances may a provider that misses one of these requirements be used, provided the entity adopts and records mitigating measures.
Timeline and Budget Planning
Build the schedule forward from the notification, not backwards from a date. The RTS sets these deadlines and minimums:
| Step | Deadline or minimum |
|---|---|
| TLPT authority notification (Art. 9(1)) | Starts the clock |
| Initiation information (Art. 9(2)) | Within 3 months |
| Scope specification document approved by the management body (Art. 9(6)) | Within 6 months of the notification |
| Threat intelligence (recital 18) | Typically about 4 weeks, not a legal deadline |
| Active red team testing phase (Art. 11(5)) | At least 12 weeks |
| Red team test report (Art. 12(2)) | Within 4 weeks after the active phase |
| Blue team report, replay and purple teaming (Art. 12(4)-(5)) | No later than 10 weeks after the active phase |
| Summary report and remediation plans (Art. 12(7), 13(1)) | Within 8 weeks of the authority notification that both reports are complete |
| Next TLPT (DORA Art. 26(1)) | At least every 3 years |
Validations and approvals by the TLPT authority have no deadline in the text, so no total duration can be read from the RTS. What the text does make clear is that the preparation phase is short. Provider shortlists, the CIF inventory and the contractual participation of ICT third-party service providers (DORA Art. 26(3) and 30(3)(d)) are best prepared before the notification.
Budget by cost line. DORA and the RTS set no cost figures, and we do not publish price ranges we cannot source:
- Threat intelligence provider, sized by the CIFs in scope and the number of scenarios
- External testers, for an active phase of at least 12 weeks
- Control team and internal staff time across the whole cycle, including replay and purple teaming
- Tooling and infrastructure for the test, such as additional monitoring
- Remediation, often the largest and least predictable line
For institutions operating in several Member States, the attestation under Art. 26(7) exists to allow mutual recognition between competent authorities, and RTS Art. 16 organises the cooperation between TLPT authorities. Clarify early which TLPT authority leads (RTS Art. 14(2)).
The 6 Most Common Pitfalls
- Starting too late. The preparation phase runs against a 3-month and a 6-month deadline counted from the notification. Institutions that only start looking for providers once notified compress procurement, scoping and management body approval into a few months.
- Wrong scope. Testing systems that do not support CIFs is wasted budget and triggers attestation queries. Testing only CIF-supporting systems but missing the CIFs themselves is non-compliance.
- White Team too large. The more people know the test is happening, the more likely a leak to the blue team, and the test loses validity. Keep the control team to the people who must decide.
- Insufficient kill-switch governance. If the Red Team finds a path to a critical system, the White Team needs a documented decision process for whether to proceed. Improvising in real time leads to either premature termination or operational accidents.
- No remediation budget. Remediation can cost more than the test itself. Institutions that budget only for the test discover findings they cannot afford to fix before the next cycle.
- Treating the attestation as the end goal. The attestation is a regulatory deliverable; the resilience improvement is the strategic goal. Institutions that organise around the attestation produce thinner findings and weaker remediation.
Frequently Asked Questions
Can we conduct TLPT internally without an external Red Team?
Partly. DORA Art. 26(8) allows internal testers, but an entity using them must contract external testers every three tests, and credit institutions classified as significant under Art. 6(4) of Regulation (EU) No 1024/2013 may only use external testers. Internal testers also need approval by the competent authority or the TLPT authority, sufficient dedicated resources with conflicts of interest avoided, and an external threat intelligence provider (Art. 27(2)). RTS Art. 15 adds a written policy and a test team of a lead plus at least two members employed for the preceding 12 months.
Does TLPT replace our other security testing?
No. DORA Articles 24-25 require an ongoing testing programme covering vulnerability scans, code reviews, penetration tests, scenario-based tests and end-to-end testing. TLPT is a separate, deeper exercise on top of that programme, not a replacement for it.
What happens if the Red Team finds a serious unpatched vulnerability mid-test?
The White Team escalates immediately under the documented escalation procedure. The standard practice is to pause the relevant scenario, allow the Blue Team to remediate, and then resume the test. The finding is documented in the final report.
Are findings disclosed to supervisors in detail?
The test managers of the TLPT authority receive the red and blue team test reports; at their request, the reports leave out sensitive information (RTS Art. 12(3)-(4)). The summary report of findings and the remediation plans go to the TLPT authority and, where different, to the competent authority (Art. 12(7), 13(1)), and the entity notifies its competent authority of the attestation, the summary and the plans (DORA Art. 26(7)).
Is mutual recognition automatic across EU Member States?
Not automatically. The attestation under DORA Art. 26(7) is designed to allow mutual recognition between competent authorities, and RTS Art. 16 sets the cooperation between TLPT authorities for entities operating in more than one Member State. Cross-border groups should clarify the lead TLPT authority at the start of Phase 1.
How Resiplan Supports TLPT Programmes
Resiplan is the specialised SaaS for DORA, business continuity and GRC. While Resiplan does not execute red-team operations, it manages the upstream data foundation that determines whether a TLPT can be properly scoped: the CIF Evaluation Module produces the auditable list of critical or important functions, the Register of Information generation aligns the contractual perimeter with the test scope, and the workflow engine tracks the control team governance, deliverables and attestation lifecycle. A CIF and ICT inventory that is already maintained is what makes the 6-month scope deadline comfortable.
TLPT is a recurring, three-year operational commitment that touches every part of an institution's security, technology, legal and risk functions. Treating it as a procurement exercise produces an attestation but not resilience. Treating it as a strategic programme produces both.
