DORA threat-led penetration testing: how to assess a TLPT provider

Before procuring threat-led penetration testing (TLPT), establish whether your financial entity must perform it under DORA. A need to assess detection and response may justify a voluntary adversary simulation, but that need alone does not create a regulatory TLPT obligation. For entities identified for mandatory TLPT, a conventional penetration test cannot fulfill that obligation. TLPT supplements the wider digital operational resilience testing program. DORA, Articles 24–26

DORA provides the operational resilience framework for the EU financial sector and has applied since January 17, 2025. Commission Delegated Regulation (EU) 2025/1190, published on June 18, 2025, sets out the detailed TLPT regulatory technical standards, referred to below as the RTS. Provider selection therefore needs to establish whether the proposed people, contractual relationships, and delivery arrangements meet the applicable requirements. European Commission: Cyber resilience, DORA, Article 64, TLPT RTS

Establish applicability and scope

A conventional penetration test assesses technical and configuration weaknesses, often within a single system or environment. An intelligence-led red-team test examines a targeted attack scenario involving people, processes, and technologies. Choose the exercise around the evidence needed, while separately establishing whether the regulatory TLPT process applies. TLPT RTS, recital 12

The relevant authority identifies entities required to perform TLPT using the applicable criteria. For those entities, DORA sets a baseline frequency of at least once every three years. The competent authority may adjust that frequency according to the entity’s risk profile and operational circumstances. A provider’s service label does not establish applicability. DORA, Article 26

Each TLPT must cover several or all critical or important functions and run on the live production systems supporting them. The entity must identify the relevant underlying ICT systems, processes, technologies, and outsourced support. The scope specification must explain which functions are included or excluded, identify supporting systems and relevant third parties, and define high-level test objectives, called flags. The management body must approve the document, and the TLPT authority must also approve it. A scope attached to a supplier’s proposal does not replace those approvals. DORA, Article 26(2)–(3), TLPT RTS, Article 9 and Annex II

Assign responsibilities and protect secrecy

The control team manages the test. It includes the entity's staff and, where relevant to the scope, personnel from its service providers and other participating parties. Its lead must be a member of the financial entity's staff and is responsible for day-to-day management and the team's decisions and actions. The red team comprises the testers simulating attacks. The blue team comprises personnel defending the entity, including relevant service-provider personnel. The TLPT authority assigns test managers to oversee the exercise. TLPT RTS, Articles 1, 3–4 and 9

Route scoping work through the control team. Access to information about a planned or ongoing TLPT is restricted on a need-to-know basis to the control team, management body, testers, threat intelligence provider, and TLPT authority. Before involving any blue-team member, the control team must consult the test managers. Do not automatically notify the security operations center (SOC), network operations center (NOC), or security-monitoring lead. Disclosure to defenders must follow the approved TLPT arrangements. TLPT RTS, Article 4

The entity remains responsible for compliance, including arrangements for participating ICT third-party providers. Its control team assesses providers, prepares the scope, manages test risks, and coordinates submissions. The external threat intelligence provider develops targeted intelligence and proposed scenarios; the testers prepare and execute the red-team plan. The blue team later documents defensive activity and participates in learning exercises. The authority oversees the process and performs the prescribed approvals. Appointing a provider does not transfer these responsibilities. DORA, Article 26, TLPT RTS, Articles 3–5 and 9–12

Assess the named team and delivery commitments

The table summarizes regulatory requirements and recommends evidence to request during procurement. The evidence requests are practical assessment methods; they are not an exhaustive list of statutory document requirements. Map the final procurement documents to the full applicable provisions and the authority’s requirements.

Staffing thresholds are only part of the assessment. Threat intelligence personnel also need intelligence-gathering, geopolitical, technical, sector, and communication skills. External testers need capabilities including reconnaissance, risk management, exploit development, physical penetration, social engineering, vulnerability analysis, and knowledge of the entity’s business. TLPT RTS, Article 7(1)(e)–(f)

Check independence at both staff and provider level

Apply three separate checks before selecting external providers:

1. Concurrent work by assigned intelligence staff. Under Article 7(1)(e)(iv), personnel assigned to provide threat intelligence for the TLPT must not simultaneously perform blue-team tasks or other services that may create a conflict of interest concerning a financial entity, ICT third-party service provider, or ICT intragroup service provider involved in that TLPT.
2. The external red team’s employment and service relationships. Under Article 7(1)(f)(iv), the assigned external red team must not be employed by, or provide services to, a threat intelligence provider that simultaneously performs blue-team tasks for a financial entity, ICT third-party service provider, or ICT intragroup service provider involved in the TLPT. This check concerns the relationship with that provider, including its concurrent defensive services.
3. Separation within a shared provider. Under Article 7(1)(e)(v) and (f)(v), the assigned intelligence and external-testing staff must be separate. The assigned intelligence staff must not report to the staff providing external testers for the same TLPT. This separation requirement applies alongside the first two restrictions. TLPT RTS, Article 7(1)(e)–(f)

