DORA Articles 24 and 25 require financial entities, other than microenterprises, to run a digital operational resilience testing programme. It must use independent testers, be risk based, remediate findings, and test all systems supporting critical or important functions at least yearly. Article 25 lists the test types, including vulnerability scans, source code reviews and penetration testing.
The programme rules (Article 24)
The programme is part of the ICT risk management framework. It should assess readiness for incidents, find weaknesses and gaps, and promptly implement corrective measures. Key points:
- It follows a risk based approach based on how ICT risk is evolving, specific risks, and criticality of assets and services.
- Tests are done by independent parties, internal or external. Internal testers need enough resources and must avoid conflicts of interest.
- The entity needs procedures to prioritise, classify and remedy all issues found, plus internal validation to confirm weaknesses are fully addressed.
- At least yearly, appropriate tests run on all ICT systems and applications supporting critical or important functions.
The test menu (Article 25)
Article 25(1) says the programme must provide for appropriate tests "such as":
- 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, performance and end-to-end testing;
- penetration testing.
"Open source analyses" and "source code reviews" are the ones software teams should note. They point to dependency analysis and code scanning in your pipeline, with results kept as evidence.
Central securities depositories and central counterparties must also perform vulnerability assessments before deploying or redeploying applications and infrastructure supporting critical or important functions. Microenterprises combine a risk based approach with planning of testing effort.
Advanced testing (Article 26)
Selected entities must carry out threat-led penetration testing (TLPT) at least every three years, on live production systems, covering several or all critical or important functions. Competent authorities identify which entities must do so, based on impact, financial stability concerns and ICT risk profile. Criteria are in Commission Delegated Regulation (EU) 2025/1190. Entities using internal testers must hire external testers every three tests.
Building a programme
- List scope: systems supporting critical or important functions, from your asset inventory.
- Pick tests per system: scanning for all, code and dependency analysis for software you build, scenario tests for recovery.
- Set the yearly calendar, with at least one pass on every critical system.
- Define independence: who tests, who can pressure the testers, how conflicts are avoided.
- Track findings with severity, owner, due date and a validation step that confirms the fix.
- Feed results into the ICT risk assessment and management reporting (Article 13(3) asks for this).
Where tooling fits
Automated scanning covers the frequent, repeatable tests. Human-led tests cover logic and scenarios. Safeguard provides SBOM and dependency scanning, reachability analysis and a free scan at gold.safeguard.sh/scan. These cover the open source analysis part, not a full programme.
Quick check
Is a yearly penetration test required for everything?
Article 24(6) requires appropriate tests at least yearly on systems supporting critical or important functions. Penetration testing is one of the listed options, and TLPT every three years applies to selected entities.
Can the internal security team be the independent tester?
Article 24(4) allows internal testers if the entity dedicates sufficient resources and avoids conflicts of interest during design and execution.
Sources
Last reviewed: 19 October 2026.
