Digital operational resilience TLPT (2026 Guide)

Your board asks a simple question after a high-profile breach hits your sector: “Have we tested whether a real attacker could compromise our critical services?” If you are responsible for DORA delivery, you quickly realize that traditional penetration tests often answer a narrower question than supervisors care about. Under DORA, threat-led penetration testing is designed to validate digital operational resilience end-to-end, across people, process, and technology, and in many cases across dependencies that sit outside your perimeter.

This guide explains what digital operational resilience TLPT means in practice for EU-regulated financial entities since DORA became applicable in January 2025. You will see how TLPT fits into the DORA testing pillar, what “threat-led” changes compared to conventional testing, how scope and control gates typically work, and what evidence you should be ready to show your National Competent Authority. If you need a refresher on the broader resilience concept, start with what is digital resilience, then come back to the TLPT specifics.

Table of Contents

Where TLPT sits in DORA’s testing pillar

Who may be in scope, and what triggers TLPT

What “threat-led” means operationally

Scoping critical functions and realistic attack paths

TLPT lifecycle and deliverables under DORA

Tester requirements, independence, and conflict management

Governance, control gates, and defensibility

Evidence you should produce and retain

Common TLPT failure modes and how to avoid them

Where TLPT sits in DORA’s testing pillar

DORA’s digital operational resilience testing requirements sit under the regulation’s testing pillar. The core concept is that you must test your ability to withstand, respond to, and recover from ICT-related disruptions, and you must do so proportionately to your size, business model, and risk profile.

Threat-led penetration testing is the most demanding form of testing described in DORA. It is not intended to replace the baseline testing program. It typically complements vulnerability assessments, scenario-based testing, tabletop exercises, control testing, and technical penetration tests that you run as part of your ongoing program for digital operational resilience testing.

Now, when it comes to supervisory expectations, TLPT is about demonstrating outcomes, not only documenting processes. That is why the “threat-led” element matters. You use real-world adversary tactics and credible threat intelligence to design test objectives that meaningfully challenge the controls protecting critical or important functions, including the operational dependencies you rely on to deliver them.

For many institutions, the practical work starts by aligning terminology and program structure internally. The difference between “DORA testing,” “cyber testing,” and “operational resilience testing” is a recurring friction point. Your DORA program should translate testing artifacts into governance language that senior management can act on. The Dorapp platform is one option institutions use to structure DORA-aligned workflows and evidence across resilience activities, so teams do not rely on email chains and ad hoc spreadsheets for approvals and traceability.

Who may be in scope, and what triggers TLPT

DORA TLPT is not automatically mandatory for every financial entity. DORA Article 26 sets the framework for threat-led penetration testing and anticipates that competent authorities will identify which entities should perform TLPT, typically using a risk-based approach. In practice, supervisory selection and timing can depend on factors such as systemic relevance, complexity, and the criticality of ICT-supported services.

Consider this scenario: a mid-sized investment firm has a lean IT function and outsources key elements of trading support and customer onboarding to specialized providers. The firm may assume TLPT is “only for large banks.” Yet the concentration and criticality of outsourced services, combined with a high-threat business line, can put testing maturity under scrutiny even if formal TLPT selection is uncertain. The reality is that you should be able to explain, defensibly, why you are or are not ready for TLPT at short notice.

What many compliance teams overlook is that TLPT readiness depends on upstream basics. If your critical services inventory is incomplete, or your dependency mapping is weak, you cannot scope TLPT credibly. That is where links to your broader DORA baseline become operationally important, including your understanding of what is ict risk and how it connects to resilience priorities.

If you need a structured DORA reference point for the regulation itself, align your internal definitions with the broader digital operational resilience act requirements and your authority’s expectations. This reduces time lost in governance debates when a testing plan needs approval.

What “threat-led” means operationally

Threat-led testing is not simply a red team exercise with a stronger narrative. It is a test approach anchored in threat intelligence about likely adversaries, relevant tactics, and realistic attack paths against your institution’s critical functions.

From an operational standpoint, “threat-led” usually changes three things.

Objectives are resilience-oriented: you validate whether attackers can meaningfully impact confidentiality, integrity, availability, and operational continuity of critical services, not just whether a system is vulnerable.

Scope is end-to-end: you include people, processes, and technology, including handoffs between teams and, where feasible, critical dependencies.

Controls are tested under realistic constraints: detection, escalation, response, and recovery are part of the evaluation, not an afterthought.

Think of it this way: a conventional penetration test might show that an internet-facing application has a weakness, while a threat-led approach asks whether an attacker can traverse identities, endpoints, cloud control planes, and operational workflows to disrupt settlement, payments, policy administration, or another critical function.

