Threat-Led Penetration Testing: Who DORA Actually Requires It From

Threat-led penetration testing is the most demanding obligation in DORA, and the first thing to establish is whether it applies to you at all. Most financial entities will never perform one.

For those that must, it is not a bigger penetration test. It runs on live production systems, its scope is validated by your regulator, and it can pull your ICT third-party providers into the exercise with you.

Who has to do threat-led penetration testing

Article 26(1) does not apply across the board. It reaches financial entities identified by their competent authority, excluding microenterprises and the entities referred to in Article 16(1).

Authorities make that identification against stated criteria: impact-related factors — the extent to which your services and activities affect the financial sector — possible financial stability concerns, including systemic character, and your ICT risk profile.

So threat-led penetration testing runs in reverse of what firms assume. You do not decide you are in scope and start planning. You are told.

The frequency is at least every three years, and it is adjustable: based on your risk profile and operational circumstances, the competent authority may require the frequency to be increased or reduced.

Live production, and a scope your regulator signs off

Article 26(2) contains the two requirements that separate threat-led penetration testing from ordinary testing.

It runs on live production systems supporting critical or important functions. Not a mirrored environment, not a staging copy. That single line drives the risk management, the deconfliction arrangements and the seniority of the people who need to approve it.

The scope is validated by the competent authority. You identify all relevant underlying ICT systems, processes and technologies supporting critical or important functions and ICT services, you assess which functions need to be covered, and the result of that assessment determines the scope — subject to validation by the authority. Scoping is a supervisory conversation, not an internal decision.

Threat-led penetration testing can pull in your providers

The scope explicitly includes critical or important functions that have been outsourced or contracted to ICT third-party service providers.

Where providers fall inside it, Article 26(3) requires the financial entity to take the necessary measures and safeguards to ensure their participation — and states that the entity retains at all times full responsibility for ensuring compliance.

That is a contractual problem discovered late by anyone who did not anticipate it. A provider under no obligation to participate in your regulator-validated test on live systems is a scoping failure with a long lead time to fix. The Regulation does contemplate the case where a provider’s participation would adversely affect the quality or security of services it delivers to other customers, which is why pooled arrangements exist — but that is a route to manage, not an exemption to assume.

Who is allowed to run a threat-led penetration test

Article 27 governs the testers, and two rules shape procurement.

Internal testers are permitted — with a limit. Where a financial entity uses internal testers for TLPT, it must contract external testers every three tests. An in-house red team can carry the programme, but not indefinitely.

Significant credit institutions must use external testers. Credit institutions classified as significant under Article 6(4) of Regulation (EU) No 1024/2013 may only use external testers meeting the Article 27(1) requirements.

The output is an attestation, and it travels

This is the part most worth knowing, and the part least often mentioned.

At the end of testing — after reports and remediation plans have been agreed — the financial 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.

The authority then provides an attestation confirming the test was performed in accordance with the requirements, expressly 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.

Mutual recognition is the commercial point. A group operating across Member States does not need a separate test per jurisdiction — the attestation is designed to carry.

Note also the ordering: remediation plans are agreed before the submission. A TLPT is not finished when the testers stop.

Where threat-led penetration testing comes from

DORA did not invent this. Recital 56 places it alongside relevant international standards — naming the G7 Fundamental Elements for Threat-Led Penetration Testing — and frameworks already applied in the Union such as TIBER-EU.

If your organisation has run a TIBER-EU engagement, the machinery is familiar. If not, that lineage is the best guide to what the exercise actually looks like in practice.

How threat-led penetration testing connects

Where to start with threat-led penetration testing

1. Establish whether you have been identified by your competent authority. Do not assume in either direction.
2. Get your critical or important function determinations right first, because they scope the test.
3. Fix provider participation contractually, well before a test is planned.
4. Prepare for live production testing — approvals, deconfliction, and who can stop the exercise.
5. Plan the tester mix against the every-third-test external rule, or the external-only rule if you are a significant credit institution.
6. Budget for remediation before submission, since plans must be agreed before the authority sees them.

This guide reflects Regulation (EU) 2022/2554 as published on EUR-Lex, read at 16 August 2026. Regulatory technical standards and national arrangements add detail — confirm with your competent authority.

The DORA Toolkit provides 100+ editable templates covering the digital operational resilience testing programme, the critical or important function determinations, the ICT third-party contractual requirements and the remediation tracking a TLPT submission depends on.