DORA TLPT: Threat-Led Penetration Testing Requirements 2026

What Is Threat-Led Penetration Testing?

Threat-Led Penetration Testing (TLPT) is the most advanced form of cybersecurity testing mandated by DORA Articles 26–27. Unlike standard penetration tests, TLPT is guided by real, current threat intelligence specific to your institution and its sector, not generic attack scenarios.

TLPT simulates the tactics, techniques, and procedures (TTPs) of the most sophisticated threat actors that could realistically target your institution: nation-state-sponsored groups, organised financial cybercriminals, and insider-threat scenarios. Crucially, tests are conducted on live production systems, not isolated test environments, making findings operationally real.

Under DORA Article 26(1), financial entities identified by their competent authority must carry out TLPT at least every three years. Each test covers several or all critical or important functions and is performed on the live production systems supporting them, including those outsourced to ICT third-party service providers (Article 26(2)).

TLPT serves two purposes simultaneously: (1) identifying exploitable vulnerabilities that simpler testing methods miss; and (2) measuring the organisation's actual detection, response and recovery capability against a real adversarial attack, not theoretical performance against a test-environment threat.

                    TLPT vs Standard Pentest: Key Differences
                    Intelligence-led: driven by real Targeted Threat Intelligence (TTI), not generic scenarios
Live production: tests on live systems, real exposure, real consequences
Testers set in law: Article 27 and RTS Article 7 fix tester and threat intelligence requirements; internal testers only under Articles 26(8) and 27(2)
Regulator involved: competent authority present at every phase, from scoping through attestation
Formal attestation: written attestation from supervisor required to complete the cycle
Remediation tracked: authority verifies remediation progress at next supervisory interaction

                

                     Not optional for identified entities: TLPT is not a best-practice recommendation. It is a legally binding obligation under DORA Article 26 for the entities your competent authority identifies. There is no EU-wide date for a first TLPT: the test starts on notification from the TLPT authority (RTS (EU) 2025/1190, Article 9(1)). Not carrying it out exposes the entity to the administrative penalties and remedial measures laid down by national law under Article 50.
                

Who Must Conduct TLPT: Designation Criteria

TLPT is not required of all DORA-in-scope entities. Competent authorities identify the entities that must perform it, on impact-related factors, financial stability concerns and ICT risk profile (DORA Article 26(8), third subparagraph), applying the criteria of RTS (EU) 2025/1190, Article 2. The TLPT itself starts when the TLPT authority notifies the entity that a test is to be carried out (RTS Article 9(1)).

Sector Thresholds

There is no total-assets threshold. RTS (EU) 2025/1190, Article 2(2), uses sector tests instead: payment institutions above EUR 150 billion of payment transactions, electronic money institutions above that figure or EUR 40 billion of outstanding electronic money (both in each of the two preceding calendar years), trading venues on market share, insurers on premiums, technical provisions and assets.

Systemic Importance

Credit institutions identified as G-SIIs or O-SIIs, or belonging to one, and all central securities depositories and central counterparties are on the RTS Article 2(2) list: the TLPT authority requires them to perform TLPT unless its assessment shows it is not justified.

Cross-Border Relevance

The RTS weighs whether the entity provides services in one or more Member States and how interconnected it is (Article 2(1)(a)). The attestation issued after the test exists to allow mutual recognition between competent authorities (DORA Article 26(7); RTS Article 16).

Risk-Based Designation

The ICT risk factors of RTS Article 2(1)(b) include the entity's risk profile and threat landscape, the complexity of its ICT architecture, its reliance on ICT third-party service providers, the outcomes of supervisory reviews of its ICT maturity, and the maturity of its detection and response. An entity outside the Article 2(2) list can be identified on these grounds.

Am I Designated?

The TLPT starts on a notification from the TLPT authority (RTS Article 9(1)); without one, no test is running for you. Identification can change with your size or risk profile, so entities near the Article 2(2) thresholds should check the criteria against their own figures each year.

Voluntary Participation