For compliance and risk teams, the “threat-led” dimension also changes governance. You must manage ethical and operational risk, including safe testing windows, kill-switch criteria, and clear decision rights. Those controls need evidence, because supervisors often focus on whether the institution ran the test responsibly and learned from it, not only on the technical findings.

Scoping critical functions and realistic attack paths

The hardest part of TLPT is not running the technical activity. It is defining scope that is narrow enough to be safe and deliverable, but wide enough to be meaningful for digital operational resilience.

A defensible scoping process typically starts from the top: critical or important functions, the business services that support them, and the ICT assets and providers that those services depend on. You should then define “crown jewels” and the plausible attacker objectives that would create real business impact.

Start with business impact, then map to technical paths

In practice, this means you translate business impacts into technical test objectives. If the critical impact is “inability to process customer payments for four hours,” the technical path may involve identity compromise, manipulation of workflow queues, or disruption of API connectivity between systems and providers.

This is where teams often discover gaps in service mapping. The scoping phase becomes an indirect validation of your DORA foundations. Many institutions use the scoping work to strengthen their broader testing program under dora digital resilience testing, so that future tests are easier to authorize and evidence.

Include third-party dependencies without creating unmanageable risk

Including third parties can be essential when critical services rely on cloud platforms, managed security services, core banking software, or other ICT services. Yet it is also where TLPT can fail operationally due to contractual constraints, unclear authorizations, or provider reluctance.

You should treat third-party involvement as a structured negotiation and risk decision, not a last-minute email request. Confirm who owns authorization to test, what provider testing policies allow, how evidence will be shared, and how you will avoid unplanned service disruption. If your institution already struggles to keep vendor information consistent across the year, that friction is a signal to tighten your DORA governance baseline, using the definition and scope boundaries set out in what is digital operational resilience act.

TLPT lifecycle and deliverables under DORA

A recurring gap in many TLPT discussions is the lifecycle itself. Under DORA Articles 26 and 27, TLPT is not just “run a red team and write a report.” It is a controlled resilience exercise with clear phases, decision points, and deliverables that you may need to justify to your National Competent Authority, subject to how your authority implements oversight and how the ESA technical standards are applied.

From a practical standpoint, a defensible TLPT cycle usually includes the stages below. Your institution may name them differently, but the underlying control intent tends to be consistent.

1) Preparation and authority alignment

This is where you confirm whether you are in scope, establish points of contact with the relevant competent authority where required, and agree the governance mechanics that prevent testing from creating unmanaged operational risk. If you are part of a group, this is also where you set entity-level accountability boundaries, so approvals and outcomes are clearly attributable to the regulated entity.

2) Threat intelligence and scenario definition

“Threat-led” means you can explain why the selected adversary behaviors are credible for your business model and sector exposure. Your documentation should show the threat intelligence inputs you used and how you translated them into one or more scenarios that connect to critical or important functions.

3) Scoping and rules of engagement

This stage locks the scope in a way that is meaningful but safe. In most institutions, you will need explicit sign-off on target boundaries, excluded areas, testing windows, safety controls, escalation paths, and stop criteria. If third-party dependencies are in scope, confirm technical and contractual constraints early and document any compensating assurance where direct testing is not possible.

4) Execution and control gate management

During execution, your control gates matter as much as your technical actions. Supervisors and internal audit functions commonly look for evidence that you stayed within approved boundaries, handled sensitive access responsibly, and escalated at the right time when risk increased. In practice, this often means maintaining a decision log and a clean trail of approvals for any material change.

5) Closure, reporting, and remediation governance

For DORA defensibility, the closure package should connect outcomes to action: prioritized findings, business impact interpretation, remediation ownership and target dates, and retest planning or risk acceptance where remediation is not feasible. What the regulation actually requires is continuous improvement driven by testing, not a one-off artifact.

This content is for informational purposes only and does not constitute legal advice. For institution-specific decisions on TLPT design, authority engagement, and deliverables under DORA Articles 26 and 27, you should seek qualified legal or regulatory counsel and consider relevant ESA guidance as it evolves.

Tester requirements, independence, and conflict management

Competitor content often goes deeper than most institutional TLPT playbooks on one point: tester eligibility. Under Article 27 of DORA, financial entities must only use testers for TLPT that meet specific suitability, capability, and independence expectations. This requirement is easy to underestimate, especially when procurement and security teams default to familiar vendors without mapping them to DORA’s criteria.

In practice, you should be ready to evidence how you assessed the testers against DORA’s requirements, including:

Suitability and reputability, including any due diligence your institution typically performs for high-risk providers.

