How long should business cloud backups be retained?

Business cloud backup retention is the period for which recoverable copies of data remain available after they are created. A suitable policy usually uses several retention tiers rather than one fixed period: recent backups support routine recovery, older copies help investigate corruption or undetected breaches, and selected records may need to be preserved for legal, regulatory or operational reasons.

The correct period depends on what the organisation may need to recover and how far back it may need to investigate an incident. A short retention window may be adequate for temporary file deletion, but it could be insufficient if data corruption is discovered weeks later or a ransomware infection has remained undetected. Retention should therefore be based on realistic recovery scenarios, not only on the storage capacity available.

When defining a policy, consider the following questions:

• How long might it take to discover accidental deletion, corruption or unauthorised changes?
• Which records must be retained to meet contractual, legal, regulatory or industry obligations?
• How far back might the organisation need to restore a file, database, virtual machine or complete system?
• Are there periods when data is particularly important, such as year-end, project completion or financial reporting?
• How much historical data can the business restore and review within its recovery procedures?
• Does the organisation have a documented deletion policy that applies to backup copies as well as live systems?

Retention is closely related to, but different from, recovery point and recovery time objectives. The recovery point objective describes how much recent data the business can afford to lose, while the recovery time objective describes how quickly systems need to be brought back into use. Retention answers a separate question: how far into the past the organisation must be able to recover. A business may require frequent recent backups for operational continuity while also keeping less frequent historical copies for investigation and record-keeping.

A practical approach is to create a retention schedule with clearly defined tiers. For example, recent restore points might be kept at a higher frequency, with older restore points consolidated or retained at wider intervals. Critical systems and important records may have a separate schedule from less important working data. The exact intervals should be agreed with the people responsible for operations, finance, compliance and information security rather than set solely by the IT function.

Data classification is useful when deciding which material needs extended retention. A temporary working document, a customer contract, payroll information and a production database may have different business and regulatory importance. Classifying data also helps prevent two common mistakes: retaining everything indefinitely without a clear purpose, or applying a short default period to records that require longer preservation.

Longer retention does not automatically make a backup policy stronger. Historical copies consume storage, increase the amount of data that must be protected and may create additional exposure if access controls are weak. Backup repositories should be protected against unauthorised access, and older copies should not be treated as harmless simply because they are no longer used operationally. Retention settings should also account for whether copies can be altered or deleted by an attacker with access to the backup environment.

Where an investigation, dispute, audit or legal matter is active, normal automated deletion should not remove relevant backup data. A documented legal hold or preservation process can suspend expiry for identified information. This process should record what is being preserved, who authorised it, the reason for the hold and when it should be reviewed. A hold should be removed when it is no longer required, so that obsolete data is not kept without a defined purpose.

Retention policies should also address data protection principles. Keeping personal data for longer than necessary can increase privacy and security risks, while deleting it too soon can prevent the organisation from meeting a legitimate obligation or recovering from an incident. The policy should explain the purpose of retention, the types of data covered, the responsible owner, the review process and how secure deletion is handled when the retention period ends.

Backup expiry should be tested rather than assumed. Administrators should confirm that restore points remain available for the intended period, that expiry behaves as documented, and that a copy subject to preservation is excluded from automated deletion. Restore testing should include both recent and older recovery points, because a policy may appear to work for routine recovery while failing when a historical copy is needed.

Retention should be reviewed after major changes to the business or its systems. New applications, acquisitions, regulatory requirements, changes in customer contracts, migration to cloud services and changes in the threat environment can all affect how long data must remain recoverable. The review should also consider whether the existing schedule is producing excessive storage, leaving gaps in historical coverage or retaining data that no longer has a valid purpose.

For most organisations, the final policy is a documented schedule linked to data classification and recovery requirements, supported by access controls, protected backup copies, legal-hold procedures and regular restore checks. This makes retention a controlled part of business continuity and information governance rather than an arbitrary setting in a cloud backup console.