Deciding When to Restore a Service
Restoring is a judgement, not a switch: what evidence the decision needs, who makes it, and why business pressure alone is never a sufficient reason to return.
The short answer
Deciding when to restore a service means judging, on the evidence available, that the service is safe to use again, for the customers and journeys proposed, under any limits proposed. The decision is not the same as a system being technically ready. A system can restart, a backup can load, and a channel can respond, while the service as a whole remains unsafe because its data is untrusted, its scope is unclear, or its connections have not been checked. The decision therefore asks a service question, not a systems question: what do we know, what do we still not know, and is that enough for this return.
Because knowledge during an incident is always incomplete, the decision is about acceptable uncertainty, not certainty. A firm will rarely know everything, and waiting for complete knowledge may itself harm customers who need the service. The decision should therefore name what is known, what remains uncertain, what limits manage that uncertainty, and who accepts the residual risk on behalf of the service. A decision recorded in those terms can be reviewed and defended. A decision recorded only as approval to go live cannot.
What evidence does the decision need?
The decision needs evidence across several questions. Is the scope of the incident understood well enough to say which parts of the service were affected and which were not. Is there a copy of data and a version of systems that the firm has reason to trust. Have the restored parts been checked in isolation and, where possible, in combination. Are the accounts, connections, and providers the restored service will rely on sound. None of these questions has a simple yes or no answer during a real incident, and the decision maker should expect partial answers.
Who makes the decision, and how?
The decision should be made by a named person with authority for the service, advised by technical, security, and operational colleagues, and by ICT providers where relevant. That structure matters because recovery decisions involve trade-offs between customer need, safety, and uncertainty, and trade-offs need an owner. A committee that shares responsibility in general terms may, in practice, leave no one responsible for the specific return. Naming the decision maker in advance, with a deputy for absence, prevents that drift.
When is a limited return the right decision?
A limited return is often the right decision when the evidence supports part of the service but not all of it. Limiting by journey, by customer group, or by function allows the firm to restore value where it is confident, while holding back the parts where uncertainty remains. Read access before transactional access, or a single channel before all channels, are familiar forms of this approach. The limit should be explainable to customers and supportable by operations, not merely a technical switch that staff cannot explain.
How should business pressure be handled?
Business pressure is real and legitimate. Customers may be unable to pay, to access funds, or to meet obligations, and every hour of outage has consequences. That pressure is a reason to work urgently on recovery, and to communicate clearly while doing so. It is not, by itself, evidence that the service is safe to return. Conflating urgency with readiness is one of the most common recovery errors, because it turns a genuine customer need into a justification for a return the evidence does not support.
How is the decision recorded and reviewed?
The decision should be recorded at the time it is made, with the evidence considered, the uncertainties acknowledged, the limits applied, and the person who made it. Contemporaneous records are more reliable than reconstructions, and they allow the firm to learn from the decision afterwards, whether the return succeeded or had to be withdrawn. The record should also note what would have changed the decision, because that note becomes the starting point for the next review.
Afterwards, the decision should be reviewed without blame, but with candour. Did the evidence prove as strong as it seemed. Did a limit prove unnecessary or insufficient. Did pressure influence the timing in a way the firm would not repeat. Those questions turn a single recovery decision into organisational learning. A firm that reviews only failed returns learns half the lesson. Successful returns also contain judgements worth examining, because a return that succeeded despite thin evidence may have succeeded by luck, and luck should not become policy.
Primary sources on the record
- FCA operational resilience, FCA operational resilience pages.
- ENISA, ENISA homepage.
- NIST Computer Security Resource Center, NIST CSRC.
Legal status: Regime-dependent and labelled in the guide. DORA applies from 17 January 2025. The UK regime has its own policy statements and dates, stated separately where the guide compares regimes. Application position for this topic: DORA: from 17 January 2025. UK: see the UK line for its own dates.