Testing is where DORA moves from assertion to evidence. A framework document says the firm is resilient. A test says whether it is. The regulation is deliberately unsentimental about the difference.
The Obligation
Financial entities must establish, maintain and review a sound and comprehensive digital operational resilience testing programme as an integral part of the ICT risk management framework. It must be risk-based, and all ICT systems and applications supporting critical or important functions must be tested at least annually.
The permitted test types span 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. Tests must be undertaken by independent parties, whether internal or external, and vulnerabilities and deficiencies identified must be fully addressed with remediation prioritised by criticality.
Above this baseline sits threat-led penetration testing for designated entities, covered separately in the TLPT article.
Scope Follows Function, Not Infrastructure
The most common programme design error is scoping by infrastructure. A firm tests its perimeter, its endpoints and its cloud configuration, produces a large volume of findings, and has still not tested whether the payments function survives the failure of its primary provider.
DORA scopes by function. The question is: for each critical or important function, what would break it, and has that been tested this year? That reframing usually shortens the target list and lengthens the scenario list.
A defensible programme document contains, for each critical or important function: the systems and providers it depends on, the test types applied in the current cycle, the date and independent tester, the findings, the remediation owner and date, and the residual risk position. That table is the deliverable. Everything else is supporting evidence.
Scenario Design
Scenario-based and end-to-end tests carry the most supervisory weight because they exercise the seams. Scenarios worth running, in rough order of neglect:
Provider failure, not provider degradation. Most continuity plans assume a provider is slow. Test the case where it is gone for seventy-two hours and the account manager is not answering.
Restore, not backup. Restore a critical dataset to a clean environment and verify integrity and elapsed time against the recovery point and recovery time objectives. Firms discover here that the objectives were never achievable.
Identity provider outage. A single sign-on failure locks staff out of every remediation tool simultaneously, including the incident management platform. Break-glass access must be tested, and it must not depend on the failed system.
Data integrity corruption. Availability failures are visible and tested. Silent corruption propagating into backups is neither, and it is the scenario with the worst recovery profile.
Concurrent incident and reporting clock. Run the technical scenario with the incident classification decision embedded, against the real deadline, with the real people.
Independence
Tests must be carried out by independent parties. Internal testers can satisfy this where there is genuine separation from the function being tested and no conflict in the reporting line for findings. The practical test is whether the tester can record a severe finding against a senior stakeholder's system without the finding being softened. If the answer is uncertain, use an external party for the critical functions and internal capability for the rest.
Remediation Is the Real Deliverable
Identified vulnerabilities must be fully addressed. A testing programme that generates findings and no closure evidence is worse than no programme, because it documents known unremediated weakness.
Track findings with a severity rating, an owner, a target date, and — for anything overdue — a documented risk acceptance at the appropriate level. Overdue critical findings without an acceptance are the most common adverse observation in operational resilience review across every regime.
Report the aggregate position to the management body: findings raised, closed, overdue, and the oldest open critical item. That single slide evidences the oversight obligation discussed in the ICT risk framework article more effectively than any policy document.
Key Takeaways
- Scope testing by critical or important function, not by infrastructure layer.
- Restore testing, provider-loss scenarios and identity provider outages are the highest-value neglected scenarios.
- Independence is about whether a severe finding can survive contact with a senior stakeholder, not about job titles.
- Remediation closure evidence is the deliverable; findings alone document unremediated weakness.
- Embed the incident classification decision inside technical scenarios so both processes are tested together.
Frequently Asked Questions
Does every system need annual penetration testing? No. The annual requirement is for appropriate testing of all ICT systems and applications supporting critical or important functions, with the test type selected on a risk basis. Penetration testing is one option among many, and the regulation lists a wide range.
Can vendor assurance reports replace testing? They contribute evidence but do not discharge the obligation. A provider's assurance report covers the provider's controls, not the financial entity's end-to-end function, and it does not test the firm's own failover, restore or escalation processes.
How should test results feed the risk framework? Findings from resilience testing are an explicit trigger for reviewing the ICT risk management framework. Route material findings into the framework review rather than closing them purely as technical remediation.
About the author
Jonas Mohamed Osman Abdelghafour is a risk and compliance expert advising banks, insurers, payment institutions and asset managers on operational resilience, ICT and third-party risk, financial crime and enterprise governance across EU and UK regimes. He works at the point where digital operational resilience obligations meet the evidence a board and a supervisor actually ask for. See qualifications and services, or get in touch to discuss an engagement.
*This article discusses regulatory frameworks in general terms and is not legal advice. Jurisdictional interpretation should be confirmed with qualified counsel.*
Frequently asked questions
What should risk leaders know about the Obligation?
Financial entities must establish, maintain and review a sound and comprehensive digital operational resilience testing programme as an integral part of the ICT risk management framework. It must be risk-based, and all ICT systems and applications supporting critical or important functions must be tested at least annually.
What should risk leaders know about scope Follows Function, Not Infrastructure?
The most common programme design error is scoping by infrastructure. A firm tests its perimeter, its endpoints and its cloud configuration, produces a large volume of findings, and has still not tested whether the payments function survives the failure of its primary provider.
What should risk leaders know about scenario Design?
Scenario-based and end-to-end tests carry the most supervisory weight because they exercise the seams. Scenarios worth running, in rough order of neglect:
What should risk leaders know about independence?
Tests must be carried out by independent parties. Internal testers can satisfy this where there is genuine separation from the function being tested and no conflict in the reporting line for findings. The practical test is whether the tester can record a severe finding against a senior stakeholder's system without the finding being softened. If the answer is uncertain, use an external party for the critical functions and internal capability for the rest.
What should risk leaders know about remediation Is the Real Deliverable?
Identified vulnerabilities must be fully addressed. A testing programme that generates findings and no closure evidence is worse than no programme, because it documents known unremediated weakness.