DORA threat-led penetration testing — who is identified, who validates the scope, and the attestation
You do not decide whether you are in scope for threat-led penetration testing, and you do not decide the scope of the test — the competent authority identifies the entities and validates the scope. Articles 26 and 27 of Regulation (EU) 2022/2554 set up TLPT as a three-yearly exercise on live production systems, with rules on which testers may be used, when internal testers are allowed, and how third-party providers get pulled in. This walks through the identification mechanism, the scoping step firms underestimate, the pooled-testing route, and the attestation that makes a test travel across borders.
1. Who has to do it, and who decides
Article 26(1) sets the population by exclusion and then by designation. TLPT applies to financial entities other than those referred to in Article 16(1), first subparagraph — the entities on the simplified ICT risk management framework — and other than microenterprises, which are identified in accordance with paragraph 8.
That last clause is the one that matters. Being outside the two exclusions does not put you in scope; being identified does. Under Article 26(8), competent authorities identify the financial entities that are required to perform TLPT, taking into account the criteria in Article 4(2) and based on an assessment of impact-related factors — in particular the extent of the services provided and activities undertaken by the entity — among others.
The baseline frequency is at least every three years. Article 26(1) then allows the competent authority, based on the entity’s risk profile and taking account of operational circumstances, to request the entity to reduce or increase that frequency where necessary. So the cycle is a default, not a fixed cadence.
2. What is tested, and on what
Article 26(2) is unusually specific about the target. Each threat-led penetration test must cover several or all critical or important functions of the entity, and must be performed on live production systems supporting those functions. There is no test-environment option.
The identification exercise underneath is broader than the test itself. Entities must identify all relevant underlying ICT systems, processes and technologies supporting critical or important functions and ICT services — including those supporting critical or important functions which have been outsourced or contracted to ICT third-party service providers. Outsourcing removes the systems from your estate; it does not remove them from the scoping exercise.
Article 26(5) then requires the entity, with the cooperation of ICT third-party providers and other parties involved including the testers but excluding the competent authorities, to apply effective risk management controls to mitigate the risks of potential impact on data, damage to assets, and disruption to critical or important functions, services or operations — at the entity itself, at its counterparts, or to the financial sector. Testing live production against a real threat scenario is an operational risk in its own right, and the mitigation of that risk is a named obligation.
3. Pulling in third-party providers, and the pooled route
Article 26(3) states the default: where ICT third-party service providers are included in the scope, the financial entity must take the necessary measures and safeguards to ensure their participation, and retains at all times full responsibility for ensuring compliance with the Regulation. Getting a provider to participate is the entity’s problem, and its failure to participate is the entity’s non-compliance.
Article 26(4) provides the escape valve. Where a provider’s participation is reasonably expected to have an adverse impact on the quality or security of services delivered to customers that fall outside the scope of DORA, or on the confidentiality of data related to those services, the entity and the provider may agree in writing that the provider contracts directly with an external tester, to conduct — under the direction of one designated financial entity — a pooled TLPT involving several financial entities to which that provider supplies ICT services.
The pooled test must cover the relevant range of ICT services supporting critical or important functions contracted to that provider by the participating entities, and it counts as TLPT carried out by each participating entity. The number of participants must be duly calibrated taking into account the complexity and types of services involved.
Facts: a payment institution’s core processing runs on a shared platform used by many firms. The provider refuses to allow a red-team exercise against production, citing risk to its other clients, several of which are outside DORA.
What the rule says: that is exactly the Article 26(4) case. The route is a written agreement under which the provider contracts directly with an external tester for a pooled test under the direction of one designated financial entity — not an exclusion of the platform from scope, and not a paper assurance from the provider.
What the practitioner does: raises pooled testing with the provider and with the other affected firms early, since a pooled test needs a designated lead and a calibrated participant list. And it puts the participation obligation into the contract at renewal, because Article 26(3) makes the entity responsible for securing something it cannot compel commercially.
4. Who may run the test
Article 27(1) sets five cumulative requirements for any tester. They must be of the highest suitability and reputability; possess technical and organisational capabilities and demonstrate specific expertise in threat intelligence, penetration testing and red team testing; be certified by an accreditation body in a member state or adhere to formal codes of conduct or ethical frameworks; provide independent assurance or an audit report on the sound management of risks associated with carrying out TLPT, including due protection of the entity’s confidential information and redress for its business risks; and be fully covered by relevant professional indemnity insurance, including against risks of misconduct and negligence.
Internal testers are permitted, but conditionally. Article 27(2) adds three conditions on top of the five: the use must have been approved by the relevant competent authority or the designated single public authority; that authority must have verified that the entity has sufficient dedicated resources and ensured that conflicts of interest are avoided throughout the design and execution phases; and the threat intelligence provider must be external to the financial entity.
Two further constraints sit in Article 26(8). Where an entity uses internal testers, it must contract external testers every three tests. And credit institutions classified as significant under Article 6(4) of Regulation (EU) No 1024/2013 may only use external testers meeting Article 27(1), points (a) to (e).
| External testers | Internal testers | |
|---|---|---|
| Article 27(1) criteria | All five apply | All five apply |
| Prior approval | Not required as such | Required from the competent or designated authority |
| Resource and conflict check | — | Authority must verify dedicated resources and absence of conflicts across design and execution |
| Threat intelligence | May be provided by the tester | Must be external to the entity |
| Rotation | — | External testers must be contracted every three tests |
| Significant credit institutions | Mandatory | Not available |
Article 27(3) closes the data question: contracts with external testers must require sound management of the TLPT results, and any processing of those results — generation, storage, aggregation, drafting, reporting, communication or destruction — must not create risks to the financial entity. The test report is itself a concentrated map of your weaknesses, and its handling is a contractual requirement rather than a matter of trust.
5. The attestation, and mutual recognition
Article 26(6) sets the closing sequence, and the order is deliberate. At the end of the testing, after reports and remediation plans have been agreed, the entity and, where applicable, the external testers provide the designated authority with a summary of the relevant findings, the remediation plans, and documentation demonstrating that the TLPT was conducted in accordance with the requirements. Remediation planning is part of the test, not a follow-on project.
Article 26(7) then produces the deliverable that makes the exercise portable. Authorities provide the entity with an attestation confirming that the test was performed in accordance with the requirements, as evidenced in the documentation, in order to allow for mutual recognition of threat-led penetration tests between competent authorities. The entity notifies its relevant competent authority of the attestation, the summary of findings and the remediation plans.
For a passported group this is the commercially significant provision: a properly documented and attested test should not have to be repeated for each host authority. Article 26(7) also carries a caveat — without prejudice to the attestation, entities remain at all times fully responsible for the impact of the tests referred to in Article 26(4).
Facts: a group runs a TLPT in its home member state, presents the summary and remediation plans, and receives the attestation. A host authority later asks about advanced testing coverage for the same functions.
What the rule says: the attestation exists precisely to enable mutual recognition between competent authorities under Article 26(7), and the entity is required to notify its relevant competent authority of the attestation, the findings summary and the remediation plans.
What the practitioner does: keeps the attestation, the summary and the remediation-plan status as a single retrievable package rather than as separate artefacts held by the security team, and treats the remediation tracker as the live document — an attested test with stalled remediation is a worse position than no test at all.
6. FAQ
How often is TLPT required under DORA?
At least every three years for entities identified by their competent authority. Article 26(1) lets the authority request a reduced or increased frequency based on the entity’s risk profile and operational circumstances.
Do we decide whether we are in scope?
No. Article 26(1) excludes entities on the simplified framework under Article 16(1) and microenterprises, but among the rest it is the competent authority that identifies which entities must perform TLPT, under Article 26(8).
Can the test run against a staging environment?
No. Article 26(2) requires the test to be performed on live production systems supporting several or all of the entity’s critical or important functions.
What if a cloud or platform provider refuses to take part?
The entity must take the measures and safeguards necessary to ensure participation and retains full responsibility. Where participation would adversely affect the provider’s out-of-scope customers or the confidentiality of their data, Article 26(4) allows a pooled test contracted directly by the provider with an external tester, under the direction of one designated financial entity.
Can we use our own red team?
Yes, subject to conditions: competent authority approval, verification of dedicated resources and absence of conflicts of interest, an external threat intelligence provider, and contracting external testers every three tests. Significant credit institutions must use external testers only.
Does an attested test count in other member states?
Article 26(7) provides for authorities to issue an attestation specifically to allow mutual recognition of threat-led penetration tests between competent authorities.
7. What to do, today
- Ask your competent authority whether you are identified, rather than inferring it from your size. Article 26(8) makes identification an authority decision.
- Run the underlying inventory first: all ICT systems, processes and technologies supporting critical or important functions, including outsourced ones. The scoping assessment depends on it and the authority validates the result.
- Open the provider conversation early. Participation clauses and the pooled-testing option both need contractual groundwork that cannot be done inside a test window.
- Check tester eligibility against all five Article 27(1) criteria, including accreditation or a formal ethical framework and professional indemnity cover for misconduct and negligence.
- If you use internal testers, confirm the authority approval is in place, the threat intelligence is externally sourced, and the every-third-test external rotation is scheduled.
- Treat remediation as part of the test. The Article 26(6) package is only submitted once reports and remediation plans are agreed.
Related: The DORA register of information · DORA Article 30 ICT contract terms · Major ICT incident reporting under PSD2 and DORA
