DORA TLPT: threat-led penetration testing requirements for financial entities

The short answer

DORA Article 26 requires significant financial entities to conduct Threat-Led Penetration Testing (TLPT) at least every three years. TLPT is a structured, intelligence-driven red team exercise targeting live production systems — not a standard penetration test. It must be conducted by qualified external testers following a recognised framework (TIBER-EU or equivalent national framework). DORA has been fully applicable since 17 January 2025.

Who must conduct TLPT

TLPT is not required for all DORA in-scope entities. It applies to significant financial entities as designated by competent authorities. The criteria for designation include:

In practice: Major banks, investment firms, central counterparties, central securities depositories, payment institutions of systemic importance, and critical ICT third-party service providers designated by the ESAs.

Smaller in-scope entities (below the significance threshold) are not required to conduct TLPT but must implement proportionate advanced testing under Art. 25.

• Systemic importance to the financial sector
• Scale of ICT infrastructure
• Nature of activities (clearing, settlement, payment systems, significant deposit-taking)

TLPT vs standard penetration testing

| Dimension | Standard pen test | TLPT (DORA Art. 26) |

|---|---|---|

| Scope | Defined systems, pre-agreed scope | Live production environment, critical functions |

| Intelligence-driven | No — checklist/vulnerability scan | Yes — threat intelligence specific to the entity |

| Red team vs blue team | Typically offensive only | Full red-blue exercise (red team attacks, blue team defends unaware) |

| Tester requirements | No regulatory requirement | Qualified external testers — TIBER-EU certified or equivalent |

| Regulators involved | None | Competent authority oversight required |

| Duration | Days to weeks | Typically 3–6 months (planning, execution, remediation) |

| Frequency | No regulatory requirement | At minimum every 3 years |

The TIBER-EU framework

TIBER-EU (Threat Intelligence-Based Ethical Red Teaming) is the ECB-developed framework that DORA Art. 26 references as the recognised TLPT methodology for the EU financial sector.

TIBER-EU has three phases:

Phase 1 — Preparation (4–6 weeks)

• Scope definition — critical functions, supporting systems, people, processes, technologies
• Procurement of Threat Intelligence Provider (TIP) and Red Team Provider (RTP)
• Notification to competent authority
• White team set up (internal TLPT team, regulator liaison — red and blue teams remain unaware of each other)

Phase 2 — Testing (8–12 weeks)

Threat intelligence phase:

Red team phase:

• TIP produces a Targeted Threat Intelligence (TTI) report specific to the entity
• TTI covers: threat actor landscape, likely attack vectors, realistic attack scenarios
• TTI delivered to Red Team Provider (not to blue team or business)
• RTP executes simulated attacks based on TTI scenarios
• Live production systems targeted (with appropriate safeguards)
• Blue team defends without knowledge that TLPT is in progress
• All actions logged and timestamped

Phase 3 — Closure (4–6 weeks)

• Red team debrief with blue team ("purple teaming")
• Findings remediation plan
• TLPT report produced
• Report submitted to competent authority
• Closure letter issued by competent authority

Tester qualification requirements

DORA Art. 26(2) requires TLPT testers to be:

Where internal testers are permitted (competent authority discretion for certain entities), the internal red team must be fully segregated from the ICT security function and must use an external threat intelligence provider.

• External (not employed by the financial entity)
• Qualified — meeting specific technical competence criteria
• Subject to a rotation requirement: the same external tester cannot conduct TLPT for the same entity more than three consecutive exercises

Regulatory involvement

Unlike standard security testing, TLPT requires direct regulator involvement:

Cross-border entities: If a financial entity operates across multiple Member States, the lead competent authority coordinates with host-country authorities. A single TLPT can be recognised across jurisdictions with competent authority agreement.

• Pre-notification — the entity notifies its competent authority (ECB/SSM for significant institutions, national NCA for others) before commencing TLPT
• Scope approval — competent authority reviews and approves the defined scope
• Oversight during testing — the white team maintains communication with the authority during the exercise
• Results submission — the final TLPT report is submitted to the competent authority
• Closure letter — the authority issues a formal closure letter confirming the TLPT has been conducted satisfactorily

TLPT scope: critical functions

The TLPT scope must cover the entity's critical or important functions as identified under DORA Art. 6 (ICT risk management framework). Scope typically includes:

Including ICT third parties in scope: DORA Art. 26(8) allows the TLPT scope to cover ICT third-party service providers. Third parties must consent and cooperate. This is increasingly expected for systemic ICT dependencies (e.g. core cloud providers).

• Core banking / trading / clearing / settlement systems
• Customer-facing digital channels
• Supporting ICT infrastructure (network, identity, privileged access)
• Key ICT third-party dependencies (cloud providers, core banking software vendors)

TLPT and ICT third-party risk

A TLPT finding that traces to an ICT third-party dependency has implications under DORA Art. 28–30 (ICT third-party risk management):

• The finding must be documented in the ICT third-party risk register
• The contractual relationship with the third party must be reviewed for security obligations
• Remediation may require renegotiating SLAs or technical controls with the third party
• If the third party is a Critical ICT Third-Party Service Provider (CTPP) designated by the ESAs, the finding may be escalated to the relevant ESA oversight framework

Frequency and scheduling

• Minimum frequency: Every 3 years (Art. 26(1))
• Competent authority discretion: Authorities may require more frequent TLPT based on entity risk profile or significant incidents
• Scheduling: Given a 3–6 month execution timeline, entities should begin planning at least 6 months before the 3-year deadline
• Post-incident TLPT: A significant ICT incident may trigger a requirement for an unscheduled TLPT

TLPT output and remediation

The TLPT produces a formal report containing:

Remediation is mandatory for critical findings. The entity must submit a remediation plan to its competent authority and evidence completion within an agreed timeframe.

• Executive summary of findings
• Technical findings by severity
• Attack narratives (how the red team achieved objectives)
• Blue team detection and response assessment
• Remediation recommendations
• Residual risk statement

NIS2 and TLPT overlap

If an entity is also subject to NIS2 (e.g. a bank that is both a financial entity under DORA and an essential entity under NIS2), TLPT findings feed both:

A single TLPT exercise can satisfy advanced testing requirements under both frameworks — coordinate with both competent authorities on scope and reporting.

• DORA Art. 6 ICT risk management framework (update risk assessment)
• NIS2 Art. 21 cybersecurity risk management measures (update security posture)

Tools on NexCyber

• DORA Applicability Checker — confirm DORA scope in 2 minutes
• 144-obligation gap assessment — maps DORA, NIS2, CRA, AI Act and RED in one assessment

Further reading

This page provides regulatory guidance for informational purposes. It is not legal advice. DORA RTS and ITS on TLPT are published by the ESAs — refer to the latest versions on the EBA, ESMA, and EIOPA websites. For TLPT planning, consult a TIBER-EU accredited provider and your competent authority.

NexCyber — EU Market Access Compliance Platform

• NIS2 implementation guide
• NIS2 × CRA overlap
• CRA Article 14 vulnerability reporting