Entities not required to conduct TLPT may voluntarily do so, and many do, as TLPT remains the gold standard for advanced resilience testing. Voluntary TLPT under the same DORA framework is a recognised good-practice signal to supervisors, rating agencies, and institutional investors.

            How many entities? Neither DORA nor RTS (EU) 2025/1190 fixes a number of entities to be identified, and we do not publish a count we cannot source. The reliable signal for your entity is the notification from your TLPT authority.
        

TLPT Scope and 5-Phase Methodology

What Must Be In Scope

Mandatory in scope:

The critical or important functions selected for the test (several or all, Article 26(2)), with the ICT systems, processes and technologies supporting them
ICT services provided by critical third parties (CTPPs) where those services support in-scope functions, including cloud-hosted infrastructure
Both internal and outsourced infrastructure, regardless of hosting location
Customer-facing digital channels where material to critical functions
Payment infrastructure and core banking, insurance, or trading platforms

May be excluded (with justified documentation):

Non-critical back-office systems with no material impact on critical functions
Legacy systems under active decommissioning (authority approval required)
Systems outside the EU regulatory perimeter (subject to NCA agreement)

                     Pooled TLPT (Article 26(4)): Where an ICT third-party service provider's participation could harm the quality, security or confidentiality of its services to other customers, the provider and the financial entity may agree in writing that the provider contracts an external tester directly, for a pooled TLPT run under the direction of one designated financial entity. It counts as TLPT for each participating entity.
                

The 3 Core Roles

TI

Threat Intelligence (TI) Provider

Independent provider that produces the Targeted Threat Intelligence (TTI) report. Must be separate from the Red Team provider. Profiles the most relevant threat actors and their TTPs for your institution's specific risk profile, sector, and geopolitical exposure.

RT

Red Team (RT) Provider

Testers who execute the covert attack simulation against live production systems. External testers must meet DORA Article 27(1) and RTS Article 7(1)(f): a manager with at least 5 years of penetration and red team testing experience plus at least two testers with at least 2 years each, five references, professional indemnity insurance, and separation from the threat intelligence staff. Uses the TTI report to design realistic, tailored attack scenarios.

WT

White Team (Internal)

A small, strictly compartmentalised internal group (CISO, legal, senior IT risk) who are aware TLPT is underway while the rest of the organisation, including the SOC: remains unaware. Manages rules of engagement, legal authorisations, abort criteria, and liaison with the competent authority.

The 5-Phase TIBER-EU Methodology

RTS (EU) 2025/1190 was drafted in accordance with TIBER-EU and sets the phases in law: preparation (Article 9), testing, split into threat intelligence (Article 10) and the red team test (Article 11), closure (Article 12), then remediation (Article 13) and attestation (Article 14). The timings below cite the RTS; where it sets none, we give none.

1

Preparation & Scoping

Define test scope and critical functions, engage the TLPT authority, initiate provider procurement. Scope specification document approved by the management body, then by the TLPT authority. RTS: initiation information within 3 months of the notification, scope specification document within 6 months (Article 9(2) and 9(6)).

2

Threat Intelligence

TI provider produces the Targeted Threat Intelligence (TTI) report: adversary profiles, most likely TTPs, specific attack vectors for your institution's risk profile. RTS: typically about 4 weeks (recital 18); at least three scenarios selected (Article 10(3)).

3

Red Team Test

Covert attack simulation on live production systems. Blue team (SOC) is unaware. Attack scenarios derived from the TTI report. Abort/pause criteria active throughout. RTS: active phase of at least 12 weeks (Article 11(5)).

4

Closure & Purple Team

Red team reveals all attack paths. Joint RT + blue team (purple team) exercise: confirm exploitability, analyse detection gaps, document every weakness found and missed. RTS: red team report within 4 weeks, blue team report and replay within 10 weeks of the end of the active phase (Article 12).

5

Report & Attestation

Summary report submitted to the TLPT authority. Remediation plan drafted and submitted. Authority conducts attestation review and issues written attestation under Article 26(7). RTS: summary report and remediation plans within 8 weeks of the authority notification that both test reports are complete (Articles 12(7) and 13(1)).

