A backup can save a business from ransomware, accidental deletion or a failed server. It can also create a long-lived copy of personal data that nobody has reviewed, tested or can properly account for. This UK GDPR data backup guide sets out how to protect recoverability without turning backup storage into an unmanaged compliance risk.

For most organisations, the aim is not simply to keep every file forever. It is to restore the right information, within an agreed timeframe, while applying the same care to personal data in backups as to data in live systems. That requires clear decisions about what is backed up, where it is held, who can access it and when it is securely removed.

Are backups covered by UK GDPR?

Yes. A backup containing information about identifiable people is processing personal data, even if it is only intended for disaster recovery. Staff records, pupil information, customer contact details, financial data, emails and documents may all fall within scope.

The UK GDPR does not prevent organisations from taking backups. In practice, dependable backup arrangements support the security and availability principles of data protection. The issue is whether the arrangement is proportionate and controlled. If a backup is copied to a personal drive, retained indefinitely or accessible to too many people, it may create a greater risk than it resolves.

Backups should be considered as part of the wider information lifecycle. The person responsible for data protection, IT and operational continuity may be different people, but their decisions need to align.

Start with the business recovery requirement

A sensible backup design starts with the question: what would happen if this system were unavailable at 10am on a working day? The answer determines both the technical approach and the level of investment required.

Two measures are particularly useful. The recovery point objective, or RPO, defines how much data loss is acceptable. For example, a system backed up every 24 hours could lose up to a day’s work. The recovery time objective, or RTO, defines how quickly the service must be restored. A payroll system, manufacturing line application or school safeguarding platform will usually need a far shorter RTO than a historic archive.

These targets should be agreed with service owners rather than assumed by IT. A daily backup may be adequate for one service and wholly unsuitable for another. Once expectations are written down, it becomes easier to select storage, connectivity and support arrangements that match the real operational risk.

Apply data protection principles to backup copies

The same principles that apply to live data should inform your backup policy. In practical terms, that means collecting only necessary data, retaining it for a defined purpose, restricting access and protecting confidentiality, integrity and availability.

Set retention periods that you can justify

Retention is often the weak point. Organisations may retain backups for years because storage is relatively inexpensive or because nobody has approved a deletion schedule. However, low storage cost is not a lawful reason to keep personal data indefinitely.

Set retention periods according to the purpose of each backup tier. Short-term operational backups may be retained for days or weeks. Monthly or annual archives may be appropriate where there is a genuine legal, contractual or business requirement. The policy should explain the rationale and identify who reviews it.

There is no universal retention period that suits every organisation. A school, charity, manufacturer and professional services firm will hold different categories of information and face different obligations. The key is to document the decision and make sure the technical settings reflect it.

Manage erasure requests realistically

The right to erasure does not normally mean engineering teams must search through every historic backup immediately. Restoring and altering backup sets can compromise their integrity and may be disproportionate.

A practical approach is to remove the individual’s data from live systems where required, prevent it being restored into normal use, and allow it to expire through the standard backup retention cycle. If a backup is restored, processes should ensure that erased data is not reintroduced unnecessarily. Record the approach in your retention and data subject request procedures.

Protect special category and high-risk data

Some data needs additional attention because the impact of exposure is greater. This can include health information, safeguarding records, biometric data, information about criminal offences and detailed financial records. Encrypting backup data, limiting administrative access and keeping reliable audit logs are particularly valuable here.

Encryption is not a substitute for good access control. If a compromised administrator account can access the encryption keys and delete backup copies, the organisation may still be unable to recover when it matters most.

Build a backup architecture that can withstand an incident

The familiar 3-2-1 principle remains a useful starting point: keep at least three copies of data, on two different types of storage, with one copy held off site. Many organisations now extend this approach by ensuring at least one copy is immutable or otherwise isolated from normal administrative access.

Immutability can prevent a backup from being amended or deleted for an agreed period. It is a strong defence against ransomware, but it needs careful configuration. Set retention too long and the organisation may retain personal data beyond its purpose. Set it too short and a sophisticated attack may go unnoticed until the protected copy has expired. The right period depends on detection capability, recovery needs and the data involved.

Cloud services also require scrutiny. Microsoft 365, for example, provides significant resilience, but that does not automatically meet every organisation’s requirements for point-in-time recovery, long-term retention or protection against accidental deletion. Understand what the service includes, what it does not, and where your responsibility begins.

If a third-party backup provider processes personal data on your behalf, carry out appropriate supplier checks. You should understand where data is stored, whether it leaves the UK, how it is encrypted, how support staff access it, what happens at contract end and what incident reporting commitments apply. A suitable data processing agreement should be in place.

Keep access tightly controlled

Backups are attractive to attackers because they may contain a broad snapshot of the organisation. Access should therefore be limited to named people who need it to perform their role. Use separate administrative accounts, multi-factor authentication and role-based permissions. Avoid using shared credentials, especially for backup consoles and storage platforms.

It is also sensible to separate backup administration from everyday domain administration where possible. That separation makes it harder for an attacker who compromises one privileged account to erase both production systems and recovery copies.

Review access when staff change role or leave. This routine task is easy to overlook, particularly where backup services have been added over time by different suppliers or internal teams.

Test recovery, not just backup completion

A green tick confirming a backup job has run is not proof that the business can recover. Files may be incomplete, applications may require a specific restoration order, and recovery credentials may be unavailable during an incident.

Testing should reflect realistic scenarios. Restore a sample of files regularly, but also test a full service recovery for critical systems. Check that applications open, permissions work and data is usable, not merely that it can be copied back to a server. Record the result, the time taken and any gaps found.

For organisations with a formal business continuity plan, backup testing should feed directly into it. A recovery exercise may reveal that a system can technically be restored within four hours but cannot be used until a third-party supplier is available. That is an operational dependency worth knowing before an incident.

Include backups in breach and incident plans

A ransomware event or unauthorised access to backup storage may be a personal data breach. Your incident plan should specify who assesses the impact, preserves evidence, contacts suppliers and decides whether notification to the Information Commissioner’s Office is required. Where reporting is necessary, the UK GDPR generally requires notification without undue delay and, where feasible, within 72 hours of becoming aware of the breach.

Do not rush to restore systems before establishing what happened. Restoring compromised data or reconnecting an affected environment too early can repeat the problem. Isolate the issue, assess the integrity of available recovery points and restore in a controlled order.

Make ownership visible

A backup policy is only useful when it describes real practice. It should identify system owners, backup frequency, retention periods, storage locations, recovery targets, access controls, testing schedules and escalation routes. Review it after major system changes, supplier changes or incidents.

CETSAT works with organisations that need backup and disaster recovery arrangements to support uptime, security and practical day-to-day operations. The most effective approach is usually right-sized rather than elaborate: clear recovery priorities, protected copies, controlled access and regular evidence that recovery works.

A well-managed backup is not a forgotten insurance policy. It is a tested operational capability that lets your organisation recover with confidence while treating personal data with the care it deserves.