DORA testing requirements: what you 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.

DORA testing obligations, who they bind and how often

Obligation	Who	How often	Article
Documented resilience testing programme	All financial entities except microenterprises	Established, maintained and reviewed	Art 24(1)
Tests on ICT systems supporting critical or important functions	All financial entities except microenterprises	At least yearly	Art 24(6)
Vulnerability assessment before deployment or redeployment	Central securities depositories and central counterparties	Every deployment	Art 25(2)
Simplified, risk-based testing	Microenterprises	Risk-based	Art 25(3)
TLPT on live production systems	Entities identified by the competent authority	At least every 3 years	Art 26(1)
External testers where internal testers are used	Entities using internal testers for TLPT	Every three tests	Art 26(8)

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 easily overlooked test types are:

• 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. Compatibility problems can arise at version boundaries – an operating system upgrade, a TLS change, a terminal firmware release. Include it where version and interface dependencies create relevant risks.

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. The threat intelligence provider is external on every TLPT, not only when internal testers run it: Article 1(10) of Commission Delegated Regulation (EU) 2025/1190 defines the role as experts contracted for each test and external both to the financial entity and to any ICT intra-group service provider, and DORA’s Article 27(2)(c) merely repeats it for the internal-tester case. 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) connects testing to required remediation and validation. 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 defined method for checking that an issue has been addressed. Depending on the finding, evidence may include a retest, configuration review, recovery exercise or another suitable validation. 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) applies the proportionality principle to Chapter II; Article 4(2) is the one that reaches testing, requiring the application of Chapters III, IV and V, Section I to be proportionate to size and overall risk profile, and to the nature, scale and complexity of services, activities and operations, “as specifically provided for in the relevant rules of those Chapters”. Article 4(3) obliges competent authorities to consider it when reviewing the framework. Proportionality sizes the duty; it does not remove it.

One real testing relief exists, and it is not the one most often claimed. 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.

Article 16(1) is not a testing relief

Article 16(1) covers small and non-interconnected investment firms, certain exempted payment, credit and electronic money institutions, and small institutions for occupational retirement provision. What it does is disapply Articles 5 to 15 – the ICT risk-management chapter – and put a simplified framework in their place: a sound documented ICT risk-management framework, continuous monitoring of all ICT systems, minimisation of ICT risk, and the rest of the second subparagraph’s list.

Chapter IV is untouched by it. Article 24 excludes microenterprises and no one else, and Article 25 adds duties rather than removing them, so an Article 16(1) entity owes the same documented programme, the same range of test types and the same at-least-yearly test on all ICT systems supporting critical or important functions as a bank does. The one Chapter IV carve-out is TLPT, and the drafters wrote it out explicitly: Article 26(1) binds financial entities “other than entities referred to in Article 16(1), first subparagraph, and other than microenterprises”. Where the Regulation means to exempt these entities it says so – and in Articles 24 and 25 it does not.

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.