Operational resilience testing under DORA

Where operational resilience testing fits within DORA

Operational resilience testing under DORA is not just a compliance exercise. It is the practical mechanism that shows whether your ICT controls, recovery arrangements, and third-party dependencies can actually support the business services that matter most. For technical teams, the value is in proving that assumptions hold under stress, not simply that a policy exists.

DORA sits alongside wider ICT risk management expectations, but testing is where design meets reality. A control may look sound on paper, yet still fail when a key SaaS dependency is unavailable, a restore point is corrupt, or an incident response workflow depends on a single engineer being available. That is why testing should be treated as part of the resilience lifecycle, not as a one-off audit activity. If you are already mapping ICT risk and control ownership, the article on ICT risk management expectations under DORA is a useful companion piece.

Why testing matters in the wider ICT risk management lifecycle

In practice, resilience testing validates the chain from risk assessment to operational recovery. It helps answer questions such as: do we know which services are critical, do we know which systems support them, do we know what happens if a provider fails, and can we restore service within an acceptable time? Those questions are especially important where the control environment spans identity, endpoint, network, cloud, and outsourced services.

Testing also closes the loop on change. New integrations, infrastructure migrations, identity platform changes, and release pipeline updates can all alter recovery characteristics. A test programme that is not updated for change quickly becomes stale. That is one reason many teams align resilience testing with change management and release governance, rather than running it as a separate annual event.

How testing supports resilience rather than just control validation

Control validation checks whether a control is present and functioning. Resilience testing goes further by checking whether the organisation can continue or recover a critical service under realistic conditions. For example, it is useful to know that backups are configured correctly, but it is more useful to know whether a restore can be completed within the recovery time objective, whether the restored system is usable, and whether the business process can resume with acceptable data loss.

That distinction matters because resilience depends on interdependencies. A service may be technically restored while still unusable because DNS, identity, certificates, message queues, or a downstream API are unavailable. Good testing therefore needs to exercise the service end to end, not just the primary application tier.

What financial entities should be testing

Core systems, critical business services, and supporting dependencies

The starting point is to define what is being protected. For DORA purposes, the most useful unit of analysis is usually the critical business service, then the ICT assets and dependencies that support it. That can include customer portals, payment flows, trading platforms, case management systems, identity services, logging platforms, and the communications tooling needed to coordinate recovery.

Technical practitioners should avoid limiting the scope to obvious production applications. Supporting services often determine whether recovery succeeds. Examples include single sign-on, privileged access management, certificate services, backup repositories, configuration management databases, and monitoring platforms. If those are unavailable, the primary service may be technically online but operationally impaired.

Dependency mapping should include internal and external services, data flows, and trust boundaries. A simple data flow diagram or service map is often enough to start, provided it captures upstream and downstream dependencies, authentication paths, and any manual workarounds. If you need a refresher on structuring those maps, the article on applying data-flow diagrams to security threat modelling is directly relevant.

Third parties, cloud services, and recovery paths

Third-party and cloud dependencies deserve explicit testing because they are often outside your direct control. This includes SaaS platforms, managed service providers, hosting providers, backup vendors, and communication services. The key question is not whether the supplier has resilience measures in place, but whether your organisation can continue operating if the supplier degrades, fails, or becomes unavailable.

For cloud-hosted services, test the assumptions around tenant recovery, region failure, identity federation, API rate limits, and administrative access. For outsourced services, test the handover points. Who declares the incident, who contacts the supplier, what evidence is shared, what access is needed, and how is service restoration verified? If those steps are not rehearsed, the first real incident becomes the test.

Recovery paths should also be tested for independence. A backup is only useful if the restore path is not dependent on the same identity provider, network segment, or management plane that has failed. This is a common blind spot in small and mid-sized environments where convenience has gradually created hidden coupling.

Testing approaches that are commonly used

Control testing, scenario testing, and recovery testing

Most resilience programmes use a mix of control testing, scenario testing, and recovery testing. Control testing checks whether specific safeguards work as intended, such as backup job success, failover configuration, or privileged access restrictions. Scenario testing asks whether the organisation can respond to a plausible event, such as cloud region loss, ransomware on a key server, or identity platform outage. Recovery testing validates the actual restoration of systems, data, and business processes.

