Restoring from Backups Safely

Restoring from backups safely means choosing a copy you have reason to trust, checking it before it serves customers, and restoring in stages that can be paused if something looks wrong. The existence of backups is not, by itself, a recovery capability. Backups can be incomplete, out of date, encrypted by the same incident, or quietly altered before anyone noticed. Safe restoration treats every copy as a candidate to be examined, not as a rescue that is assumed to work, and it keeps the live service separate from the restored copy until the checks are done.

The practical consequence is that restoration is a decision process with a record, not a single technical action. A firm should be able to say which copy was chosen, why that copy rather than a newer or older one, what checks were run, what was found, and who approved the return. Where those answers are missing, restoration may still succeed, but the firm will not know whether it succeeded by judgement or by luck, and luck is a poor basis for declaring a service recovered.

Choosing a copy begins with understanding the timeline of the incident, even where that timeline is incomplete. The firm needs a view of when the service was last known to be sound, when suspicious activity may have begun, and which copies fall on either side of that uncertainty. A copy taken after the incident began is not automatically tainted, and a copy taken before it is not automatically clean, but the timeline gives the firm a reasoned place to start its checks rather than a random one.

Before a restored copy serves customers, it should be checked in a place where a problem cannot spread. That checking may include scanning for known malicious material, comparing the copy with independent records, looking at recent changes to accounts and configuration, and testing whether the service behaves as expected on representative journeys. No single check proves cleanliness. Together, they build a picture, and a copy that fails a meaningful check should be set aside rather than explained away under time pressure.

Restoring in stages gives the firm chances to stop. A common pattern is to restore first to an isolated environment, then to a limited live use, and only then to full service, with checks at each boundary. Each stage answers a different question. Isolation asks whether the copy is safe. Limited use asks whether it behaves correctly for real customers. Full return asks whether the whole service, with its providers and connections, holds together. Skipping a stage removes a question, not the risk behind it.

Restoration involves the firm that owns the service and its ICT providers, each with a part that should be clear before an incident. Providers may hold the backup platform, the tooling, or the infrastructure on which restoration runs, and their knowledge of what was backed up, in what form, and how it can be restored is essential. But the decision about which copy to trust and when to return the service belongs to the firm, because it is the firm that answers to its customers for the service. A provider can advise and execute. It cannot own the service judgement on the firm's behalf.

After a restore, the work is not finished. The firm should watch the restored service closely for behaviour that suggests the incident persisted, such as unexpected account changes, unusual connections, or errors concentrated in the restored data. Monitoring that was itself affected by the incident may need rebuilding or independent checking, because a firm cannot rely on a compromised lens to judge whether the service is clean. Independent signals, including customer reports and reconciliation results, deserve attention alongside system monitoring.

The firm should also preserve the record of the restore: the copy chosen, the checks run, the limits applied, and the approval given. That record serves two purposes. It supports review and learning, and it allows the firm to explain its decisions afterwards without reconstructing them from memory. A restore that is not recorded may have worked, but it has taught the firm little, and it leaves the next incident to be handled from scratch. Safe restoration is therefore as much about the record as about the technology.