The challenge (and why it matters now)

Financial services run on trust and uptime. Yet today’s attackers move with speed, precision, and patience—blending social engineering with living‑off‑the‑land techniques, abusing third‑party dependencies, and timing campaigns to maximise business impact. The Digital Operational Resilience Act (DORA) responds to this reality by making Threat‑Led Penetration Testing (TLPT) a recurring, authority‑supervised exercise for significant financial entities across the EU. DORA TLPT is not a routine pentest. It is an intelligence‑led Red Team operation on live production systems, designed to measure how well your organisation prevents, detects, responds, and recovers when real attackers press every advantage—technical, human, and procedural.

The solution: Run TLPT using the TIBER‑EU playbook under your competent authority’s oversight. TIBER‑EU provides the structure, roles, deliverables, and quality bar so your TLPT is safe, meaningful, and recognised across jurisdictions—aligning directly with DORA’s requirements.

In this post we walk through the typical end‑to‑end process we follow when executing a DORA‑aligned TLPT—from initial scoping with the authority, through threat intelligence and Red Team execution, to closure, Purple Teaming, and remediation governance. It is written for security leaders, risk managers, and business stakeholders who want depth and clarity, without excessive jargon. Despite us simplifying the jargon, there are still a number of acronyms and terms. Feel free to refer to our Glossary of DORA TLPT terms.

What is TLPT in summary?

TLPT is an intelligence‑led (threat‑informed), bespoke (entity‑specific), controlled (risk‑managed), and live‑system Red Team test that emulates the TTPs (Techniques, Tactics and Procedures) of real threat actors targeting your critical or important functions. Unlike classic pentests that focus on individual assets, TLPT evaluates end‑to‑end resilience—including people, processes, and technology—against scenarios prioritised by current threat intelligence. Per DORA, qualifying entities conduct TLPT at least once every three years under competent authority supervision and with formal deliverables.

Why TIBER‑EU under DORA TLPT?

The European Central Bank established TIBER‑EU as a common framework for intelligence‑led Red Teaming on live production systems. DORA’s TLPT provisions are aligned with TIBER‑EU core requirements, enabling entities and authorities to execute TLPTs consistently, safely, and with mutual recognition across the EU. In practice, using TIBER‑EU gives you the tested methodology, roles, templates, knowledge centre, and lessons learned from hundreds of completed tests across many countries.

The actors and who does what in DORA TLPT

A successful TLPT depends on clear governance and role segregation. Under DORA/TIBER‑EU, the following actors are typically involved:

• TLPT Cyber Team / TIBER Cyber Team (Authority side): Your competent authority’s dedicated team provides oversight, validates key deliverables, ensures framework compliance, and facilitates recognition.
• Control Team (Entity side): A small, trusted “White Team” formed in Preparation. They own risk management, day‑to‑day coordination, procurement, approvals, and communications with the authority. They safeguard business continuity and can pause the test if needed. They are separated from the Blue Team and they do not share information with the Blue Team.
• Blue Team (Entity’s SOC/Defence): Unaware during active testing to keep detections genuine. Their prevention, detection, and response capabilities are what’s being tested.
• Threat Intelligence Provider (External): Produces targeted threat intelligence and proposes realistic attack scenarios tailored to your sector, geography, and tech stack. This function is central to TLPT and distinct from pentesting skills.
• Red Team (Internal or External): Executes the approved scenarios in live environments across human, physical, and digital attack surfaces. Plans and deliverables follow framework appendices and require validation by the Control Team and authority.
• Purple Team (Joint): Formed in the Closure stage to replay scenarios, validate fixes, and accelerate defensive uplift without the secrecy of active testing. Under DORA, Purple Teaming is explicitly emphasised

The three phases of a DORA TLPT

Phase 1 — Preparation

Goal: Establish governance, scope the test around critical functions, procure providers, and agree practical constraints and safeguards.

1. Engagement & Scoping with the Authority

Your competent authority (or central bank) engages early to agree the high‑level scope, focusing on Critical or Important Functions (CIFs) and supporting assets. A Control Team (the entity’s “White Team”) is formally appointed with clear accountability, lines of escalation, and stop‑go criteria.

2. Procurement of Services

You’ll procure a Threat Intelligence Provider (TIP) and confirm the Red Team Testers (RTT) execution capability. Many entities choose external RTTs to preserve independence and keep a clear separation from the Blue Team. DORA defines when internal testers may participate and outlines how organisations must safeguard their independence and testing quality. TIBER’s Services Procurement Guidelines help entities select providers with the right capability, ethical standards, and insurance coverage.

