TLPT under DORA – how to start: who is in scope, the 7-stage timeline and RTS 2025/1190 deadlines

What is TLPT under DORA? Threat-led penetration testing (TLPT) is the advanced resilience test that the Digital Operational Resilience Act requires from designated financial entities: systemic banks, large payment and e-money institutions, CCPs, CSDs, major trading venues and large insurers. External testers replicate the tactics of real threat actors against live production systems, while a TLPT authority approves every stage and issues an attestation at the end. The test recurs at least every 3 years and is governed by Articles 26-27 of DORA and Commission Delegated Regulation (EU) 2025/1190, applicable since 8 Jul 2025.

Canonical definition: TLPT (threat-led penetration testing) is a resilience test required by Article 26 of DORA in which external testers simulate the tactics of real threat actors against live production systems, guided by targeted threat intelligence.

TLPT under DORA – key takeaways:

1. DORA (Regulation (EU) 2022/2554) has applied since 17 Jan 2025; Article 26 requires TLPT at least every 3 years from entities designated by their TLPT authority.
2. RTS 2025/1190 (published 18 Jun 2025, applicable from 8 Jul 2025) sets the designation thresholds, provider requirements and deadlines for each phase.
3. The obligation is triggered by a notification from the TLPT authority: 3 months to submit initiation documents, 6 months to submit the scope specification.
4. The active red-team phase lasts at least 12 weeks; a full cycle from notification to approved remediation plan typically takes 9-14 months.
5. The threat intelligence provider must always be external, and at least every third test must be delivered entirely by external testers.
6. Patronusec delivers TLPT as both threat intelligence provider and red team, with the staff separation the RTS demands – from readiness assessment through to remediation-plan support.

---

---

How is TLPT different from a conventional penetration test?

TLPT differs from a conventional penetration test in scope, objective and oversight. A penetration test finds vulnerabilities in a defined system over a short window, with the IT team’s knowledge. TLPT tests the whole organisation – people, processes and technology – on production systems, covertly against the defensive team, under regulatory supervision, and along scenarios derived from real threat intelligence.

Recital 12 of RTS 2025/1190 states the distinction plainly: conventional penetration testing assesses technical and configuration weaknesses of a single system or isolated environment, whereas threat-led red-team testing covers a full targeted-attack scenario against the entire entity. The practical consequences:

Criterion	Conventional pentest	Commercial red team	TLPT under DORA
Scenario basis	vulnerability catalogue, OWASP, PTES	objectives agreed with client	targeted threat intelligence (TTI) from an external provider
Environment	test or segregated production	usually production	live production systems only
Defenders’ awareness	usually informed	unaware	unaware (blue team must not know)
Active testing window	1-4 weeks	4-8 weeks	at least 12 weeks (RTS Art. 11(5))
Oversight	internal	internal	TLPT authority approves scope, providers, plan and reports
Outputs	vulnerability report	attack narrative	red-team report, blue-team report, test summary, remediation plan, authority attestation
Frequency	1-2 per year	as needed	at least every 3 years

TLPT differs from a conventional penetration test in that its attack scenarios are built on the tactics, techniques and procedures (TTPs) of real threat actors rather than on a list of technical vulnerabilities.

In practice, this means annual pentesting experience does not prepare an organisation for TLPT. The roles are different, the documentation is different, and the counterpart across the table is a test manager from the TLPT authority rather than your own IT department.

Patronusec Insight: In our project experience, the threat intelligence phase is the one entities most often underestimate. A targeted threat intelligence report is not an OSINT summary: Annex III of the RTS expects, among other things, analysis of leaked employee credentials, look-alike domains, information for sale on dark-web markets and profiles of the specific groups attacking the financial sector in your jurisdiction. If a provider reduces this to an external attack-surface scan, the scenarios will not survive the test manager’s approval. We run the TI phase in a team separate from the red team, as Article 7(1)(e) of the RTS requires, so the separation evidence is ready for the control team before contracting.

---

Who is in scope for TLPT under DORA, and how do you check whether your entity is?

