TLPT DORA: Threat-Led Penetration Testing Requirements

Artur - AFINE cybersecurity team member profile photo
Pawel Woyke
Feb 24, 2026
14
min read
TLPT DORA Requirements Flag

TLPT DORA is the most rigorous cybersecurity testing requirement the EU has ever imposed on financial institutions. Commission Delegated Regulation (EU) 2025/1190 - which went live on July 8, 2025 - fills in everything DORA Article 26 left open about who has to do it, how the process works, and what the methodology looks like.

This guide explains what TLPT DORA is, which financial institutions are in scope, how the six-phase process works, and what to prepare before your TLPT Authority sends the notification.

What TLPT DORA Is and Is Not

Before anything else: TLPT is not a penetration test.

That distinction matters more than most people realize. A pentest scopes one application or one network segment, runs for a week or two, produces a list of CVEs, and everyone gets their report. The security team knows it is happening. The blue team is watching.

TLPT is a full-scale red team exercise on live production systems. It simulates a real attack by a real adversary, from the first step of reconnaissance to the final objective. The security team, the SOC, the incident responders - they have no idea a test is happening. They respond to alerts exactly as they would in a genuine incident.

The difference is scope. A pentest checks whether a lock can be picked. TLPT checks whether your entire security organization can catch a sophisticated attacker who has been inside your network for weeks.

"TLPT mimics the tactics, techniques and procedures of real life threat actors perceived as posing a genuine cyber threat" - that is DORA's own language. And it delivers a controlled, bespoke, intelligence-led test of the financial entity's critical live production systems.

That is why TLPT carries real operational risk, requires regulator involvement at every step, and takes months to complete properly.

TLPT process diagram
Source: EBA/JC 2024-29 - DORA RTS on TLPT (Commission Delegated Regulation EU 2025/1190)

Who Is Required to Perform TLPT Under DORA

DORA does not require every bank, insurer, or payment company to run a full red team exercise. The regulation only targets the largest, most critical institutions - the ones whose failure could genuinely destabilize the EU financial system. Here is who falls into mandatory scope:

  • Banks (credit institutions) - only the systemically important ones. Regulators classify the biggest banks into two categories: G-SIIs (globally important banks, think ING, BNP Paribas, Deutsche Bank) and O-SIIs (significant at national or EU level, think the largest bank in your country). If your bank is in either category, you are in scope. Smaller regional or community banks are not affected.
  • Payment institutions - only the biggest processors. You need to have processed more than €150 billion in total transactions in each of the last two years. This is a very high bar - it captures companies like major card networks and large payment processors, not typical fintechs or smaller payment companies.
  • Electronic money institutions - similar threshold. You are in scope if you exceeded €150 billion in transactions or held more than €40 billion in outstanding e-money (digital stored value, like prepaid cards or digital wallets) in each of the last two years. Again, this affects only the largest players.
  • Central securities depositories (CSDs) and central counterparties (CCPs) - automatically in scope, with no size threshold. CSDs are organizations that hold and record ownership of securities (stocks, bonds) on behalf of investors. CCPs stand between every buyer and seller in a trade to guarantee the deal goes through. Because their failure would freeze entire financial markets, DORA treats them as inherently critical regardless of size.
  • Trading venues (stock exchanges, MTFs) - only the dominant ones. You are in scope if your electronic trading systems hold the highest national market share in key instrument categories, or account for more than 5% of EU-level trading turnover. Most smaller trading venues are not affected.
  • Insurance and reinsurance companies - the tightest criteria of all. You need to clear a baseline (gross written premiums over €1.5B, technical provisions over €10B, and total assets over 3.5% of your national sector) plus at least one elevated threshold (premiums over €3B, provisions over €30B, or assets over 10% of the national sector).

Important: even if you meet all the criteria above, your national regulator (called the TLPT Authority) can still release you from the obligation if your ICT risk profile does not justify a full TLPT. And the opposite is also true - if you fall outside these categories but the regulator considers you a meaningful risk, they can still pull you in. If you are unsure whether you are in scope, speak with your legal and compliance team now.

