This article is for general information only and does not constitute legal, regulatory, or compliance advice. Specific obligations under the Digital Operational Resilience Act (DORA) and related regulatory technical standards depend on an entity’s classification and should be confirmed with qualified advisors and the relevant competent authority.
For most fintech and financial entities, the conversation about the Digital Operational Resilience Act has moved beyond incident reporting and governance into one of its most demanding requirements: advanced resilience testing through Threat-Led Penetration Testing, or TLPT. Unlike routine security testing, TLPT is designed to simulate how a real, motivated adversary would attack a specific institution — and it is carried out against live production systems. This guide explains, from a compliance and decision-maker’s perspective, what TLPT is, who it applies to, how it differs from ordinary testing, and how organizations can prepare without getting lost in technical detail.
What TLPT Is — and What It Is Not
Threat-Led Penetration Testing is an advanced form of security assessment that mimics the tactics, techniques, and procedures of real-world threat actors likely to target a particular financial entity. The word “threat-led” is the key: rather than running a generic checklist of vulnerabilities, TLPT begins with tailored threat intelligence about who would realistically attack the institution and how. A specialized red team then attempts to reach defined critical functions using those realistic scenarios, testing people, processes, and technology together.
Two features set it apart from a standard penetration test. First, it is intelligence-driven, grounded in scenarios specific to the entity rather than a broad vulnerability scan. Second, it is typically conducted against live production systems rather than isolated test environments, which makes findings operationally real but also demands careful control and coordination. TLPT under DORA aligns with the established TIBER-EU framework, which many European institutions already recognize as the reference model for this kind of testing.
Who Must Comply
An important point for decision-makers is that DORA does not require every financial entity to perform TLPT. The regulation takes a risk-based, two-tier approach. Entities that are significant from a systemic or operational standpoint — identified by competent authorities on the basis of their size, risk profile, and role in the financial system — fall within scope, and certain globally systemically important institutions are automatically included. Smaller or lower-risk entities are generally not required to conduct full TLPT, though they remain subject to DORA’s other resilience-testing obligations.
This selectivity matters commercially. Being identified as in scope for TLPT is a signal of systemic importance and carries a substantial operational commitment. Entities should confirm their classification with their competent authority rather than assuming, in either direction, whether the requirement applies to them.
How the Process Works at a High Level
TLPT is a structured, multi-stage exercise rather than a single event, and DORA envisions it being conducted on a recurring basis — commonly framed as at least once every three years for in-scope entities, subject to authority direction. Once an entity is notified, it moves through defined phases: preparation and scoping, threat intelligence gathering, the red-team testing itself, and a closing phase of analysis, remediation planning, and reporting to authorities.
| Phase | Focus | Compliance Consideration |
|---|---|---|
| Preparation and scoping | Identifying critical functions to be tested and agreeing rules of engagement | Scope must reflect genuinely important functions, not a convenient subset |
| Threat intelligence | Building realistic adversary scenarios specific to the entity | Quality of intelligence determines how meaningful the test is |
| Red-team testing | Simulated attacks against live systems by qualified testers | Requires careful control to protect real operations and customers |
| Closure and remediation | Analysis, findings, remediation planning, and authority reporting | Findings must translate into tracked, prioritized improvements |
Timelines are deliberately demanding. After notification, entities generally have a limited window to submit initiation documentation and a further period to deliver a detailed scope specification. The first waves of notifications across the EU are expected around late 2026 and into 2027, with in-scope entities working toward completion over the following period. Because exact deadlines and thresholds are set in regulation and by authorities, they should always be verified against current official sources.
Why TLPT Is Operationally Harder Than Ordinary Testing
Several factors make TLPT more challenging than a conventional assessment. Testing against production systems means the exercise must be tightly controlled to avoid disrupting real services or affecting customers. The requirement for qualified, independent red-team providers and for tailored threat intelligence raises the bar on both cost and coordination. And because the test spans people, processes, and technology, weaknesses may surface in areas — such as detection and response, or internal communication — that a purely technical scan would never reach. This breadth is precisely the point: operational resilience is a whole-organization property, and TLPT is designed to test it as such. It sits alongside DORA’s broader expectations on operational resilience and incident reporting rather than replacing them.
Preparing Without Overreacting
For entities that expect to be in scope, preparation is less about last-minute scrambling and more about building durable capability. A strong posture rests on a few foundations. Knowing your critical functions is essential; you cannot scope a meaningful test without a clear picture of which services matter most and what they depend on — including the third parties behind them, which connects directly to third-party and vendor risk management. Mature detection and response determines how the organization performs when the red team attacks, so investment there pays off directly. And where testing touches automated decision or risk systems, the discipline of model risk management helps ensure those components are understood and governed. Entities that are not in scope can still treat TLPT principles as a useful benchmark, adopting proportionate testing suited to their size and risk.
Common Pitfalls
A few mistakes recur. The first is treating TLPT as a compliance checkbox rather than a genuine test of resilience; a narrowly scoped exercise that avoids uncomfortable systems produces a clean report and a false sense of security. The second is underestimating the timeline and coordination involved, particularly the need for qualified external providers and authority engagement. The third is failing to close the loop — running the test but not translating findings into tracked, prioritized remediation. The fourth is assuming scope in either direction without confirming classification with the competent authority.
Frequently Asked Questions
Is TLPT the same as a normal penetration test?
No. TLPT is intelligence-led, scenario-based, conducted against live systems, and tests people and processes as well as technology. A standard penetration test is typically narrower and not driven by entity-specific threat intelligence.
Does every fintech have to do it?
No. Only entities identified as sufficiently significant are in scope. Others remain subject to DORA’s other testing requirements but not full TLPT. Classification should be confirmed with the competent authority.
How often is TLPT required?
For in-scope entities it is generally framed as a recurring obligation — commonly described as at least every three years — but frequency and specifics are set by regulation and authority direction and should be verified against official sources.
Conclusion
Threat-Led Penetration Testing represents DORA’s most advanced resilience requirement: a realistic, intelligence-driven test of how an institution would withstand a determined attacker across people, processes, and technology. For decision-makers, the priorities are clear — confirm whether the requirement applies, understand that it is an operational commitment rather than a routine scan, and build the underlying capabilities in critical-function mapping, detection and response, and remediation that make such a test meaningful. Preparing thoughtfully turns a demanding obligation into a genuine strengthening of operational resilience.
To discuss how resilience-testing expectations intersect with your compliance operations and technology, our team is available to help you assess your readiness and plan a proportionate approach.