How long should Microsoft 365 Backup data be retained?

Microsoft 365 Backup data should be retained for the period required to recover from operational incidents, meet documented record-keeping obligations and support legitimate investigations. In practice, this means setting different retention rules for recent recovery points, longer-term records and data subject to a legal or regulatory hold, rather than applying one expiry date to every backup.

Start with the business record, not the backup product. Identify which Microsoft 365 data the organisation must be able to recover and the point in time to which it may need to return. A recent recovery point may be sufficient for accidental deletion or a configuration error, while older copies may be needed to investigate a dispute, reconstruct a transaction or establish what information existed at a particular date.

A retention policy should document:

• the types of data covered, such as mailboxes, files, collaboration content and user records;
• the minimum period for which recoverable copies are maintained;
• which recovery points are kept more frequently and which are retained for longer;
• the event that starts the retention period, such as creation, deletion, contract completion or the end of an accounting period;
• who can approve exceptions, extensions and permanent deletion; and
• how expired data is identified, deleted and recorded.

Use a tiered retention model. Many organisations retain a detailed set of recent recovery points to deal with day-to-day incidents, then preserve less frequent points for a longer period. This avoids treating every backup copy as a permanent archive while still providing historical coverage. The exact periods should come from the organisation’s risk assessment and records schedule, not from an assumed industry standard.

Retention should also be aligned with recovery objectives. Recovery point objectives determine how much recent data the organisation can afford to lose, while recovery time objectives determine how quickly systems and information need to be restored. These objectives influence how many recent copies are useful, but they do not by themselves determine how long older copies should remain available. A business may need frequent short-term recovery points and a separate long-term policy for records that must be preserved.

Consider legal and regulatory requirements carefully. Some records may have prescribed retention periods, contractual obligations or sector-specific requirements. Others may be subject to a litigation hold, investigation or access request. A backup policy must not silently delete data that has been placed on hold. Conversely, keeping every backup indefinitely can conflict with data minimisation principles, increase exposure of personal information and make it harder to identify which copy is authoritative.

Under UK data protection principles, retaining personal data for longer than necessary should be justified and controlled. Backup copies are still part of the organisation’s information estate, even when they are not used for routine business activity. The retention schedule should therefore explain why a period is necessary, distinguish backup data from active records, and define how expired copies are removed or rendered inaccessible.

Handle leavers and deleted information explicitly. Removing a user’s licence or account does not necessarily answer how long their backed-up data should remain. The organisation should decide whether the data belongs to a continuing business record, is needed for handover or investigation, or can be disposed of after the relevant retention period. The same principle applies to deleted files, shared mailboxes and data from projects that have ended.

Retention controls should account for backup-chain behaviour. Depending on the backup design, deleting one visible recovery point may not immediately remove all underlying data if other recovery points still depend on it. Policies should therefore describe expiry in terms of recoverability and confirmed disposal, rather than assuming that deleting a single entry removes every associated copy.

Separate retention from preservation. A normal retention schedule allows data to expire according to approved rules. A preservation hold temporarily overrides that schedule for specific information. Holds should have a named owner, a clear scope, a reason for being applied and a review or release process. When the hold ends, the ordinary retention rule should resume rather than leaving the data indefinitely protected from deletion.

A practical review should involve IT, information governance, legal or compliance teams and relevant business owners. Review the policy when the organisation enters a regulated market, changes its Microsoft 365 use, introduces new data types, changes contractual obligations or experiences an incident that exposes a gap in historical recovery. The result should be a written retention schedule that is technically configured, authorised by the business and periodically checked against actual backup behaviour.