Do you need to back up Microsoft 365, and what does it already keep

These are the platform defaults as Microsoft documents them, and each is worth confirming against your own tenant, because several are changeable. The 93 day figure is the one most often misread. A deleted file lands in the site recycle bin, and if someone empties that bin it moves to the site collection recycle bin. The second stage does not start a fresh 93 days.

It inherits whatever remains of the original clock, so a file deleted today is gone 93 days from today however many bins it passes through. Anything removed from the site collection recycle bin is hard deleted and no longer reachable by a user or an administrator. SharePoint also exposes APIs that skip the recycle bin and delete immediately, which matters for any script that tidies up content on your behalf.

The departed employee case is where the arithmetic bites. When an account is deleted from Microsoft Entra ID, the OneDrive is held for 30 days by default, a value the SharePoint admin centre accepts as anything from 30 to 3650 days. The deleted user also sits in the Microsoft 365 admin centre for 30 days, and the two run concurrently. When the OneDrive period expires the site moves to the site collection recycle bin for 93 days, restorable only by a SharePoint administrator working in PowerShell.

That is 123 days in total, which is why a departure discovered at month six has nothing left to recover on default settings. Notification goes to the manager on the account, or to the secondary owner set in the SharePoint admin centre where no manager is listed, with a reminder seven days before deletion. Where accounts carry neither, those warnings land nowhere.

Mail runs on shorter numbers than most people expect. When a user empties Deleted Items or presses shift and delete, the item moves to the Deletions subfolder of Recoverable Items for 14 days by default, configurable per mailbox to a maximum of 30. Single item recovery is enabled by default on new Exchange Online mailboxes, so an administrator can still retrieve an item the user purged within that window.

Two edge cases surprise people: calendar items are purged on a 120 day cycle, and a folder a user created and then shift deleted is hard deleted immediately and cannot be recovered even under litigation hold, although its contents do land in Deletions.

A Microsoft 365 retention policy keeps content that would otherwise be gone. When a user edits or deletes a covered item in SharePoint or OneDrive, a copy of the original as it stood when retention was applied goes to the Preservation Hold library and stays discoverable for the retention period.

That is a compliance control and it is not a restore capability. There is no user facing button and no helpdesk workflow. Pulling a document back out is a site collection administrator task, and what comes back is the retained copy, which may not be the version anyone wanted.

Retention also overrides the deletion timers above, which is the cheapest fix for the departure problem. Microsoft states that retention settings always take precedence over the standard OneDrive deletion process, so covered content can be held well past the 123 day ceiling. Precedence runs one way: retention beats deletion, and where several policies apply the longest period wins. Applying a policy to a leaver's OneDrive and mailbox for the period your obligations require costs a decision and an afternoon.

What a hold cannot reach is the detail that catches people out. Content sitting in a recycle bin is not indexed, so an eDiscovery search cannot find it and a hold cannot attach to it, and a matter that arrives after someone emptied a bin does not reach backwards. Litigation hold also requires an Exchange Online Plan 2 licence, and a Plan 1 mailbox needs a separate Exchange Online Archiving licence first.

Removing a licence disconnects the mailbox, starts a 30 day clock on the data, and makes it unsearchable by Content Search and eDiscovery straight away, so the hold has to go on before the licence comes off. Where the risk is a privileged account, Preservation Lock stops anyone, including a global administrator, from turning a retention policy off, deleting it or shortening it: locations can be added but never removed, the period extended but never reduced, and the lock cannot be undone.

Teams needs its own decision. Chat and channel messages live in hidden folders inside user and group mailboxes, but retention policies configured for Exchange mailboxes do not cover them; the Teams chats and Teams channel messages locations have to be selected explicitly.

A message a user deletes disappears from the app immediately but does not move into the hidden SubstrateHolds folder for 21 days, and Microsoft states plainly that what a user sees in the Teams app is not an accurate reflection of what has been retained or destroyed. A tenant that never configured Teams retention has a conversation record with different properties from its email.

Run your tenant through four cases and the decision usually makes itself. The first is ordinary accidental deletion, someone removing a file or a mail item and noticing within days. The platform handles this well, because the recycle bin, Recoverable Items and version history exist for exactly this. Most alarm about Microsoft 365 data loss quietly assumes this case fails, and for most tenants it does not.

The second is the departed employee, and it fails on discovery time. The content survives 123 days by default and the request to find it arrives at month six, when a client asks about a matter the leaver handled. Nothing in the platform will help at that point.

What works is retention applied to the accounts and locations that carry obligations, a hold placed before the account is deleted so the mailbox becomes an inactive mailbox, and a deleted user OneDrive retention raised above its default. Every one of those is a setting.

The third is an administrator with credentials, whether hostile, compromised or simply mistaken. A global or SharePoint administrator can empty a site collection recycle bin, delete a site, drop an unlocked retention policy, lower version limits and trim existing versions.