For example, suppose a bidder supplies threat intelligence and external testers while also operating a participating entity’s SOC. If the external red team is employed by that bidder, the relationship falls within Article 7(1)(f)(iv). Putting intelligence, testing, and SOC personnel in separate departments does not by itself satisfy that provision. Any proposed exceptional arrangement must follow the process described below. This example applies the rule to a hypothetical provider structure. TLPT RTS, Article 7(1)(f)(iv) and 7(2)

Screen more than SOC contracts: blue-team tasks also include ICT infrastructure, helpdesk support, and operational incident management. Include each of those service categories in the relationship register when relevant to the financial entity, participating ICT provider, or intragroup provider. TLPT RTS, Article 1(4)

As procurement evidence, require a relationship register identifying each assigned person’s employer, the relevant legal entities, service and subcontracting relationships, concurrent defensive and potentially conflicting assignments, their recipients and dates, and reporting lines. It should cover the participating financial entities and ICT third-party and intragroup providers. Support it with conflict declarations and relevant contract extracts or equivalent verifiable records. Recommend a contractual duty to report changes so the control team can reassess the arrangement.

The control team must retain compliance evidence, document its assessment, and provide evidence to the test managers before contracting the selected external providers. Article 7(2) permits an exceptional arrangement where one or more requirements in Article 7(1)(a)–(f) are unmet, provided the entity adopts and records appropriate measures to mitigate the resulting risks. This is subject to the authority’s assessment under Article 9(11). The control team must not contract the providers if the authority considers the applicable requirements or exception conditions unmet. A conflict declaration or separate staffing arrangement does not itself establish eligibility for this exception. TLPT RTS, Articles 7(2) and 9(11)

Establish whether internal testers are eligible

Credit institutions classified as significant under Article 6(4) of Regulation (EU) No 1024/2013 must use external testers. Other eligible entities using internal testers must engage external testers every third test. Internal testing requires authority approval, sufficient dedicated resources, avoidance of conflicts of interest, and an external threat intelligence provider. DORA, Articles 26(8) and 27(2)

The RTS also requires a documented, periodically reviewed internal-tester policy covering suitability, competence, conflicts, management responsibilities, and training. The internal team must include a lead and at least two additional members, all employed by the entity or an ICT intragroup service provider for the preceding 12 months. The entity must provide sufficient resources and protect its defensive and resilience capabilities. Testers employed by an ICT intragroup service provider count as internal testers. TLPT RTS, Article 15

Make approvals and testing boundaries explicit

Following the authority’s notification to initiate TLPT, the entity has three months to submit the initiation information to the test managers and six months to submit the scope specification. The authority validates the initiation information and control-team composition. Provider selection must be completed before the testing phase begins. TLPT RTS, Article 9

After scope approval, the threat intelligence provider develops targeted intelligence and proposed scenarios. The control-team lead selects at least three scenarios using the provider’s recommendations, test-manager input, tester feasibility assessments, and the entity’s characteristics. At most one may use the forward-looking, non-threat-led exception in Article 10(4). The authority approves the targeted intelligence report; the control team and authority then approve the red-team plan before active testing begins. TLPT RTS, Articles 10–11

The control team must assess production risks, including incident escalation, effects on third parties, offensive and defensive actions, and incomplete restoration. It must consult the test managers about the risk assessment and controls before testing. Providers must follow Article 7’s restoration requirements and prohibitions, including those concerning uncontrolled modification, intentional disruption of the continuity of critical or important functions, and unauthorized inclusion of systems outside the scope. Testing boundaries follow the approved TLPT scope, plan, and risk controls; TLPT does not authorize unrestricted activity. TLPT RTS, Articles 5, 7 and 9(10)

For procurement, require named emergency contacts, protected communication channels, measurable stop conditions, and recorded restoration checks. Suggested stop conditions include credible risk of data corruption or service degradation beyond an agreed tolerance. The control-team lead may suspend testing in the exceptional risk circumstances specified in Article 11(10). Changes to an approved red-team plan require approval by the control-team lead and test managers. TLPT RTS, Article 11(6) and (10)

