Data Backup and Disaster Recovery: A 2026 UK Checklist

Backing up your data is not a technical requirement of Cyber Essentials. That is the opening line of Section C of Cyber Essentials: Requirements for IT Infrastructure v3.3, the document in force for assessment accounts created from 27 April 2026: “Backing up your data is not a technical requirement of Cyber Essentials. However, we highly recommend implementing an appropriate backup solution.”

Which leaves a gap that a lot of certified firms have not noticed. Cyber Essentials proves your five technical controls are in place. It does not prove you could get your business back if someone got past them. And in the last 12 months, 43% of UK businesses reported a breach or attack. That figure comes from the Cyber Security Breaches Survey 2025/2026, published by DSIT on 30 April 2026.

So here is what your backup and disaster recovery plan needs to contain in 2026. We cover what the NCSC actually asks for, and the checklist we use to test whether a plan is real.

The gap between backing up and recovering

The Cyber Security Breaches Survey 2025/2026 (fieldwork August to December 2025) is the best UK-wide picture we have. It shows a familiar pattern. Most organisations back something up. Far fewer plan the recovery.

• 74% of businesses back up data securely via a cloud service; 48% back up securely via other means.
• 25% of businesses have a formal incident response plan — rising to 57% of medium-sized businesses and 76% of large businesses, but only 21% of micro businesses.
• Among small businesses, having a business continuity plan that addresses cyber security fell to 44%, down from 53% the previous year. Formal policies covering cyber risks fell too, to 52% from 59%.

Read those together and the shape of the problem is clear. Backup is widely adopted as a product. Recovery is not widely adopted as a process. When a firm calls us mid-incident, the sentence we hear is almost never “we have no backups” — it is “we have backups, but we cannot get them back”.

The cost of that gap is measured in downtime, which we have broken down separately.

What Cyber Essentials actually says about backups

This is easy to misread, so it is worth being precise.

Backups sit in Section C of the v3.3 Requirements document, ahead of the scope and controls sections. That placement is a deliberate signal of importance. But the wording is a recommendation, not a control:

“Backing up your data is not a technical requirement of Cyber Essentials. However, we highly recommend implementing an appropriate backup solution.”

The document then recommends turning on automatic backups where you can. It also adds one instruction that is really a security control in disguise: if you back up your information to a USB stick or an external hard drive, the guidance says, disconnect it from your computer whenever a backup is not actually running.

That is the offline-backup principle in one sentence. A backup permanently attached to the machine it protects is a file, not a backup.

Working through what else changed in April 2026? Our guide to the Cyber Essentials v3.3 changes covers the mandatory controls. This article covers the part the certificate does not test.

Backups that survive a ransomware attack

The NCSC’s position is that “making regular backups is the most effective way to recover from a destructive ransomware attack” — and that attackers know it. Its guidance notes that “in the early stages of a destructive ransomware attack, actors often target backups and infrastructure, deleting or destroying the data stored there.”

Follow the 3-2-1 rule: 3 copies, 2 devices, 1 offsite

The NCSC’s baseline is the familiar one: “at least 3 copies, on 2 devices, and 1 offsite.” The reasoning is simple. No single event should be able to destroy every copy.

Cloud storage adds a wrinkle that trips up a lot of otherwise sensible setups. As the NCSC puts it, “unlike conventional backup storage, you cannot take your cloud storage offline by simply unplugging it.” Access controls have to do that job instead. Let authorised clients write backups, and deny connection requests while the storage is idle.

The six NCSC principles for on-premises backups

The NCSC publishes two sets of principles for backups that resist destruction. For on-premises solutions:

1. Make it possible to isolate your backup solution
2. Update your backup solution
3. Backups should be resilient to destructive actions
4. Restoration from an earlier backup is possible, even if later versions become corrupted
5. Have in place robust key management for data-at-rest protection
6. Alerts are triggered if significant changes are made, or privileged actions attempted

The five NCSC principles for cloud backups

