Backup Integrity and Isolation

Backup integrity means a backup is complete, unaltered, and usable when it is needed. Backup isolation means the backup cannot be reached, altered, or destroyed by the same incident that damaged the live service. Both are needed. A complete backup that an attacker can encrypt is no rescue. An isolated backup that turns out to be incomplete is no rescue either. Integrity and isolation are therefore twin properties, and a firm should be able to evidence each of them separately, rather than assuming that having backups in place proves both.

The uncomfortable truth is that backups are often tested least where they matter most. A backup job may report success while missing a data store, capturing a corrupted file, or storing a copy that can never be restored in usable form. Integrity and isolation are not properties of a product label. They are properties demonstrated by regular checks, by separation that survives a real incident, and by restore attempts that actually succeed. Until those demonstrations exist, a backup is a hope, not a capability.

Integrity covers more than whether a file exists. It covers whether the backup captured everything the service needs, whether the captured data matches the live data at the point of capture, whether it has changed since, and whether it can be restored into a working service. Each of those can fail independently. A backup may be complete yet altered. It may be unaltered yet partial. It may be both complete and unaltered yet stored in a form that restoration tooling cannot use under pressure.

Isolation requires that the backup survive the incident it is meant to recover from. In practice, that means separation in access, in credentials, and in the paths by which the backup can be changed or deleted. If the same administrative account that manages live systems can also delete backups, then an incident that compromises that account compromises the rescue as well. If backups sit on the same network segment, under the same management plane, and with the same exposure as live systems, they share the fate of those systems.

Incidents reach backups through the same routes they reach live systems: compromised credentials, trusted management tools, shared infrastructure, and time. An attacker who gains administrative access may look for backup systems early, because destroying the rescue makes the attack harder to reverse. A failure that corrupts live data may also corrupt backups if the backup process faithfully copies corrupted data before anyone notices. In both cases, the backup system does what it was asked to do. The flaw is in the assumption that copying, by itself, preserves trustworthiness.

Integrity and isolation are demonstrated by testing that mirrors the real incident as closely as possible. A restore test shows whether a copy is usable. A test that restores from an isolated copy, using recovery credentials rather than everyday access, shows whether isolation works in practice. A test that attempts restoration after simulating loss of the live estate shows whether the firm can actually reach its rescue when the ordinary routes are gone. Each test should be recorded with what was attempted, what succeeded, and what failed.

Ownership sits with the firm that owns the service, with its ICT providers, even where the backup platform is supplied by someone else. A provider may operate the tooling, but the firm must be able to say, for each important service, which backups exist, where they are held, how they are isolated, and when they were last shown to restore. That knowledge cannot be outsourced in the sense of being unknown to the firm. If the firm cannot answer those questions without asking its provider to investigate from scratch, it does not yet own its recovery capability.

Under DORA, which applies from 17 January 2025, the EU frame expects digital operational resilience to include recoverability of ICT systems and data, labelled here as the EU line. Under the UK regime, FCA PS21/3 and PRA PS6/21 carry the operational resilience expectations, with their own dates stated separately. Either way, the practical question for the firm is the same: can it show, from its own records, that its backups are intact and isolated, or is it relying on assurance it has never examined. The answer to that question should be known before an incident, not discovered during one.