The Four Groups Involved in Every TLPT

Before walking through the process, you need to understand who is doing what. There are four distinct groups in every TLPT, and their roles do not overlap.

  • The TLPT Authority is your national regulator for this process. Every EU Member State designates one. For significant credit institutions, the ECB plays this role. The TLPT Authority is not a passive observer. It validates documentation, approves providers, monitors the test, and issues the attestation at the end. Nothing moves to the next phase without their sign-off.
  • The Control Team is your internal group that knows the test is happening. Typically three to five people maximum. The Control Team Lead has to be senior enough to make binding decisions fast, have access to the management body, and understand the entity well enough to make scope decisions. The control team manages everything: risk, communication with the regulator, provider selection, leg-ups during testing, and secrecy management.
  • The Threat Intelligence Provider is always external. Always. Even if you use your own internal red team, the threat intelligence side must come from outside. They gather real intelligence about your organization, map your attack surface, identify the threat actors most likely to target you, and build the scenarios the testers will execute. They need at least one person with five-plus years of threat intelligence experience and a combined track record of at least three prior assignments in this context.
  • The Red Team (Testers) executes the attack. They can be internal, external, or a mix. But every third TLPT must use exclusively external testers. External teams need at minimum one lead with five or more years of red team experience plus two additional testers with at least two years each, five client references, and professional indemnity insurance.

If you are thinking about using an external provider for both threat intelligence and red teaming, that is allowed. But their staff assigned to each role must be completely separated.

The Full Process, Phase by Phase

TLPT runs in six phases. Here is what happens in each one.

Phase 1: Preparation

TLPT process diagram
Source: EBA/JC 2024-29 - DORA RTS on TLPT

Everything starts with a notification from your TLPT Authority. Once that arrives, you have three months to submit initiation information and six months to submit a complete scope specification document.

Within three months, you submit a project charter with your Control Team Lead's details, a decision on whether you will use internal testers, external testers, or both, your communication channels (encrypted email, secure data rooms, instant messaging), and a codename for the entire exercise. The codename exists to prevent the blue team, third parties, and anyone outside the control team from identifying that a TLPT is underway.

After the TLPT Authority validates your initiation information, you formally establish the control team. Then you run a risk assessment of the TLPT itself: risks of system disruption, data corruption, crisis escalation, third-party impact, and the risks of giving external testers access to your most sensitive systems. The TLPT Authority reviews this and can require revisions.

The scope specification document is where the real work happens. You need to identify every critical or important function, decide which ones are in scope for the test and why, identify the ICT systems supporting each in-scope function, and define preliminary flags. Flags are specific security objectives the testers will try to achieve, targeting confidentiality, integrity, availability, or authenticity of particular systems. Your management body has to formally approve the scope document.

Once the scope is validated, you identify and vet providers. You submit evidence of their qualifications to the TLPT Authority. You do not sign contracts until the TLPT Authority approves your selection.

Tip: A good external partner can help you map your critical functions, define realistic flags, and prepare the scope specification document in a format that holds up to TLPT Authority scrutiny. Rushing this phase is the most common way institutions create problems for themselves downstream.

Phase 2: Threat Intelligence

Once the scope is approved, the threat intelligence provider starts gathering intelligence. Approximately four weeks, though the actual timeline varies.

What they are looking for: employee credentials in breached datasets, look-alike domains that could be used for spear phishing, exposed or vulnerable software in your stack, information your employees have posted online that could enable social engineering, dark web intelligence, and profiles of the threat actors most likely to target a financial institution with your footprint.

From this, they build at minimum three scenarios. Each scenario targets a different critical function, uses a different threat actor profile, and applies different TTPs. One scenario must target service availability. One must target data integrity. One must target information confidentiality.

The Targeted Threat Intelligence Report goes to the TLPT Authority for approval before anything else moves forward.

Phase 3: Active Red Team Testing

TLPT process diagram
Source: EBA/JC 2024-29 - DORA RTS on TLPT

