What "Testing Backups" Actually Means

Completion is not the same as recovery

When someone says "we test our backups," they often mean the backup job reports success. That is not the same as restore verification. A successful backup job confirms that data was written to storage. It does not confirm that:

• the data is complete enough for operational use;

• access permissions allow an authorised recovery;

• the restored output is usable; or

• recovery can occur within the time window the business can tolerate.

The UK Information Commissioner's Office (ICO) makes this distinction explicit. UK GDPR Article 32 requires the ability to restore the availability and access to personal data in a timely manner after a physical or technical incident, and to ensure ongoing integrity and resilience of processing. The ICO's own guidance states that organisations must have appropriate processes in place to test the effectiveness of their security measures, and undertake any required improvements. A backup that has never been restored does not satisfy that requirement — it is a hypothesis, not a control.

The National Cyber Security Centre (NCSC) takes the same position: "Test your backups so you know you can successfully restore your data." The NCSC recommends mixing different types of tests regularly, including validating that data can be restored, checking access permissions, and confirming the backup remains usable after recovery. The 3-2-1 rule — three copies, on two different media types, with one copy off-site — is the NCSC's baseline topology, but the rule only has value if those copies can actually be restored.

What a test should prove

A meaningful restore test should demonstrate four things:

1. Data completeness — the restored set contains everything the business needs for the system being tested.

2. Access permissions — the right people can access the restored data; the wrong people cannot.

3. Integrity — the restored output is usable and uncorrupted.

4. Time window — recovery completed within the RTO the business has defined for that system.

If your test does not cover at least these four elements, you are not testing recovery — you are testing hope.

A Practical Testing Cadence for SMEs

There is no single statutory interval for backup testing. The ICO and NCSC both describe testing as a proportionate, risk-based obligation rather than a fixed-schedule tick-box. For an SME with ten to twenty-five seats, a tiered approach is the most practical way to balance governance with operational reality.

Monthly: the spot check

A monthly test should confirm that recent backups can be restored successfully. This might include recovering a sample of files from the file share, a mailbox item from Microsoft 365, or a record from the line-of-business system. The test should be rotated across different systems so that drift does not go unnoticed.

Monthly testing catches the most common failure mode: the backup appears to be running but is not actually covering the data you think it covers. This can happen when new systems are added, permissions change, or retention policies are adjusted. A monthly spot check — typically fifteen to thirty minutes — is the minimum frequency for systems that support daily operations.

Quarterly: the timed restore

A quarterly test should go further. Restore a key business system — a server, a virtual machine, or a core cloud dataset — to an isolated environment and time the process against your documented Recovery Time Objective (RTO). This verifies not only that the restore works, but that it works within the time window the business depends on.

Paper recovery times and actual recovery times are frequently different. A process that looks correct on paper may reveal hidden dependencies, corrupted backup chains, or missing credentials when performed end to end. The quarterly timed restore is where those gaps become visible.

Annually: the disaster recovery exercise

Once or twice a year, run a broader exercise that simulates a realistic incident — ransomware, hardware failure, or accidental deletion of a shared environment. This exercise should test roles, decision sequences, communications, and fallback processes, not just the technical restore.

A full-scale simulation should be scheduled and owned, not left to happen only after an actual incident. Testing after an incident is too late to build confidence.

Change-triggered: out-of-cycle testing

Scheduled testing alone is not sufficient when the environment changes. Material changes — new systems, permission restructures, migrations, or alterations to restoration paths — should trigger out-of-cycle testing so that recoverability is re-proven after the environment shifts.

This is a governance decision, not an IT task. The owner of the system being changed should be the one who confirms that the backup and recovery configuration has been re-tested before the change is accepted as live.

Factors That Change the Cadence

Business criticality

Systems that would stop operations if unavailable — customer records, financial data, communication platforms — deserve more frequent testing than archival data that changes rarely. A small business owner running backup tests should map each system to its business impact before setting the cadence.

Compliance obligations

Some sectors and data types carry explicit testing requirements. UK GDPR Article 32 requires that security measures be tested, assessed, and evaluated using appropriate processes — and that organisations act on the results where they highlight areas for improvement. Cyber Essentials v3.3, in force from 27 April 2026, recommends implementing an appropriate backup solution but does not make it a technical control requirement. However, the ICO's position is clear: appropriate measures include offline and segregated backups, and the ability to demonstrate those measures in accordance with the state of the art, cost, and risk of processing.

If you hold personal data and cannot recover it after an incident, you would struggle to show that you had appropriate technical measures in place. That makes tested backup recovery the practical standard, even though the regulation never uses the word "backup" directly.

RTO and RPO

Recovery Time Objective (RTO) and Recovery Point Objective (RPO) are the two numbers that should govern your cadence. RPO determines how frequently you must snapshot — and therefore how much data loss you would accept between the last backup and an incident. RTO determines whether your recovery process needs to be instant or can tolerate a slower restore.

The ICO describes "timely manner" as dependent on the circumstances of the organisation and the personal data being processed. What matters is that the business has taken this into account during its information risk assessment and selection of security measures. A documented RTO and RPO are the evidence that this consideration has actually happened.

Common Misconceptions

"If backups run, they'll restore"

Backup completion does not prove restoration. Restore verification is a different outcome that must be evidenced. A backup job showing a green checkmark confirms that something was written to storage. It does not confirm that the something is complete, uncorrupted, current, or restorable. The gap between backup completion and verified recovery is where most governance failures hide.

"Testing is only needed once a year"