For technical teams, scenario testing is often the most valuable starting point because it exposes coordination issues. A well-designed scenario should define the trigger, the affected service, the expected decision points, the dependencies to be exercised, and the success criteria. It should also include a clear distinction between service continuity, degraded operation, and full recovery, because those are not the same outcome.

Recovery testing should be as realistic as possible without causing unnecessary business disruption. That usually means restoring from known-good backups into an isolated environment, validating data integrity, checking application dependencies, and confirming that the service can be used by a representative user journey. If the service is customer-facing, include authentication, transaction processing, and logging. If it is internal, include the minimum workflow needed for staff to resume work.

Threat-led and intelligence-led testing for higher-risk environments

Where the risk profile justifies it, more advanced testing can be useful. Threat-led or intelligence-led testing uses current threat information to shape scenarios around realistic attack paths and failure modes. This is not about simulating an exploit in production. It is about testing whether the organisation can detect, contain, and recover from a credible operational disruption.

For example, a team might test the impact of credential compromise on privileged access, the loss of a key SaaS tenant administrator, or the unavailability of a cloud control plane. The point is to validate the organisation’s ability to maintain or restore service under conditions that mirror how real incidents unfold. Frameworks such as MITRE ATT&CK can help structure the threat perspective, while the testing itself should remain safe, controlled, and approved.

For teams already using structured validation methods, the article on security regression testing and abuse case testing provides a useful mindset for turning scenarios into repeatable checks. The same discipline applies to resilience testing: define the expected behaviour, execute the test consistently, and capture the evidence.

How to build a risk-based testing programme

Prioritising by business impact, dependency criticality, and change rate

A risk-based programme starts with prioritisation. Not every service needs the same depth or frequency of testing. The highest priority should go to services with the greatest business impact, the most complex dependency chains, or the fastest rate of change. A payment workflow with multiple integrations and strict recovery expectations should be tested more rigorously than a low-impact internal tool with a simple restore path.

Three practical criteria work well for prioritisation. First, business impact: what happens if the service is unavailable for one hour, one day, or longer. Second, dependency criticality: how many upstream and downstream services must work for recovery to succeed. Third, change rate: how often the service, infrastructure, or supplier arrangement changes. The more change, the more likely your assumptions are out of date.

It is also sensible to consider concentration risk. If several critical services rely on the same identity provider, backup platform, or network segment, a single test can reveal a shared weakness. That can be more valuable than testing each application in isolation. This is where service mapping and dependency analysis pay off.

Setting test frequency and scope without creating unnecessary operational burden

Small teams often worry that resilience testing will become a large, disruptive programme. In practice, the answer is to scale the test design to the risk. A mature programme may include lightweight quarterly checks for lower-risk services, semi-annual scenario exercises for critical services, and more detailed recovery tests after major change. The exact cadence should reflect the service criticality and the organisation’s tolerance for disruption.

Scope should be explicit. A test that aims to validate backup restoration should not also try to validate every application feature. Keep the objective narrow enough that the team can determine success or failure. If the test objective is too broad, the result becomes ambiguous and the evidence is weak. A good test plan states what is in scope, what is out of scope, what dependencies will be exercised, and what constitutes a pass.

Where possible, automate the repetitive parts. Backup verification, infrastructure provisioning, configuration drift checks, and evidence capture can often be scripted. That reduces manual effort and improves repeatability. For teams building more mature control automation, the article on automating security testing as part of release pipelines offers a useful pattern for embedding checks into normal engineering workflows.

Evidence, governance, and reporting considerations

What good test evidence looks like for internal stakeholders and suppliers

Good evidence is specific, reproducible, and tied to the test objective. It should show what was tested, when it was tested, who authorised it, what dependencies were involved, what the expected outcome was, what actually happened, and what was learned. Screenshots alone are rarely enough. Include logs, timestamps, change references, restore reports, and any manual validation steps.

For recovery tests, evidence should demonstrate more than a successful restore job. It should show that the restored system was usable and that the business process worked. That might include application health checks, sample transactions, user acceptance checks, and confirmation that monitoring and alerting resumed. If the test exposed a gap, record the impact clearly and avoid soft language. A vague note such as “issue observed” is not useful for remediation tracking.