Technical and organizational capability, including specific expertise in threat intelligence, penetration testing, and red team testing.

How certification, accreditation, or adherence to formal codes of conduct and ethical frameworks was validated, where applicable.

How independence and conflicts of interest were managed, particularly if internal testers are used.

How professional indemnity insurance coverage was verified for external testers, consistent with Article 27 expectations.

Now, when it comes to internal testers, Article 27 introduces additional constraints and approvals. In many cases, your ability to use internal resources may depend on competent authority approval and on demonstrating conflict management and resource adequacy. It is also common to separate the threat intelligence function from internal execution to protect objectivity, subject to the specific supervisory approach taken in your Member State.

Consider this as a governance test, not just a vendor selection exercise. If you cannot show a clear rationale for tester selection and independence safeguards, your TLPT can become vulnerable in audit and supervisory discussions even if the technical execution is strong.

This content is for informational purposes only and does not constitute legal advice. Testing eligibility, accreditation expectations, and competent authority approvals can be subject to supervisory interpretation. You should seek qualified legal or regulatory counsel when designing your TLPT resourcing model.

Governance, control gates, and defensensibility

Supervisors tend to care about governance because TLPT introduces real operational risk. You should be prepared to demonstrate who authorized the test, what controls constrained it, and how you ensured independence and competence of the testers.

Here’s the thing: the most common TLPT governance gap is unclear decision rights. If you cannot show that senior management understood the objectives, approved the risk, and received outcomes, your test can look like a technical exercise disconnected from DORA’s resilience intent.

Typical governance elements you should be able to evidence

Documented scope, objectives, and success criteria approved by accountable owners.

Rules of engagement, including safety controls, escalation paths, and stop criteria.

Segregation of duties, including maker-checker style approvals for scope changes and critical decisions.

Clear handling of sensitive outputs, such as exploit details and privileged access artifacts.

Integration into remediation governance, including deadlines and risk acceptance where remediation is not feasible.

For EU groups, add one more complexity: entity-level accountability. Group security teams often want to run a single red team program, while DORA compliance is assessed at the regulated entity level. Your governance package should clearly show which entity approved what, how shared services were handled, and how residual risks are owned.

Some institutions implement workflow control gates in dedicated tooling to reduce execution risk, especially when multiple teams must sign off on scope, testing windows, and remediation. Dorapp’s platform approach, based on controlled workflows and audit-ready records, is one example of how teams can make approvals and evidence less dependent on individual inboxes, particularly for third-party dependencies and board reporting.

Evidence you should produce and retain

TLPT can generate large volumes of sensitive evidence. Your challenge is to retain what is necessary for audit and supervisory defensibility while applying strict access controls.

Evidence should show not only what the testers did, but what you learned and changed. A credible DORA posture typically includes a clear chain from test scenario to finding to remediation to retest or closure decision.

In practice, TLPT evidence packages often include:

Threat intelligence rationale, including why the chosen threat actor profiles and tactics were relevant.

Scope documentation, including target systems, identity boundaries, and excluded areas with justification.

Rules of engagement, safety controls, and incident escalation procedures used during testing.

Testing artifacts, such as attack path narratives, logs of key actions, and proof-of-compromise, stored securely.

Detection and response performance observations, including gaps in monitoring, escalation, and containment.

Remediation plan, ownership, target dates, and evidence of closure or risk acceptance.

Management reporting, including concise outcomes and prioritized actions.

What many compliance teams overlook is the need to reconcile TLPT findings with other DORA registers and governance outputs. If TLPT reveals that a critical service depends on an undocumented integration or subcontractor, you should update the underlying service and third-party records and ensure consistency with the rest of your DORA evidence set. This is why teams often connect TLPT outputs back to the broader operational resilience documentation described in the digital operational resilience act framework.

Common TLPT failure modes and how to avoid them

TLPT programs fail more often due to operational weaknesses than due to technical complexity. If you want a test that stands up to scrutiny, focus on the failure patterns supervisors and internal audit teams repeatedly see.

Failure mode 1: Scope that is either cosmetic or uncontrolled

Cosmetic scope happens when the test targets non-critical systems because critical services are hard to authorize. Uncontrolled scope happens when testers move into sensitive areas without pre-approved boundaries. Both undermine credibility.

To mitigate this, define scope from critical functions, approve boundaries explicitly, and keep a decision log for any scope change. Build in hard stop criteria and escalation thresholds that are owned by accountable business and IT leaders.

Failure mode 2: Findings that do not translate into resilience improvements

