How long should business backup data be retained?

A backup retention policy defines how long each recoverable copy of business data is kept before it is automatically removed or replaced. The appropriate period depends on the data’s business importance, the consequences of losing or altering it, applicable contractual or regulatory duties, and how far back the organisation may need to investigate an incident.

There is no universally correct retention period. Keeping every backup indefinitely can increase storage costs, complicate management and retain personal or confidential information longer than necessary. Retaining copies for too short a period can leave the organisation unable to recover from a problem that is discovered late, such as a gradual data corruption issue or malware infection that remained unnoticed for several weeks.

Assess retention by data category. A policy should distinguish between information with different operational and legal characteristics. Factors to consider include:

• How long the information remains relevant to the organisation’s work.
• Whether it supports contractual, financial, employment or regulatory records.
• How likely it is that an issue will be detected only after a delay.
• Whether the data can be recreated from another source.
• The sensitivity of the information and the risks created by retaining it.
• Whether the organisation operates in a sector with specific record-keeping requirements.

Retention should also reflect the difference between operational recovery and historical reference. A business may need recent copies to restore files or systems after an accidental deletion, while older copies may be needed to establish what information existed at a particular point in time. These purposes should be documented separately so that a short-term recovery requirement does not accidentally determine the treatment of every backup copy.

Use a defined retention schedule. The schedule should state which data or systems it covers, the types of recovery point that are retained, the minimum retention period, the person responsible for approving changes and the event that permits deletion. It should also explain what happens when a copy reaches the end of its period, including whether it is securely deleted, overwritten or transferred into a separate archive.

Retention rules must account for delayed discovery. For example, if an organisation could continue creating backups after an unnoticed corruption event, retaining only the newest copies could remove the last usable version. The schedule should therefore preserve enough historical depth to identify and recover a point from before the suspected problem. The required depth will vary according to the system, the rate at which data changes and the time it may take to identify an issue.

Separate backup retention from archiving. Backups are primarily intended to restore data after loss, damage or disruption. An archive is normally controlled for longer-term reference, legal, historical or operational purposes. If a business must preserve a record for a defined period, that requirement should not be left to an ordinary backup cycle. Archived information needs its own ownership, access controls, search arrangements, preservation rules and disposal process.

Legal disputes, investigations, audits or formal preservation instructions may require normal deletion to be suspended for specific information. A documented legal hold process should identify the affected data, record who authorised the hold, prevent relevant copies from expiring and define how the hold is released. A backup policy should not permit automatic deletion to undermine such an instruction.

Personal data requires particular care. The organisation should be able to explain why information remains in backup storage and how retention aligns with its wider data protection practices. Backup copies can be difficult to amend or delete individually, so the policy should document how deletion requests, data minimisation requirements and the eventual expiry of copies are handled in the backup platform.

Retention settings should be reviewed whenever there is a significant change to the organisation’s systems, contracts, regulatory obligations, data types or risk profile. They should also be checked after a recovery exercise or real incident, because the exercise may show that older recovery points are needed, that certain systems require different treatment or that the existing schedule is unnecessarily complex.

A practical review should confirm that:

• Every important system and data set has an identified retention rule.
• The policy distinguishes recovery copies from records kept for longer-term reference.
• Retention periods have an identified business, legal, contractual or risk-based rationale.
• Expiry and deletion processes are understood and documented.
• Legal holds and investigations can override routine expiry where necessary.
• Changes to retention settings are authorised and recorded.
• Recovery testing includes sufficiently old copies to demonstrate that the policy works in practice.

The result should be a retention policy that is long enough to support realistic recovery and investigation needs, but not so broad that the organisation keeps all information without a defined purpose. It should be approved by the relevant business, legal, compliance and IT stakeholders, then translated into backup configuration and reviewed as the organisation changes.