← All posts

DORA TLPT: Are You Required to Do It, and What Does It Actually Involve?

Threat-led penetration testing is the most intensive compliance requirement in DORA. It involves simulating real cyberattacks against your live production systems, using the techniques of actual threat actors who target your sector. It runs for at least 12 weeks. It ends with mandatory purple teaming and a remediation plan that your competent authority reviews before issuing an attestation.

It is also not required for most financial entities.

That distinction matters, because the effort and cost of a TLPT programme is significant. Before you start scoping vendors and budgeting for red team engagements, the first question to answer is whether you are actually in scope. And if you are not, you still need to be able to explain why — because your regular resilience testing programme under Articles 24 and 25 still applies.

The Starting Point: Who Is Required to Perform TLPT?

Article 26 of DORA establishes that competent authorities identify which financial entities must perform TLPT. This is not a self-assessment. You do not decide that you are in scope — your supervisor tells you. From July 2025, regulators started sending formal notification letters to designated entities.

Two groups are automatically excluded: Article 16 entities (those on the simplified ICT risk management framework) and microenterprises (fewer than 10 employees, under EUR 2 million turnover). If you fall into either category, TLPT does not apply to you.

For everyone else, the competent authority makes the determination based on three factors from Article 26(8):

  • Impact — the extent to which your services and activities impact the financial sector
  • Financial stability — whether your entity has systemic character at EU or national level
  • ICT risk profile — your level of ICT maturity and the technology features involved

The RTS on TLPT, published in June 2025, introduced a two-layer approach to identification. The first layer sets specific criteria and thresholds for entities in major financial sub-sectors. The second layer gives competent authorities discretion to include additional entities that do not meet those thresholds but still warrant advanced testing based on their risk profile.

The Thresholds: Sector by Sector

The RTS defines concrete thresholds that trigger mandatory TLPT designation. These are the primary criteria — if you meet them, your competent authority will designate you.

Credit Institutions

Entities identified as Global Systemically Important Institutions (G-SIIs) or Other Systemically Important Institutions (O-SIIs) under the CRD framework. If your bank has been designated as an O-SII by your national authority, expect a TLPT notification.

Payment Institutions and Electronic Money Institutions

Payment institutions that have processed more than EUR 120 billion in total payment transactions in each of the previous two financial years. Electronic money institutions may qualify based on a lower threshold of EUR 40 billion in outstanding e-money.

Insurance and Reinsurance Undertakings

Entities exceeding EUR 500 million in gross written premiums in each of the previous two financial years, along with other criteria related to market significance.

Financial Market Infrastructures

Central securities depositories and central counterparties are included by default, given their foundational role in post-trade services. Trading venues with electronic systems must also perform TLPT if they hold the largest national market share in financial instruments or exceed a 5 percent market share at EU level over the previous two years.

Discretionary Designation

Beyond these thresholds, national competent authorities can require any other financial entity to perform TLPT based on risk factors, market impact, and operational dependencies. This is the second layer — it means that even if you do not hit the numeric thresholds, your supervisor can still designate you if they consider your ICT risk profile warrants it.

If You Are Not Designated: What You Still Need to Do

If you have not received a TLPT notification, you are not off the hook for resilience testing. Articles 24 and 25 require all financial entities (except Article 16 entities) to maintain a risk-based digital operational resilience testing programme. This includes:

  • Vulnerability assessments and scans
  • Network security assessments
  • Software and source code reviews where feasible
  • Penetration testing (standard, not threat-led)
  • Scenario-based testing
  • Performance testing and end-to-end testing

The testing programme must cover all ICT systems supporting Critical or Important Functions and be reviewed and updated at least annually. Independent testers must carry out the testing — though the independence requirement can be met through internal resources if they are free from conflicts of interest.

The practical difference is scope and intensity. Standard resilience testing targets specific systems or applications. TLPT targets your organisation as a whole, simulating how a real adversary would chain together multiple techniques to compromise your critical functions.

What TLPT Actually Involves

If you are designated, here is what the process looks like from start to finish. A realistic timeline is 12 to 18 months from the decision to launch to the formal closure and attestation.

Phase 1: Preparation

You form an internal Control Team — a small group of senior staff who manage the TLPT process. The Control Team is the only group in your organisation that knows the test is happening. The blue team (your SOC, your security operations, your incident responders) must not be informed. This is deliberate — the test measures your actual detection and response capability, not your prepared-for-it capability.