Only financial entities designated by their TLPT authority under Article 26(8) of DORA and the criteria of Article 2 of RTS 2025/1190 must perform TLPT. There is no self-initiated obligation: the test starts when the entity receives a notification. Microenterprises and entities under the simplified ICT risk framework of Article 16 DORA are excluded.

Article 2(2) of RTS 2025/1190 lists the categories for which the TLPT authority requires the test by default, unless its assessment of the entity’s ICT risk profile indicates otherwise:

• credit institutions identified as global (G-SII) or other systemically important institutions (O-SII) under Article 131 CRD, and entities forming part of such groups;
• payment institutions whose total payment transactions exceeded EUR 150 billion in each of the two preceding calendar years;
• e-money institutions above the same transaction threshold or with e-money in circulation above EUR 40 billion;
• central securities depositories and central counterparties – no quantitative threshold;
• trading venues with the largest national market share in a class of instruments, or above 5 % of EU turnover;
• insurance and reinsurance undertakings with gross written premiums above EUR 1.5 billion, technical provisions above EUR 10 billion and assets above 3.5 % of the national sector – and, within that subset, those exceeding EUR 3 billion in premiums, EUR 30 billion in provisions or 10 % of sector assets.

Article 2(1) also allows the authority to designate any other financial entity on qualitative grounds: size, interconnectedness, substitutability of services, complexity of the ICT architecture, reliance on ICT third-party providers and the maturity of detection and response capabilities. Recital 3 explicitly names crypto-asset service providers authorised under MiCA as candidates for future designation.

The TLPT authority is the public body designated under Article 26(9) of DORA that identifies entities required to test, approves the scope and the providers, and issues the attestation once the test is closed – for significant credit institutions this is the European Central Bank.

Under DORA, each Member State designates its own TLPT authority – typically the national supervisor or central bank, often running a national TIBER implementation. Groups with entities in several Member States should expect the home authority to lead and host authorities to join as observers (RTS Art. 16). UK-headquartered groups are not subject to DORA in the UK, where CBEST and STAR-FS apply, but their EU subsidiaries are – and the DORA test cannot be replaced by a UK CBEST exercise without the EU authority’s recognition.

Decision tree – does TLPT apply to your entity?

1. Are you a microenterprise or under the simplified framework of Article 16 DORA? → YES: outside TLPT; only the baseline testing programme of Articles 24-25 applies. NO: go to step 2.
2. Do you fall into a category of Article 2(2) RTS (O-SII, payment institution above EUR 150 billion, CCP, CSD, large insurer)? → YES: expect a notification; start preparing now. NO: go to step 3.
3. Do you provide functions the sector depends on, or belong to a group in which another entity meets the thresholds? → YES: qualitative designation or a joint group TLPT is possible; assess readiness. NO: TLPT is unlikely, but the Article 24 testing obligations (including penetration tests and vulnerability scans) remain.

In practice: if you sit in step 2 or 3, preparations should begin before the notification arrives, because the RTS deadlines run from that date and leave no allowance for procurement or for building a control team.

---

What are the roles in a TLPT and who is responsible for what?

A TLPT involves five roles: the control team and the blue team within the entity, the TLPT cyber team (test managers) within the authority, and two external TLPT providers – the threat intelligence provider and the testers (red team). Article 1 of RTS 2025/1190 defines these roles and mirrors the TIBER-EU structure.

Role	Who	Core responsibilities	Basis
Control team lead	entity employee with board access	day-to-day management, decisions, secrecy, liaison with the authority	RTS Art. 4(1)
Control team (white team)	3-6 people: security, IT, risk, legal	scope, provider selection, test risk assessment, leg-ups, board reporting	RTS Art. 9(4)
Blue team	SOC, infrastructure, incident response – unaware of the test	normal defence; afterwards the blue-team report and replay	RTS Art. 1(3), Art. 12
TLPT cyber team (TCT)	test manager plus at least one deputy from the authority	approves documents, monitors every phase, issues the attestation	RTS Art. 3
Threat intelligence provider	external, always	targeted threat intelligence report, actor profiles, at least 3 scenarios	RTS Art. 10, DORA Art. 27
Testers (red team)	external or internal (every third test external)	red-team test plan, active testing of 12+ weeks, red-team report, purple teaming	RTS Art. 11-12

