TLPT (Threat-Led Penetration Testing)

Threat-Led Penetration Testing (TLPT) represents the most advanced and rigorous form of security testing mandated under the Digital Operational Resilience Act (DORA). Established in Articles 26 and 27, TLPT goes far beyond conventional penetration testing by requiring financial entities to simulate realistic, intelligence-driven attack scenarios against their live production systems. The fundamental principle behind TLPT is that an organization's defensive capabilities can only be truly validated when tested against the actual tactics, techniques, and procedures (TTPs) that real-world threat actors would employ against that specific entity. This makes TLPT not just a technical exercise but a comprehensive assessment of an organization's people, processes, and technology under realistic adversarial pressure.

DORA's TLPT framework is explicitly aligned with the TIBER-EU (Threat Intelligence-Based Ethical Red Teaming) framework developed by the European Central Bank. TIBER-EU was originally introduced in 2018 as a voluntary framework for testing the cyber resilience of financial institutions across Europe. Several EU member states had already adopted national implementations -- TIBER-DE in Germany, TIBER-NL in the Netherlands, TIBER-BE in Belgium, and others -- before DORA made threat-led testing a legal requirement. DORA Article 26(11) specifically states that TLPT shall be carried out in accordance with the TIBER-EU framework, ensuring methodological consistency across the EU. The Regulatory Technical Standards (RTS) published by the ESAs further detail the requirements for TLPT, including the qualifications of testers, the scope of testing, and the reporting obligations.

The scope of TLPT under DORA applies specifically to financial entities that are identified as significant by their competent authorities. Not every financial institution must perform TLPT -- the requirement targets those entities whose failure or operational disruption could have systemic implications. Competent authorities such as BaFin in Germany identify which entities fall within scope based on factors including systemic importance, the nature and complexity of ICT-supported services, the institution's ICT risk profile, and the interconnectedness with other financial entities. The competent authority formally notifies the entity that it must conduct TLPT and specifies which critical or important functions must be included in the testing scope.

The TLPT process is structured into three distinct phases, each with specific deliverables and governance requirements. The first phase is the Threat Intelligence phase. During this phase, a qualified threat intelligence provider conducts a detailed analysis of the financial entity's specific threat landscape. This involves identifying the most relevant threat actors targeting the entity's sector and geography, analyzing their known TTPs, mapping the entity's external attack surface, and developing targeted attack scenarios that reflect realistic threats. The threat intelligence report serves as the blueprint for the subsequent red team engagement and must be reviewed and validated by the entity's competent authority before testing begins.

The second phase is the Red Team Testing phase, which constitutes the core of the TLPT exercise. Based on the scenarios developed in the threat intelligence phase, a qualified red team attempts to compromise the entity's critical or important functions using techniques that mirror real-world attacks. This testing must be conducted on live production systems -- not test environments -- to ensure that the results reflect the entity's actual security posture. The red team operates covertly, with knowledge of the engagement limited to a small control team within the entity (typically consisting of senior management and a designated TLPT project manager). The blue team (the entity's security operations and incident response staff) is deliberately kept unaware of the exercise so that their detection and response capabilities can be genuinely tested. The red team testing phase typically spans 8 to 12 weeks, during which the testers attempt to achieve specific objectives such as accessing sensitive data, disrupting critical systems, or demonstrating the ability to persist undetected within the network.

The third phase is the Closure phase, which involves comprehensive analysis, remediation planning, and regulatory reporting. After the testing is complete, the red team produces a detailed report documenting all attack paths attempted, which succeeded and which were detected, the vulnerabilities exploited, and the overall assessment of the entity's defensive capabilities. A purple team exercise is then conducted, bringing together the red team and blue team to walk through each attack scenario, share findings, and identify specific improvements. The entity must develop a remediation plan addressing all identified weaknesses, with prioritized actions and defined timelines. Both the test results and the remediation plan must be submitted to the competent authority, which may require modifications or additional actions.

DORA mandates that in-scope entities conduct TLPT at least every three years. However, the competent authority may adjust this frequency based on the entity's risk profile -- requiring more frequent testing for highly systemic institutions or accepting longer intervals for entities with demonstrated strong resilience. Each new TLPT cycle must cover all critical or important functions identified by the competent authority, though the specific attack scenarios will change based on the evolving threat landscape. Entities must also ensure continuity between TLPT cycles by tracking remediation progress and validating that previously identified weaknesses have been effectively addressed.

The requirements for qualified TLPT testers are deliberately stringent. DORA Article 27 requires that external testers perform the red team testing, with limited exceptions for internal testing subject to strict conditions. External testers must possess recognized certifications in penetration testing and red teaming, carry appropriate professional liability insurance, and demonstrate relevant experience in threat-led testing of financial sector entities. They must adhere to formal codes of conduct regarding the handling of sensitive information obtained during testing. The threat intelligence provider must similarly demonstrate expertise in financial sector threat analysis. Importantly, DORA requires that the same testing firm should not be used for more than three consecutive TLPT engagements to ensure fresh perspectives and avoid complacency.

The distinction between TLPT and regular penetration testing is fundamental and frequently misunderstood. Standard penetration testing, which DORA also requires as part of the general resilience testing program under Article 25, focuses on identifying technical vulnerabilities in specific systems, applications, or network segments. It is typically scoped narrowly, conducted in test environments, and aims to produce a list of vulnerabilities ranked by severity. TLPT, by contrast, is objective-driven rather than vulnerability-driven. The red team's goal is not to find every vulnerability but to achieve specific strategic objectives that a real attacker would pursue. TLPT tests the entire defensive chain -- from perimeter security through detection and monitoring to incident response and decision-making under pressure. A penetration test might reveal that a server is missing a patch, while TLPT reveals whether the organization can detect and respond to a sophisticated attacker who exploits that missing patch as part of a broader campaign.

Practical implementation of TLPT requires careful planning and significant organizational commitment. Financial entities should begin preparing well in advance of their testing window by establishing a TLPT governance framework that defines roles, responsibilities, and escalation procedures. The control team -- the small group within the entity who are aware of the test -- must include sufficiently senior leadership to authorize testing activities that could potentially impact production systems, while maintaining strict information barriers to preserve the integrity of the blue team assessment. Entities should budget 6 to 12 months for a complete TLPT cycle, from initial scoping through remediation verification, with the active testing phase typically spanning 10 to 14 weeks.

The costs and resource requirements of TLPT are substantial compared to standard security testing. A typical TLPT engagement for a mid-sized financial institution can cost between 200,000 and 500,000 euros, depending on the scope and complexity. This includes the threat intelligence assessment, the red team engagement, the purple team workshop, and the comprehensive reporting. However, these costs must be weighed against the potential impact of a successful cyberattack on a financial institution, which can easily reach tens of millions of euros in direct losses, regulatory fines, and reputational damage. Organizations should also factor in the internal resource commitment, including the time of the control team, the involvement of senior management in reviewing results and approving remediation plans, and the ongoing effort to implement and verify remediation actions. Compliance automation platforms can help manage the TLPT process by tracking remediation progress, maintaining evidence for regulatory reporting, and ensuring that findings are integrated into the broader ICT risk management framework.