Selecting and Qualifying Your TLPT Providers

Provider qualification is one of the most consequential, and most often underestimated, aspects of TLPT preparation. Both your TI provider and your testers must meet the requirements of DORA Article 27 and RTS (EU) 2025/1190, Article 7. The control team keeps the evidence on file (Article 7(2)); only in exceptional circumstances may a provider that misses one of the requirements be used, with mitigating measures adopted and recorded.

Threat Intelligence Provider Requirements

The TI provider must demonstrate:

TI Provider Qualification Criteria

Proven capability in financial-sector threat intelligence, not generic cyber threat feeds
Access to primary intelligence sources (closed forums, C2 infrastructure analysis, dark web monitoring)
Demonstrable experience profiling threat actors relevant to the EU financial sector (e.g. Lazarus Group, Carbanak, state-linked APTs)
A manager with at least 5 years of threat intelligence experience plus one member with at least 2 years, and at least three references (RTS Article 7(1)(c) and (e))
Staff separated from the testers of the same provider and performing no blue team tasks for the entities involved (RTS Article 7(1)(e)(iv)-(v)); report content as set in RTS Annex III
Contractual confidentiality covering TTI report contents (which describe live attack vectors)

Red Team Provider Requirements

The RT provider must demonstrate:

RT Provider Qualification Criteria

Certification by an accreditation body in a Member State, or adherence to formal codes of conduct or ethical frameworks (DORA Article 27(1)(c))
Proven red team experience in financial services environments, not just general enterprise IT
Capability to execute the full kill chain against live production: reconnaissance, initial access, lateral movement, exfiltration simulation
Adequate professional indemnity insurance to cover potential production system impacts
No prior relationship with the institution that would reduce operational realism
Contractual obligation to follow Rules of Engagement and abort/pause protocols

            Plan procurement before the notification: RTS Article 7 sets minimum team sizes, experience and references for the threat intelligence provider and the external testers, and provider selection happens in the preparation phase, which runs against the 3-month and 6-month deadlines counted from the TLPT authority notification (Article 9). The regulation does not say how many providers qualify: check availability early rather than relying on market estimates.
        

            Ask your TLPT authority: DORA and the RTS do not create an EU register of approved TLPT providers. Ask your TLPT authority what evidence it expects against Article 27 and RTS Article 7, and keep the CVs, certifications, insurance and references on file (Article 7(2)).
        

TLPT Frequency and Planning Timeline

Mandatory Frequency

Identified entities must carry out TLPT at least every 3 years (Article 26(1)). Based on the entity's risk profile and operational circumstances, the competent authority may ask to reduce or increase that frequency. Circumstances an authority may weigh (examples, not a list set by DORA):

A significant ICT incident affecting critical functions during the prior period
Material changes to critical ICT infrastructure (major cloud migration, core system replacement)
Prior TLPT findings that were not adequately remediated within agreed timelines
Risk-based supervisory assessment indicating elevated threat exposure

                    No transitional credit in the text: Neither DORA nor RTS (EU) 2025/1190 contains a rule that counts a TIBER-EU test run before the RTS entered into force (8 July 2025) as a first TLPT cycle. Ask your TLPT authority how it treats a recent TIBER-EU exercise.
                

Key Planning Milestones

Step (RTS (EU) 2025/1190)	Deadline or minimum
TLPT authority notification (Art. 9(1))	Starts the clock
Initiation information to the test managers (Art. 9(2))	Within 3 months
Scope specification document, approved by the management body (Art. 9(6))	Within 6 months of the notification
Threat intelligence (recital 18)	Typically about 4 weeks
Active red team testing phase (Art. 11(5))	At least 12 weeks
Red team test report (Art. 12(2))	Within 4 weeks after the active phase
Blue team report, replay and purple teaming (Art. 12(4)-(5))	No later than 10 weeks after the active phase
Summary report and remediation plans (Art. 12(7), 13(1))	Within 8 weeks of the authority notification that both reports are complete
Next TLPT	At least every 3 years (DORA Art. 26(1))

             No EU-wide first deadline: DORA sets no date by which a first TLPT must be completed. The 17 January 2028 date often quoted is the Commission's review of DORA (Article 58(1)), not a TLPT deadline. What binds you is the clock of RTS (EU) 2025/1190, which starts with the TLPT authority notification: 3 months for the initiation information, 6 months for an approved scope. Preparing the functions inventory, the contractual participation of ICT third-party service providers (DORA Article 26(3)) and the provider shortlist before the notification is what keeps those deadlines achievable.
        

