Backing up Microsoft 365: retention is not backup, and restores must be tested

Shared responsibility

Microsoft replicates data across datacentres and protects the infrastructure against hardware failures and disasters. However, if a user, an administrator or an attacker with legitimate permissions deletes or encrypts data, the service faithfully carries out the instruction it received. Protecting against those scenarios is the customer's responsibility, as the service terms make clear. You therefore need to distinguish service availability, which Microsoft provides, from data recoverability, which is yours.

Why retention is not backup

Recycle bins, recoverable items, file versions, retention policies, litigation hold: these mechanisms are useful and should be configured. But they have structural limits:

• they live in the same tenant, under the same administrative plane; a compromised administrator can often change or disable them;
• they are designed for compliance and search, not for quickly restoring a previous state at scale;
• their time windows are limited, and a deletion discovered late may be permanent;
• they cover the tenant's own configuration poorly.

Scenarios to cover

The design must start from concrete scenarios, each with a recovery time objective:

1. One-off mistake: a user deletes a folder or a shared mailbox is emptied by accident.
2. Ransomware on endpoints: files synchronised with OneDrive are encrypted and the encrypted version reaches the cloud. Restoring OneDrive to an earlier date covers part of the need, one user at a time.
3. Targeted destruction by an attacker: sites, mailboxes or Teams deleted from a compromised admin account, after retention policies have been changed.
4. Tenant-wide compromise: loss of control over privileged accounts; data must then be restored into an environment the attacker does not control.
5. Loss of configuration: Conditional Access policies, Intune settings, applications, groups; often missing from backup plans.

Microsoft 365 Backup or a third-party tool

Microsoft 365 Backup is a pay-as-you-go Microsoft service that protects Exchange, OneDrive and SharePoint with frequent restore points and fast, large-scale restores. Its strengths are restore performance and native integration. Its main limit is that backups remain within the Microsoft ecosystem and are administered from the tenant: their protection therefore depends on the protection of the roles that manage them.

Third-party tools usually store copies outside the tenant, sometimes immutably, with separate administration. Some build on the Microsoft 365 Backup interfaces. They sometimes cover additional items, such as Teams or part of the Entra ID configuration. The scope of each offering changes: check precisely what is and is not covered, item by item.

Whatever the choice, backup administration must be isolated: dedicated accounts, phishing-resistant MFA, no dependency on a Global Administrator of the protected tenant, and alerts on any backup deletion or retention change.

Testing restores

A backup that has never been restored is an assumption. Tests should cover the chosen scenarios: restoring an item, a full mailbox, an entire site, and measuring the time required for a realistic volume. The results let you compare recovery objectives with actual capabilities and adjust before an incident.

What an audit checks

• Documented loss scenarios and their recovery objectives.
• Configuration of native mechanisms: retention, recoverable items, versioning.
• The actual scope of the backup solution, service by service.
• Isolation of backup administration from the tenant.
• Backup of tenant and Entra ID configuration.
• Reports from the most recent restore tests.