The blue team in a TLPT is the entity’s defensive staff who, under Article 1(3) of RTS 2025/1190, are not aware of the test – which is why the test carries a code name and information is shared strictly on a need-to-know basis.

Two elements of this structure are routinely under-resourced. First, the control team lead needs a genuine mandate: Recital 10 of the RTS calls for appropriate seniority and access to the management body, because this person decides whether to suspend the test when business continuity is at risk. Second, Article 4(2)(c) obliges the control team to halt incident escalation if the blue team detects the testers – which requires a rehearsed procedure that does not reveal the test to the wider organisation.

---

How does a TLPT run step by step, and what deadlines does RTS 2025/1190 impose?

A TLPT runs in three phases – preparation, testing and closure – and RTS 2025/1190 attaches hard deadlines to each: 3 months for initiation, 6 months for the scope specification, at least 12 weeks of active red teaming, then 4, 10 and 8 weeks for the successive reports and the remediation plan. A full cycle typically takes 9-14 months.

Measured from the notification date (D), the sequence looks like this:

Step	What happens	RTS deadline	Article
1. Notification	the authority informs the entity and names the test managers	D	Art. 9(1)
2. Initiation	project charter (Annex I), control team lead, internal/external testers, communication channels, code name	D + 3 months	Art. 9(2)
3. Scope specification	all critical or important functions, supporting ICT systems, preliminary flags (Annex II); approved by the management body, then by the authority	D + 6 months	Art. 9(6)
4. Provider selection	assessment against DORA Art. 27 and RTS Art. 7; evidence to the authority before contracting	before the testing phase	Art. 9(9)-(11)
5. Threat intelligence	TTI report (Annex III), at least 3 scenarios, authority approval	about 4 weeks (Recital 18)	Art. 10
6. Red team	test plan (Annex IV), active testing, weekly progress reports	at least 12 weeks	Art. 11
7a. Red-team report	attack paths, flags captured, vulnerabilities, root causes (Annex V)	4 weeks after active testing ends	Art. 12(2)
7b. Blue-team report, replay and purple teaming	detections, log evidence, lessons (Annex VI); joint replay with testers	10 weeks after active testing ends	Art. 12(4)-(5)
7c. Test summary report	material findings for the authority (Annex VII)	8 weeks after the authority confirms the reports	Art. 12(7)
7d. Remediation plan	shortcomings, prioritised measures, root causes, owners, risk of non-implementation	8 weeks after the same confirmation	Art. 13
8. Attestation	the authority issues the attestation (Annex VIII) enabling mutual recognition across the EU	after closure	Art. 14

The active red-team testing phase of a TLPT lasts at least 12 weeks under Article 11(5) of Commission Delegated Regulation (EU) 2025/1190, and the scenarios may be executed sequentially or in parallel.

Some less obvious rules embedded in this timeline:

• Testers report progress to the control team and the test managers at least weekly (Art. 11(7)).
• Leg-ups – information or access granted to testers who are stuck – must be designed in the test plan and approved by the test managers (Art. 11(8)).
• If the blue team detects the test, the control team proposes measures to the test managers that allow the TLPT to continue while preserving confidentiality (Art. 11(9)).
• In exceptional circumstances the control team lead may suspend the test or, with the authority’s prior approval, continue with limited purple-teaming activities that count towards the 12-week minimum (Art. 11(10)).

In practice, the testing phase alone (TI plus red team) takes at least 4 months, and closure adds another 4-5. With up to 6 months of preparation on top, a first cycle rarely closes in under a year.

---

Does your entity meet the Article 2 thresholds, but the notification has not arrived yet?

Patronusec runs a TLPT readiness assessment: within 10 working days you receive an evaluation of your control team set-up, a preliminary list of critical or important functions for the scope, a gap map against Annexes I-II of the RTS, and a realistic schedule for your first cycle.

Book a TLPT readiness assessment

---

How do you select critical or important functions and build the scope specification?

You build the TLPT scope around critical or important functions (CIFs) from the register required by Article 8 of DORA, not around systems. Article 26(2) requires several or all such functions to be covered, and Article 9(7) of the RTS provides seven selection criteria. The scope specification is approved by the entity’s management body and then by the TLPT authority.