TLPT Reporting and Supervisory Attestation

TLPT Report Structure

The final TLPT report submitted to the competent authority must contain all of the following, per the TLPT RTS report template:

Executive summary: scope, objectives, overall assessment and key findings
TTI summary: threat actors profiled and attack scenarios selected
Attack narrative: chronological account of the red team operation, including reconnaissance, access methods, and lateral movement paths
Findings catalogue: each vulnerability with severity rating (CVSS or authority-specified equivalent)
Detection analysis: what the blue team detected, when, and what was missed, including analysis of detection gaps
Remediation plan: each finding mapped to an owner, priority level, and target remediation date

What the Authority Reviews for Attestation

The competent authority's attestation under Article 26(7) is substantive, not rubber-stamped. Before issuing attestation, authorities typically verify:

Scope completeness: all critical functions covered; exclusions documented and justified
Provider independence: TI and RT providers met qualification requirements
Methodology compliance: test followed TLPT RTS framework; TTI report quality meets standards
Findings completeness: all vulnerabilities documented with appropriate severity ratings
Remediation plan credibility: each finding has an owner, priority, and realistic timeline

                    Conditional attestation: The authority may issue attestation subject to remediation of specific critical findings within a defined timeframe. Failure to meet those remediation commitments will be reviewed at the next SREP interaction.
                

Sharing and Confidentiality

Reports shared only with the competent authority: not published or shared with third parties
Pooled TLPT results may be shared proportionately with participating entities
Attestation issued to allow mutual recognition between competent authorities (Article 26(7))
Aggregated, anonymised findings may inform sector-wide ESA guidance publications

TLPT Cost and Budget Planning

TLPT is a material investment, but neither DORA nor RTS (EU) 2025/1190 sets a cost, and we do not publish price ranges we cannot source. The RTS does fix the inputs that drive a quote: team sizes and experience (Article 7), at least three scenarios (Article 10(3)) and an active red team phase of at least 12 weeks (Article 11(5)). Budget by cost line:

Threat intelligence A manager with at least 5 years' experience plus one member with at least 2 years (Article 7(1)(e)); scales with the functions in scope

Red team A manager with at least 5 years plus two testers with at least 2 years (Article 7(1)(f)), for an active phase of at least 12 weeks

Control team Internal staff time across the cycle: coordination, rules of engagement, replay and purple teaming (Articles 9(4) and 12(5))

Remediation Depends on the findings; often the least predictable line, planned through the Article 13 remediation plan

Cost Reduction: Pooled TLPT

For institutions relying on the same ICT third-party service provider, pooled testing under Article 26(4) lets the provider contract one external tester for a TLPT run under the direction of one designated financial entity, which counts as TLPT for every participant. Sharing one test can lower the cost per entity; DORA gives no figure, and the saving depends on how the participants split it. The coordination overhead is real (several control teams, several authorities).

Budgeting for the Full 3-Year Cycle

Boards should understand that TLPT cost does not end with attestation. Remediation of findings (particularly critical and high-severity items) can substantially exceed the test cost itself. A TLPT revealing fundamental weaknesses in network segmentation or privileged access controls may require a multi-year remediation programme with dedicated budget. Best practice is to present the board with a total-cost-of-resilience-testing view: TLPT procurement + remediation investment + increased monitoring during the test period, amortised over the 3-year cycle.

Additionally, budget for the next cycle before the current one closes: TLPT recurs at least every 3 years (Article 26(1)), and the preparation deadlines run again from the next notification.

TLPT vs All Other DORA Testing Requirements