Supplier evidence should be treated carefully. If a third party provides test results, ask whether the scenario was relevant to your service, whether the test covered your specific tenant or environment, and whether any assumptions limit the value of the evidence. Supplier reports can support assurance, but they do not replace your own understanding of how the service fits into your operating model.

Ownership, sign-off, remediation tracking, and management oversight

Every test should have a named owner, a business sponsor, and a technical lead. Ownership matters because resilience issues often sit across teams. One team may own the application, another the infrastructure, another the supplier relationship, and another the incident response process. Without clear ownership, findings drift.

Sign-off should be based on the test objective, not on whether the exercise felt successful. If the service recovered but took longer than expected, that is a finding. If the team relied on undocumented manual steps, that is a finding. If the test revealed that a dependency was not mapped, that is a finding. Management oversight should focus on whether those findings are being remediated and whether the risk picture is improving over time.

For organisations that already use structured governance, resilience testing can be folded into existing risk and assurance forums. The article on internal audits under ISO 27001 is relevant here because it shows how to turn checks into evidence-backed review activity without overcomplicating the process.

Common gaps seen in resilience testing programmes

Testing that validates controls but not real recovery outcomes

One of the most common weaknesses is stopping at control validation. A team may confirm that backups exist, that failover is configured, or that a supplier has a business continuity statement, but never prove that the service can actually be restored and used. That leaves a gap between assurance and reality.

Another issue is testing in a way that avoids the hard parts. If a restore test excludes identity, certificates, integration points, or data validation, it may give false confidence. Real recovery is usually constrained by the least mature dependency, not the primary application itself. Tests should therefore include the awkward parts that are most likely to fail under pressure.

Weak dependency mapping, incomplete scenarios, and poor follow-through

Weak dependency mapping is a recurring problem. If teams do not know which services depend on which platforms, they cannot design meaningful scenarios. Incomplete scenarios are also common, especially when exercises are written from a purely technical perspective and do not include business decision points. A resilience test should reflect how the organisation actually operates, including escalation, communications, and manual workarounds.

Poor follow-through is the final weakness. Findings are only useful if they are tracked to closure, retested, and reflected in updated procedures. Without that discipline, the same issues reappear in the next exercise. A simple remediation register with owners, due dates, and retest status is often enough to keep momentum.

Practical next steps for UK SMEs in scope of DORA

A simple maturity baseline for starting or improving testing

If you are building or improving a programme, start with a baseline. Identify your critical services, map their key dependencies, and confirm which recovery assumptions are currently untested. Then classify each service by risk and decide what level of testing is proportionate. A basic maturity model might look like this: no formal testing, ad hoc testing, scheduled testing, scenario-based testing, and integrated testing with evidence and remediation tracking.

The aim is not to reach the most advanced level immediately. It is to make the programme repeatable and risk-based. For many UK SMEs, the biggest gains come from testing the services that would hurt most if they failed, rather than trying to cover everything at once. That approach is more realistic, easier to sustain, and more likely to produce useful evidence.

How to align testing with incident response and recovery planning

Resilience testing should feed directly into incident response and recovery planning. If a scenario reveals that the escalation path is unclear, update the incident runbook. If restore validation takes too long, adjust the recovery plan. If a supplier handover step is missing, document it and rehearse it again. The point is to turn test outcomes into operational improvements.

It is also worth aligning resilience testing with digital forensics and evidence preservation. When a real incident occurs, the organisation may need to balance restoration speed with the need to preserve evidence. The article on why digital forensics matters after an incident explains why that balance matters and how it affects recovery decisions.

For UK SMEs in scope of DORA, the practical goal is straightforward: know what matters, test the assumptions that support recovery, capture evidence that stands up to scrutiny, and close the gaps that the tests reveal. If you want help shaping a proportionate testing programme, speak to a consultant.

Frequently asked questions

What is the Digital Operational Resilience Act (DORA)?

DORA is an EU regulation focused on ICT risk management, resilience, and operational continuity in the financial services sector. In practice, it requires organisations and their suppliers to understand, test, and improve the technology and third-party arrangements that support critical services.

What types of tests are typically used for operational resilience under DORA?

Common approaches include control testing, scenario-based exercises, and recovery testing. Higher-risk environments may also use threat-led or intelligence-led testing to validate how well the organisation can withstand realistic disruption scenarios.