The criteria of Article 9(7) with which you justify including or excluding each function:

1. the critical or important nature of the function and its impact on the sector and on financial stability,
2. its importance to the entity’s ongoing business,
3. substitutability (could another entity take it over),
4. interconnections with other functions,
5. geographical location,
6. sectoral dependency of other entities on the function,
7. any threat intelligence available on the function.

Annex II requires the scope specification to list all CIFs and, for each one: the reasoning for inclusion or exclusion, the supporting ICT systems, whether services are outsourced and to which provider, the jurisdictions involved, and a high-level description of the preliminary flags indicating which security attribute each flag targets – confidentiality, integrity, availability or authenticity.

Flags in a TLPT are the key objectives within the ICT systems supporting critical or important functions that testers attempt to reach during the test, as defined in Article 1(14) of RTS 2025/1190.

The most frequent mistake at this stage is excluding functions delivered by ICT third-party providers. Article 26(3) of DORA requires the scope to cover providers whose services support CIFs; where a test could harm the provider’s other clients, Article 26(4) provides for pooled testing, in which the provider organises a single TLPT for several entities. If your entity shares a provider with other institutions, the authority may propose that model – raise it at initiation. For classifying providers and structuring due diligence, see our article on third-party risk management under DORA and NIS2.

---

What requirements must testers and the threat intelligence provider meet?

Testers and the threat intelligence provider must meet Article 27 of DORA (reputability, capability, certification or code of conduct, independent assurance report, professional indemnity insurance) and the detailed criteria of Article 7 of RTS 2025/1190: documented team experience, 3-5 references, no conflict with blue-team tasks and separation of TI staff from red-team staff. The control team records this assessment and presents the evidence to the authority before contracting.

Minimum team requirements under Article 7(1) of the RTS:

Requirement	Threat intelligence provider	External testers (red team)
Team composition	manager with ≥5 years in threat intelligence + at least 1 member with ≥2 years	manager with ≥5 years in penetration testing and red teaming + at least 2 testers with ≥2 years each
References from previous engagements	at least 3	at least 5
Skills	intelligence-gathering TTPs, geopolitical and sector knowledge, communication	reconnaissance, risk management, exploit development, physical penetration, social engineering, vulnerability analysis
CVs and certifications	detailed CVs and copies of certifications under recognised market standards	as opposite
Professional indemnity insurance	required, including errors and omissions	required
Conflict of interest	no blue-team tasks for the entity or its ICT providers	no link to a TI provider performing blue-team tasks
Separation	TI staff separated from, and not reporting to, the same provider’s red team	mirror requirement
After the test	secure deletion of credentials and collected data	additionally: C2 deactivation, backdoor removal, kill switches, breach notification

Under Article 27(2) of DORA, the threat intelligence provider in a TLPT must always be external to the financial entity, whereas testers may be internal provided the TLPT authority approves and every third test is outsourced.

Article 26(8) adds a further restriction: credit institutions classified as significant (directly supervised by the ECB) may use external testers only. For everyone else, Article 15 of the RTS sets the conditions for internal testers: a documented policy, a lead plus at least 2 members employed by the entity for the previous 12 months, and no adverse effect on defensive capabilities during the test.

One provider may deliver both the threat intelligence and the red team – the RTS then requires staff separation and no reporting line between the two teams (Art. 7(1)(e)(v) and (f)(v)). Patronusec delivers TLPT engagements in both roles with separate teams and separation evidence prepared for the test manager’s review, and we treat conventional penetration testing as the preceding step rather than a substitute.

Patronusec Insight: The Article 7 criteria are a floor, not a guarantee of quality. In our project experience, three things decide whether a test succeeds, and they are worth asking every provider about: can the team run an operation for 12 weeks without detection (C2 infrastructure, OPSEC discipline); does it have a documented procedure for the moment the blue team notices; and does its red-team report map attack paths to MITRE ATT&CK in a way the blue team can reproduce from its own logs. Our testers hold OSCP, CREST and OSWE certifications and write reports on the assumption that a supervisory test manager, not just the IT department, will read them.

---