During preparation you also:

  • Define the scope. The test must cover several or all of your Critical or Important Functions and the live production systems that support them. You propose the scope; your competent authority validates it.
  • Select providers. You need a Threat Intelligence (TI) provider and a Red Team provider. The TI provider must always be external. The red team can be internal for some tests, but every third TLPT must use an external red team. Significant credit institutions must use external testers exclusively.
  • Establish rules of engagement. Document what methods are permitted, what is off-limits, and define kill switches — mechanisms to halt the test immediately if unintended disruption occurs.

Phase 2: Threat Intelligence

The TI provider produces a targeted threat intelligence report specific to your entity. This is not a generic threat landscape briefing. It identifies the actual threat actors most likely to target your organisation, their tactics, techniques and procedures, and the attack scenarios most relevant to your critical functions.

The red team builds its test plan from this intelligence. The scenarios must be realistic and reflect genuine adversary behaviour — not textbook vulnerabilities.

Phase 3: Red Team Testing

The active testing phase lasts at least 12 weeks. The red team attempts to compromise your critical functions using the scenarios developed from the threat intelligence. They operate against your live production systems.

During this phase, the red team reports weekly to the Control Team and, where applicable, to the TLPT authority. The Control Team monitors progress and can adjust the test plan if necessary — for example, if a particular attack path risks genuine operational disruption that exceeds acceptable limits.

Your blue team does not know this is happening. They respond (or fail to respond) to the red team's activities as they would to any real attack.

Phase 4: Closure — Purple Teaming and Remediation

This is where DORA adds something that TIBER-EU originally treated as optional: mandatory purple teaming. Once the active testing phase ends, the blue team is informed, and both teams sit down together.

Purple teaming is a structured replay where the red team walks through every action they took — every initial access attempt, every lateral movement, every data exfiltration path — and the blue team explains what they detected, what they missed, and why. The point is mutual learning: the red team sees how their actions looked from the defender's perspective, and the blue team discovers which attack techniques were invisible to them.

This is not a presentation. It is collaborative analysis. Alternative attack paths that were not executed are also explored: what would have happened if the red team had gone left instead of right?

Reporting timeline:
  • The red team submits its report to the Control Team within 4 weeks of completing active testing
  • The Control Team shares the report with the blue team
  • The blue team submits its own report within 10 weeks
  • The Control Team prepares a Test Summary Report
Remediation plan:

Within 8 weeks of the Test Summary Report, you submit a remediation plan to your competent authority. This plan must cover every finding and include:

  • Root cause analysis for each vulnerability or detection gap
  • Proposed remediation measures
  • Prioritisation (critical findings first)
  • Implementation responsibilities and timelines
  • Risk analysis for any findings you choose not to remediate immediately

Phase 5: Attestation

After reviewing your test summary and remediation plan, your competent authority issues an attestation confirming that the TLPT was conducted in compliance with DORA requirements. This attestation enables mutual recognition across EU jurisdictions — meaning another member state's supervisor will accept that the test was valid.

How to Determine and Document Your TLPT Position

Whether you are designated or not, you should document your assessment of whether TLPT applies to you. This serves two purposes: it demonstrates that you have considered the requirement, and it gives your competent authority a clear basis for their own assessment.

If You Are Below the Thresholds

Document the following:

  • Entity classification — Your entity type, authorisation, and supervisory authority
  • Threshold assessment — For your sector, state the relevant RTS threshold and your own position against it. For example: "We are a payment institution. Our total payment transaction volume for 2024 was EUR 8.3 billion and for 2025 was EUR 9.1 billion. The TLPT threshold for payment institutions is EUR 120 billion over each of the previous two years. We are significantly below this threshold."
  • Systemic relevance — Assess whether your entity has systemic character at national or EU level. If you are not designated as an O-SII or equivalent, state that.
  • Discretionary risk factors — Consider whether any aspect of your operations might attract discretionary designation: high ICT dependency, concentration risk with a single provider, critical role in a payment chain, or history of significant ICT incidents.
  • Conclusion — State that based on the above assessment, you do not currently meet the criteria for mandatory TLPT under Article 26, and that you will reassess annually or upon material change.
  • Ongoing resilience testing — Reference your existing testing programme under Articles 24-25, confirming that standard penetration testing and vulnerability assessments are being conducted.

