What DORA TLPT requires
DORA threat-led penetration testing is an authority-supervised exercise for selected financial entities. It brings together targeted threat intelligence, controlled testing of live production systems, defensive learning and accountable remediation. Commissioning a conventional penetration test does not by itself satisfy the TLPT process.
This guide explains the main requirements in DORA Articles 26 and 27 and Commission Delegated Regulation (EU) 2025/1190, the TLPT regulatory technical standards (RTS). For engagement planning, explore our DORA TLPT services. The preparation suggestions below are practical ways to organise the work, distinguished from the regulatory requirements they support.
| Question | Requirement to plan around |
|---|---|
| Who must perform TLPT? | Financial entities identified by the relevant authority under the applicable selection criteria; not every organisation subject to DORA. |
| How often? | At least every three years for entities required to perform TLPT, with the authority able to adjust frequency where necessary. |
| What is tested? | Several or all critical or important functions, through the live production systems supporting them, within a validated scope. |
| How long is active testing? | At least 12 weeks; preparation, threat intelligence and closure require additional time. |
| What follows testing? | Red and blue team reporting, replay, purple teaming, a summary report and a remediation plan. |
1. Confirm applicability and authority involvement
DORA’s wider resilience-testing programme and its advanced TLPT obligation are different. Article 26 provides for authorities to identify the entities that must perform TLPT. Article 2 of the RTS supplies selection criteria, including sector-specific quantitative criteria and the authority’s assessment of impact, financial stability concerns and ICT risk.
Do not assume that a headcount threshold, a customer request or being a bank settles the question on its own. Confirm the relevant legal entity, the authority responsible for TLPT, any notification received and whether a group or shared-service arrangement affects the proposed exercise.
The usual minimum frequency is once every three years. The competent authority can reduce or increase that frequency where necessary, based on the entity’s risk profile and operational circumstances. Put the confirmed schedule into your planning record rather than treating three years as an unconditional entitlement.
2. Scope critical functions and their dependencies
DORA Article 26 requires TLPT to cover several or all critical or important functions and to run on the live production systems supporting them. The financial entity identifies the relevant systems, processes, technologies and outsourced ICT services; the precise scope is subject to authority validation.
A useful working map connects each candidate function to its applications, identities, networks, data flows, staff processes and third-party dependencies. Record why a function is included or excluded, and reconcile the map with the scope specification required by RTS Article 9 and Annex II. Article 9(6) requires the management-body-approved scope specification to be submitted to the test managers within six months of the authority notification referred to in Article 9(1).
For example, a payment function may depend on a customer channel, identity services, transaction processing and an outsourced connection. Listing only the public website would leave the business process poorly explained. This is an illustrative scoping example, not a prescribed scenario.
Resolve third-party participation and permissions early. Article 26 addresses provider participation and, under specified conditions, pooled testing. Outsourcing a supporting service does not remove the financial entity’s responsibility for the TLPT. Read our TLPT scoping guide for a more detailed preparation approach.
3. Verify tester and threat-intelligence capability
DORA Article 27 requires suitable testers with the necessary expertise, capabilities and reputation. It also addresses certification or adherence to formal professional frameworks or codes, independent assurance, professional indemnity insurance, and protection of confidential information. The RTS adds provider requirements in Article 7.
Ask for evidence about the people who will deliver the engagement, their financial-sector threat-led testing experience, the delivery method, information-handling arrangements and conflicts of interest. A generic company brochure is not enough to assess the proposed team.
Internal testers are possible only under the applicable conditions and authority approval. DORA requires an external threat-intelligence provider when internal testers are used, and external testers at least every third test. Significant credit institutions under the Single Supervisory Mechanism must use external testers. RTS Article 15 adds internal-team governance, staffing and capability requirements.
The threat-intelligence report informs the attack scenarios and red team plan. RTS Article 10 requires the control team lead to select at least three scenarios. No more than one may use the permitted forward-looking, non-threat-led approach. Articles 10 and 11 set out the review and approval process. Keep the connection between intelligence, scenario, target function and test objective visible in the engagement documents.
4. Govern the live-production test
The RTS establishes a restricted control team within the financial entity and test managers on the authority side. Confidentiality matters because advance knowledge can alter defensive behaviour. Risk management is essential because the exercise concerns live services.
Before execution, turn the approved scope and red team plan into workable operating arrangements: authorised targets, communication channels, decision makers, escalation, stopping conditions, evidence handling and any agreed assistance. These preparation details help the teams operate safely; they do not replace the formal approvals.
Under RTS Article 11, active red team testing lasts at least 12 weeks. Testers report progress at least weekly to the control team and test managers. Changes to the approved plan and the use of assistance must follow the specified approval arrangements. The control team lead can suspend testing in the exceptional risk circumstances described in that article.
Budget separately for preparation, intelligence gathering and closure. A 12-week active phase is not a promise that the entire engagement will finish in 12 weeks. See our DORA TLPT timeline guide.
TLPT RTS Articles 4–6 and 11: governance, risk and execution
5. Complete reporting, replay and purple teaming
The exercise does not end when the testers stop. RTS Article 12 requires a red team report, a blue team report, replay, purple teaming and feedback. This gives the entity a way to connect the attack record with what defenders observed and how they responded.
| Milestone | Regulatory timing |
|---|---|
| Red team report | Within four weeks after the active red team testing phase ends. |
| Blue team report | After receiving the red team report and no later than ten weeks after active testing ends. |
| Replay | No later than ten weeks after active testing ends; Article 12 also requires a closure purple teaming exercise. |
| Summary report | Within eight weeks of the authority notification under Article 12(7) concerning the required contents of the red and blue team reports. |
| Remediation plan | Within eight weeks of that same Article 12(7) notification, to the TLPT authority and, if different, the competent authority. |
The eight-week clock is tied to the authority’s notification, not automatically to the last day of testing. Track these dates explicitly. The annexes specify report contents: Annex V for the red team, VI for the blue team, and VII for the summary.
6. Assign remediation and preserve evidence
RTS Article 13 requires the remediation plan to address each finding with the shortcoming, proposed measures, prioritisation and expected completion, root cause, responsible staff or functions, and risks associated with not implementing the measures or, where relevant, implementing them.
As a practical delivery measure, add an acceptance check to each action. “Improve detection” is difficult to close; a named detection change with a documented verification exercise is easier to assess. Preserve the distinction between a recommendation, an implemented change and a verified result.
DORA Article 26 provides for an authority attestation to support mutual recognition. RTS Article 14 and Annex VIII specify the attestation. It is not a provider-issued certificate that the organisation is secure or that every DORA obligation has been met.
A practical checklist before procurement
- Confirm the legal entity, relevant authority and TLPT requirement or notification.
- Identify candidate critical or important functions and map supporting dependencies.
- Nominate a control team lead with the necessary mandate and availability.
- Identify third parties, permissions, contracts and shared-service constraints.
- Request delivery-team evidence against the tester and provider requirements.
- Plan for the minimum active-testing period plus preparation and closure.
- Assign owners for reports, authority submissions and remediation decisions.
- Agree secure channels before sharing sensitive architecture or technical evidence.
Use this checklist to prepare a discussion, not as a substitute for the full regulatory text or your authority’s instructions. The existing DORA requirements overview and illustrative TLPT report provide additional context.
Plan your DORA TLPT engagement
Explore our DORA TLPT services, then describe your organisation, functions and authority context in the TLPT scoping brief. You can attach an NDA or existing RFP when contacting Atlant Security.
Primary sources
General information, not legal advice. Confirm the applicable requirements and test arrangements with your relevant authority.
Published by Atlant Security. Sources, editorial policy and corrections.
