Threat-led penetration testing is not penetration testing with more paperwork. With the regulatory technical standards under Article 26 of DORA now in force through Commission Delegated Regulation (EU) 2025/1190, adversary simulation in European finance has become a supervised activity with a named scope, a mandated cadence, an accredited supplier market, and a rule that quietly reshapes the whole exercise: the threat-intelligence provider must always be external to the institution being tested. Most banks have costed the test. Fewer have costed the supply chain it now depends on.
Executive Summary
- The regime is now specified, not sketched. Commission Delegated Regulation (EU) 2025/1190, published in the Official Journal on 18 June 2025, supplements DORA Article 26 with regulatory technical standards covering scope, methodology, results, the use of internal testers, and supervisory cooperation including mutual recognition across Member States.
- TIBER-EU is the substrate. The regime is built on the European framework for threat intelligence-based ethical red-teaming, so institutions with TIBER experience are not starting from zero — but TIBER participation was voluntary and this is not.
- Three years is the floor, not the plan. Designated entities test at least every three years across critical functions, and a competent authority may raise or lower that frequency on the entity's risk profile.
- Testing is only half the deliverable. A TLPT produces supervisory evidence. The artefacts — scoping rationale, threat intelligence, attack narrative, remediation and retest — are the output that matters, and they need to be built during the exercise rather than assembled afterwards.
What Actually Changes When a Test Becomes a TLPT #
Most banks already run offensive security. The instinct is therefore to treat TLPT as an existing capability with a compliance wrapper. That instinct is wrong in four specific places, and each has a budget consequence.
Table 1: Conventional offensive testing versus TLPT under DORA #
| Dimension | Conventional penetration test | TLPT under DORA |
|---|---|---|
| Who decides it happens | The institution, on its own risk appetite | A competent authority designates the entity; frequency is at least every three years |
| What is targeted | Systems chosen by the security function | Critical or important functions, including those running in production and those outsourced |
| Where the threat model comes from | Internal judgement or the tester's own library | Commissioned threat intelligence, from a provider external to the institution |
| Who may execute | Any competent supplier, or an internal team | Testers meeting Article 27 conditions; internal teams for at most two of every three cycles |
| What the output is for | An internal report and a remediation backlog | Supervisory evidence, with results and remediation subject to authority scrutiny and cross-border recognition |
The last row is where programmes tend to underestimate the work. A penetration-test report is written for the people who will fix the findings. A TLPT package is written for a supervisor who was not in the room, and it has to reconstruct why the scope was drawn where it was drawn, what the intelligence said, what the red team actually did, and what changed as a result.
Who Is In Scope, and Why You Do Not Get to Decide #
DORA does not apply the TLPT obligation to every entity in its perimeter. Competent authorities identify the financial entities required to perform it, taking account of systemic importance, size, and ICT risk profile; microenterprises are excluded.
Two consequences follow that are easy to miss.
Designation is not a maturity award. Being named means a supervisor considers your failure consequential, and it arrives with a cadence obligation attached. The correct reading is a standing three-year commitment with associated supplier procurement, not a one-off project.
Non-designation is not exemption from the reasoning. An entity that is not designated still has to demonstrate proportionate advanced testing under DORA's general testing provisions. The difference is the formality of the regime, not the presence of the expectation.
The Tester Market Is the Binding Constraint #
This is the part that belongs on a board slide, and it rarely appears on one.
Article 27 does not simply require competent testers. It requires testers who demonstrate technical and organisational capability with specific expertise in threat intelligence, penetration testing and red teaming; who are certified by an accreditation body in a Member State, or adhere to formal codes of conduct or ethical frameworks; who can provide independent assurance or an audit report covering the sound management of the risks the testing itself creates; and who carry professional indemnity insurance including cover against misconduct and negligence.
Table 2: What Article 27 asks of a tester, and what it screens out #
| Requirement | What it is really testing for | Who it removes from the market |
|---|---|---|
| Demonstrated expertise across threat intelligence, penetration testing and red teaming | That the supplier can run the whole chain, not one link of it | Boutiques strong in exploitation but without an intelligence function |
| Accreditation in a Member State, or a formal code of conduct | Verifiable standing rather than reputation | Individual contractors and informal collectives |
| Independent assurance or audit report on risk management | That testing a production bank will not break it | Suppliers without their own governance maturity |
| Professional indemnity cover, including misconduct and negligence | That there is a balance sheet behind the risk | Thinly capitalised firms |
Read those four rows together and the shape of the market becomes clear: a modest number of firms, mostly larger, and all of them selling into every designated entity across the Union on a synchronised three-year rhythm.
Institutions that treat tester procurement as a routine sourcing exercise scheduled a quarter ahead will discover the constraint at the worst moment. The scarce resource is not the red team; it is a qualifying red team with the right window and no conflict against your estate.
Internal Teams Help, But They Cannot Carry It #
Banks with mature offensive capability reasonably ask whether the internal team can absorb this. Partly.
Internal testers are permitted, subject to supervisory approval, adequate resourcing, and conflict-of-interest management — but with two hard limits. External testers must be contracted every three tests, so an internal team can cover at most two cycles in three. And the threat-intelligence provider must be external to the institution in every test, including the ones the internal team executes.
That second rule is the more interesting one, because it is not really about capability. An internal intelligence function knows which conclusions would be inconvenient. Requiring the intelligence to come from outside is a structural defence against a red team that quietly tests what the organisation is already comfortable being tested on — the failure mode that makes an exercise reassuring rather than informative.
The practical planning consequence: build the internal capability for the cycles it can serve, but treat external intelligence as a permanent line item rather than a periodic one.
Your Third Parties Are In the Test #
Where a critical or important function depends on an ICT third-party provider, that provider's systems can fall within TLPT scope, and the provider may be required to participate.
For a wholesale bank, that is not a footnote. Critical functions in payments, custody and settlement disproportionately run on vendor platforms, managed services and cloud. A test scoped honestly against critical functions will reach into suppliers, and the moment it does, three questions arrive that are contractual rather than technical:
- Does the contract permit it? Right-to-test clauses written for conventional assessment often do not contemplate an intelligence-led red team operating against production without the provider's operations staff being forewarned.
- Who carries the risk if the test causes an incident? Between the bank, the tester and the provider, this needs to be settled in writing before scoping, not negotiated under time pressure once a test window is booked.
- Can the provider serve everyone at once? A concentrated provider serving many designated entities faces the same synchronised demand the tester market does — and it has no obligation to prioritise you.
The clause work has a longer lead time than the test. It belongs in the renewal template now, for the same reason and on the same logic as any other supervisory right of access.
What the Defenders Owe the Exercise #
A red team that succeeds silently teaches an institution very little. The value sits in the reconstruction: what was emitted, what was detected, what was escalated, and how long each step took.
Three commitments make the difference between an exercise that produces evidence and one that produces a story.
Instrument for reconstruction before the test, not during it. If detection telemetry is not already retained at sufficient fidelity, the post-exercise analysis becomes a matter of recollection. That is the single most common way a technically successful exercise produces a weak supervisory package.
Measure time, not just outcome. Whether the red team achieved the objective is the least interesting finding. Time to first detection, time to correct attribution, and time to containment are the numbers that describe the defensive capability, and they are the numbers that improve between cycles.
Close the loop into the blue team deliberately. Collaboration with the defending team is built into the framework rather than bolted on, and it is what converts a single exercise into durable capability. An institution that runs the test, files the report and changes nothing observable has satisfied a cadence and learned nothing.
The Operating Playbook #
- Establish whether you expect designation, and plan as if you are. The procurement lead time is long enough that waiting for formal notification is the expensive option.
- Put tester procurement on a three-year forward plan, not a project schedule. Qualify a panel against the Article 27 conditions — accreditation or code adherence, assurance report, indemnity cover — well before a window is needed.
- Contract external threat intelligence as a standing arrangement. It is required in every cycle regardless of who executes the test, so it is not a variable cost.
- Fix the third-party clauses this quarter. Right to test, participation obligations, incident-risk allocation. This has the longest lead time of anything here and it is not an engineering task.
- Raise detection telemetry fidelity ahead of the first exercise. The evidence package is only as good as what was recorded while the red team was operating.
- Report the timings, not the verdict. Time to detect, attribute and contain, tracked across cycles, is the metric that shows a supervisor a capability rather than a compliance event.
The institutions that will handle this comfortably are not the ones with the most impressive internal red team. They are the ones that treated a supervised testing obligation as a supply-chain and evidence problem early enough to solve it calmly.
Frequently Asked Questions #
Is every DORA-regulated entity required to perform TLPT?
No. Competent authorities identify the entities required to carry it out, based on systemic importance, size and ICT risk profile, and microenterprises are excluded. Entities that are not designated remain subject to DORA's general digital operational resilience testing requirements — the expectation does not disappear, only the formal regime does.
How often must a designated entity test?
At least every three years, covering critical or important functions. A competent authority may require a higher or lower frequency depending on the entity's risk profile and operational circumstances.
Can we use our own red team?
For up to two of every three tests, subject to supervisory approval, adequate resourcing and conflict-of-interest management; external testers must be contracted every third test. Separately, and in every cycle, the threat-intelligence provider must be external to the institution.
Do our outsourced providers have to take part?
They can be required to. Where a critical or important function depends on an ICT third-party provider, that provider's systems may fall within the scope of the test and the provider may be required to participate — which is why the right to test and the allocation of incident risk need to be settled contractually in advance.
We already run TIBER-EU exercises. Are we compliant?
You are well positioned, because the regime is built on the same framework, but the two are not equivalent. TIBER participation was voluntary; the DORA obligation is supervised, carries a mandated cadence, and comes with the specific tester conditions and cross-border recognition arrangements set out in the regulatory technical standards.
References #
- European Parliament and Council of the European Union, 2022. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Brussels: Official Journal of the European Union. Available at: European Parliament and Council of the European Union, 2022..
- European Commission, 2025. Commission Delegated Regulation (EU) 2025/1190 supplementing Regulation (EU) 2022/2554 with regard to regulatory technical standards on threat-led penetration testing. Brussels: Official Journal of the European Union. Available at: European Commission, 2025..
- European Central Bank, 2026. TIBER-EU: European framework for threat intelligence-based ethical red-teaming. Frankfurt am Main: European Central Bank. Available at: European Central Bank, 2026..
Last reviewed .