Annual testing is the absolute minimum floor, not the target. If a company tests only once a year, a failed restore can remain hidden for months. That is a long time to carry risk without knowing it. Quarterly testing creates regular discipline and gives leadership four checkpoints per year to validate whether recovery goals still match business needs.

"Testing is a technical task, not a governance requirement"

Testing is governance because it proves recoverability and produces accountability evidence. The records should show what was tested, what worked, what failed, and how issues were tracked to remediation and re-test. This is what creates accountability and avoids repeating the same failures.

"Cloud backups don't need testing"

Recoverability still depends on access, integrity, and restoration paths — regardless of where the backup is stored. Microsoft 365 retention features and third-party backup services both require validation. The NCSC notes that, unlike conventional backup storage, cloud storage cannot be taken offline by simply unplugging it. Access controls have to do that job instead.

"We can test only after an incident"

Testing after an incident is too late to build confidence. Scheduled and change-triggered testing provides assurance beforehand. A credible testing programme is the difference between knowing you can recover and hoping you can.

What Evidence Looks Like

A test that cannot be evidenced does not help you in an audit. The ICO expects organisations to document the results of their testing and act on any recommendations. For an SME, the evidence pack does not need to be complex — it needs to exist.

The minimum evidence for each test should include:

• what was tested and when;

• what systems or data sets were included;

• the outcome (pass/fail and any issues found);

• who performed the test;

• how issues were tracked to remediation;

• confirmation of re-test where remediation was required.

Where an issue is identified but not remediated, the business should have a documented reason for that decision. Silent failures, unclear ownership, and missing test records are among the most common findings in post-incident reviews.

How This Connects to Your Security Baseline

Backup testing is not an isolated IT task. It is one of the controls that sits within a maintained security baseline — the set of governed, evidenced, and reviewed controls that Cyber Essentials represents as a minimum standard for UK SMEs.

A business that cannot evidence its recovery capability has a baseline gap. Repeated test failures, unclear ownership, missing datasets, and changes that invalidate recovery paths are not "technical inconveniences"; they indicate that the baseline is not being maintained. That is the point where a structured baseline review becomes appropriate: to restore scope clarity, decision rights, and evidence-led assurance.

The question of how often backups should be tested is therefore not purely technical. It is a governance question. The answer depends on the business's risk profile, its compliance obligations, the systems it depends on, and its willingness to treat recovery as something that must be proved, not assumed.

For a ten-to-twenty-five seat SME in Sussex or Kent, quarterly restore testing is the practical minimum for critical systems. Monthly spot checks strengthen that position. An annual broader exercise validates the full recovery sequence. Out-of-cycle tests after material change keep the evidence current. And a documented evidence trail is what turns the exercise from a calendar event into something the business can rely on when it matters most.

FAQ

Is there a legal requirement for how often backups must be tested?

UK GDPR Article 32 requires that technical and organisational measures be tested, assessed, and evaluated using appropriate processes, and that improvements be made where testing reveals gaps. The ICO's guidance confirms this applies to backup and recovery arrangements. However, the regulation does not prescribe a specific interval — it requires proportionate testing matched to the nature, scope, context, and purposes of processing and the risks to the rights and freedoms of natural persons. The cadence is therefore a governance decision, not a fixed statutory requirement.

Does Cyber Essentials require backup testing?

Cyber Essentials v3.3, in force from 27 April 2026, states explicitly that backing up data is not a technical requirement of the scheme. However, it recommends implementing an appropriate backup solution and describes precautions such as keeping copies off the primary device and disconnecting removable media when not in use. The NCSC's ransomware-resistant backups guidance — which sits within the Cyber Essentials assurance ecosystem — describes testing as essential. The distinction matters: backup is recommended rather than mandated under CE, but the broader UK GDPR and ICO expectation makes tested recovery the practical standard.

What is the difference between a backup test and a disaster recovery exercise?

A backup test verifies that specific data can be restored from a specific backup copy. A disaster recovery exercise goes further: it simulates a realistic incident and tests the full sequence of decisions, roles, communications, and technical recovery steps. Most SMEs should run backup tests monthly or quarterly, and a full disaster recovery exercise at least annually.

What should I record after a backup test?

The minimum evidence is what was tested, when, by whom, the outcome, any issues found, how they were remediated, and confirmation of re-test where required. A test without a record does not demonstrate compliance in an audit or support continuous improvement.

Can I outsource backup testing?

Testing can be performed internally, externally, or both. The ICO's guidance states that testing may be undertaken internally or externally, and in some cases it is recommended that both take place. The key requirement is that the business retains accountability for the outcome and the evidence, regardless of who performs the technical work.

How does backup testing connect to cyber insurance?

Many UK cyber insurance policies now require evidence of tested backup and recovery arrangements as a condition of cover or in support of a claim. An insurer reviewing a ransomware incident will ask whether the backup could actually be restored. A log of regular restore tests is the evidence that the business had appropriate measures in place under UK GDPR Article 32 and can satisfy both the ICO and the insurer.

Related resources:

• How often should you test backups? — Infinite Cloud IT resource page

• Backup & Business Continuity for SMEs — Sussex & Kent

• Do I need Microsoft 365 backup?

• Top 10 Cybersecurity Risks Facing Small Businesses in 2026

If your backup testing cadence is not producing the evidence you would need to demonstrate recoverability under incident conditions, a Security Triage Call can give you a clear picture of where your current controls stand against a maintained baseline.

This article was generated with AI assistance and reviewed by the Infinite Cloud IT marketing team.