How do you prepare the organisation before the TLPT authority’s notification arrives?

Preparing for TLPT before notification covers five areas: an up-to-date register of critical or important functions, a nominated control team lead and team, budget and procurement planning for TI and red-team services, an honest view of SOC maturity (the blue team is what gets tested), and contracts with ICT providers that permit production testing. All of it without informing the blue team.

Recital 20 of the RTS allows the active phase to exceed 12 weeks where the scope is large, so organisational maturity translates directly into test cost. The checklist below reflects the questions a test manager will ask during preparation.

TLPT readiness checklist (test manager’s perspective):

1. Is the Article 8 register of critical or important functions current, and mapped to ICT systems and providers?
2. Has a control team lead with board access and the authority to suspend the test been appointed?
3. Is the control team as small as possible (Recital 10) and free of anyone with blue-team duties?
4. Is there a procedure to halt incident escalation once testers are detected (Art. 4(2)(c))?
5. Do contracts with ICT third-party providers supporting CIFs permit production testing and define how their staff participate?
6. Has a test risk assessment been prepared across the six categories of Article 5(2), including financial-stability impact?
7. Are secure communication channels (encrypted email, data room, messenger) ready for the project charter (Annex I)?
8. Can budget and procurement contract a TI provider and testers within the window between scope approval and testing start?
9. Does SOC log retention allow the blue team to reconstruct 12 weeks of tester activity for its report (Annex VI)?
10. Does the board know it will approve the scope specification (Art. 9(6)) and own the remediation plan?

---

If nobody in your organisation can own these preparations, a vCISO can act as control team lead or adviser – kept separate from the teams under test. For the wider sequence of a security programme, see the 12-month cybersecurity roadmap.

---

Which beliefs about TLPT under DORA are myths?

Several beliefs about TLPT circulate that have no basis in the text of DORA or RTS 2025/1190. Each myth/fact pair below points to the relevant article.

MYTH: Every entity covered by DORA must perform TLPT.
FACT: Only entities designated by the TLPT authority perform TLPT (DORA Art. 26(8), RTS Art. 2). Everyone else runs the Article 24-25 testing programme, including penetration tests and vulnerability scans.

MYTH: TLPT can be delivered as an extended penetration test in a test environment.
FACT: Article 26(2) of DORA requires testing on live production systems supporting critical or important functions.

MYTH: One red-team provider can also produce the threat intelligence.
FACT: The threat intelligence provider must be external (DORA Art. 27(2)), and its staff must be separated from the same provider’s testers (RTS Art. 7(1)(e)(v)).

MYTH: The test ends with the red-team report.
FACT: Closure includes the blue-team report, replay, purple teaming, the test summary for the authority and the remediation plan (RTS Art. 12-13). Only then is the attestation issued.

MYTH: An internal red team can perform all tests.
FACT: Every third test must be delivered by external testers, and significant credit institutions may use external testers only (DORA Art. 26(8)).

---

FAQ – how to prepare for TLPT under DORA

---

Recommended reading

1. DORA and cyber resilience glossary – definitions of control team, threat intelligence and the other terms used in this article.
2. IT security testing methods – how penetration tests, scans and red teaming form the testing programme that precedes TLPT.
3. Third-party risk management – how to structure contracts with providers supporting critical functions before they enter the test scope.
4. Ransomware response playbook – the first 72 hours – the availability-loss scenario that Annex III of the RTS requires among the TLPT scenarios.

---

TLPT under DORA – free consultation

Patronusec delivers TLPT as threat intelligence provider and red team, with the separation of both roles required by RTS 2025/1190. We work with financial-sector and fintech clients, and our testers hold OSCP, CREST and OSWE certifications.

In a free 30-minute consultation we will help you:

• assess whether your entity meets the Article 2 thresholds of RTS 2025/1190 and when to expect a notification,
• shortlist the critical or important functions for the scope and the preliminary flags,
• define the control team composition and the confidentiality arrangements required by Article 4 of the RTS,
• set a realistic schedule for your first cycle around the 3-month, 6-month and 12-week deadlines.

Book a free TLPT consultation | TLPT testing | DORA implementation | Penetration testing | vCISO