A backup you’ve never tested isn’t a backup, it’s a hope. The only way to know a recovery plan actually works is to have tried it before the day it matters.
The 3-2-1 rule
The Cyber Security: Core Standard sets out backups in concrete terms, not general good practice:
- Keep at least three copies of important data, on two different types of media, with one copy off-site.
- Backups must be immutable: unable to be altered once created, so ransomware that reaches your live systems can’t also corrupt the backup sitting behind them.
- Test and log backups termly, and review the backup plan annually or after any major change.
- Restoration shouldn’t depend on specific hardware. If the only machine that can restore a backup breaks, the backup is effectively useless.
- Physical off-site backups must be encrypted and stored securely, and the standard is explicit on one point worth repeating directly: backups should never be taken to a person’s home.
Why the “immutable” requirement matters
A standard backup can still be encrypted or deleted by ransomware that’s reached far enough into a network. If the backup is just another writable file share, it’s just another target. Immutable backups close that gap: once written, they can’t be altered or deleted for a set period, even by someone with admin access. That’s the difference between a backup that survives an attack and one that gets taken down alongside everything else.
Only back up what you actually need
More backup isn’t automatically better backup. Storage costs money, and every additional copy of something is one more thing to secure, encrypt, and account for if it’s ever breached. Schools often back up far more duplicate data than they realise. A common example is teacher planning folders copied completely, year after year, with no process for retiring the ones nobody’s opened since the year they were written.
This isn’t just a cost question. It connects directly to the UK GDPR’s storage limitation principle: personal data shouldn’t be kept for longer than necessary, and that applies to backup copies as much as live data. A backup regime that indefinitely retains every version of every folder ever created isn’t just expensive; it’s also quietly expanding how much personal data the school is holding, and for how long, without anyone having decided that on purpose.
Worth doing periodically: review what’s actually in scope for backup, retire genuinely obsolete duplicate data (with appropriate sign-off, not just deleted on a hunch), and make sure the backup policy and the data retention policy are actually saying the same thing to each other.
Cloud services need checking specifically. SharePoint, email, and similar platforms
It’s easy to assume that because data lives in the cloud, it’s automatically backed up to the standard this article describes. That’s not necessarily true, it's called the shared responsibility model. Microsoft 365 (SharePoint, Exchange Online/email, Teams) commonly used in schools: Microsoft is responsible for the platform’s uptime and infrastructure, but retention and recovery of your actual data is the customer’s responsibility, not something covered automatically by the subscription. Native retention policies and the recycle bin are not the same thing as a true backup: they typically have limited retention windows, don’t protect against all forms of data loss, and can themselves be affected by the same compromised admin account that caused the problem in the first place.
Practically, that means:
- Check specifically whether your school’s backup strategy covers SharePoint, email, and Teams data, or whether it assumes Microsoft (or Google, for Workspace users) is already doing this.
- If it isn’t covered, a dedicated third-party backup tool for these platforms is a genuine gap to close, not an optional extra.
- Apply the same immutability and testing expectations here as to on-premises backups. A cloud backup that’s never been test-restored is exactly as unproven as any other.
This is worth raising directly with whoever manages your Microsoft or Google tenancy, since it’s easy for this to sit in a gap between “IT support assumes the cloud provider handles it” and “the cloud provider’s own terms say otherwise.”
Checking supplier-held backups more broadly
The same principle extends to your MIS, website, and any other SaaS (Software as a System) platform: each usually holds its own backups as part of the service, but “usually” isn’t “confirmed.” Worth checking directly with each supplier:
- What’s actually backed up, and how often.
- How long backups are retained, and whether you could restore to a specific point in time if needed.
- Whether the backup is genuinely separate from the live system, not just a second copy on the same infrastructure.
This is the same supplier assurance thread running through this series. A data sharing agreement with a cloud provider is only reassuring if it actually covers what happens to your data when something goes wrong, not just while everything’s working normally.
Where ransomware payment policy is heading
Backups matter more than ever given where UK policy is going. Following its public consultation, the government has confirmed its intention to ban public sector bodies, including schools, from paying ransomware demands, alongside mandatory incident reporting and a requirement for organisations outside the ban to notify the government before paying a ransom. This isn’t in force yet, but the direction is clear: a working, tested backup is likely to become the only recovery route available, not just the recommended one.
Reflection questions worth actually answering
- Could you restore your server configurations, not just the data sitting on top of them?
- How current and relevant is what’s actually in the backup. Would it genuinely be useful if restored today?
- Are backups protected from the same malware or ransomware that might hit the live systems?
- Do you know exactly where backups are physically located, including any off-site or cloud copies?
Who’s accountable
IT support is Responsible for running, testing, and logging backups, confirming restoration actually works, and checking cloud/SaaS backup coverage specifically. The SLT digital lead is Accountable for making sure the termly test and annual review are genuinely happening, not assumed. The DPO/Data Protection Lead is Consulted on backup locations, retention, and the overlap with the storage limitation principle, since backed-up data is still personal data under the same obligations as the live copy. Governors remain Informed, and the NCSC’s governor question about whether the school could keep operating if it lost access to its data overnight is, in practice, a direct question about whether this section has been taken seriously.
💡Daily Cyber Tip
Check the date of your last successful backup restore test, not backup run, restore test. A backup that’s never been restored is unproven, however many copies exist of it.