If You Have Been Designated

Document your preparation approach:

  • Notification details — Date of notification, competent authority, any specific instructions received
  • Scope proposal — Which Critical or Important Functions will be included, which live production systems they depend on, and which third-party providers are in scope
  • Provider selection criteria — How you will select TI and red team providers, including Article 27 qualification requirements
  • Internal vs external testers — Whether you will use internal red team resources and, if so, the independence safeguards in place
  • Timeline — Target dates for each phase, including buffer for the 12-week minimum active testing period
  • Governance — Control Team composition, escalation procedures, kill switch protocols
  • Budget and resources — Realistic cost and resource allocation (TLPT engagements typically require significant investment in external providers)

If You Are Uncertain

Some entities fall close to the thresholds or have characteristics that could trigger discretionary designation. If you are in this position:

  • Document your threshold position honestly, including any upward trends
  • Proactively engage your competent authority to understand their approach to discretionary designation in your jurisdiction
  • Prepare your resilience testing programme so that it could be scaled up to TLPT if needed — this means investing in CIF identification and asset mapping now, rather than after notification
  • Consider whether a voluntary TLPT would strengthen your overall resilience posture, even if not yet mandatory

Key Differences: Standard Penetration Testing vs TLPT

It is worth being clear about what separates these two, because they are fundamentally different exercises.

Standard penetration testing typically targets a specific application, network segment, or system. It lasts one to two weeks. The scope is defined technically. The testers look for known vulnerability classes. The output is a vulnerability report with severity ratings. TLPT targets your organisation's critical functions, not individual systems. It lasts at least 12 weeks. The scope is defined by business criticality. The testers simulate real adversary behaviour based on specific threat intelligence. The output includes attack narratives, detection gap analysis, mandatory purple teaming findings, and a remediation plan reviewed by your competent authority.

Standard penetration testing tells you whether a system has vulnerabilities. TLPT tells you whether your organisation can detect and respond to a determined attacker targeting your most important functions.

Common Mistakes

Assuming you are not in scope without checking. The discretionary designation power means that even entities below the published thresholds can be required to perform TLPT. Do not assume — check with your competent authority and document your assessment. Confusing TLPT with regular penetration testing. Some entities commission a standard pentest, label it as TLPT, and consider themselves compliant. The two are structurally different. A pentest that does not involve threat intelligence, does not run on live production systems, does not include purple teaming, and is not attested by your competent authority is not a TLPT. Underestimating the timeline. From initial scoping to attestation, a TLPT programme takes 12 to 18 months. If you receive a notification and have not started planning, you are already behind. The provider selection alone can take months — qualified TLPT providers with the required Article 27 credentials are in limited supply. Forgetting the blue team matters. TLPT is not just a red team exercise. The closure phase — purple teaming, blue team analysis, remediation planning — is where the actual operational resilience improvement happens. Treating the red team report as the final deliverable misses the point of the exercise. Not budgeting for remediation. The test is not the end. The remediation plan is a commitment to your competent authority. If you identify critical gaps during TLPT but then do not fund or prioritise the fixes, the attestation process becomes significantly harder.

Where to Start

If you have not assessed your TLPT position yet:

  • Check the thresholds. Look up the RTS criteria for your sector and compare your entity's metrics against them. This takes an afternoon, not a project.
  • Check for notification. If you are above the thresholds or close to them, confirm with your competent authority whether you have been or will be designated.
  • Document your position. Whether you are in scope or not, write it down. A one-page assessment that states your entity type, the relevant threshold, your position, and your conclusion is sufficient.
  • Review your CIF identification. TLPT scope is built on Critical or Important Functions. If your CIF identification work is incomplete or outdated, fix that first — it is a prerequisite for scoping a meaningful test.
  • Assess your testing programme. Even without TLPT, your resilience testing under Articles 24-25 must be risk-based, cover CIF-supporting systems, and be reviewed annually. Make sure it is.

TLPT is a serious undertaking, but it is also one of the more well-defined requirements in DORA. The RTS spells out what is expected, the TIBER-EU framework provides a proven methodology, and the phased structure gives you a clear path from preparation to attestation. The key is starting with an honest assessment of whether it applies to you — and being ready if it does.

Ready to simplify DORA compliance?

Purpose-built platform for EU financial entities. Start your free trial today.

Get Started →