One privileged account can collapse several of these timers in an afternoon, and once the site collection recycle bin is emptied no customer restore path remains inside the platform. This is where Preservation Lock, a short administrator list and audit review earn their place, because the failure mode is not that Microsoft keeps too little but that one identity governs both the data and its protection.

The fourth is mass encryption of versioned files, where a compromised endpoint encrypts everything a sync client can reach and pushes the result to the cloud. Version history is the actual defence, and Files Restore is built directly on those versions.

The failure modes are specific: a version limit with an expiry period can leave a file nobody has edited recently with no versions to roll back to, the automatic setting thins older versions to weekly beyond 180 days, and the restore operates on one library or one account at a time. Recovering one infected user is quick, recovering a department account by account becomes a scheduling problem, and how long the business can wait is what decides it.

Recovery time is the variable most tenants have never measured. Restoring a few files from a recycle bin takes minutes. Restoring a deleted OneDrive after the first window has closed means a SharePoint administrator connecting the management shell, locating the deleted site, restoring it, then assigning themselves as site collection administrator to read the content, which is straightforward when rehearsed and slow when improvised.

Restoring a deleted group exposes an asymmetry Microsoft documents directly: the SharePoint site is retained for 93 days but the other group resources for only 30, so a late restore can return a site without the team, the plan or the shared mailbox around it.

Treating eDiscovery as a recovery path is a common mistake. It finds and exports content that retention has preserved, which is the right answer when someone needs evidence, but an export is not a working restore into the place the business needs the data, and re-importing one costs time and usually loses structure and metadata.

The measurement worth doing is small. Take the scenario most likely to happen to you, usually one user's OneDrive and mailbox, restore it end to end into a test location while somebody times it, then multiply by a realistic number of affected accounts and compare that against how long the business believes it can operate without the data.

None of these requires a new product, and all of them start by reading the current value. In a tenant that has run for years several will already differ from the documented default, which is the reason to look before changing anything.

Together they move a default tenant from roughly two weeks of mail protection and four months of file protection to windows matched to your obligations. Do them before you evaluate anything else, because each one changes what any further spending would need to add.

The case for a separate copy rests on two questions. How fast do you need to be back, and can the people who can destroy your data also destroy the copies? If your answer to the first is measured in hours across many accounts, the native tooling will struggle, because it restores one account or one library at a time. If your answer to the second is that a single compromised administrator holds both, everything you rely on lives inside the blast radius of one credential.

Microsoft now sells a first-party answer to the first question. Microsoft 365 Backup protects SharePoint sites, OneDrive accounts and Exchange Online mailboxes with a one year retention period, restore points every ten minutes for the previous two weeks and weekly back to 52 weeks for SharePoint and OneDrive, and ten minute points across the full year for Exchange.

It is billed by consumption and restores in bulk at rates the recycle bin and Files Restore path cannot approach. It answers the second question much less well, because the backups are created inside the Microsoft 365 service boundary, honour your existing data residency, and remain deletable by the backup administrator through product offboarding.

Obligations are the third input, and Australian ones routinely outrun the platform defaults. Financial records must be kept for seven years under the Corporations Act 2001, employee records carry a seven year requirement under the Fair Work framework, and Australian Privacy Principle 11 requires reasonable steps to protect personal information from misuse, interference and loss as well as from unauthorised access.

A window measured in days does not meet a requirement measured in years, and for that gap the answer is usually a retention policy, because what the obligation asks for is preservation and production.

A quieter licensing path to loss sits alongside it: deleting a user from Microsoft Entra ID makes their OneDrive unlicensed, an unlicensed account goes read-only on its 60th unlicensed day and is archived on its 93rd, and Microsoft's documentation states that after twelve months of unpaid archive storage the data may be deleted regardless of retention settings, policies or holds.

Plenty of Australian businesses reach a defensible position without a separate copy: extended windows, retention applied to what matters, a locked policy where an obligation demands it, a short administrator list and a rehearsed restore. Others cannot, usually because their recovery time requirement is short, their administrator population is large, or their regulator will ask a question that a shared responsibility diagram does not answer.

When we review a Microsoft 365 tenant we read what it is configured to do: the actual deleted item retention on mailboxes, the actual OneDrive retention value, which locations retention policies cover, whether Teams was ever included, which mailboxes the assigned licences permit you to hold, and who holds the roles that can purge content. That produces a list of timers specific to the tenant, and usually a short list of settings changes that closes most of the exposure without buying anything.

The rest is the part a note cannot do for you: timing one real restore, agreeing how long the business can be without each system, and deciding where a copy the tenant's own administrators cannot reach is warranted. That work sits inside vCISO advisory and incident response readiness, and it belongs alongside the identity and access decisions that determine who could destroy the data in the first place.