1. Backups should be resilient to destructive actions
2. A backup system should be configured so that it is not possible to deny all customer access
3. The service allows a customer to restore from a backup version, even if later versions become corrupted
4. Robust key management for data-at-rest protection is in use
5. Alerts are triggered if significant changes are made, or privileged actions are attempted

Three of these are worth calling out because they are so often missing in practice.

Isolate the credentials. The NCSC is direct about this: in a ransomware attack, it is common for attackers to “discover and then gain access to enterprise admin accounts”. A backup system administered with the same domain admin account as everything else is not isolated from anything. Use separate admin accounts and credentials for the backup solution, and mandate MFA for requests to alter or destroy data.

Retain by time, not by count. The NCSC recommends storing backup data “according to a fixed time period, rather than a fixed number of backups”. If you keep the last 14 backups, an attacker who can run 14 corrupted backups in quick succession has destroyed your recovery without deleting a thing.

Assume your alerting infrastructure is compromised too. Cloud backup services should offer alert delivery that still reaches you if your own infrastructure is down. An alert emailed to a mailbox that is part of the incident is not an alert.

This is the same logic behind immutable storage, which we cover in more depth in our guide to ransomware in 2026.

Why you have to back up Microsoft 365 yourself

Most London SMEs now hold their most valuable data in Microsoft 365 — email, SharePoint document libraries, OneDrive, Teams. And most assume Microsoft is backing it up.

Microsoft does not say that. Its own Services Agreement is blunt twice over. “We strongly advise you to make regular back-up copies of Your Content.” And: “We recommend that you regularly backup Your Content and Data that you store on the Services or store using Third-Party Apps and Services.”

What you get natively is retention and deletion safety nets. They are time-limited by design. Microsoft’s own documentation sets out the deleted-user process. The default OneDrive retention period is 30 days. Seven days before it expires, the manager or secondary owner gets a reminder. After that the OneDrive moves to the site collection recycle bin, where Microsoft says it is kept for 93 days. Then it is gone.

Ninety-three days sounds generous until you consider the two scenarios that matter:

• A departure that goes wrong. A dispute surfaces eight months after someone leaves and the evidence lived in their OneDrive. Retention windows do not care that you needed it.
• A quiet corruption or malicious deletion. Damage found outside the window is gone for good. And a recycle bin is reachable by any account an attacker has taken over.

Retention is not backup. If Microsoft 365 holds anything you would be unable to reconstruct — client files, contracts, correspondence with a regulator — it needs a separate, independently controlled copy. That is a licensing and configuration decision, and it belongs in the same conversation as the rest of your Microsoft 365 estate.

Why a green backup job proves nothing

The NCSC is explicit here. Its principles “will only be effective in practice if system owners regularly test and monitor the health of the backup data”. This is where good intentions collapse.

A backup job that reports success proves one thing: a job ran. It does not prove the data is complete, uncorrupted, or decryptable with a key you still hold. It certainly does not prove the person on duty can restore it — at 6am, on a Sunday, with the phones ringing.

Two numbers should be agreed with the business before any technology is chosen:

• RPO (recovery point objective) — how much data you can afford to lose, expressed as time. Nightly backups mean an RPO of up to 24 hours. If losing a day of fee-earner work is unacceptable, nightly is the wrong answer and no amount of storage fixes it.
• RTO (recovery time objective) — how long you can be down before the impact becomes unacceptable. This drives whether you need replication and failover or whether a restore-from-backup is proportionate.

Then test against them. A restore test is not “we pulled back a file”. Nominate a realistic failure. Restore into an isolated environment. Confirm the applications actually run. Measure how long it took, and write down what broke. Something always breaks the first time. Far better on a Tuesday than during an incident.

Tested recovery is also one of the controls underwriters ask about, alongside MFA and patching. We cover that in our note on reducing cyber insurance premiums.

Where the regulation is heading

Resilience is moving from good practice towards obligation, though more slowly than the headlines suggest.