Purple teaming brings testers and defenders together to examine attack and defense techniques. During active testing, limited purple teaming is an exceptional last resort requiring prior authority validation under Article 11(10). The purple-team exercise required during closure serves a separate learning purpose. TLPT RTS, Articles 11–12

Contract for safe handling of results

For external testers, the contract must govern the safe handling and processing of TLPT results. Ask for reviewable terms and procedures covering the creation, storage, combining, drafting, reporting, transmission, and destruction of results. Record access rights, approved locations, and retention periods as implementation evidence, then confirm that the arrangement prevents risks to the financial entity. This is a procurement obligation, not a post-test administrative task. DORA, Article 27(3)

Procure closure evidence and submission support

After active testing ends, the control-team lead informs the blue team that TLPT took place. Testers must submit their red-team report to the control team within four weeks. The control team forwards it to the blue team and test managers without undue delay. The blue team submits its report to the control team no later than ten weeks after active testing ends; the control team then forwards it to the testers and test managers without undue delay. TLPT RTS, Article 12(1)–(4)

Within ten weeks of the end of active testing, testers and defenders must conduct a replay: a joint reconstruction of the offensive and defensive actions performed during the test. The control team must also conduct a purple-team exercise on jointly identified topics. Participants exchange feedback after the replay and purple-team exercises. TLPT RTS, Article 12(5)–(6)

The red-team report records successful and unsuccessful attack paths, achieved and unachieved flags, deviations, assistance, findings, and remediation recommendations. The blue-team report connects attack steps with detected actions and corresponding logs, assesses findings, and records defensive evidence, root causes, and lessons. Together, these deliverables support an assessment of defensive effectiveness. TLPT RTS, Annexes V–VI

The next deadline starts when the TLPT authority notifies the control-team lead under Article 12(7) that both reports contain the information required by Annexes V and VI. Within eight weeks of that notification:

• The entity submits the test summary report, containing the Annex VII information, to the TLPT authority for approval.
• The entity provides the remediation plan and the documentation demonstrating compliant execution under DORA Article 26(6) to the TLPT authority and, if different, its competent authority.

These are separate deliverables with the same notification-based deadline. TLPT RTS, Articles 12(7) and 13(1)

For each finding, the remediation plan must include the shortcoming, proposed measures, priority, expected completion, root-cause analysis, responsible staff or functions, and risks of not implementing the measures and, where relevant, of implementing them. As additional procurement recommendations, record dependencies, appropriate interim compensating measures, and how remediation will be verified. These additional fields are not expressly listed in Article 13. TLPT RTS, Article 13(2)

The authority issues the attestation confirming execution in accordance with the requirements evidenced by the documentation, supporting mutual recognition between authorities. The provider should support the documentation but cannot issue the authority’s attestation. The entity must notify its relevant competent authority of the attestation, findings summary, and remediation plans. DORA, Article 26(6)–(7), TLPT RTS, Article 14

Before issuing the request for proposals

Prepare a short decision record covering the authority’s notification and requirements, the proposed several or all critical or important functions, supporting systems and third parties, tester eligibility, the control-team lead, and the approval schedule. Require bidders to map their named teams, employment and service relationships, and deliverables to the evidence requests above. Assess eligibility, independence, controlled execution, and closure support before comparing price.

Use this guide to structure procurement and evidence review. Resolve entity-specific applicability, scope decisions, and permitted testing arrangements with the relevant authority.

FAQ

Can a three-day red-team exercise satisfy DORA TLPT requirements?

No. The active red-team phase alone must last at least 12 weeks, within the prescribed preparation, approval, testing, and closure process. A shorter exercise may serve a separate testing objective. TLPT RTS, Articles 9–12

Can one provider supply both threat intelligence and external testers?

Yes, subject to all applicable requirements. Assigned intelligence and testing staff must be separate, and intelligence staff must not report to the external-testing staff for the same TLPT. Assigned intelligence staff must also satisfy the restrictions on concurrent defensive or conflicting work. In addition, the external red team must not be employed by, or provide services to, a threat intelligence provider simultaneously performing blue-team tasks for a participating financial entity or ICT third-party or intragroup provider. Separate teams alone do not satisfy that last restriction. Any proposed exception must follow Articles 7(2) and 9(11). TLPT RTS, Articles 7 and 9

Does a red-team report showing no achieved test objectives prove that monitoring worked?

No. That result alone does not establish which actions were detected or how defenders responded. Assess the blue-team report, corresponding logs, and replay alongside the red-team evidence. TLPT RTS, Article 12 and Annexes V–VI

Further reading

• Penetration test preparation — this checklist is for conventional penetration tests. For TLPT, disclosure follows the control team's arrangements and the authority's requirements.
• Reporting and risk