DORA testing requirements: what financial entities must test

What Article 24 actually requires

DORA — Regulation (EU) 2022/2554 — does not ask you to buy a penetration test once a year and file the report. Article 24(1) requires financial entities, other than microenterprises, to "establish, maintain and review a sound and comprehensive digital operational resilience testing programme" as an integral part of the ICT risk-management framework in Article 6. All three verbs bind: a programme written once and never reviewed fails the article.

The same paragraph gives the purpose — assessing preparedness for handling ICT-related incidents, identifying weaknesses, deficiencies and gaps, and promptly implementing corrective measures. The measure is not how much testing you bought, but what it found and whether that was fixed.

Article 24(2) requires "a range of assessments, tests, methodologies, practices and tools to be applied in accordance with Articles 25 and 26". One recurring test type is not a range. Article 24(3) makes the selection risk-based: the Article 4(2) criteria, the evolving ICT risk landscape, the specific risks the entity faces, the criticality of information assets and of services provided.

The obligations at a glance

Six obligations carry the testing pillar. The rest of a programme is a decision about how to satisfy them.

The twelve test types in Article 25(1)

Article 25(1) enumerates the tests the programme draws on, and the list is longer than most programmes assume — 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.

Nothing obliges you to run all twelve against every system every year — Article 24(3) decides the mix, and you have to show it was chosen deliberately. Two items are missing from almost every programme:

• Physical security reviews. They sit in the Regulation alongside penetration testing: data centre access, cabling, badge and visitor control at sites supporting critical or important functions belong in the testing programme, not only in facilities management.
• Compatibility testing. Resilience usually breaks at version boundaries — an operating system upgrade, a TLS change, a terminal firmware release. It is the named control for that failure mode, and it is rarely in the programme.

How often you have to test

Article 24(6) requires entities to ensure, at least yearly, that appropriate tests are conducted on all ICT systems and applications supporting critical or important functions. The word doing the work is "all": a programme that tests the three loudest systems annually and rotates the rest over three years fails Article 24(6) for the systems in the rotation.

Two obligations sit outside that rhythm. Article 25(2) requires central securities depositories and central counterparties to perform vulnerability assessments before any deployment or redeployment of applications, infrastructure components and ICT services supporting critical or important functions — an event trigger, not a calendar one. And entities identified by their competent authority run threat-led penetration testing at least every three years under Article 26(1), a regime detailed by Commission Delegated Regulation (EU) 2025/1190 and built on the ECB’s TIBER-EU framework; our guide to how DORA TLPT works covers it.

Yearly is a floor, and a low one for internet-facing systems. ENISA analysed 4,875 incidents between 1 July 2024 and 30 June 2025 and describes campaigns rapidly weaponising vulnerabilities within days of disclosure; exploitation of vulnerabilities lay behind 21.3% of observed intrusion cases. Continuous vulnerability assessment underneath a deeper yearly test is what matches that window.

Who is allowed to test

Article 24(4) answers the question every ICT team asks first. Tests must be undertaken by "independent parties, whether internal or external". DORA does not require you to hire an external firm for the baseline programme. It requires independence.

Where an internal tester runs the test, the paragraph attaches two conditions: dedicate sufficient resources, and avoid conflicts of interest "throughout the design and execution phases". Design is the half that gets skipped — if the team that operates a control also sets the scope and success criteria, the execution can be flawless and independence still fails.

TLPT is stricter, and there external testers do become mandatory in places. Under Article 26(8) entities using internal testers must contract external testers every three tests, and credit institutions classified as significant in accordance with Article 6(4) of Regulation (EU) No 1024/2013 may use only external testers; under Article 27(2)(c) the threat intelligence provider must be external whenever internal testers run the test. Article 27(1) adds the tester criteria: reputability, demonstrated expertise in threat intelligence, penetration testing and red team testing, certification or a formal code of conduct, and professional indemnity insurance.

Findings, remediation and internal validation

Article 24(5) turns testing into compliance. Entities must establish procedures and policies to prioritise, classify and remedy all issues revealed throughout the performance of the tests, and establish internal validation methodologies to ascertain that all identified weaknesses, deficiencies or gaps are fully addressed.

Read the second half slowly. A validation methodology is not a status field set to "closed". It is a method, agreed before the test, for proving a finding no longer reproduces: a retest along the original attack path, evidence tied to the finding. Without one, remediation is asserted rather than demonstrated.

The Verizon 2026 DBIR shows why that matters operationally. Exploitation of vulnerabilities reached 31% of breaches as an initial access vector, up from 20% and now the most common route in — yet only 26% of the CISA KEV vulnerabilities found in organisations’ environments were fully remediated, at a median of 43 days, up from 32.

Proportionality and the lighter regimes

Article 4(1) and (2) require Chapter II to be implemented in accordance with the principle of proportionality — size and overall risk profile, and the nature, scale and complexity of services, activities and operations. Article 4(3) obliges competent authorities to consider it when reviewing the framework. Proportionality sizes the duty; it does not remove it.

Two real reliefs exist. Microenterprises are outside Article 24 altogether: under Article 25(3) they perform the Article 25(1) tests by combining a risk-based approach with strategic planning, balancing resources and time against urgency, type of risk and criticality. Entities under Article 16(1) — small and non-interconnected investment firms, certain exempted payment, credit and electronic money institutions, and small institutions for occupational retirement provision — follow a simplified framework in which Articles 5 to 15 do not apply, though they must still keep a sound documented ICT risk-management framework, monitor all ICT systems and minimise ICT risk. They are outside the TLPT obligation in Article 26(1) too.

Where to start

Start from scope, not from tests. The mapping of critical or important functions to the ICT systems that support them is what Article 24(6) attaches to, and every later decision inherits its errors. Our DORA testing checklist walks the stages in order, with the article and the evidence to keep at each one.