3. Defining the Scope Specification

The Control Team documents CIFs, underlying processes, people, technology, third parties, and “flags” (clear, measurable objectives such as compromising a payment workflow or exfiltrating a specific dataset). Strong scoping is crucial because recognition and cross‑border mutual acceptance depend on a defensible, risk‑managed scope.

4. Safeguards and Business Continuity

In parallel, you plan operational safeguards (rate limits, maintenance windows, safety words, pre‑agreed “leg‑ups” to avoid stalls) and confirm business continuity controls. TLPT occurs on live systems, so BCP/DR readiness is non‑negotiable.

Experience tip: Preparation can feel front‑loaded. That’s intentional. The best TLPTs invest early in role clarity, legal/contractual hygiene, safety nets, and a scope aligned to real business risk—not just an asset list.

Phase 2 — Testing

Phase 2 splits into two dependent parts: Targeted Threat Intelligence and Red Team Execution.

Part 1: Targeted Threat Intelligence (TTI)

Goal: Translate the real threat landscape into entity‑specific, regulator‑reviewed scenarios.

Why it matters:

• The TI phase is the signature differentiator of TLPT. It demands a separate skillset—analysts who understand actors, TTPs, sectoral patterns, and local context (e.g., regional crimeware ecosystems, language nuances, regulatory sensitivities).

What happens:

• Identify and prioritise assets underpinning CIFs by confidentiality, integrity, and availability (CIA) impact. Many “obvious” assets are under‑documented; TI helps surface blind spots and business logic risks.
• Assess market, region, and entity‑specific threats using OSINT, industry reporting, recent incidents, and adversary emulation libraries.
• Develop multiple attack scenarios mapped to real adversaries and kill‑chain phases (initial access through exfiltration/impact). The Control Team typically selects three that best represent realistic, material risk to CIFs.
• Produce a Targeted Threat Intelligence Report (TTIR) for authority review/approval, ensuring scenarios and flags are proportionate, safe, and testable.

Part 2: Red Team Execution

Goal: Execute the approved scenarios against live production systems and services and capture evidence of detection/response and business impact.

• Test plan & validation: The Red Team creates a Red Team Test Plan that operationalises the TTIR scenarios into stepwise TTPs, IOCs, safety controls, and evidence artefacts. The Control Team and authority validate the plan prior to launch.
• Multidomain attack surface: TLPT often traverses human (social engineering), physical (visitor access, device drops), and digital (external/internal) vectors to achieve flags—reflecting real adversary tradecraft rather than tool‑centric pentesting.
• Duration: While the active Red Team window is typically several weeks to a few months, the overall test lifecycle (prep → TI → execution → closure) often spans 6–12 months, especially for complex scenarios, cross‑border operations, or pooled testing.
• Blue Team realism: The Blue Team remains unaware during active testing to preserve genuine detection/response signals. Their SOC processes, runbooks, EDR tuning, and escalation chains are observed without forewarning.
• What’s being assessed: Beyond “can we be breached?”, TLPT validates how quickly and safely you contain, eradicate, and return to normal operations—and what that implies for customer harm, regulatory reporting thresholds, and reputational risk.

Expert observation: The most valuable TLPTs measure operational resilience under uncertainty—for example, how detection works when the first indicator is ambiguous and the workload is already high, or how playbooks adapt when TTPs intentionally avoid known alert paths.

Phase 3 — Closure, Purple Teaming, and Remediation

Goal: Turn findings into resilience. TLPT only delivers value if the lessons learned are embedded into people, process, and technology.

Reporting sequence (tight timelines)

1. Red Team Report → Control Team → Blue Team: Within ~4 weeks of test end, the RTT provides a detailed report (TTPs, timelines, evidence, flags achieved/attempted, business impact hypotheses). Content aligns to framework appendices.
2. Blue Team Report: Within ~4 weeks of receiving the RTT report, the Blue Team documents detections, investigative timelines, response actions, gaps, and proposed improvements.
3. Purple Teaming: Within ~4 weeks thereafter, Red Team and Blue Team run facilitated replays and micro‑exercises to verify fixes, tune detections, and ensure control owners can repeatedly prevent/detect/respond. DORA and ECB guidance underscore purple teaming’s role in institutionalising learning.
4. Summary to Authority: The Control Team submits a TLPT summary and conclusions to the authority (typically within a defined window after active testing), enabling recognition and supervisory follow‑up.
5. Resilience‑first remediation planning
   Remediation goes beyond patch‑and‑move‑on. A strong remediation plan includes root cause analysis, prioritised mitigations, owners, target dates, and risk acceptances (with rationale) where appropriate. Expected measures span governance (policies, segregation of duties), process (SOC workflows, incident handling), security controls (hardening, identity, network segmentation, email security), technology refresh (end‑of‑life replacements), capacity/availability improvements, and cloud control baselines. Plans should anticipate re‑tests to evidence effectiveness.