After the threat intelligence report is approved, the testers produce the Red Team Test Plan. This covers the TTPs permitted and prohibited, ethical boundaries for social engineering, per-scenario details including the specific flags being targeted, the exact attack paths planned, and a schedule mapping the exercise across three sub-phases: gaining initial access, moving laterally, and executing objectives.

Both the control team and the TLPT Authority approve this plan before active testing begins.

The active phase runs for a minimum of 12 weeks. The testers report to the control team and test managers at least weekly. The blue team has no idea this is happening. When they detect suspicious activity, they respond as if it is real.

If the testers hit a genuine dead end, the control team can provide leg-ups: access credentials, network positioning, internal documentation. Leg-ups are pre-planned and documented every time they are used.

Phase 4: Closure

TLPT process diagram
Source: EBA/JC 2024-29 - DORA RTS on TLPT

The active testing phase ends when all parties agree it is done. The control team lead then tells the blue team that a TLPT just happened.

Within four weeks, the testers submit their Red Team Test Report covering every attack action, every flag reached or missed, every TTP used, all leg-ups provided, and remediation recommendations.

Within ten weeks, the blue team produces their own Blue Team Test Report: which attack actions they detected versus missed, log evidence of detections, their own root cause analysis.

Also within those ten weeks, the testers and blue team conduct a replay session and a mandatory purple teaming exercise. Both sides walk through the entire attack together, explore scenarios that could not be completed, test alternative paths.

Purple teaming is not optional under TLPT DORA requirements. It is mandatory - a specific addition DORA makes to the TIBER-EU framework.

Phase 5: Remediation

Within eight weeks of the Test Summary Report notification, you submit your remediation plan covering every finding: description of the shortcoming, remediation measures with priority rankings and completion dates, root cause analysis, responsible teams, and the risks of not remediating each finding. Regulators will follow up on this.

Phase 6: Attestation

Once everything is done, the TLPT Authority issues a formal attestation certifying that your TLPT was conducted in compliance with DORA requirements. For financial entities operating across multiple Member States, this attestation can be mutually recognized by TLPT Authorities in other countries, avoiding duplicate testing.

The Timeline in One View

A quick reference for the deadlines that matter:

Table showing timeline of TLPT under DORA

Cross-Border and Group Scenarios

If your entity operates across multiple EU Member States, your home TLPT Authority leads the test but must inform host Member State authorities. They have 20 working days to observe or assign their own test manager.

If your group shares ICT systems or a common ICT intra-group service provider with other group entities, TLPT Authorities will assess whether a joint TLPT makes more sense than individual tests.

If multiple entities share a third-party ICT provider (a core banking system, a cloud provider, a data analytics platform), a pooled TLPT can cover all participating entities simultaneously. At least one scenario in a pooled TLPT must target the third-party provider's own underlying systems.

TLPT DORA Compliance: What to Start Working On Now

Most institutions that will receive TLPT notifications in 2026 are not ready. Not because they lack security maturity, but because TLPT readiness is a specific organizational problem that most security programs have never had to solve.

  • Map your critical and important functions before anyone asks you to. The scope specification document requires you to list all critical or important functions, decide which are in scope, and document the ICT systems supporting each one. Doing this under a three-month deadline while simultaneously setting up a control team and running a risk assessment is brutal. Start the function mapping now.
  • Identify your Control Team Lead. This person needs seniority, authority, and availability. They will spend the next year of their professional life managing a regulatory exercise. Most organizations underestimate how senior this role needs to be.
  • Understand your options for testers. Decide whether you plan to use internal testers, external testers, or both. If internal, check whether your team meets Article 15 requirements: 12 months of continuous employment, documented training, a formal internal tester policy. Remember that the third TLPT must use exclusively external testers.
  • Assess the market for qualified providers. External testers need five client references. Threat intelligence providers need three. Both need professional indemnity insurance. Start identifying candidates before you are under time pressure.
  • Make sure your management body understands what they are signing. The scope specification document requires management body approval. They need to understand what a TLPT is and what approving scope means in practice.
  • Check your secrecy management. During the entire active testing phase, the blue team cannot know the test is happening. Think now about how your control team would contain an incident escalation without revealing the exercise.

