DORA's testing chapter has two tiers, and they are often discussed as if they were one. The first applies to almost every financial entity in scope: a risk-based testing program, with yearly tests of the systems that support critical or important functions. The second applies only to entities their supervisors select: threat-led penetration testing, or TLPT, on live production systems.
Most entities need to get the first tier right and will never run the second. Those that do run TLPT find it is a supervised exercise with its own procedures, and that it often pulls in their ICT providers.
This article covers both tiers, Articles 24 to 27: what the program must include, what counts as a test, how TLPT works, who may act as a tester, and what happens when a provider's systems are in scope.
The testing program every entity needs
Article 24 requires financial entities to establish, maintain and review a sound and comprehensive digital operational resilience testing program. It is an integral part of the ICT risk management framework, not a separate initiative.
The program has four properties the regulation names:
Risk-based. It accounts for the entity's evolving ICT risks, specific risks it is exposed to, and the criticality of its information and ICT assets. Proportionality under Article 4 applies.
Independent. Tests are carried out by independent parties, internal or external. Internal testers need sufficient resources, and conflicts of interest must be avoided throughout design and execution.
Closed loop. Entities establish procedures and policies to prioritize, classify and remedy every issue the tests reveal, with internal validation methods confirming that weaknesses are fully addressed.
Yearly for what matters most. Entities other than microenterprises test all ICT systems and applications supporting critical or important functions at least yearly.
The yearly requirement is the one supervisors can check against a list. If your register of information names a function as critical or important, there should be a test record within the year for each system supporting it.
What counts as a test
Article 25 lists the kinds of test the program should provide for, as appropriate:
Vulnerability assessments and scans
Open source analysis
Network security assessments
Gap analysis
Physical security reviews
Questionnaires and scanning software solutions
Source code reviews, where feasible
Scenario-based tests
Compatibility testing
Performance testing
Testing across complete process chains
Penetration testing
The list is broad on purpose. It is not a requirement to run all of them on every system every year. It is the toolkit from which a risk-based program selects. Record why you chose each test for each system, so the selection reads as a decision.
Remediation is where programs usually fail examination. A test that found issues and a tracker showing them open six months later is evidence against you. Set remediation timelines by severity, as you would for vulnerability management SLAs, and record validation when each issue closes.
Threat-led penetration testing
DORA defines TLPT as a framework that mimics the tactics, techniques and procedures of real-life threat actors perceived as posing a genuine cyber threat. It delivers a controlled, bespoke, intelligence-led red team test of the entity's critical live production systems.
Who must run it
Competent authorities identify the entities required to perform TLPT, based on factors such as their impact, financial stability concerns, and their ICT risk profile and maturity. The regulatory technical standards set out the criteria. Identified entities carry out TLPT at least every three years. The authority can ask an entity to change that frequency based on its risk profile.
If you have not been told you are identified, you are not required to run TLPT. Some entities choose to run comparable intelligence-led exercises voluntarily, and that is a separate decision.
What it covers
Article 26 requires each TLPT to cover several or all critical or important functions, and to run on the live production systems supporting them. The entity identifies all the relevant underlying systems, processes and technologies, including those supporting functions provided by ICT third-party service providers. The competent authority validates the scope.
The regulatory technical standards on TLPT were developed in accordance with the TIBER-EU framework. Entities familiar with TIBER-EU will recognize the structure: a preparation phase, a testing phase in which threat intelligence produces realistic scenarios that a red team then executes, and a closure phase that covers reporting and remediation.
How it closes
At the end of testing, once reports and remediation plans are agreed, the entity provides the authority with a summary of the findings, the remediation plans, and documentation showing the test was conducted in line with the requirements. The authority then issues an attestation confirming this, which supports mutual recognition of the test between authorities.
Who may act as a tester
Article 27 sets requirements for TLPT testers. They must:
Be of the highest suitability and reputability.
Have technical and organizational capabilities and specific expertise in threat intelligence, penetration testing and red team testing.
Be certified by an accreditation body in a member state, or adhere to formal codes of conduct or ethical frameworks.
Provide independent assurance, or an audit report, on the sound management of TLPT risks, including protection of confidential information and redress for the entity's business risks.
Be fully covered by relevant professional indemnity insurance, including against misconduct and negligence.
Internal testers are permitted under conditions. Their use must be approved by the competent authority, the authority must verify sufficient dedicated resources and the absence of conflicts of interest, and the threat intelligence provider must be external. Credit institutions classified as significant under the Single Supervisory Mechanism must use external testers only.
When an ICT provider is in scope
TLPT scope follows the critical or important function, not the corporate boundary. If a function runs on a provider's platform, the provider's systems can be in scope.
Where a provider is included, the entity must take the measures and safeguards needed to secure its participation, and it retains full responsibility for the test. For services supporting critical or important functions, DORA's contract rules require the provider to participate and fully cooperate in the entity's TLPT. The contract should already say so, as covered in our article on the register of information and third-party risk.
Article 26 also addresses the provider's position. If participation could reasonably be expected to harm the quality or security of services delivered to customers outside DORA's scope, or the confidentiality of data related to them, the entity and provider may agree in writing that the provider contracts directly with an external tester. That arrangement supports pooled testing, where several financial entities using the same service are covered by one test under the direction of a designated entity.
If you are a provider, prepare before a customer asks:
Name a contact who can authorize testing activity against your platform.
Write standard rules of engagement for customer-led testing, including notice, timing and boundaries.
Decide how you will isolate other customers' data and services during a test.
Know whether you would propose pooled testing, and on what terms.
Make sure your own incident response team can distinguish an authorized test from a real attack without compromising the test.
Common mistakes
Treating the yearly penetration test as the whole program. Article 24 expects a program across the listed test types, chosen by risk.
Testing systems that are not on the critical function map. Effort spent outside the critical or important scope does not satisfy the yearly requirement for systems inside it.
Leaving findings open. Unremediated issues without accepted risk decisions undermine the program.
Discovering the provider question during TLPT scoping. Contract terms and provider contacts should exist before the authority validates scope.
Whether your entity is identified for TLPT, and how the requirements apply to your providers, are points to confirm with counsel and your competent authority. Our DORA framework page places testing alongside the rest of the regulation.
How TrustLynce helps
TrustLynce's continuous monitoring checks controls between tests and routes failures to their owners, so issues do not wait for the next yearly cycle to surface. The auditor portal keeps requests and findings in one place when a supervisor or tester asks for the record.