DORA mandates a full programme of digital resilience testing under Article 25 (all entities) and Article 26 (designated entities). TLPT is the apex. It does not replace the mandatory annual baseline testing that all entities must conduct.

Test Type	DORA Article	Who Must Do It	Frequency	Scope	Regulator Involvement
TLPT	Art. 26–27	Entities identified by the competent authority (Art. 26(8))	Every 3 years minimum	Several or all critical or important functions, live production	High: attestation required
Vulnerability Assessments	Art. 25(1)	All financial entities	Annual; after major changes	ICT systems supporting critical functions	Low: results kept internally
Network Security Assessments	Art. 25(1)	All financial entities	Annual minimum	Network perimeter and segmentation	Low: internal
Gap Analysis / ICT Risk Review	Art. 25(1)	All financial entities	Annual (linked to risk cycle)	ICT risk framework vs. DORA requirements	Low: feeds ICT risk report
Scenario-Based Testing	Art. 25(1)	All financial entities	Regular: risk-based cadence	Critical function continuity, cyber scenarios	Medium: may be reviewed
Source Code Reviews	Art. 25(1)	Entities with significant in-house dev	Before major releases; periodically	Internally developed ICT applications	None: internal audit
Open-Source Intelligence	Art. 25(1)	All financial entities	Continuous / periodic	Digital footprint, exposed assets	None: feeds risk assessment

Not sure where your testing programme stands across all 7 types? The Gap Analysis covers your full DORA testing obligations.

Run Free Gap Analysis

5 Fatal Errors That Derail TLPT Programmes

Based on TIBER-EU exercise experience and DORA supervisory feedback, these are the five errors that most frequently invalidate TLPT results, delay attestation, or force costly re-runs.

1

Tipping Off the Blue Team

The most common and most damaging error. TLPT's core value is measuring actual detection capability: how quickly your SOC identifies a sophisticated attacker operating in your environment. If any member of the blue team (SOC analysts, monitoring personnel, incident responders) is aware that TLPT is underway, detection metrics become meaningless. Even well-intentioned informal briefings ("stay alert this month") contaminate results. The White Team must be strictly limited to the absolute minimum needed for legal and operational management, typically three to five people. Any breach should be documented and reported to the competent authority immediately, as it may require scope adjustment or partial replay.

2

Starting Provider Procurement Too Late

DORA sets no EU-wide date for a first TLPT, so the pressure comes from elsewhere: once the TLPT authority notifies you, RTS (EU) 2025/1190 gives 3 months for the initiation information and 6 months for a scope specification document approved by the management body (Article 9), and provider selection sits inside that preparation phase. Providers must meet the team, experience and reference requirements of Article 7; a provider that misses one can be used only in exceptional circumstances, with mitigating measures recorded (Article 7(2)). Starting procurement after the notification compresses all of this into a few months. TLPT programme planning belongs on the CISO's agenda before the notification arrives.

3

Generic Threat Intelligence with No Institution-Specific Profiling

The Targeted Threat Intelligence report must be genuinely targeted: specific to your institution's business model, market position, geographic exposure, and technology stack. A generic "EU financial sector threat landscape" report does not satisfy TLPT requirements and will not produce meaningful attack scenarios for the red team. Common symptoms of poor TTI: attack scenarios that apply equally to any bank; adversary profiles with no institution-specific indicators; no analysis of your specific third-party dependencies, supply chain, or publicly exposed assets. Competent authorities reviewing TLPT reports have flagged generic TTI as a basis for conditional or withheld attestation.

4

Inadequate Scope Definition

Deliberately or inadvertently excluding critical systems from TLPT scope is the fastest path to conditional attestation or enforcement action. Common scope failures include: excluding critical-function systems hosted by third parties because "the provider won't allow it" (DORA requires contractual testing rights: negotiate these in advance); excluding legacy systems without documented justification; defining "critical functions" too narrowly to avoid testing complexity; and scoping out recently acquired business lines. The competent authority's scope validation in Phase 1 is specifically designed to catch these failures before the test begins, but institutions that present artificially narrow scope proposals may receive them back with expansion requirements that delay the entire programme.

