Backing up Microsoft 365: what Microsoft does and doesn't do

Microsoft runs the infrastructure: data centres, replication between them, hardware failures and service availability. That protects you from Microsoft losing your data. It does not protect you from your own users, admins or attackers deleting, encrypting or overwriting it with valid credentials, because to the service those are legitimate actions.

Microsoft's own Services Agreement recommends that customers regularly back up their content and data, and notes that in an outage you may not be able to retrieve it. That sentence is the clearest statement of the shared responsibility model you will find.

The built-in features are useful but they are not a backup. Each has a time limit and a gap.

You need a real backup when you must restore at scale, from a known point in time, after the built-in windows have passed, or when the tenant itself is compromised. Two routes exist.

Microsoft 365 Backup is Microsoft's own product. It protects SharePoint sites, OneDrive accounts and Exchange mailboxes with restore points, and can roll a site or OneDrive back to an earlier state. Its advantage is speed and tight integration. Its limitation is that the backup lives inside the same Microsoft cloud and is administered from the same tenant.

Third-party backup products copy data to separate storage, often with a separate login. That independence matters if an attacker gains Global Administrator rights. Choose based on restore speed, scope (Teams, Planner, Entra ID objects, Intune configuration), retention length, data residency in Canada, and who can delete backups.

• Exchange Online mailboxes, including shared mailboxes and archive mailboxes.
• OneDrive accounts, especially for leadership and anyone handling client files.
• SharePoint sites and Teams-connected sites (Teams files live in SharePoint).
• Teams chat and channel messages if your backup supports them; many firms rely on retention for these instead.
• Configuration: Conditional Access, Intune policies, Entra ID groups and app registrations. Losing these after a compromise is slow and painful to rebuild by hand.
• Data outside Microsoft 365 that the business depends on: line-of-business databases, accounting systems, file servers.

A backup you have not restored from is a hope, not a control. Test these at least once a year and write down how long each took.

1. 01

   Single file, last week

   A user overwrote a spreadsheet. Restore one version without disturbing others.

2. 02

   Leaver's mailbox, six months later

   A dispute arises about a former employee. Find and export their mail.

3. 03

   Whole site after mass deletion

   A sync client or script deleted a client folder tree. Roll the site back to yesterday.

4. 04

   Ransomware-encrypted OneDrive

   Thousands of files encrypted and synced. Restore to the last clean point and confirm nothing malicious came back.

5. 05

   Tenant-level compromise

   Assume an attacker had admin rights. Can you still reach your backups with a separate login?

The Canadian Centre for Cyber Security's Ransomware playbook (ITSM.00.099) warns that attackers who gain control will try to delete connected backups before they encrypt, and describes online and offline backup options. Apply the same thinking to cloud data.

Protect backup administration with phishing-resistant MFA and accounts that are not used for daily work. Turn on immutability or deletion protection where your product offers it. Keep at least one copy that a compromised Microsoft 365 admin cannot delete. And before restoring after an incident, preserve evidence: a forensic investigation may need the encrypted files, logs and attacker artifacts that a hasty restore would overwrite.