DORA has been in force since January 17, 2025. For most financial entities, the initial compliance effort focused on ICT risk management framework documentation, incident classification, and third-party register updates. The element that receives less planning attention — and carries the most operational complexity — is Threat-Led Penetration Testing under Article 26.
TLPT is not a standard penetration test. It is a red team engagement executed against live production systems using threat intelligence relevant to your specific sector exposure, conducted by approved testers, and assessed by your competent authority. The scope, standards, and approval process are materially different from conventional assurance testing, and the preparation timeline is longer than most security programmes have budgeted.
Who is required to conduct TLPT
Article 26 applies to “significant” financial entities — those designated by their competent authority based on systemic importance. The EBA’s RTS on TLPT identifies the criteria: total assets above €100bn, being identified as a GSIB or OSIB, or explicit designation by the NCA.
In practice, this covers major banks, central counterparties, credit rating agencies designated under Article 10 of the CRA Regulation, and significant payment institutions. The list is not exhaustive and NCAs retain discretion to designate additional entities.
For UK CISOs: DORA does not directly apply to UK-headquartered entities post-Brexit, but it applies to your EU subsidiaries and branches. Entities with significant EU operations — particularly those with EU-authorised subsidiaries — cannot treat TLPT as an EU compliance checkbox: a TLPT failure at an EU subsidiary creates operational resilience questions for the group as a whole. The Bank of England’s own CBEST programme has similar requirements under a different framework, and firms subject to both should look for efficiency in scope alignment.
The TIBER-EU vs DORA TLPT relationship
DORA’s TLPT requirements are broadly consistent with TIBER-EU (Threat Intelligence-Based Ethical Red Teaming), the framework many larger financial institutions already used for equivalent testing. The EBA’s TLPT RTS aligns the two where possible.
The key difference is mandatory scope. TIBER-EU allowed entities to define the scope. DORA TLPT requires that “critical or important functions” as identified in your ICT risk management framework are included. If your payment processing infrastructure, custody systems, or core banking platform are documented as critical functions — and they must be under Article 6’s ICT risk management requirements — they are in scope for TLPT.
This matters because some institutions had previously scoped TIBER exercises around less sensitive perimeter systems. That approach does not satisfy Article 26.
The three-year testing cycle
TLPT under DORA must be conducted at least every three years. The competent authority may require more frequent testing after a significant incident or if the threat landscape for the sector shifts materially. “Pooled” testing arrangements — where a shared ICT provider is tested once on behalf of multiple financial entities — are permitted under the RTS, which is significant for managing the cost and coordination burden when the same core banking platform is used across several institutions.
Planning the three-year cycle requires working backwards from the NCA’s assessment window. Testing itself takes three to six months from scope definition to report submission. NCA review and feedback can add another three to six months. Entities that haven’t started planning a 2026 TLPT engagement are behind schedule for completing and receiving feedback before the end of the year.
Third-party ICT provider involvement
The most operationally complex element of DORA TLPT is the mandatory involvement of critical ICT third-party providers. Under Article 26(3), where a financial entity outsources functions to a critical third party — and most significant entities outsource core functions to one or more major cloud or software vendors — the TLPT must include testing of those systems.
This creates a contractual and coordination challenge. Your TLPT testers need access to a third party’s production environment, or at minimum to systems within the third party’s infrastructure that support your critical functions. The EBA’s RTS permits substitutive testing — testing the third party’s environment in isolation — where direct integration testing isn’t feasible, but the entity remains responsible for demonstrating that the substitutive approach covers the risk adequately.
Practical steps for CISO teams:
-
Review your third-party contracts now. DORA’s ICT contract requirements (Article 30) require that critical third-party contracts include provisions for audit and testing access. If your major cloud contracts pre-date DORA and don’t include TLPT cooperation clauses, renegotiation is needed — or you need a plan for substitutive testing that your NCA will accept.
-
Identify your critical ICT third parties under your risk management framework. The TLPT scope flows from the critical function map, which flows from the third-party register. If the register isn’t complete or the criticality assessments haven’t been refreshed since 2024, that’s the starting point.
-
Engage your NCA on scope before commissioning testers. NCAs must be notified before a TLPT commences, and scope approval (explicit or implicit through lack of objection) is required. Starting with an unapproved scope is a wasted engagement.
Approved testers
DORA TLPT must be conducted by testers meeting the criteria in the EBA’s RTS — either in-house red teams that meet the independence and competence requirements, or external testers from approved provider lists maintained by some NCAs.
The in-house option is more restricted than it appears. “Independence” under the RTS means independence from the operational teams managing the systems being tested and independence from the ICT risk management function. For most institutions, this means a dedicated internal red team that reports separately from the CISO organisation. Smaller significant entities typically use external providers.
Board-level reporting requirements
Under Article 26(7), the results of TLPT must be reported to the management body. This is not a compliance formality: the management body must be able to demonstrate to the competent authority that it has received and reviewed TLPT findings and that remediation plans are being tracked.
The reporting to the management body should include: the scope tested (critical functions covered), significant findings by risk category, remediation actions with owners and timelines, and the overall resilience conclusion the management body is being asked to endorse. Finding material vulnerabilities in production critical infrastructure and presenting only summary data to the board creates a fiduciary exposure — the board needs enough detail to discharge its oversight responsibility.
What to prioritise in Q3/Q4 2026
For CISOs of significant entities who haven’t yet completed a DORA TLPT or are approaching the end of their first three-year cycle:
- Third-party contract review: Identify gaps in audit and testing access rights for critical providers
- Scope documentation: Ensure the critical function map is current and defensible as the TLPT scope basis
- NCA pre-engagement: Notify and align with the NCA on scope before commissioning testers
- Pooling opportunities: Where multiple entities use the same critical provider, explore pooled testing arrangements to reduce cost and coordination burden
- Board reporting template: Prepare the reporting structure for management body submission before results are available — not after
The regulatory expectation is not perfection in the TLPT findings. It is a functioning programme with competent execution, genuine scope coverage, and credible remediation. NCAs have been explicit that entities finding significant issues and addressing them with appropriate rigour are meeting the spirit of DORA; entities with suspiciously clean test results and narrow scope are not.