Two levels of testing in DORA
Chapter IV of the Digital Operational Resilience Act, Regulation (EU) 2022/2554, deals with digital operational resilience testing. It sets two levels. The first applies to every financial entity in scope: a testing programme, described in articles 24 and 25, proportionate to the entity's size and risk. The second applies only to a subset of entities identified by their competent authority: advanced testing based on threat-led penetration testing, known as TLPT, described in articles 26 and 27.
Most mid-sized financial entities, and almost all of the ICT providers that serve them, sit in the first level. The second level gets the attention because it is the most demanding, but the first is where most testing obligations actually fall. Testing is one of the five areas covered in our overview of the five pillars of DORA.
The testing programme every financial entity needs
Article 24 requires financial entities, other than microenterprises, to establish, maintain and review a sound and comprehensive digital operational resilience testing programme as part of their ICT risk management framework. The programme follows a risk-based approach and takes into account the evolving threat landscape. Tests must be carried out by independent parties, which can be internal or external, and the entity must have procedures to prioritise, classify and remedy the issues found.
Article 24 also sets a frequency. All ICT systems and applications supporting critical or important functions must be tested at least yearly. Entities using the simplified ICT risk management framework under article 16 still test, with lighter requirements.
What the programme can include
Article 25 lists the types of test the programme can draw on: vulnerability assessments and scans, open source analyses, network security assessments, gap analyses, physical security reviews, questionnaires and scanning software solutions, source code reviews where feasible, scenario-based tests, compatibility testing, performance testing, end-to-end testing and penetration testing.
The list is a menu, not a checklist. The entity chooses the combination that fits its risks and documents why. In practice, a programme for a mid-sized entity usually combines continuous vulnerability scanning, periodic penetration tests of exposed applications, backup and recovery tests, and a scenario exercise for the most important services. The difference between scanning and testing is explained in our article on pentests versus vulnerability scans.
What TLPT is and how it differs from a penetration test
TLPT is a controlled attempt to compromise the critical functions of a financial entity by mimicking the tactics, techniques and procedures of real threat actors. It differs from a standard penetration test in four ways. It is driven by threat intelligence specific to the entity. It is run against live production systems, not test environments. It covers several or all critical or important functions, including the people and processes around them. And it is supervised by the competent authority from start to finish.
The method is set by Commission Delegated Regulation (EU) 2025/1190, published in the Official Journal on 18 June 2025, which aligns TLPT with the TIBER-EU framework used by European central banks. A test runs in three phases. In the preparation phase the scope is set and a control team is formed. In the testing phase, threat intelligence providers produce a targeted threat report and red team testers run the attack scenarios built from it. In the closure phase the red team and the entity's defenders review what happened together, and the entity draws up a remediation plan.
Which entities have to run TLPT
Article 26 requires TLPT at least every three years from the financial entities that competent authorities identify, based on their impact, systemic character and ICT risk profile. The delegated regulation sets the criteria. Some categories are in scope by default when they meet the thresholds, such as global and other systemically important credit institutions, large payment and electronic money institutions, central securities depositories, central counterparties and large insurance undertakings. Authorities can also include or exclude individual entities on a case-by-case assessment.
An entity that has not been notified by its authority is not required to run TLPT. It still needs the article 24 programme, and it may still meet TLPT through its suppliers or its customers.
Testers, internal teams and ICT providers
Article 27 sets requirements for testers, from reputation and certification to professional indemnity insurance. Internal testers are allowed under conditions, including that the entity uses external testers every three tests. Credit institutions classified as significant under the Single Supervisory Mechanism must use external testers only.
ICT third-party service providers can be drawn in. When a provider supports critical or important functions that fall within the TLPT scope, article 26 requires the financial entity to ensure the provider participates. Where a provider's participation could affect the confidentiality of its other customers, the provider can arrange pooled testing involving several financial entities. For an ICT provider serving the financial sector, this belongs in the contract, alongside the other obligations covered in our article on third party risk under DORA and NIS2.
Where Qalea fits
For financial entities and ICT providers outside the TLPT perimeter, the work is the article 24 programme: a documented, risk-based set of tests, run on schedule, with findings tracked to remediation. Qalea runs that programme. External attack surface monitoring and vulnerability scanning run continuously, penetration tests cover critical applications, and the SOC and the compliance platform keep the findings, the remediation and the evidence in one place for the supervisor or the client's auditor. More on the regulation in our DORA topic hub.
