Disaster Recovery Plans for ICT

A disaster recovery plan for ICT sets out how the technology and data behind a service are brought back after disruption, in the order the service needs them. It is not a list of systems in alphabetical order or in order of technical size. It begins with the customer-facing steps, traces them to the platforms, data stores, networks and suppliers underneath, and sequences restoration so that the earliest restored step is genuinely usable. Under DORA in the EU, which applies from 17 January 2025, ICT risk and recovery expectations are central, while the UK regime in FCA PS21/3 and PRA PS6/21 treats ICT as part of wider operational resilience. The plan should label which regime it supports, rather than merging the two.

Recovery order is where many ICT plans go wrong. Engineers may naturally restore the largest platform earliest, or the system they know best, while the service step customers need remains dependent on a smaller component that has not yet returned. A service-led plan avoids that by mapping dependencies in service order. It asks, for each customer step, what must be present before that step can be trusted: identity checks, account data, transaction history, payment connections, or reporting feeds. It then orders technical restoration around those needs. That discipline also reveals where a partial service is possible, for example where customers can view balances but cannot yet transact, and where partial restoration would mislead customers and should therefore be avoided.

Consider an illustrative online account service. Customers log in, view balances, move money and download statements. Behind those steps sit identity services, core account data, transaction processing and document storage, each with its own dependencies. A recovery plan should state which data copy will be used, how its integrity will be checked, and what happens if that copy is incomplete or suspect. Restoring a system quickly is of limited value if the data it serves is wrong, out of sequence or drawn from a source that was itself affected by the disruption. Integrity checks, reconciliation steps and a clear decision point before customers are reconnected are therefore part of recovery, not an afterthought to be fitted in afterwards.

Disaster recovery also needs to consider the nature of the disruption. A hardware failure, a failed change, a supplier outage and a cyber incident do not call for identical responses. In a cyber incident, for example, restoring from the most recent copy without checking whether that copy is clean can reintroduce the problem. The plan should therefore include decision points for different disruption types, and criteria for choosing a clean recovery point even when that means losing more recent data or taking longer. Those trade-offs should be discussed before disruption, with service owners involved, because during an incident the pressure to restore quickly can overwhelm careful judgement about whether restoration is safe.

Dependencies beyond the firm's own estate deserve explicit attention. Cloud services, network providers, data suppliers and outsourced platforms may each have their own recovery arrangements, and those arrangements may not match the firm's service tolerance. The plan should record what each supplier promises in practical terms, how the firm will know whether that promise is being met, and what the firm will do if it is not. It should also state how access credentials, configuration records and recovery tools will be available if normal systems are unavailable. Recovery that depends on a password store, a runbook or a contact list held only inside the disrupted system is fragile, and that fragility should be found in testing rather than during a real event.

Testing turns a recovery plan from a document into a capability. A restore test that only checks that a backup can be read proves little about service recovery. A stronger test restores the service steps in order, checks data integrity, reconnects a controlled group or a simulated customer journey, and records where the sequence broke. Tests should also practise the handover from technical recovery to service ownership, because the decision to return a service to customers is a service decision, not purely a technical one. Lessons should amend the plan, the dependency map or the data checks, and the amended steps should be tested again. That loop is what makes recovery credible when it matters.