6. Incident classification & threat reporting interplay
   TLPT findings often touch on your major incident classification logic and significant cyber threat notifications. The ESAs’ second batch of DORA policy products includes templates and timelines for major ICT‑related incident reporting and voluntary significant cyber threat notifications—useful context when mapping TLPT lessons to your reporting playbooks and thresholds.

Trustworthiness in practice: We advise boards to request a remediation traceability matrix that shows each TLPT finding → proposed fix → owner → target date → verification evidence. This gives assurance that TLPT converts into measurable, sustained risk reduction.

Typical timeline at a glance (indicative)

The timeline below is purely indicative and would depend on the size and complexity of the entity in question as well as on the scenarios selected in the TTIR and the TTPs selected for the RTT’s attacks.

• Month 0–2: Authority engagement, Control Team formation, legal/contracts, initial scoping.
• Month 2–4: TIP procurement, deep‑dive scoping and asset CIAs, threat intel research.
• Month 4–5: Scenario selection (often three), TTIR finalisation and authority approval.
• Month 5–8: Red Team Test Plan, safety controls, authority validation, active testing starts.
• Month 8–10: Active testing completes; Red Team Report (≤ ~4 weeks), Blue Team Report (≤ ~4 weeks).
• Month 10–12: Purple teaming, summary to authority, remediation plan baselined and tracked.

5 Common pitfalls—and how to avoid them

1. Treating TLPT like a big pentest

Pentests maximise vulnerability coverage on scoped assets. TLPT evaluates operational resilience of CIFs under realistic adversary pressure. Ensure your governance, metrics, and reporting reflect this difference.

2. Under‑investing in Threat Intelligence

Weak TI produces generic scenarios, misaligned to your real risk. Prioritise TIP quality, sector experience, and local threat context.

3. Skipping safeguards

Testing live systems without rigorous BCP, guardrails, and stop conditions is unacceptable. The authority will insist on controls; you should too.

4. Thin remediation

TLPT isn’t about point‑in‑time compliance. Focus on root causes, control design, identity and segmentation strategy, and people/process updates—then re‑test.

5. Documentation that doesn’t match RTS/TIBER

Misaligned templates slow approvals. Use the RTS/TIBER structure for faster reviews and future recognition.

How TLPT intersects with other DORA obligations

• Incident reporting: Use TLPT insights to tune thresholds, data capture, and timelines for major ICT‑related incidents and significant cyber threats using the ESAs’ templates.
• Third‑party risk: Scenarios frequently involve critical ICT third‑party providers. TLPT outcomes should inform your oversight posture under DORA’s third‑party framework.
• Mutual recognition: Executing to TIBER‑EU core requirements supports recognition across EU jurisdictions—key if you’re cross‑border.

Beyond compliance: designing for resilience

DORA makes TLPT mandatory for selected entities, but the spirit of TLPT is capability development, not checklists. The ECB emphasises that TIBER‑EU is as much a learning mechanism as it is a test; entities that treat findings as design inputs to SOC, identity, network, and third‑party governance derive disproportionate value—and demonstrate assurance to boards and supervisors.

Frequently Asked Questions (TL;DR responses)

How often must we run TLPT?

At least every three years for in‑scope entities, with competent authorities able to adjust frequency based on risk.

Do we have to use TIBER‑EU?

DORA’s TLPT process aligns with TIBER‑EU core requirements. Running your test to TIBER standards supports mutual recognition and supervisory confidence.

Can we use internal red teamers?

DORA TLPT allows internal testers under defined conditions, but independence, capability, and governance requirements apply; many entities still choose external RTTs. Threat intelligence must be external.

What makes TLPT different from a normal pentest?

TLPT is intelligence‑led, live‑system, scenario‑based, and authority‑supervised, aimed at end‑to‑end resilience of CIFs—not asset coverage.

How long does it take?

Plan 6–12 months from initiation to closure and remediation planning; active red teaming typically spans several weeks to months.

What deliverables are expected?

A TTIR (scenarios), Red Team Test Plan, Red Team Report, Blue Team Report, Purple Team outcomes, and a summary to the authority, aligned with RTS/TIBER templates.

How do TLPT findings affect incident reporting?

Use them to refine major incident criteria and significant cyber threat processes in line with ESAs’ templates/timelines.