DORA Resilience Testing Requirements: Articles 24-25

DORA Articles 24 and 25 require every in-scope financial entity, other than microenterprises, to run a documented digital operational resilience testing programme: a standing set of tests, methodologies, and tools, reviewed regularly, that checks ICT systems for weaknesses before an incident does. Critical or important functions need appropriate testing at least once a year. This is the baseline that sits underneath threat-led penetration testing (TLPT), not a replacement for it.

Article 24: the testing programme itself

Article 24 is the general duty. It requires a "sound, comprehensive" digital operational resilience testing programme, built as an integral part of the ICT risk-management framework rather than a bolt-on compliance exercise. Three things follow from that framing:

• It has to be proportionate. Scope, frequency, and depth scale with the entity's size, business model, and the ICT and cyber risks it actually carries, not a fixed checklist applied identically to a five-person payment institution and a systemic bank.
• It has to be a programme, not an event. The regulation expects a standing set of tests, practices, and tools that gets reviewed and updated, so a one-off penetration test commissioned before an audit does not satisfy Article 24 on its own.
• Microenterprises are carved out of the annual-testing duty, though they remain subject to DORA's general ICT risk-management obligations under the simplified framework where applicable.

The programme's output also has to feed back into the framework: findings get prioritised, remediated, and tracked, closing the loop back to the learning-and-evolving duty in Article 13 of the risk-management pillar.

Article 25: what the tests actually look like

Article 25 lists the toolkit a testing programme draws from. It is broader than "penetration testing," and reads more like a menu than a fixed sequence:

• 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
• Penetration testing

Which combination applies depends on the system and the risk it carries. A risk-based approach is meant to steer entities toward heavier, more frequent testing for the ICT systems and applications that support a critical or important function, and lighter coverage elsewhere. Article 25 also sets a floor: all ICT systems and applications supporting critical or important functions must be tested at least yearly, and central securities depositories and central counterparties carry an extra duty to run vulnerability assessments before deploying or redeploying applications, infrastructure components, or ICT services that support those functions.

How this differs from TLPT

Article 25 testing is the base layer every in-scope entity (bar microenterprises) has to run. Threat-led penetration testing under Articles 26 and 27 is a narrower, heavier obligation that only applies to entities a competent authority identifies as significant, based on systemic importance, financial-stability impact, and the criticality of their ICT dependencies. TLPT simulates a live adversary against production systems at least every three years, using testers who meet specific competence and, where external, insurance requirements. Confusing the two is a common mistake: passing an annual vulnerability scan under Article 25 says nothing about whether an entity also owes TLPT, and being out of TLPT scope does not excuse the Article 24-25 baseline.

Who this applies to, and how proportionality plays out

Every financial entity within DORA's scope, other than microenterprises, owes the Article 24 programme and the Article 25 test types. What changes by entity type is depth and frequency, not whether the obligation exists at all. A small investment firm eligible for the simplified ICT risk-management framework under Article 16 still needs a testing approach proportionate to its size and interconnectedness; a bank or insurer with systemic reach is expected to run a materially deeper programme, and is far more likely to also sit inside TLPT scope. Entities scoping this out for the first time, payment institutions, investment firms, or crypto-asset service providers among them, can check our who-must-comply guides for how the obligation lands on their specific entity type.

Building the programme in practice

• Start from the asset inventory, not the test catalogue. The ICT-risk-management framework's Article 8 asset map should already flag which systems support a critical or important function; that list sets the scope for the annual-minimum testing duty.
• Match test type to system risk, using Article 25's list as a menu rather than running every test against every system. A customer-facing payment API and an internal reporting tool do not need the same test mix.
• Document the programme, not just the results. Article 24 expects a reviewable programme description: what gets tested, how often, by whom, and how findings are tracked to closure.
• Set a remediation SLA tied to severity, so a critical vulnerability found in March is not still open when the annual test runs again next year.
• Check TLPT scope separately. Running Article 25 tests well does not answer whether the entity also needs threat-led penetration testing; that determination sits with the competent authority under different criteria.

Common gaps seen in practice

• A single annual penetration test standing in for the whole programme. Article 25's list is broad on purpose; relying on one test type leaves gaps a scenario-based test or a source-code review would catch.
• No documented link between test findings and remediation. Findings get logged in a report that nobody revisits, rather than tracked through to a fix and re-test.
• Scope drawn from an outdated asset inventory. A new critical function goes live without being added to the testing scope, so it misses the annual-minimum requirement entirely.
• Treating "proportionate" as "optional." Smaller entities sometimes read proportionality as a reason to skip testing rather than to scale it down; the duty applies to all non-microenterprises.

Entities working through a full DORA checklist or scoping a resilience testing plan can use the DORA Readiness Score to see how their testing programme scores against the other four pillars before committing budget to a full build-out.

Sources

• Regulation (EU) 2022/2554 (DORA), Articles 24-25, EUR-Lex.
• ESMA, Digital Operational Resilience Act (DORA).
• EBA, Digital operational resilience Regulation (DORA).

Last updated: 7 September 2026.