5

Weak Remediation Governance After Attestation

Attestation is not the end of the TLPT cycle. It is the beginning of the remediation phase. Institutions that treat TLPT as a box-ticking exercise complete once attestation is received, without building genuine remediation governance, face predictable consequences: critical findings are still open at the next SREP interaction; supervisors ask for evidence of remediation progress that does not exist; and the institutional learning from the test, the real resilience value, evaporates. Best practice requires: each finding assigned a named owner with board-level accountability; quarterly remediation progress reports to the risk committee and board; a formal closure process for each finding with evidence of verification; and integration of lessons learned into the next testing cycle plan, the ICT risk management framework, and operational monitoring rules.

TLPT Implementation Checklist

Use this checklist to assess your readiness for TLPT, whether you are preparing for your first cycle or reviewing your posture before the next one.

Confirmed whether your entity has been formally designated by your NCA for mandatory TLPT
Completed inventory of all critical or important functions per DORA Article 3(22) and your Register of Information
Mapped all ICT systems supporting critical functions: internal and outsourced, including CTPP-hosted infrastructure
Formal TLPT scope document prepared and submitted to the competent authority for Phase 1 validation
Senior management and board accountability for TLPT formally assigned and documented
TLPT programme integrated into the annual ICT risk and resilience testing plan
Third-party contract audit rights verified: can your red team legally test CTPP-hosted infrastructure?

Threat Intelligence (TI) provider selected: team, experience, references and insurance per RTS Article 7(1)(b), (c) and (e)
Red Team (RT) provider selected: separated from the TI staff, team and experience per RTS Article 7(1)(d) and (f)
Evidence kept on file for both providers: CVs, certifications, insurance, references (RTS Article 7(2))
TI and RT contracts reviewed for DORA Article 27 requirements (independence, confidentiality, deliverables, RoE obligations)
Professional indemnity insurance coverage confirmed for both providers (adequate to cover production system risk)
Rules of Engagement (RoE) document drafted and signed by all parties, including abort/pause criteria
White Team members identified and briefed: strictly limited to minimum required (3–5 people)

Targeted Threat Intelligence (TTI) report received, reviewed, and validated as institution-specific (not generic)
Red team test plan, built on the TTI report, approved by the control team and the TLPT authority before the active phase begins (RTS Article 11(3))
Red team access and authorisations formally documented, no "friendly fire" risk with SOC or incident responders
Crisis management and legal counsel briefed on test timeline under White Team compartmentalisation protocol
Abort/pause criteria defined and communicated to White Team (critical zero-day, production instability, real incident overlap)
SOC/blue team detection logging captured in full during test period for purple team analysis: do not alter monitoring rules

Purple team exercise conducted: all attack paths walked through jointly by RT and blue team, detection gaps documented
Final TLPT report drafted: findings catalogued, severity rated, detection gaps analysed per TLPT RTS report template
Remediation plan prepared: each finding has a named owner, priority level (Critical/High/Medium/Low), and target date
TLPT report submitted to competent authority in required format
Formal attestation received from competent authority under Article 26(7)
Remediation governance established: quarterly board reporting, named accountable owners for each finding
Lessons learned integrated into ICT risk management framework, monitoring rules, and next testing cycle plan

Check your TLPT readiness score across all 5 phases with our free interactive tool: includes a maturity rating.

TLPT Readiness Checker

TLPT Frequently Asked Questions

Key questions about TLPT in practice. For broader DORA compliance questions, see our full DORA FAQ.

Is TLPT the same as a standard penetration test?

No. TLPT is fundamentally different from a standard penetration test in four ways: (1) Intelligence-led. TLPT is driven by real threat intelligence (the Targeted Threat Intelligence report) specific to your institution and its most likely adversaries, not generic attack scenarios; (2) Live production scope, tests are conducted on live production systems, not isolated test environments, making findings operationally real; (3) Tester requirements set in law. The threat intelligence provider is always external, testers must meet DORA Article 27 and RTS (EU) 2025/1190 Article 7, and internal testers are allowed only under the conditions of Articles 26(8) and 27(2); (4) Regulatory oversight, your competent authority is formally involved at every phase and issues a binding attestation upon completion. A standard pentest has none of these characteristics.

