Backup & Restore Assurance Pack — Guide

Backup & Restore Assurance

Most organisations can show that their backup jobs run. Few can show that the data comes back. A finished job says only that it wrote something. It does not say that the data restores, that it restores within the time the service can wait, or that an attacker holding your administrator credentials could not have reached the copy and deleted it first. Attackers look for backups early. This pack sets the backup standard that your recovery objectives rely on, protects the copies, and proves each one by restoring it, checking the result and timing it.

Is this for you?

This pack is for you if:

• your backup report shows green, and nobody has restored a critical system from it this year;
• the backup console signs in through the same directory an attacker would take over;
• a cloud provider or software supplier holds data you need, and you do not know what it backs up;
• an auditor or an insurer asks for evidence that your backups restore, and you have none to hand.

How it works

Start with the data. List every data set a critical service needs, and the data needed to rebuild the foundations. Each has an owner and a class: Critical, Important or Other. Each critical data set is backed up at least as often as the recovery point of its service. It keeps at least 3 copies on 2 kinds of storage, with 1 offsite and 1 immutable or offline. That copy must be out of reach of production administrator credentials. Retention is the longest of the business, legal and recovery needs, and the recovery need is 35 days unless you set another.

Then protect the copies. Backup administrators use their own accounts, separate from the production directory, with multi-factor authentication. Locks on immutable copies need two named people to change. The keys sit outside the estate they unlock.

Then prove it. Restore tests come in five types, from a file restore to a clean-room rebuild. A critical data set is restored and checked every 3 months. Each critical service gets a full restore, end to end, rebuild or tenant test at least once a year. A test passes only when it completes, passes its integrity checks, meets the recovery time and recovery point, is checked by someone other than the tester, and leaves evidence. A tabletop exercise is not a restore test. Every failure is a finding with an owner and a date: High within 90 days, Medium within 180, Low within 365.

How it runs in practice (EXAMPLE)

Take the distributor from the recovery pack: 900 staff, three warehouses, an online ordering service. After ransomware hit 14 office PCs in August 2026, its Head of IT listed six data sets on 30 September 2026.

The checks found six failures. The backup of warehouse dispatch runs daily, and dispatch can lose 4 hours. The distributor holds no copy of its card payment records. The email backup keeps 30 days, less than the 35 the recovery need asks for. The directory and network backups have never been restored. Only 4 of 6 critical data sets met the copies rule.

The tests found two more. The ordering platform took 4 days to restore in May, against 24 hours allowed. The warehouse restore in August lost 24 hours of data. Two of five critical services were restored within their objectives in the last year.

Of 15 protection controls, 9 are met, 3 are not met and 3 are not checked, because the backup provider has not been assessed. In September, 3 of 120 jobs failed, and each was fixed within its time. Eight findings are open, 2 of them High, and none is past due.

Start with these three

1. Backup Coverage & Retention Matrix: each data set, its copies, and the six checks that find gaps.
2. Restore Testing Methodology: the five test types, how often each runs and the pass criteria.
3. Immutable & Offline Backup Protection Checklist: the controls that keep an attacker away from the copies.

Your first round

What to report

Each quarter, to executive management, and each year to the approver:

• critical data sets backed up as often as their recovery point, and those that are not, by name;
• critical data sets meeting the copies rule, with none unverified;
• protection controls met, not met and not checked;
• failed backup jobs, and how many were fixed within their time;
• critical services restored within their recovery time in a test this year;
• findings open, with High and past-due findings by name.

Everything in the pack

Adapting it

• Recovery objectives: the Cyber Resilience & Recovery pack sets each service’s recovery time and recovery point. Restore tests here measure against them and never set one.
• Incident response: the Incident Response Plan decides when backup jobs stop and how backups are protected in an incident. This pack changes none of its decisions.
• Exercises: a tabletop exercise tests decisions. A restore test restores data and measures it. Plan both.
• Law: this pack is not legal advice. Which backup and testing duties apply to you depends on your sector and national law. Confirm them with counsel or your supervisor.

Framework references

• ISO/IEC 27001:2022: Annex A 8.13, Information backup.
• NIST CSF 2.0: PR.DS-11.
• NIS2: Article 21(2)(c).
• DORA (financial entities): Articles 12(1) and 12(2).
• GDPR: Article 32(1)(c).
• Guidance, binding nobody: NCSC (UK), “Offline backups in an online world” (2019); NIST SP 800-209 (October 2020), RA-SS-R5.