Disaster Recovery Testing for ICT

Disaster recovery testing for ICT checks whether technology and data behind a service can actually be restored, in service order, with data that can be trusted, without affecting live customers. It goes beyond confirming that a backup exists or can be read. A meaningful test restores the service steps, checks integrity, exercises dependencies and supplier connections in a controlled way, and records where the sequence breaks. Under DORA in the EU, which applies from 17 January 2025, and under the separate UK regime in FCA PS21/3 and PRA PS6/21, testing expectations should be labelled by regime. The test result, including failures, is the evidence that matters.

Isolation is the first design choice. Recovery tests should run in an environment separated from live service, so that a failed restore, a data error or a configuration mistake does not become a customer incident. That separation also allows testers to try realistic failure stories, including a corrupted copy, a missing dependency or a supplier connection that does not behave as expected, without fear of harming live work. Where a test must touch a shared component, planners should define safeguards, scope limits and a stop condition in advance, and should brief customer-facing teams so that any visible effect is understood as a test, not mistaken for a real incident.

A test should follow the service, not just the technology. Testers should start with a customer step, such as viewing a balance, submitting a claim, or making a payment, and check whether that step works after restoration, with the data and checks it needs. That approach exposes gaps that a purely technical test misses, such as a restored system that cannot authenticate users, a data copy that is readable but out of sequence, or a reporting feed that restores after the step that needs it. It also forces a decision point that mirrors real recovery: at what point would the service owner allow customers to reconnect, and what evidence would support that decision.

Consider an illustrative securities settlement service. Its recovery test might restore trade data, settlement instructions and counterparty connections in order, then check that trades reconcile, that duplicate instructions are not created, and that exceptions are visible to operations staff. A test that only restores the core platform, without checking settlement connections and reconciliation, would claim success while leaving the service step that matters most untested. The test should also include the people who would perform recovery, using the runbooks and access routes they would actually have, because a recovery that only works when a particular specialist is present, or when undocumented knowledge is available, is fragile.

Failure in a test is useful information, provided it is handled honestly. A test that reveals a missing dependency, an unreadable data copy, a permission problem or a supplier gap has succeeded as a test, even though it has failed as a recovery demonstration. The report should describe the failure plainly, assign an owner, and set a follow-up test for the corrected step. A culture that treats test failures as embarrassment, or that re-runs a test until it passes without changing anything, destroys the value of testing. Reviewers should therefore look for evidence of failures found and fixed, not only for a record of tests passed.

Testing should keep pace with change. A recovery test passed before a major system change, a supplier change or a data migration does not prove that recovery still works afterwards. Test planning should therefore be linked to change: material changes to the recovery sequence, to data stores, or to dependencies should trigger a proportionate retest, rather than waiting for a routine test cycle. Over time, a series of focused tests, each tied to a service step or a recent change, can build stronger assurance than a single large annual exercise that tests everything superficially. That steady, service-led approach is what turns disaster recovery testing from a periodic event into a capability that service owners can rely on.