DORA threat-led penetration testing: who is in scope and what it involves

Regulation (EU) 2022/2554 — the Digital Operational Resilience Act — has applied since 17 January 2025. Unlike NIS2 it is a regulation, so it applies directly without national transposition, which removes a layer of ambiguity but not the harder question: which of its two testing obligations applies to you.

The two obligations, separated

How TLPT designation works

Competent authorities identify which financial entities must perform TLPT, based on criteria including the entity's impact on the financial sector, financial stability concerns, and its specific ICT risk profile. You do not self-assess into scope, and you do not opt in by ambition. If you are in scope you will know, because the process is authority-led and involves the authority throughout.

TLPT under DORA is closely aligned with the TIBER-EU framework, which many European central banks already operated before DORA. Entities that have run a TIBER engagement will recognise the structure: a preparation phase, a threat intelligence phase producing entity-specific scenarios, a red team execution phase against live production, and a closure phase with replay, remediation planning and attestation.

What a TLPT engagement actually involves

1. Preparation. Scope definition covering critical or important functions, appointment of a control team, risk management for testing against production, and authority engagement.
2. Threat intelligence. A targeted intelligence provider produces a threat landscape and specific, plausible attack scenarios for your entity — not generic industry material.
3. Red teaming. External testers execute those scenarios against live production over an extended window, typically twelve weeks or more, with only the small control team aware.
4. Closure. Replay workshops with the blue team, a remediation plan, reporting to the authority, and an attestation confirming the test was performed in accordance with the requirements.

Three points are routinely underestimated. It runs against production, which means the control team carries real operational risk and needs genuine authority to stop the test. The blue team must not be informed, which requires discipline that is harder to maintain than it sounds. And the elapsed time is long — the active testing window alone is measured in months, and the full cycle including intelligence and closure typically runs six to nine months.

If you are in scope for DORA but not for TLPT

Article 24 and 25 obligations still apply, and they are substantial. Your programme must cover critical ICT systems and applications at least yearly, using a range of methods appropriate to the risk, executed by independent parties with conflicts of interest properly managed. Findings must be fully addressed and vulnerabilities remediated.

• Vulnerability assessments and scans of the estate supporting critical functions.
• Open source analysis and network security assessments.
• Gap analyses, physical security reviews and questionnaires.
• Scenario-based testing, compatibility, performance and end-to-end testing.
• Penetration testing of the systems supporting critical or important functions.
• Source code reviews where feasible for entities other than microenterprises.

The word doing the work there is proportionate. A small payment institution and a systemically important bank are both covered, and are not expected to produce comparable programmes. Document your proportionality reasoning; it is the thing a supervisor will probe.

The ICT third-party angle most programmes miss

DORA's third-party risk chapter is where many entities are least prepared. You must maintain a register of information on all contractual arrangements for ICT services, ensure contracts contain specified provisions, and — where a third party supports a critical or important function — retain audit and access rights, including the right to have testing performed.

For entities designated for TLPT, providers supporting critical functions may need to be included in the test scope. That has to be secured contractually well in advance. Discovering at scoping time that your core banking provider's contract contains no testing right is a nine-month problem, not a nine-day one.

Practical sequencing

1. Confirm your DORA scope and, separately, whether you have been designated for TLPT. Do not assume either.
2. Map critical or important functions to the ICT systems and providers supporting them. This map is the foundation of everything else.
3. Check contracts for audit, access and testing rights against that map, and start renegotiating the gaps now.
4. Build the yearly testing programme against critical systems, with documented proportionality reasoning and independence arrangements.
5. Only if designated: begin TLPT preparation with the competent authority, and budget the full elapsed cycle rather than the testing window alone.