If TLPT ends as a report that sits in a folder, you have not improved resilience. DORA expects testing to feed continuous improvement. That requires remediation governance with deadlines, ownership, and closure evidence.

Align your remediation workflow with existing risk governance so you can demonstrate traceability. Some institutions use DORA-focused workflow tooling, such as Dorapp, to maintain auditable remediation tracking, approvals, and periodic reporting, especially where multiple lines of defense must review and sign off.

Failure mode 3: Third-party friction that blocks meaningful testing

Third parties may refuse testing or require long lead times. If you wait until scoping is finalized to engage vendors, TLPT timelines can collapse.

Engage providers early, confirm contractual testing rights, and document constraints and compensating controls where direct testing is not feasible. If a provider is critical, you should be able to explain how you gain assurance over that dependency through alternative testing, attestations, and ongoing oversight.

Frequently Asked Questions

How is TLPT different from a standard penetration test under DORA?

A standard penetration test usually targets specific systems or applications to find exploitable weaknesses. Under DORA Article 26, TLPT is designed to be threat-led and resilience-focused, meaning it typically validates realistic attacker objectives against critical services and tests more than technical controls. You should expect broader scope across identities, detection and response, operational workflows, and in some cases critical third-party dependencies. The deliverable is not only a vulnerability list, but a defensible narrative of attack paths, resilience gaps, and prioritized remediation aligned to critical or important functions.

Does every financial entity subject to DORA need to perform TLPT?

Not necessarily. DORA anticipates that competent authorities may identify which entities must conduct TLPT, based on risk, complexity, and supervisory priorities. Even if you are not selected, you still must run an appropriate testing program under the testing pillar. Many institutions treat TLPT readiness as a maturity target because selection can change over time and because TLPT scoping relies on strong foundational artifacts. A practical starting point is to align your testing program with digital operational resilience testing and document the rationale for your testing choices.

What should you scope first when preparing for a TLPT cycle?

Start from business impact and critical or important functions, then map to the services and ICT assets that enable them. Your first scoping outputs should include: the critical service(s) to be tested, the end-to-end service chain, key identity and privilege boundaries, and the plausible attacker objectives that would cause material disruption. If you cannot trace service scope to risk and business impact, you will struggle to justify why the test is meaningful. This ties back to your broader DORA understanding of what is digital resilience and how resilience is governed.

How do you handle third-party providers in TLPT without breaching contracts?

You need explicit authorization, not implied permission. Review contracts and provider testing policies early, confirm the precise conditions for testing (windows, method restrictions, notification rules), and document what is in scope. Where direct testing is constrained, you may need compensating assurance, such as validated reports, targeted control testing, or alternative scenario-based exercises. If a provider is critical to the delivery of critical services, you should be able to explain how the limitation affects your residual risk posture and what governance decision you took. This is also why DORA programs must connect testing to broader obligations under the digital operational resilience act.

What kind of governance evidence do supervisors typically expect for TLPT?

Expect to show who approved the test and how you controlled operational risk. Governance evidence often includes approved scope and objectives, rules of engagement, escalation and stop criteria, documented segregation of duties, and a clear decision trail for scope changes. Supervisors may also focus on independence and competence of testers and how sensitive results were protected. You should be able to show that senior management received outcomes and that remediation was tracked to closure or risk acceptance. The emphasis is usually on demonstrable control, not only on producing a technically detailed report.

How do you connect TLPT findings back to your ICT risk management framework?

TLPT should update risk understanding, not sit outside governance. If TLPT demonstrates exploitable paths to disrupt critical services, you typically need to reassess inherent and residual risk, review control effectiveness, and update remediation plans with clear ownership. Use the findings to refine KRIs, detection engineering priorities, and third-party oversight actions. This is where alignment with what is ict risk becomes practical: TLPT often reveals the real drivers of ICT risk that are not visible in purely document-based assessments.

How often should TLPT be performed under DORA?

DORA Article 26 frames TLPT as a periodic requirement for entities in scope, with timing subject to the applicable regulatory technical framework and competent authority expectations. In practice, frequency can vary and may be influenced by your risk profile, complexity, and the outcomes of prior tests. You should avoid building a program that only “wakes up” for a TLPT cycle. Supervisors typically expect evidence of continuous improvement, so your broader testing plan, including scenario-based testing and control testing, should operate year-round and feed governance reporting.

What are common mistakes in “threat-led” test design?

The most common mistake is choosing a threat story that sounds realistic but does not tie back to critical services and measurable business impact. Another is treating the exercise as purely technical, without testing detection, escalation, and decision-making under pressure. Teams also underestimate the lead time needed for third-party coordination and internal approvals. Your design should start with credible threat intelligence, define clear success criteria, and explicitly state what you are testing and what you are not. For internal alignment, it helps to keep definitions consistent with what is digital operational resilience act materials.