The Cyber Security and Resilience (Network and Information Systems) Bill amends the NIS Regulations 2018. It extends the regulated perimeter and updates incident reporting duties. It had its House of Lords second reading on 14 July 2026. Committee stage — the first line-by-line examination — is scheduled for 1 September 2026, according to Parliament’s own bill news page. It has not received Royal Assent.

Two things follow for a typical London SME. First, the Bill targets operators of essential services, and pulls managed service providers and data centres into scope. It will not impose backup duties directly on most private businesses. Second, and more practically: if you outsource your IT, your provider’s obligations are changing. That reaches you through contracts and assurance questions. We covered the direction of travel in our piece on the Cyber Security and Resilience Bill.

Regulated firms should read their recovery testing obligations against DORA as well, as should anyone serving EU financial entities. There, tested resilience is already explicit rather than recommended.

A backup and disaster recovery checklist

Work through this with your IT team or provider. Any “we think so” is a finding.

Coverage

• List every system that would stop the business if it disappeared today — including SaaS platforms, not just servers.
• Confirm Microsoft 365 (Exchange, SharePoint, OneDrive, Teams) is covered by an independent backup, not native retention alone.
• Confirm line-of-business application databases are backed up in a restorable state, not just as files on disk.

Architecture

• Verify 3 copies, on 2 devices, with 1 offsite.
• Confirm at least one copy is genuinely isolated — physically disconnected, or access-controlled so it cannot be reached from a compromised network.
• Confirm backup storage blocks deletion and alteration for a defined retention period.
• Confirm retention is set by time period, not by number of backups.

Access

• Confirm the backup system uses admin accounts and credentials separate from the rest of the network.
• Confirm MFA is enforced on any request to alter or delete backup data.
• Confirm you can still reach your backups if your primary identity provider is unavailable.
• Confirm encryption keys are held somewhere that survives the loss of the environment they protect.

Proof

• Agree an RPO and RTO per system with the business, in writing.
• Run a full restore test at least quarterly, into an isolated environment, and time it.
• Document who does what during recovery, and make sure that document exists somewhere other than the network being recovered.
• Confirm alerts fire on failed backups, mass deletions and retention changes — and that they reach a human by a route that survives the incident.

If you cannot tick the “Proof” section, you have a backup product rather than a recovery capability. That is the single most common finding in the reviews we run.

Proving your recovery time instead of estimating it

We build and run backup and disaster recovery for London and South East businesses, with copies that are immutable, offsite and isolated from the production estate. We test recovery to a schedule and document the results, so you can hand them straight to a client, an insurer or an assessor.

For our managed IT support clients, restore testing is part of the regular rhythm of running the estate rather than a once-a-year exercise. And if you are certifying, we will happily walk you through where Cyber Essentials stops and where your recoverability begins, because they are not the same line.

If you would like to know how quickly your business could be back on its feet, book a recovery review. We will run the restore with you and time it, rather than reading the backup report together.

---

Sources

• NCSC / IASME, Cyber Essentials: Requirements for IT Infrastructure v3.3, April 2026, Section C — ncsc.gov.uk
• DSIT, Cyber security breaches survey 2025/2026, published 30 April 2026 (fieldwork Aug–Dec 2025) — gov.uk
• NCSC, Ransomware-resistant backups (collection overview and both principle sets) — ncsc.gov.uk
• NCSC, Offline backups in an online world — ncsc.gov.uk
• Microsoft, Microsoft Services Agreement (sections 2 and 6) — microsoft.com
• Microsoft Learn, OneDrive retention and deletion — SharePoint in Microsoft 365 — learn.microsoft.com
• UK Parliament, Cyber Security and Resilience (Network and Information Systems) Bill — bills.parliament.uk and Cyber Security Bill debated in the Lords — parliament.uk

Last reviewed: 3 August 2026. Cyber Essentials requirements are updated annually and the Cyber Security and Resilience Bill is still before Parliament — check the current position before relying on any dated guidance.