All Articles

What Threat-Led Penetration Testing Actually Requires Under DORA

Threat-Led Penetration Testing (TLPT) is the advanced testing obligation created by Articles 26 and 27 of Regulation (EU) 2022/2554, the Digital Operational Resilience Act (DORA). It sits above the baseline digital operational resilience testing that Article 25 requires of every in-scope financial entity. Article 25 testing (vulnerability assessments, network security assessments, gap analyses, scenario-based testing, source code review, open-source intelligence analysis) is mandatory for all financial entities on an at-least-annual basis. TLPT is not. It applies only to financial entities that a competent authority has formally identified under Article 26(8), based on impact, financial stability relevance, and ICT risk profile.

The legal text of Article 26(2) is precise about what a threat-led penetration test must do: it must cover several or all of the entity's critical or important functions, and it must be performed on the live production systems supporting those functions. This is what separates TLPT from a conventional penetration test. A standard pentest is typically scoped to a defined set of applications or network segments, often in a staging environment, and is not built around a live intelligence profile of the specific adversaries most likely to target the institution. TLPT is intelligence-led (built on a Targeted Threat Intelligence report specific to the entity), covert (the entity's own detection and response staff, referred to in the TIBER-EU framework as the Blue Team, are not told the test is happening), conducted on production infrastructure, and closed out with a regulatory attestation rather than a private vendor report.

