The Digital Operational Resilience Act has been in application since 17 January 2025, but the regulatory technical standard governing its most rigorous testing obligation — Threat-Led Penetration Testing (TLPT) — only landed mid-year. On 18 June 2025 the European Commission published Commission Delegated Regulation specifying the elements of TLPT under Article 26(11) of DORA, and the RTS became directly applicable across all Member States on 8 July 2025. The text formalises a TIBER-EU-aligned methodology as the binding standard for the largest and most interconnected financial entities in the EU. Smaller entities still face Article 24 baseline penetration testing, but the TLPT regime is now the apex layer.
Which entities are in scope?
Article 26 of DORA does not name specific firms; it delegates identification to designated authorities under criteria spelled out in the RTS. The criteria combine a firm's significance to financial stability with its operational and ICT risk profile. Practically, the in-scope perimeter includes global systemically important institutions (G-SIIs) and other systemically important institutions (O-SIIs) above defined thresholds, the largest insurance and reinsurance undertakings, central counterparties (CCPs), central securities depositories (CSDs), trading venues with significant cross-border activity, and credit rating agencies of sufficient size. Designated authorities — typically the national competent authority that supervises the entity for prudential purposes — publish lists and notify entities. The European Banking Authority estimates the in-scope population across the EU at several hundred firms, considerably smaller than DORA's overall reach of approximately 22,000 financial entities.
How often must TLPT be performed?
Article 26(1) of DORA sets the baseline frequency at no less than every three years. The RTS preserves this, but adds important discretion. National authorities can require more frequent testing for an entity whose risk profile, size, or systemic importance warrants it, and they can also reduce frequency in exceptional circumstances — for example, when an entity has just completed a major remediation cycle from a previous test. The RTS specifies that the three-year clock starts from the last completed TLPT, not from the regulatory deadline. Entities that conducted TIBER-EU exercises in 2024 thus carry forward credit and may not face a new exercise until 2027.
What does the methodology look like?
The RTS aligns TLPT structure with TIBER-EU, the European framework that has been used by central banks since 2018. A test runs through five phases: preparation, threat intelligence, red-team testing, closure, and remediation. The preparation phase scopes the test against critical or important functions (CIFs) — DORA's term for business functions whose disruption would materially impair financial services — and confirms scope with the test manager from the designated authority. Threat intelligence is procured from an external Threat Intelligence (TI) provider that produces a Targeted Threat Intelligence Report tailored to the entity. The red-team testing phase, typically 12 weeks of active testing, is performed by an external Red Team (RT) provider against the production environment, with a small "white team" of insiders aware of the exercise. Closure includes a replay and remediation workshop, and remediation is tracked through formal action plans signed off by the authority.
What about testers and providers?
The RTS imposes detailed competence and independence requirements on TI and RT providers. Providers must hold formal accreditation or evidence of recognised certification — typical examples named in supervisory practice include CREST CBEST, GBEST, and equivalent national schemes. They must have at least five years of demonstrable experience in threat-led testing, carry adequate professional indemnity insurance, and meet conflicts-of-interest rules that bar them from providing other audit or assurance services to the entity for a defined cooling-off period. Internal red teams may perform TLPT only where the firm meets stringent governance separation criteria and the designated authority approves the arrangement — in practice, this is rare and typically restricted to a handful of the largest banks.
# Illustrative TLPT scoping inputs the RTS expects in the engagement scope
critical_or_important_functions:
- payments_clearing
- securities_settlement
- retail_internet_banking
external_perimeter:
- public_dns_zone
- customer_facing_apis
- partner_extranet
in_scope_ict_third_parties:
- cloud_provider_X # under joint testing arrangement
test_manager: national_competent_authority
ti_provider: certified_threat_intel_firm
rt_provider: certified_red_team_firm
white_team_size: 8
test_duration_weeks: 12
out_of_scope:
- safety_critical_settlement_window # confirmed with authority
How does TLPT interact with ICT third-party testing?
DORA Article 30 already imposes ICT third-party risk management obligations, but TLPT explicitly contemplates joint testing arrangements with critical ICT third-party providers — typically cloud providers and core processing vendors. The RTS clarifies that where a CIF depends materially on a third party, the test must extend to that party's perimeter under a pooled arrangement, with appropriate non-disclosure controls. This is operationally significant because it forces standardisation across providers serving multiple financial entities: a single cloud provider cannot reasonably accommodate dozens of bespoke red-team exercises, so cooperative pooled testing models are emerging through the European Supervisory Authorities' Oversight Forum for designated critical ICT third-party providers.
What evidence must the firm retain?
The RTS lists the artefacts that a designated authority can request: the engagement scope and approval, the Targeted Threat Intelligence Report, the Red Team Test Plan and rules of engagement, the daily attack log, the test report including findings and severities, the remediation action plan, and confirmation of remediation completion. The test report is not subject to public disclosure but must be available to the supervisor and is considered when assessing the entity's overall ICT risk management framework under Article 6 of DORA. Failure to perform TLPT when required, or to perform it in compliance with the RTS, falls within the enforcement scope of national authorities under Article 50 of DORA, which mandates effective, proportionate, and dissuasive penalties.
How Safeguard Helps
Safeguard maintains the asset and software inventory that scopes a TLPT engagement, mapping every public-facing service back to the Critical or Important Function it supports — so the test manager and red team start with an authoritative target list rather than reconstructing one from disparate CMDB sources. The platform's reachability analysis on the production SBOM highlights externally exposed code paths and dependency-derived attack surface, which threat intelligence providers can feed directly into the Targeted Threat Intelligence Report. Findings from a TLPT exercise can be ingested as policy violations and tracked through Safeguard's remediation workflow against the authority-approved action plan, with evidence packs generated for the supervisor's closing review. Joint-testing arrangements with cloud and SaaS providers are managed through Safeguard's TPRM module, which keeps third-party attestations, certifications, and recent test summaries in a single audit-ready evidence store.