How does my institution know if it must conduct TLPT?

Your competent authority identifies the financial entities required to perform TLPT, based on impact-related factors, financial stability concerns and ICT risk profile (DORA Article 26(8), third subparagraph). RTS (EU) 2025/1190, Article 2(2), lists the entities the TLPT authority shall require to perform TLPT unless its assessment shows it is not justified: credit institutions identified as G-SIIs or O-SIIs or belonging to one, payment institutions above EUR 150 billion of payment transactions and electronic money institutions above that figure or EUR 40 billion of outstanding electronic money (in each of the two preceding calendar years), central securities depositories, central counterparties, trading venues meeting market-share tests, and insurance and reinsurance undertakings meeting premium, technical-provision and asset tests. There is no total-assets threshold. The TLPT then starts on a notification from the TLPT authority (RTS Article 9(1)). If you have not been notified, no TLPT is running for you yet, though identification can change with your size or risk profile.

Can we use an internal red team for TLPT?

Yes, within limits. DORA Article 26(8) allows internal testers, but an entity using them must contract external testers every three tests, and credit institutions classified as significant under Article 6(4) of Regulation (EU) No 1024/2013 may only use external testers. Under Article 27(2), internal testers also require approval by the competent authority or the TLPT authority, sufficient dedicated resources with conflicts of interest avoided, and an external threat intelligence provider. RTS (EU) 2025/1190, Article 15, adds a written policy and a test team of a lead plus at least two members employed for the preceding 12 months. Separately, a small internal control team (the RTS term for what TIBER-EU practice long called the White Team) coordinates the test and manages the rules of engagement. The Blue Team (defenders, typically the SOC) is informed only after the active red team testing phase (RTS Article 12(1)).

What is the "white team" and why does it matter?

The White Team is a small group within the institution (typically CISO, legal counsel, senior IT risk officer, and crisis management representative) who are aware that the TLPT is underway while the rest of the organisation, including the SOC, remains unaware. The White Team serves several critical functions: they manage the rules of engagement and legal authorisations; they define pause/abort criteria (for example, if the red team discovers a genuine zero-day in production); they serve as the single point of contact with the competent authority during the test; and they ensure the red team has the necessary access without triggering real incident responses that could derail the exercise. Keeping the White Team small and strictly compartmentalised is essential, any leak to the Blue Team invalidates the detection measurement.

What happens if the red team finds a critical zero-day during a live test?

The Rules of Engagement document (agreed before the test begins) defines the abort and pause criteria, including the discovery of critical zero-day vulnerabilities or evidence of a pre-existing real attacker in the system. If the red team discovers a critical unpatched vulnerability that poses immediate risk to live operations or customer data, the White Team may invoke an emergency pause. The vulnerability is immediately disclosed to the CISO and remediation begins, with the test resuming once the critical risk is mitigated. The TLPT RTS also requires contingency procedures for scenarios where the red team's activity inadvertently causes system instability. All such events must be documented and included in the final TLPT report submitted to the competent authority.

How is a previous TIBER-EU test counted under DORA?

TIBER-EU is the ECB framework for threat intelligence-based ethical red teaming, introduced in 2018 on a voluntary basis. DORA TLPT is a legal obligation for the entities identified by their competent authority. RTS (EU) 2025/1190 was drafted in accordance with TIBER-EU and mirrors its methodology, process and structure; entities may apply TIBER-EU or a national implementation in as much as it is consistent with DORA Articles 26 and 27 and the RTS (recital 1). Neither DORA nor the RTS contains a rule that counts a TIBER-EU test run before the RTS entered into force (8 July 2025) as a first TLPT cycle: how a recent exercise is taken into account is a question for your TLPT authority. Once a TLPT is notified, the RTS deadlines run from that notification (Article 9), and the test recurs at least every 3 years (DORA Article 26(1)).

