DORA TLPT Testing Methodology: Complete Phase-by-Phase Implementation Guide

Threat-Led Penetration Testing (TLPT) is the most operationally complex obligation in DORA. It is mandated by Articles 26 and 27 of Regulation (EU) 2022/2554, requires the use of the TIBER-EU framework (or a recognised equivalent), and must be completed at least once every three years by significant in-scope entities. The first mandatory cycle must be finished before 17 January 2028. This guide provides a definitive methodology for planning, executing and attesting a TLPT engagement.

What TLPT Is — and What It Is Not

TLPT is a controlled, intelligence-led red-team exercise conducted on the live production systems supporting an institution's critical or important functions (CIFs). It simulates the tactics, techniques and procedures (TTPs) of real adversary groups identified through targeted threat intelligence, with the objective of measuring detection and response capabilities under realistic attack conditions.

TLPT is not a vulnerability scan, not a standard penetration test, not a tabletop exercise and not a purple-team engagement. It is materially different in scope, methodology, regulatory weight and cost.

Who Must Conduct TLPT

Article 26(8) defers the identification of in-scope entities to the competent authorities, applying proportionality criteria including size, risk profile, ICT maturity, sector and substitutability. In practice, the institutions in scope are:

• Significant credit institutions under direct ECB supervision (SSM)
• Globally Systemically Important Banks (G-SIBs) and Other Systemically Important Institutions (O-SIIs) at national level
• Significant insurance and reinsurance undertakings
• Trading venues and central counterparties of systemic relevance
• Payment institutions and electronic money institutions of significant size
• Crypto-asset service providers exceeding the MiCA significance thresholds

The estimated EU population in scope is approximately 250 institutions, materially smaller than the ~22,000 entities subject to DORA generally.

The 5 Phases of TLPT

TIBER-EU and the DORA-specific articles 26-27 structure TLPT into five sequential phases, each with explicit deliverables and stakeholder authorisations. Skipping or rushing a phase is one of the most common reasons supervisor attestation is denied.

Phase 1 — Preparation (typically 2-3 months)

Establishes governance, scope and team setup. Deliverables include:

• White Team appointment (typically: CISO, Head of Resilience, Head of Internal Audit, Head of Legal, plus an external TLPT cyber-team test manager)
• CIF inventory confirmation and scope definition (which production systems supporting which CIFs are in test scope)
• Risk management plan, including kill-switch procedures and escalation paths
• Engagement letters with TI provider and Red Team provider, both registered with the relevant TIBER cyber team
• Notification to the competent authority and TIBER cyber team of intent to commence the engagement

Phase 2 — Threat intelligence (typically 1-2 months)

The TI provider produces a Targeted Threat Intelligence (TTI) report identifying the threat actors most likely to target the institution, their TTPs (typically expressed in MITRE ATT&CK® framework), and proposed attack scenarios. Deliverables:

• Targeted Threat Intelligence Report
• 3-5 candidate attack scenarios mapped to specific CIFs
• Threat scenario approval by White Team and TIBER cyber team

Phase 3 — Red teaming (typically 4-6 months)

The Red Team provider executes the approved scenarios against live production systems. Defenders (Blue Team) operate blind — they do not know a test is in progress. The White Team monitors continuously, holding the kill-switch authority. Deliverables:

• Daily White Team status updates
• Mid-engagement progress review
• Red Team test report covering each scenario, attack path, evidence captured, and detection events triggered (or missed) by the Blue Team

Phase 4 — Closure (typically 1-2 months)

The engagement transitions from offensive testing to lessons learned and remediation planning. The Blue Team is informed and joins the analysis. Deliverables:

• Replay workshop where Red Team walks the Blue Team through each attack path
• 360-degree feedback report covering what the Blue Team detected, what was missed, what tooling gaps exist, what process gaps exist
• Remediation plan with owner, deadline and validation method per finding
• Test summary report ready for attestation

Phase 5 — Attestation and reporting (typically 1-2 months)

Documents are submitted to the competent authority and the TIBER cyber team. The competent authority issues an attestation that the TLPT was conducted in accordance with TIBER-EU and DORA Article 26 requirements. Deliverables:

• Final TLPT report (executive summary, scenarios, findings, remediation plan)
• Attestation request to the competent authority
• Mutual recognition where the institution operates across multiple Member States

Team Setup: Red Team, Blue Team, White Team, Purple Replay

Red Team

External offensive testing provider, registered with at least one TIBER-EU national cyber team, demonstrably independent from the institution and from any provider of detection or response services to the institution. Article 27(2) sets specific competence and independence requirements that go beyond standard pentest providers.

Blue Team

The institution's in-house security operations function (SOC, incident response, threat hunting) plus any outsourced managed detection and response (MDR) providers. Operates blind during Phase 3.

White Team

Internal control function with full visibility of the test, holding kill-switch authority. Membership typically: CISO, Head of Operational Resilience, Head of Internal Audit, Head of Legal, plus the external test manager. The White Team must be small enough to maintain confidentiality and senior enough to make real-time decisions if the Red Team finds something the institution cannot accept testing further.

Purple Replay (Phase 4)

Joint Red+Blue session reconstructing each attack path. This is where the institution extracts most of the operational learning value from a TLPT.

Threat Intelligence Requirements

