- Confirmed whether your entity has been designated for mandatory TLPT by your competent authority
- Completed inventory of all critical and important functions per DORA Article 2
- Mapped all ICT systems supporting critical functions (internal + outsourced)
- Formal TLPT scope document prepared and submitted to the competent authority for validation
- Senior management sponsorship and accountability for TLPT formally assigned
- TLPT programme integrated into the annual ICT risk and resilience testing plan
What Is Threat-Led Penetration Testing?
Threat-Led Penetration Testing (TLPT) is an advanced form of cybersecurity testing mandated by DORA Articles 26–27 for significant financial institutions. Unlike standard penetration tests, TLPT is guided by real, current threat intelligence specific to the institution and its sector.
TLPT simulates the tactics, techniques, and procedures (TTPs) of the most sophisticated and most likely threat actors — nation-states, organised crime groups — that could target your institution. The goal is to discover and close exploitable vulnerabilities in live production systems before real attackers do.
Under DORA Article 26, financial institutions that meet the significance threshold must conduct TLPT at least every three years, covering all critical or important functions and their underlying ICT systems.
TLPT vs Standard Pentest — Key Differences
- Intelligence-led: driven by real threat intelligence, not generic scenarios
- Live production: tests are conducted on live systems, not isolated environments
- External red team: contracted independent red team providers required
- Regulatory oversight: competent authority involved at every phase
- Formal attestation: supervisor signs off on TLPT completion
- Remediation tracked: findings and resolution plan reviewed by authority
Important: TLPT is not a vulnerability scan or a classic pentest. It is a full-scale simulation of an advanced attack by a skilled adversary against your most critical systems — with your supervisor watching.
TLPT Scope and Methodology
What Must Be In Scope
Mandatory in scope:
- All ICT systems supporting critical or important functions
- ICT services provided by critical third parties where those services support critical functions
- Both internal and outsourced infrastructure
- Customer-facing digital channels where material
- Payment infrastructure and core banking/insurance platforms
May be excluded (with justification):
- Non-critical back-office systems with no impact on critical functions
- Legacy systems under decommissioning (authority approval required)
- Systems outside the EU regulatory perimeter (subject to authority agreement)
Pooled TLPT (Article 26(5)): Financial entities that use the same critical third-party ICT provider may conduct joint TLPT exercises, sharing costs and contributing proportionate results. Requires agreement from all participating entities and the relevant supervisors.
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.
RT
Red Team (RT) Provider
External, TIBER-EU-accredited security firm that conducts the covert attack simulation. Must be independent from the institution. Uses the TTI report to tailor the attack scenarios.
CA
Competent Authority (CA)
Your national regulator (e.g. EBA, EIOPA, ESMA or NCA). Involved from scoping through attestation. Validates scope, receives results and issues the formal TLPT attestation.
The 5-Phase Methodology
DORA TLPT follows the structured TIBER-EU methodology, adapted as legally binding:
1
Preparation & Scoping
Define scope and critical functions, engage competent authority, select and onboard TI and RT providers. Estimated: 4–8 weeks.
2
Threat Intelligence
TI provider produces the Targeted Threat Intelligence report: adversary profiles, most likely TTPs, specific attack vectors for your institution. Estimated: 6–10 weeks.
3
Red Team Test
Covert attack simulation by the RT provider on live production systems. Blue team (defenders) are typically unaware. Tests run over 8–12 weeks in most cases.
4
Closure & Purple Team
Red team reveals attack paths. Joint red + blue team (purple team) exercise: confirm exploitability, analyse detection gaps, document all weaknesses found.
5
Report & Attestation
TLPT report submitted to the competent authority. Remediation plan drafted and formally agreed. Authority issues attestation under Article 26(7).
TLPT Frequency and Planning
Mandatory Frequency
Designated entities must complete TLPT at least every 3 years. Your competent authority may require more frequent testing based on:
- A significant ICT incident affecting critical functions
- Material changes to critical ICT infrastructure
- Findings from the previous TLPT cycle that were not adequately remediated
- Risk-based supervisory assessment
TIBER-EU credit: If your institution completed a TIBER-EU test under the updated 2024+ framework before DORA entered into force, this counts as the first TLPT cycle. The 3-year clock starts from that test's completion.
Key Planning Timeline
| Milestone | Timing |
|---|---|
| Designation notification from supervisor | H1 2025 for large banks |
| Begin provider selection | 12–18 months before test |
| Scope agreement with authority | 8–10 months before test |
| TI phase | 6–10 weeks |
| RT test execution | 8–12 weeks |
| Purple team + closure | 3–4 weeks |
| Final report + attestation | 4–8 weeks |
| First mandatory TLPT deadline | 17 January 2028 |
Critical deadline: DORA Article 26(3) requires designated entities to have completed their first TLPT by 17 January 2028. Given that a full TLPT cycle takes 6–12 months from provider procurement to attestation, entities should begin planning no later than Q1 2027 — and ideally in 2025 to allow for provider scarcity.
TLPT Reporting and Remediation
TLPT Report Structure
The final TLPT report submitted to the competent authority must contain:
- Executive summary: scope, objectives, overall assessment
- TTI summary: threat actors profiled and attack scenarios used
- Attack narrative: chronological account of the red team operation
- Findings catalogue: each vulnerability with severity rating (CVSS or equivalent)
- Detection analysis: what the blue team detected vs. missed
- Remediation plan: owner, priority, and target date for each finding
Sharing and Confidentiality
TLPT reports contain highly sensitive information about live vulnerabilities. DORA manages this through:
- Reports shared only with the competent authority — not published
- Results from pooled TLPT may be shared proportionately with participating entities
- Cross-border results recognised by other EU supervisors (Article 26(5))
- Aggregated, anonymised findings may inform sector-wide ESA guidance
Remediation tracking: The competent authority will verify at the next supervisory interaction that remediation items are progressing to plan. Unresolved critical findings may trigger follow-up supervisory action.
TLPT vs Other DORA Testing Requirements
DORA mandates a full programme of resilience testing, not just TLPT. Understanding which test applies to which entity and when is essential for building your testing roadmap.
| Test Type | DORA Article | Who Must Do It | Frequency | Scope | Regulator Involvement |
|---|---|---|---|---|---|
| TLPT (Threat-Led Penetration Test) | Art. 26–27 | Significant entities designated by NCA | Every 3 years minimum | All critical/important functions, live production | High — attestation required |
| Vulnerability Assessments | Art. 25(1)(a) | All financial entities | Annual minimum; after major changes | ICT systems supporting critical functions | Low — results kept internally |
| Network Security Assessments | Art. 25(1)(b) | All financial entities | Annual minimum | Network perimeter and segmentation | Low — internal |
| Gap Analysis / ICT Risk Review | Art. 25(1)(c) | All financial entities | Annual (linked to risk assessment cycle) | ICT risk framework vs. DORA requirements | Low — feeds ICT risk report |
| Scenario-Based Testing | Art. 25(1)(d) | All financial entities | Regular — risk-based cadence | Critical function continuity, cyber scenarios | Medium — may be reviewed |
| Source Code Reviews | Art. 25(1)(e) | Entities with significant in-house development | Before major releases, periodically | Internally developed ICT applications | None — internal audit |
| Open-Source Intelligence | Art. 25(1)(f) | All financial entities | Continuous / periodic | Digital footprint, exposed assets, threat landscape | None — feeds risk assessment |
Articulation with RTS on resilience testing: The RTS on Advanced Testing (aligned with TIBER-EU, published 2025) specifies minimum standards for TLPT methodology, provider requirements, and the reporting format. Non-TLPT testing requirements are detailed in the RTS on ICT Risk Management (2024/1774, Pillar 2).
Not sure where your testing programme stands? The Gap Analysis covers all 5 DORA pillars including your testing obligations.
Run Free Gap AnalysisTLPT Implementation Checklist
Use this checklist to assess your readiness for TLPT — whether you are preparing for your first cycle or reviewing your compliance posture for the next one.
- Threat Intelligence (TI) provider selected — TIBER-EU accredited or equivalent
- Red Team (RT) provider selected — independent from TI provider and from your institution
- Both providers verified against your competent authority's approved provider list (where applicable)
- TI and RT contracts reviewed for DORA Article 26 requirements (independence, confidentiality, deliverables)
- Professional indemnity insurance coverage confirmed for both providers
- Rules of engagement document signed by all parties (institution, TI, RT, competent authority)
- Targeted Threat Intelligence (TTI) report received and reviewed — adversary profiles and TTPs validated against internal risk assessment
- Test scenarios derived from TTI report and approved by competent authority before RT phase begins
- Red team access and authorisations formally documented (no "friendly fire" risk with SOC)
- Crisis management and legal counsel briefed on test timeline (confidential — only small "white team" aware)
- Abort/pause criteria defined (e.g., if RT discovers a critical zero-day in production)
- SOC/blue team detection logging captured in full during test period for purple team analysis
- Purple team exercise conducted: all attack paths walked through jointly by RT and blue team
- Final TLPT report drafted: findings catalogued, severity rated, detection gaps analysed
- Remediation plan prepared: each finding has owner, priority level, and target date
- TLPT report submitted to the competent authority
- Formal attestation received from competent authority (Article 26(7))
- Remediation tracking process established — progress reported to board/senior management quarterly
- Lessons learned integrated into the ICT risk management framework and next testing cycle plan
Check your TLPT readiness score with our free interactive tool — covers all 5 phases with a maturity rating.
TLPT Readiness CheckerReady to Assess Your TLPT Posture?
Use our free TLPT Readiness Checker, download the full RTS TLPT guide PDF, or speak with a DORA expert about your implementation.
TLPT Readiness Checker Download TLPT Guide Expert Guidance