Does TLPT need to cover third-party ICT providers?

Yes, where those third-party ICT providers support critical or important functions, their services must be within the TLPT scope. If a Critical ICT Third-Party Provider (CTPP) provides infrastructure supporting your core banking platform, that infrastructure must be tested, regardless of who owns it. This has significant practical implications: the financial entity must have contractual audit and testing rights in place (required under DORA Article 30) that enable the red team to test third-party-hosted systems. Article 30(3)(d) requires contracts supporting critical or important functions to oblige the provider to participate and fully cooperate in the TLPT, and Article 26(3) leaves the financial entity fully responsible for securing that participation. Where the participation could harm the provider's other customers, Article 26(4) allows pooled testing: the provider contracts an external tester directly for a TLPT run under the direction of one designated financial entity, which counts as TLPT for each participating entity.

What does the competent authority verify before issuing attestation?

The competent authority's attestation under DORA Article 26(7) is not automatic, it follows a substantive review of the TLPT report. Authorities typically verify: (1) Scope compliance (whether all critical and important functions were covered and any exclusions were properly justified; (2) Provider independence) that TI and RT providers meet independence and qualification requirements; (3) Methodology compliance (that the test followed the TLPT RTS framework, including the TTI report quality; (4) Findings completeness) that all discovered vulnerabilities are documented with appropriate severity ratings; (5) Remediation plan adequacy, that each finding has a responsible owner, priority level, and realistic timeline. Attestation may be conditional: the authority may issue attestation subject to remediation of specific critical findings within a defined timeframe.

Can a TLPT finding result in a DORA fine?

DORA does not make a vulnerability found during a TLPT a breach in itself: finding weaknesses before real attackers do is the purpose of the test. What can expose an entity to the administrative penalties and remedial measures that Member States lay down under Article 50 is failing the obligations around the test: (1) not carrying out TLPT once identified by the competent authority (Article 26(1)); (2) missing the deadlines of RTS (EU) 2025/1190 that run from the TLPT authority notification, such as the scope specification document within 6 months (Article 9(6)); (3) a scope that leaves out critical or important functions without justification (Article 26(2)); (4) not delivering the remediation plans (RTS Article 13); or (5) findings that reveal failures of the ICT risk management framework required by DORA Articles 5 to 16. In those cases the TLPT findings become evidence of broader ICT risk governance failures. DORA sets no EU-wide penalty amount for financial entities: amounts depend on national law.

How should TLPT findings be prioritised for remediation?

RTS (EU) 2025/1190, Article 13(2), requires a remediation plan entry for each finding: a description of the shortcoming, the proposed measures with their prioritisation and expected completion, a root cause analysis, the staff or functions responsible, and the risks of not implementing the measures. The plans go to the TLPT authority within 8 weeks of its notification that the red and blue team reports are complete (Article 13(1)). Neither DORA nor the RTS sets remediation deadlines per severity: the entity proposes them. A practical ranking combines exploitability (how easily a real attacker could use the finding), impact on critical or important functions, and detectability (would current monitoring catch an exploitation attempt?).

Best practice, consistent with supervisory expectations: prioritises by a combination of exploitability (how easily a real attacker could use this finding), impact on critical functions (does exploitation affect payment processing, core banking, or customer data?), and detectability (would your current monitoring catch an exploitation attempt?). Critical findings (high exploitability, high impact, low detectability) should be remediated within 30–90 days. High findings within 90–180 days. Medium and low findings within the next cycle planning window. All remediation progress should be reported to the board quarterly and to the competent authority at the next SREP interaction. Failing to achieve remediation timelines agreed with the authority is itself a compliance risk.

Related Resources

RTS TLPT: Full Technical Guide (HTML) TLPT Methodology: Phase-by-Phase Guide TLPT Explained: In-Depth Article TIBER-EU Alignment with DORA TLPT All DORA RTS/ITS Standards Overview DORA Gap Analysis Tool (Free) What is DORA? Complete Guide Incident Reporting Requirements