Article 26(2) requires that test scenarios be based on threat intelligence relevant to the financial entity. In practice, the TIBER-EU framework structures the TI deliverable into three components:

1. Targeted Threat Intelligence Report. Identifies the threat actors most likely to target the institution given its sector, country, profile and recent industry incidents. Cites named adversary groups (APT clusters, financial crime groups, hacktivists) where the evidence supports it.
2. Adversary capability mapping. Maps each identified actor's known TTPs to the MITRE ATT&CK® framework. This becomes the source for designing realistic attack scenarios.
3. Attack scenario proposal. Three to five candidate scenarios, each tied to a specific CIF. Each scenario specifies entry vector, lateral movement path, target objective and expected detection signal.

Vendor Selection

Selecting Red Team and TI providers is the single decision with the largest impact on TLPT quality. Use these criteria:

• TIBER-EU registration. The provider must be registered with the cyber team of at least one EU Member State and meet the competence requirements of Article 27(2). Pure penetration testing firms without TIBER experience are not eligible regardless of their general technical reputation.
• Independence. The provider must not have provided detection, response, or security architecture services to the institution in the preceding 24 months. This is stricter than typical audit independence requirements.
• Sector experience. Banking, insurance and payments have very different attack surface profiles. A provider with deep banking experience but no insurance expertise will design scenarios that miss insurance-specific risks.
• Threat intelligence depth. Generic CTI feeds are not sufficient. The provider must produce bespoke intelligence based on the institution's specific exposure.
• Scale capacity. A 4-month red-team phase requires sustained senior consultant capacity. Boutique providers can be excellent but capacity-constrained.

Timeline and Budget Planning

Build the schedule backwards from the regulatory deadline. For the first cycle ending January 2028:

Typical budget envelope for a single TLPT cycle:

• Threat intelligence: EUR 30k-80k
• Red Team execution: EUR 150k-300k
• White Team operations and external test manager: EUR 30k-60k
• Internal staff time (estimated): EUR 50k-150k
• Tooling and infrastructure: EUR 10k-30k
• Total: EUR 270k-620k per cycle

For institutions operating in multiple Member States, mutual recognition under Article 26(8) avoids duplicate testing per jurisdiction — but the lead competent authority must be agreed before Phase 1.

The 6 Most Common Pitfalls

1. Starting too late. Institutions that begin scoping in 2027 cannot complete a defensible TLPT before January 2028. Vendor capacity in 2027 will be the binding constraint as ~250 institutions compete for the limited pool of TIBER-registered providers.
2. Wrong scope. Testing systems that do not support CIFs is wasted budget and triggers attestation queries. Testing only CIF-supporting systems but missing the CIFs themselves is non-compliance.
3. White Team too large. When more than 8-10 people know the test is happening, leakage to the Blue Team becomes likely and the test loses validity.
4. Insufficient kill-switch governance. If the Red Team finds a path to a critical system, the White Team needs a documented decision process for whether to proceed. Improvising in real time leads to either premature termination or operational accidents.
5. No remediation budget. The post-test remediation programme typically requires more spend than the test itself. Institutions that budget only for the test discover findings they cannot afford to fix before the next cycle.
6. Treating the attestation as the end goal. The attestation is a regulatory deliverable; the resilience improvement is the strategic goal. Institutions that organise around the attestation produce thinner findings and weaker remediation.

Frequently Asked Questions

Can we conduct TLPT internally without an external Red Team?

No. Article 27(2) requires demonstrable independence of the testers from the entity and from its current security service providers. Internal teams cannot meet the independence requirement.

Does TLPT replace our other security testing?

No. DORA Articles 24-25 require an ongoing testing programme covering vulnerability scans, code reviews, penetration tests, scenario-based tests and end-to-end testing. TLPT is a separate, deeper exercise on top of that programme, not a replacement for it.

What happens if the Red Team finds a serious unpatched vulnerability mid-test?

The White Team escalates immediately under the documented escalation procedure. The standard practice is to pause the relevant scenario, allow the Blue Team to remediate, and then resume the test. The finding is documented in the final report.

Are findings disclosed to supervisors in detail?

The final attestation report goes to the competent authority and includes findings at a level of detail sufficient for the supervisor to assess remediation adequacy. Detailed technical artefacts (exploit code, specific configurations) typically remain with the institution and are not transmitted to supervisors.

Is mutual recognition automatic across EU Member States?

Article 26(8) provides for mutual recognition, but it requires advance coordination between competent authorities. Cross-border groups should agree the lead authority and notify all relevant national authorities at the start of Phase 1.

How Resiplan Supports TLPT Programmes

Resiplan is the specialised SaaS for DORA, business continuity and GRC. While Resiplan does not execute red-team operations, it manages the upstream data foundation that determines whether a TLPT can be properly scoped: the CIF Evaluation Module produces the auditable list of critical or important functions, the Register of Information generation aligns the contractual perimeter with the test scope, and the workflow engine tracks the White Team governance, deliverables and attestation lifecycle. Institutions that arrive at Phase 1 with a Resiplan-managed CIF and ICT inventory typically save 3-4 weeks of Phase 1 preparation time.

TLPT is a multi-million-euro, three-year operational commitment that touches every part of an institution's security, technology, legal and risk functions. Treating it as a procurement exercise produces an attestation but not resilience. Treating it as a strategic programme produces both.