DORA's TLPT Requirements: Scoping Your First Threat-Led Penetration Testing Cycle

DORA's Chapter IV (Articles 24–27) sets a tiered testing regime: Article 24 establishes the general requirements for the testing programme, Article 25 covers testing of ICT tools and systems, Article 26 introduces advanced testing through TLPT, and Article 27 sets requirements for the testers ¹. Financial entities not identified for TLPT still have to operate the general resilience-testing programme under Articles 24 and 25, including appropriate annual testing of the ICT systems and applications supporting critical or important functions.

Article 26 raises the bar for a designated subset. TLPT is intelligence-led red-teaming conducted against live production systems, covering several or all of the entity's critical or important functions (Art. 26(2)). The differences that matter:

• It uses targeted threat intelligence about threat actors, attack paths and scenarios relevant to the entity — not a generic test plan.
• It tests live production systems supporting critical or important functions.
• It is overseen by the TLPT authority. At the end, the entity submits the required test summary, remediation plan and supporting documentation; the authority issues the attestation (Art. 26(6)–(7)).

DORA's relationship with TIBER-EU is explicit. Article 26(11) required the TLPT technical standards to be developed in accordance with the TIBER-EU framework. Commission Delegated Regulation (EU) 2025/1190 now provides the binding detail and mirrors TIBER-EU's methodology, process and structure. In Luxembourg, the revised TIBER-LU programme covers mandatory DORA TLPTs as well as voluntary tests ^{1 2 3 6}.

In practical terms, TLPT tests whether the entity can prevent, detect and respond to a realistic attack against the production systems supporting its critical or important functions.

Commission Delegated Regulation (EU) 2025/1190 structures a TLPT into three phases, followed by a remediation plan ²:

1. Preparation — initiating the project, establishing the control team, assessing test risks and defining the proposed scope. The financial entity assesses which critical or important functions should be included and submits its scope specification; the TLPT authority reviews and validates the scope (Art. 26(2)).
2. Testing — producing targeted threat intelligence and conducting the active red-team test against live production systems. The active red-team testing phase must last at least 12 weeks (Art. 11(5)). In exceptional circumstances creating a risk of disruption or damage, the control team lead may suspend the test or, with prior validation from the TLPT authority, continue through limited purple teaming; that time still counts towards the 12-week minimum (Art. 11(10)).
3. Closure — preparing the red- and blue-team reports, replaying relevant actions, conducting purple teaming and producing the test summary.
4. Remediation plan — documenting root causes, prioritised actions, owners and target completion dates.

The financial entity submits the required test summary, remediation plan and supporting documentation. The authority then issues an attestation confirming that the test was performed in accordance with the requirements, primarily to support mutual recognition. The attestation does not mean that all findings have already been remediated or that the authority endorses the entity's overall resilience (Art. 26(6)–(7)) ^{1 2}.

The main participants are the entity's control team; the blue team whose prevention, detection and response capabilities are tested; the external threat-intelligence provider; the red-team testers; and the TLPT authority's test managers. The control team is deliberately small because most of the blue team should not know that the test is under way.

Before the first cycle begins, check whether the following capabilities and dependencies are ready:

• Threat-intelligence readiness. Confirm that procurement, onboarding and lead time for an external provider capable of producing targeted, entity-specific threat intelligence fit the notification-driven schedule.
• Remediation governance. The remediation plan must set out each shortcoming, its root cause, prioritised corrective actions, responsible owners and expected completion dates. The plan is due within the timetable set by Article 13 of the TLPT RTS; remediation progress then needs to be governed and evidenced ².
• Feed lessons back into the ICT risk framework. DORA Article 13(7) requires lessons from TLPT and other resilience testing to be incorporated continuously into the ICT risk-assessment process—not left in a standalone test report ¹.
• Third-party coordination. Provider participation and pooled-testing coordination can extend planning, so contractual and operational discussions should begin during the preparation phase.

A stronger first-cycle approach treats TLPT as a programme connecting targeted threat intelligence, controlled live testing, reporting and remediation with the wider ICT risk-management framework—not as a one-off procurement exercise.

The work around a TLPT is mapping Chapter IV obligations to critical or important functions, maintaining the required evidence and governing remediation after the test. Cyvalent RGX supports that work by connecting scope decisions, test evidence, findings, owners, target dates and progress reporting. See how Cyvalent RGX approaches DORA Chapter IV resilience-testing obligations — explore the approach.