Financial entities other than microenterprises and other than the entities excluded under Article 16(1) can be designated for TLPT. Designation is not self-assessed: it is a formal act by the competent authority (or, where a Member State has designated one, a single TLPT authority for the whole financial sector) following the criteria in Article 26(8): impact-related factors (the extent to which disruption of the entity's services would affect the financial sector), financial stability concerns (including systemic importance at Union or national level), and the entity's specific ICT risk profile and technology maturity.

Fact-Checking the Regulatory Basis: What the RTS Actually Specifies

The Joint Committee of the ESAs (EBA, ESMA, EIOPA), in agreement with the European Central Bank, was required under Article 26(11) to submit draft Regulatory Technical Standards (RTS) on TLPT to the European Commission by 17 July 2024. The final report (JC 2024-29) sets out, in binding legal text rather than guidance, the criteria for designation, the requirements for internal and external testers, the scope-setting process, the phase-by-phase methodology, and the closure and remediation obligations.

The RTS resolves a question that many summaries of TLPT get wrong: it does not create an optional choice between TIBER-EU and some other methodology. The RTS mirrors the TIBER-EU framework's structure and terminology directly, and for entities subject to TLPT, the RTS itself is the legally binding text. TIBER-EU and its national implementations may still be referred to and applied, but only to the extent they are consistent with the RTS. Where the two diverge, the RTS controls.

Which entities are designated: the actual thresholds

The RTS sets quantitative thresholds for a defined list of entity types (Article 2(1) of the RTS). This is more precise than the commonly repeated shorthand ("large banks over roughly EUR 30 billion in assets"), and CISOs should check their entity against the actual criteria rather than a size rule of thumb.

Two mechanisms soften a purely mechanical reading of these thresholds. First, an opt-out (RTS Article 2(2)): an entity that meets a quantitative threshold can still be excluded if the competent authority's assessment of impact, financial stability relevance, and ICT risk profile does not justify TLPT. Second, an opt-in (RTS Article 2(4)): entities that do not meet any quantitative threshold can still be designated on qualitative grounds, such as interconnectedness, substitutability, complexity, third-party ICT dependence, or a poor Supervisory Review and Evaluation Process (SREP) ICT risk score. Designation is therefore a mix of hard thresholds and supervisory judgment, and a CISO cannot assume exemption purely because the entity sits under a headline size figure. Formal written notification from the competent authority is what starts the clock, not self-assessment against the thresholds above.

The TIBER-EU Methodology: Correcting the Phase Structure and Durations

The European Central Bank's TIBER-EU Framework, updated in January 2025 to align explicitly with DORA, describes the test process as three mandatory phases (preparation, testing, closure), with the testing phase split into two sequential process steps (threat intelligence, then red teaming), plus one optional pre-phase (the Generic Threat Landscape report). Many public summaries compress this into a "5-phase" list for readability: Preparation and Scoping, Threat Intelligence, Red Team Test, Closure and Purple Team, and Report and Attestation. That five-step breakdown is a legitimate simplification of the same underlying process and is not incorrect, but it should not be presented as the TIBER-EU framework's own official phase count, which is three mandatory phases.

Durations are the area where public guidance most often understates the real timeline, because they mix outdated 2018-era TIBER-EU figures with the current, DORA-aligned figures. The current (January 2025) ECB framework and the RTS specify materially longer minimums than the older TIBER-EU documentation:

Adding the current minimums (roughly 6 months preparation, 4-6 weeks threat intelligence, at least 12 weeks active red teaming, and up to roughly 18 weeks of closure activity, with some overlap permitted between steps) puts a realistic end-to-end TLPT cycle in the range of 9 to 14 months from formal notification to attestation, not the shorter, unqualified "several months" framing that some guides use. Any CISO building a program plan should treat 9-14 months as the working assumption and start provider procurement well before scoping formally begins, since procurement itself is not counted inside these regulatory clocks.

The three roles: correct current terminology and composition rules

Public TLPT guides commonly describe three roles: a Threat Intelligence (TI) provider, a Red Team (RT) provider, and an internal "White Team." That terminology is accurate for the original TIBER-EU framework and remains in wide informal use, but the January 2025 ECB framework has renamed the internal oversight group. It is now formally the Control Team (CT), led by a Control Team Lead (CTL), and the framework no longer uses "White Team" as its defined term. The entity's own defenders, excluded from all knowledge of the test until closure, are the Blue Team (BT), a term that is unchanged.

A further DORA-specific rule not always captured in public guides: significant credit institutions supervised directly by the ECB under the Single Supervisory Mechanism face a tighter internal-tester restriction, reflecting the general principle that greater systemic importance pushes an entity toward mandatory external testing rather than internal testing options.

How TLPT Scope Is Actually Determined and Documented

Scope is not decided informally between the CISO and the test provider. Article 26(2) requires the entity to identify all relevant ICT systems, processes and technologies supporting critical or important functions, including those outsourced to ICT third-party providers, and the resulting assessment must be validated by the competent authority.

Under the RTS (Article 8(5)-(6) and Annex II), this happens through a mandatory Scope Specification Document, which the entity's control team must submit to the test managers within six months of receiving the TLPT authority's written notification, and which must be approved by the entity's management body before submission. The RTS specifies the selection criteria the entity must apply when deciding which critical or important functions go into scope:

• The criticality or importance of the function and its potential impact on the financial sector and financial stability, nationally and at Union level
• The importance of the function to the entity's day-to-day operations
• How exchangeable or substitutable the function is
• Interconnectedness with other functions
• The geographical location(s) in which the function operates
• The extent to which other entities in the sector depend on the function
• Available threat intelligence concerning the function, where it exists

For every function identified, the Scope Specification Document must record, per Annex II: whether it is included or excluded and why; for included functions, the ICT system(s) supporting it; whether each system is outsourced (and if so, to which ICT third-party provider); the jurisdiction(s) in which the system operates; and a high-level description of the preliminary "flags," meaning which specific security property (confidentiality, integrity, authenticity, or availability) the test is meant to validate for that system. The TIBER-EU framework's own supplementary guidance suggests, as a practical rule of thumb rather than a hard legal cap, that scoping more than around ten critical or important functions per test tends to dilute the depth and realism of the exercise. The competent authority reviews the document and must formally validate it before the preparation phase can be considered complete; this validation step is where authorities most often push back on artificially narrow scoping, such as excluding a function because a third-party contract does not yet grant testing rights over it. DORA Article 30 requires that contracts with ICT third-party providers preserve the entity's ability to conduct this testing, so a missing testing clause is a contract remediation item, not a valid basis for exclusion.

A CISO Platform member perk. FireCompass is offering CISO Platform members a free AI pen test on their own attack surface. Run yours and get exploit-validated findings that feed directly into your Article 25 baseline testing evidence, while you plan the separate TLPT track below.

Purple Teaming and the Closure Phase: The Actual Step-by-Step Process

The closure phase is where the value of TLPT is realized or lost, and it is more structured under the current RTS than most public descriptions suggest. Purple teaming, in particular, is now a mandatory activity, not an optional add-on left to the provider's discretion.

1. End of active testing. The Red Team Testers formally conclude the offensive phase, having reached, partially reached, or not reached the "flags" (validation targets) set during scoping.
2. Red Team Test Report (RTTR), due within four weeks of the end of active testing. Drafted by the RTT and delivered to the control team, it must include, at minimum: the critical or important functions and ICT systems targeted; a summary of each attack scenario used; which flags were reached and which were not; the attack paths followed, both successful and unsuccessful; the tactics, techniques and procedures (TTPs) used, successfully and unsuccessfully; any deviations from the agreed Red Team Test Plan; any "leg-ups" granted (assistance given to the testers to keep the test on schedule when they are blocked); any Blue Team actions the testers became aware of during the test; the vulnerabilities and other findings discovered, each with a criticality rating; a root-cause analysis of each successful attack path; and remediation recommendations with an indicated priority.
3. Blue Team Test Report (BTTR), due within ten weeks of the end of active testing. Once the entity's own defenders are finally informed a test took place, they produce their own account: what they detected, when, via which log entries or alerts, mapped against the Red Team's actions step by step; their own assessment of the testers' findings and recommendations; evidence of the attacks they did capture; their own root-cause analysis of detection failures; lessons learned; and topics they want to raise in the purple teaming exercise.
4. Replay exercise, within ten weeks of the end of active testing. The Blue Team and the Red Team Testers jointly walk back through the test, action by action, comparing what the attackers did against what the defenders saw (or didn't see) at each step. This is a shared reconstruction of the attack timeline, not a presentation delivered one-way by the testers.
5. Purple teaming exercise, conducted alongside or immediately after the replay, within the same ten-week window. This is now a mandatory RTS requirement (RTS Article 11(5)), not an optional extra. The Red Team Testers and Blue Team work together on the paths the attackers did not have time or budget to pursue during active testing: could this pivot have worked, would this detection control have fired, what happens if the same TTP is attempted again with the defenders now forewarned. The RTS and the current TIBER-EU guidance describe this as ranging from a tabletop, catch-and-release, or war-gaming discussion up to a hands-on collaborative proof-of-concept walkthrough on the actual systems, depending on residual risk appetite and time available.
6. 360-degree feedback meeting. The entity, the TLPT/TIBER authority, and the TI and RT providers meet to review not just the findings but the process itself: what worked, what should change for the next cycle, any process-level friction between teams or with the authority.
7. Test Summary Report (TSR) and Remediation Plan, due within eight weeks of the authority's notification that the RTTR and BTTR are adequate. The TSR is the document intended for wider, cross-authority sharing and mutual recognition, so by design it does not repeat sensitive technical vulnerability detail from the RTTR. It must record: the parties involved; the project plan; the validated scope, including the rationale for including or excluding specific critical or important functions and systems; the scenarios selected and any material deviation from the threat intelligence report; the attack paths executed; flags captured and not captured; the vulnerabilities identified at a summary level; root-cause analysis; a high-level remediation plan; and lessons learned from the 360-degree feedback. The separate Remediation Plan must set out, for each finding: a description of the shortcoming; the remediation measure and its priority and expected completion date; a root-cause analysis; the staff or function responsible; and the risk of not implementing the fix on schedule.
8. Attestation. Once the TLPT/TIBER authority has approved the Test Summary Report and Remediation Plan, it issues the attestation confirming the test was conducted in accordance with the applicable requirements, identifying which critical or important functions were covered. Where more than one authority was involved (a multi-jurisdiction or pooled test), the lead authority issues the single attestation, which is the mechanism that enables mutual recognition across the other participating authorities without each of them re-running or re-validating the same test.

Two details are frequently missed in public write-ups. First, the RTS allows a "limited purple teaming exercise" to substitute for continued active red-team testing as a last resort, for example if the Red Team Testers are detected and blocked partway through, and the time spent on that limited exercise counts toward the 12-week active-testing minimum rather than being added on top of it. Second, purple teaming under the current RTS is compulsory, which matters for program planning: it cannot be skipped to save time or cost, and its output feeds directly into the mandatory Test Summary Report.

Pooled and Joint Testing: How Article 26(4)-(5) Actually Works

DORA and the RTS distinguish two related but legally separate mechanisms for sharing a TLPT exercise across more than one financial entity, and public guides frequently blur them together under a single "pooled testing" label.

Pooled testing (Article 26(4))

Pooled testing is a narrow, specific mechanism. It applies where a financial entity and an ICT third-party service provider agree in writing that the provider will directly contract an external tester, so that a single TLPT can cover several financial entities that all rely on that provider, under the direction of one designated financial entity. This mechanism exists specifically to address a conflict: the third-party provider might reasonably expect that letting one client entity's testers loose on shared infrastructure would create an adverse impact on the quality or security of the services it delivers to other, unrelated customers (including customers outside DORA's scope entirely), or would risk the confidentiality of other customers' data. Rather than forcing each client entity to separately test the same shared infrastructure (multiplying risk to the shared environment), Article 26(4) lets the provider itself hold the tester contract and run one exercise that counts as each participating entity's TLPT.

Operationally, under RTS Article 14(5): the TLPT authorities of the entities involved agree which financial entity will be the "designated financial entity" leading the pooled test, based on the services the shared provider delivers and on testing efficiency; that entity's TLPT authority then leads the exercise, unless the authorities agree otherwise; and the TLPT authorities of the other participating entities can either observe or assign their own test manager to the exercise. The RTS also requires that pooled test scenarios include at least one scenario targeting the shared ICT third-party provider's own systems and processes supporting the critical or important functions of the entities in scope, not only scenarios aimed at each entity's own perimeter. Each participating entity's control team still runs its own risk assessment and risk management measures; the designated entity's control team additionally has to account for the fact that multiple entities are involved, and all control teams must cooperate to identify shared risks, such as a genuine single point of failure in the shared infrastructure.

The number of entities that can pool is not fixed by a numeric cap in the RTS. Instead, the lead TLPT authority may impose a maximum number of participating authorities where a larger group would compromise the test's efficient conduct, and the RTS explicitly states the number of participating entities must be "duly calibrated" to the complexity and type of shared services, which in practice authorities interpret narrowly given how demanding coordination across multiple entities, multiple national authorities, and one shared infrastructure target already is.

Joint testing (a distinct, more common mechanism)

Separately, the RTS defines joint testing for entities that belong to the same group and use common ICT systems, or that share the same ICT intra-group service provider, without needing the third-party-provider-led contracting structure that defines pooled testing. Where entities meeting the designation criteria belong to the same group and share common systems, their TLPT authorities decide jointly whether TLPT should be run individually for each entity or as a single joint exercise. A joint test is explicitly preferred over multiple individual tests wherever it would reduce cost and resource burden without compromising the soundness of the test, which is the RTS's own stated rationale for consolidating testing across a corporate group.

What this means for cost-sharing in practice

Neither DORA nor the RTS specifies a cost-sharing formula. What they specify is the coordination mechanism (designated/lead entity and authority, shared scenario coverage, joint risk assessment) that makes cost-sharing among the participating entities commercially and contractually possible; the actual apportionment of the shared provider's fee among the pooled or joint participants is a private commercial arrangement between those entities, not a regulatory calculation. CISOs evaluating whether pooling makes sense for their institution should treat the regulatory mechanism as an enabler of a lower per-entity cost, not as a guarantee of one, since coordination overhead across multiple control teams, multiple national TLPT authorities, and a single shared target can offset some of the savings from splitting a single provider contract three or four ways.

Cost Ranges: What Can Be Verified

Neither DORA, the RTS, nor the TIBER-EU framework publishes cost figures or benchmark price ranges; the ESAs' own impact assessment for the RTS discusses costs and benefits qualitatively (noting, for example, that the RTS raised certain designation thresholds partly in response to industry cost-burden feedback), without publishing a specific EUR figure that public guides could cite as an official number. Cost figures circulating in commercial guides (for example, per-component ranges for the threat intelligence report, the red team execution, and control-team coordination, alongside an aggregate total-cycle figure) originate from market surveys and vendor pricing data collected by commercial TLPT advisory firms, not from the regulation itself. Any cost range presented to a board should therefore be sourced and labeled as a market estimate, not a regulatory figure, and should be revisited against actual vendor quotations once the entity has a validated scope, since price is highly sensitive to the number of critical or important functions in scope, whether providers must cover third-party-hosted infrastructure, and current provider capacity constraints in the entity's jurisdiction.

The January 2028 Deadline: What Is and Is Not Established

The frequently cited "17 January 2028" first-mandatory-TLPT deadline does not appear as an explicit calendar date inside DORA's own Article 26 or 27 text, nor inside the RTS text as reviewed. Article 26 sets a recurring three-year testing cycle once an entity is designated, and the RTS ties phase deadlines to the date of the competent authority's written notification to the entity, not to a single EU-wide calendar date. The commonly repeated January 2028 figure functions in industry commentary as a practical implied deadline: DORA applied from 17 January 2025, the RTS's own testing-cycle logic points to a three-year designation-to-first-test runway, and 17 January 2028 is exactly three years after DORA's application date. Treat it as a reasonable planning anchor and an industry-standard shorthand, not as a figure that appears verbatim as a hard deadline in the statute or the RTS. Entities should rely on the date stated in their own written notification from their competent authority, since that notification, not a single Union-wide date, is what starts each entity's individual three-year clock under Article 26(1).

TLPT Versus Baseline DORA Testing

Implementation Checklist for CISOs and Execution Teams

Governance and scoping

• Confirm designation status directly against written notification from the competent/TLPT authority; do not rely solely on the RTS quantitative thresholds as a self-assessment, since opt-in on qualitative grounds is possible even below the thresholds
• Inventory all critical or important functions per DORA Article 3(22) and cross-reference against the entity's DORA Register of Information
• Map every ICT system, process and technology supporting each critical or important function, explicitly including outsourced and third-party-hosted systems
• Verify that contracts with ICT third-party providers preserve testing rights under DORA Article 30; treat any missing clause as a contract remediation item, not a scoping exclusion
• Draft the Scope Specification Document per RTS Annex II and obtain management-body approval before the six-month submission deadline from written notification
• Assign the Control Team (Control Team Lead plus a small number of named specialists); document who is aware the test is happening and keep that list to the minimum necessary

Provider procurement

• Begin TI and RT provider procurement well ahead of the RTS's internal phase clocks; provider capacity in the accredited TIBER-EU/DORA market is limited and lead times of 12-18 months are commonly reported by advisory firms
• Verify the TI provider's certifications, minimum three prior threat-intelligence references, professional indemnity insurance, and staffing (manager with 5+ years, at least one additional analyst with 2+ years) against RTS Article 5(2)
• Verify the RT provider's certifications, minimum five prior assignment references, professional indemnity insurance, and staffing (manager with 5+ years, at least two additional testers with 2+ years each) against RTS Article 5(2)
• Confirm the TI and RT providers are organizationally separated from each other, even where both roles happen to be delivered by the same parent firm
• If considering internal testers for the Red Team role, confirm eligibility against RTS Article 13 (documented policy, minimum three-person team, 12 months' tenure, no conflicts of interest) and obtain prior competent authority approval; remember external testers are still required at least once every three test cycles

Execution

• Confirm the Threat Intelligence Provider's report is genuinely institution-specific (named threat actors, TTPs, and attack vectors relevant to this entity's business model and technology stack), not a generic sector threat landscape repackaged as targeted intelligence
• Ensure the agreed Red Team Test Plan and Rules of Engagement define abort/pause criteria in advance, including discovery of an unrelated critical vulnerability or a genuine live incident overlapping with the test window
• Plan for a minimum of 12 weeks of active red team testing; do not assume the test can be compressed to hit an internal deadline
• Keep the Blue Team genuinely uninformed until closure; document immediately and notify the authority if any inadvertent disclosure occurs, since it may require scope adjustment or a partial replay

Closure, attestation and remediation

• Budget for the full closure sequence (RTTR, BTTR, replay, mandatory purple teaming, 360-degree feedback, Test Summary Report, Remediation Plan, attestation), which can run past 18 weeks after the end of active testing
• Treat purple teaming as mandatory, not optional, and ensure Blue Team participants come prepared with their own detection timeline before the replay session
• Assign a named, board-accountable owner to every finding in the Remediation Plan, with a priority level and a realistic completion date
• Report remediation progress to the board and risk committee on a recurring cadence, and expect the competent authority to follow up on outstanding critical findings at the next supervisory review
• If pooling or joint testing with other group entities or shared-provider clients, confirm in writing which entity is the designated/lead entity, which authority leads, and how the shared provider's contract addresses testing rights and cost allocation, before scoping begins

Frequently Asked Questions

Is TLPT the same as a standard penetration test?

No. TLPT is built on institution-specific threat intelligence, runs on live production systems rather than test environments, legally requires independent accredited external providers for the Threat Intelligence and Red Team roles (except in the narrow, approved internal-tester scenario), and concludes with a supervisory attestation rather than a private report. A standard penetration test has none of these characteristics and does not satisfy the TLPT obligation.

Can an entity use an internal red team?

Only in defined exceptional circumstances, with prior competent authority approval, a documented internal-tester policy, a minimum three-person team with at least 12 months' tenure at the entity, and no conflicts of interest. Even where internal testers are approved, the entity must still contract external testers at least once every three test cycles, and the Threat Intelligence provider must always be external, regardless of whether the Red Team is internal or external.

What is the difference between the "White Team" and the "Control Team"?

They refer to the same function. "White Team" was the term used in the original TIBER-EU framework and remains in wide informal use. The ECB's January 2025, DORA-aligned update to the TIBER-EU framework renamed this internal oversight group the Control Team, led by a Control Team Lead. Both terms describe the small internal group that knows the test is underway, manages scoping and risk controls, and liaises with the authority, as distinct from the Blue Team, which remains unaware until closure.

Does purple teaming happen automatically, or does the entity have to request it?

Under the current RTS, purple teaming is a mandatory closure-phase activity, required within the same window as the replay exercise (within ten weeks of the end of active testing). It is not something the entity opts into separately, and its output must feed into the Test Summary Report.

What exactly must be in the Red Team Test Report?

At minimum: the targeted critical or important functions and ICT systems, a summary of each scenario used, flags reached and not reached, successful and unsuccessful attack paths, TTPs used, deviations from the agreed test plan, any leg-ups granted, Blue Team actions the testers observed, discovered vulnerabilities with criticality ratings, root-cause analysis of successful attacks, and prioritized remediation recommendations. It is due to the control team within four weeks of the end of active testing.

How does pooled testing actually work if we share a cloud provider with other banks?

Pooled testing under Article 26(4) applies specifically where the shared ICT third-party provider itself contracts the external tester, because testing the shared environment on behalf of one client entity could otherwise create risk to that provider's other customers or their data confidentiality. The TLPT authorities of the participating entities agree on a designated lead entity and lead authority; at least one test scenario must target the shared provider's own systems, not just each entity's individual perimeter; and each participating entity's control team still runs its own risk assessment. The number of entities that can pool is calibrated by the lead authority to the complexity of the shared service, not fixed by a numeric rule in the regulation. Joint testing, a related but separate mechanism for group entities sharing common systems or an intra-group ICT provider, does not require this third-party-led contracting structure.

Is 17 January 2028 a legally fixed deadline?

It does not appear as an explicit calendar date in DORA Articles 26-27 or in the RTS text. It is widely used in industry commentary as the practical implied deadline, since DORA applied from 17 January 2025 and the regulatory testing cycle logic points to roughly a three-year runway from application. The actual deadline that binds any individual entity is set by that entity's own written notification date from its competent authority, plus the applicable cycle length, not by a single Union-wide date.

What triggers enforcement action under Article 50?

Finding vulnerabilities during TLPT is the intended outcome and does not itself trigger enforcement. Enforcement risk arises from failing to conduct TLPT once formally designated, materially inadequate or artificially narrow scoping, failure to remediate critical findings within the timeline agreed with the competent authority, or from TLPT findings that expose broader, pre-existing governance failures under DORA's ICT risk management provisions (Articles 5-16).

As a CISO Platform member, you get free access. Ready to see what continuous, validated testing surfaces on your own attack surface while you plan your TLPT track? Start your free AI pen test.

Not yet a CISO Platform member? Join CISO Platform for free to access compliance guides like this one, peer benchmarking, and the community discussion on DORA and TLPT readiness.

About Priyanka Aash
Priyanka Aash is Co-Founder of CISO Platform, the world's first online community for information security executives, and Co-Founder of FireCompass. She has been nominated for the Cybersecurity Excellence Award for leadership and AI innovation in cybersecurity, honored with the NetApp Excellerate HER award, and featured in SC Media's Women in IT Security series. She is the author of The AI Divide. Security technologist Bruce Schneier advises FireCompass.