If you are looking for a qualified TLPT provider, click here to book a consultation

Selecting a TLPT DORA-Qualified Provider: What to Look For

Choosing who conducts your TLPT matters more than most institutions realize. The RTS sets minimum qualifications, but minimum qualifications and genuine capability are not the same thing.

Here is what to look for when evaluating providers:

TLPT Red Team Qualifications: The People Behind the Engagement

TLPT is delivered by individual specialists, not by logos. Ask to see the certifications and CVEs of the people who will work on your test. The RTS requires an external lead with at least five years of penetration testing and red team experience plus two additional testers with at least two years each. But years on a CV alone do not tell you much. Look for offensive security certifications that require hands-on technical proof: OSCP, OSEP, CRTO, CRTE, OSED, OSCE3. These are not easy to obtain. A team that holds them has demonstrated actual technical depth under exam conditions, not just sat through a training course.

DORA-Compliant Threat Intelligence: What “Actually Current” Means

The threat intelligence phase is not a "Google search and a report". It requires active intelligence gathering, dark web access, and genuine analysis of the threat actors that target financial institutions. Ask how they gather intelligence, what sources they use, and how they validate the relevance of identified threat actors to your specific institution. The difference between a good and a poor TI report determines whether the testing phase simulates a realistic threat or chases a generic one.

Verifiable Track Record in Offensive Security Research

A provider's CVE publication history tells you more than any sales deck. Firms that regularly discover vulnerabilities in enterprise software are the ones whose specialists are genuinely working at the technical frontier. AFINE's research team has published more than 150 CVEs in enterprise software from vendors including SAP, Microsoft, CyberArk, and Palo Alto Networks. That research background directly informs how specialists think about attack paths against complex, multi-vendor financial infrastructure. You can review the research portfolio directly.

Financial Sector Experience in DORA-Compliant Engagements

Financial institutions have specific regulatory constraints, complex third-party dependencies, and very particular definitions of what a critical function means. AFINE has been delivering offensive security engagements for European banks, payment institutions, and critical infrastructure operators since 2015, including organizations such as PKO BP, ING Bank,Isabel Group and BGK.

Operational Risk Management During Live TLPT Testing

TLPT involves genuine risks to production systems. The specialists running your test need clear restoration procedures, defined kill switches, tight scope controls, and the judgment to know when to stop. Ask specifically how they document and manage operational risk during active testing. Good providers do this anyway because they understand what is at stake.

Communication and Oversight Throughout the TLPT Process

The control team will be speaking with testers weekly at minimum. The threat intelligence provider needs to stay available for queries throughout active testing. This is a months-long engagement with a live regulatory audience. Ask how the team communicates, who is the day-to-day contact, and what the escalation path looks like when something unexpected happens.

AFINE delivers TLPT engagements for EU financial institutions - red team operations and closure reporting, with threat intelligence provided by a specialist partner.

Book a consultation at
afine.com/services/tlpt-dora

TLPT DORA Compliance: Key Takeaways

TLPT is the most rigorous mandatory cybersecurity exercise the EU financial sector has ever faced. It is longer, more complex, and more expensive than anything most institutions have done before. It is also genuinely useful.

A properly conducted TLPT tells you whether your security program works under real pressure. The mandatory replay and purple teaming phases exist precisely to make sure, the exercise produces learning, not just documentation.

The first wave of notifications is coming in 2026. The six-month window from notification to scope submission is tight for organizations that have not done the groundwork. Start the function mapping, identify your Control Team Lead, and evaluate your provider options before you are in a reactive posture.

This post is based on Commission Delegated Regulation (EU) 2025/1190 of 13 February 2025 and Regulation (EU) 2022/2554 (DORA). It reflects the regulation as published and does not constitute legal or regulatory advice. For compliance planning specific to your institution, engage qualified legal counsel.

Official Regulatory Sources

Related Pages