How can tooling help without turning TLPT into a “checkbox exercise”?

Tooling should support governance and evidence quality, not replace expert judgment. The value is usually in workflow control (who approves what, and when), consistent evidence capture, and traceability from findings to remediation. A DORA-focused platform can also reduce operational friction, especially when multiple lines of defense must review outputs and when board reporting requires consistent narratives. Dorapp, for example, is structured around controlled workflows and audit-ready records across DORA processes, which can help teams show that TLPT outcomes drove measurable improvement rather than producing isolated reports.

What are the tester requirements for TLPT under DORA?

Under Article 27 of DORA, TLPT testers must meet requirements related to suitability, capability, and independence, and external testers are expected to be appropriately covered by professional indemnity insurance. If you use internal testers, additional conditions may apply, including competent authority approval and stronger conflict-of-interest controls. The practical expectation is that you can evidence your due diligence, independence assessment, and safeguards for handling confidential information and business risk during the test. This content is for informational purposes only and does not constitute legal advice, so you should seek qualified counsel for institution-specific application.

What are the 5 pillars of DORA, and where does TLPT fit?

DORA is commonly explained through five pillars: ICT Risk Management, ICT-related incident reporting, digital operational resilience testing, ICT third-party risk management, and information-sharing arrangements. TLPT sits within the digital operational resilience testing pillar and is typically treated as an advanced test for entities in scope under Article 26. Even where TLPT is not mandatory, it is often used as a maturity benchmark because it forces you to validate end-to-end resilience across critical services and dependencies.

Is TLPT required every three years under DORA?

DORA Article 26 establishes TLPT as a periodic requirement for entities identified as in scope, with details influenced by the applicable technical standards and competent authority practice. Many market discussions reference a three-year cycle, and that cadence may be used in some supervisory contexts, particularly for more significant entities. You should treat frequency and scheduling as subject to supervisory expectation and proportionality and confirm the approach applicable to your entity with qualified counsel and, where appropriate, your competent authority.

What are typical TLPT deliverables you should be ready to show supervisors?

Supervisors typically expect a defensible package that shows the lifecycle and control intent, not just technical output. This may include: the threat intelligence rationale and scenario, approved scope and rules of engagement, evidence of control gates and decision logs during execution, tester due diligence aligned to Article 27, and a closure package showing prioritized findings, remediation ownership, deadlines, and retesting or risk acceptance decisions. The precise format can vary by competent authority and by how ESA technical standards are implemented.

Key Takeaways

TLPT under DORA Article 26 is a resilience-focused, threat-informed test that typically goes beyond conventional penetration testing.

Credible TLPT scope starts from critical or important functions and maps to realistic attacker objectives and end-to-end dependencies.

Governance matters as much as technical execution: approvals, safety controls, segregation of duties, and decision traceability should be evidence-backed.

TLPT outputs should feed continuous improvement, including remediation tracking, risk reassessment, and updates to service and dependency mapping.

Early third-party engagement is often the difference between meaningful coverage and constrained, low-value testing.

Conclusion

TLPT is one of the clearest ways to prove that your digital operational resilience program is more than documentation. It forces you to connect critical services to real attacker behavior, evaluate whether controls work under realistic conditions, and demonstrate that governance can authorize high-risk testing responsibly. For many EU financial entities, TLPT readiness is shaped less by technical capability and more by the maturity of service mapping, third-party coordination, and remediation governance.

If you are building or refining your testing program after DORA’s January 2025 application date, use TLPT planning to strengthen the foundations that also support your wider dora digital resilience testing obligations. If you want to see how a dedicated DORA compliance platform can help structure evidence, approvals, and remediation traceability across resilience activities, you can explore Dorapp at DORApp Functions or discuss your operating model with the team via Book a Demo.

Regulatory Disclaimer: This article is provided for informational and educational purposes only. It does not constitute legal advice and should not be relied upon as a substitute for qualified legal or regulatory counsel. DORA compliance obligations vary depending on the nature, scale, and risk profile of each financial entity. Always consult with a qualified legal advisor or compliance professional regarding your specific obligations under the Digital Operational Resilience Act and applicable Regulatory Technical Standards. DORA interpretation and supervisory expectations may evolve as the European Supervisory Authorities (EBA, ESMA, EIOPA) publish additional guidance and as National Competent Authorities refine supervisory practices. This content reflects available information at the time of publication and should be verified against current ESA publications. DORA applies to EU-regulated financial entities as defined under Regulation EU 2022/2554.