The Microsoft 365 Data Your Legal Hold Does Not Reach

Federal Rule of Civil Procedure 37(e) does not ask whether you had a backup. It asks whether you took reasonable steps to preserve electronically stored information once litigation was reasonably anticipated, and it lets a court impose sanctions — up to an adverse-inference instruction — when ESI that should have been preserved is lost because you did not. The operative words are "reasonable steps" and "ESI," and both are broader than the average Microsoft 365 hold assumes.

A Microsoft 365 litigation hold, or a retention policy, preserves mailboxes and — with the appropriate license — SharePoint and OneDrive. That is the load-bearing part of most matters. But the same tenant carries a long tail of ESI that lives behind different Graph APIs and outside the mailbox hold, and it is exactly the tail that surfaces late in discovery, when a custodian mentions a Teams chat or a Planner board that nobody preserved.

What a mailbox hold does not include

Calendars, contacts, and the in-place archive. A recurring meeting series, a delegated calendar, and the online archive that holds years of moved mail are distinct Exchange resources. They are ESI, and a hold scoped to inbox mail can miss them.

Teams chats. Channel messages are covered by Teams retention; the 1:1, group, and meeting chats where the substance of a matter often lives sit behind a different API and different permissions. A backup that captures channels but not chats leaves the most-cited Teams evidence unpreserved.

Microsoft 365 Groups conversations and Planner. The group mailbox thread and the Planner board attached to a Team are work product that disappears when the Group is deleted — and a departing-employee cleanup is a common way for that to happen after a hold should already be in force.

SharePoint lists, pages, and version history. The registers and trackers teams build as SharePoint lists, and the prior version of an overwritten file, are ESI that a document-library-only view does not enumerate.

Why the gap becomes a sanctions question

The native recycle bins in Microsoft 365 are operational conveniences with short, fixed windows measured in days, not a preservation mechanism. Once a deletion ages past that window, or a licensed user is removed, the only surviving copy is whatever an independent backup captured. If that backup did not reach the workload in question, the ESI is gone — and under Rule 37(e)(2) a court can treat an intentional failure to preserve as grounds for the harshest instructions.

The defensible posture is not "we had Microsoft 365." It is a demonstrable, item-addressable copy of the full tenant — every workload — held outside Microsoft's deletion windows, with a record that shows what was captured and when.

How the coverage is captured

Every workload is read through Microsoft Graph after a one-time admin-consent connection — no agent, no stored password. After the first baseline, each syncs by delta, and the cursor is persisted, so throttling pauses the stream rather than restarting it. Each item — a calendar event, a chat message, a list row — is deduplicated in a content-addressable store, encrypted with the tenant's own key, and recorded on a tamper-evident, hash-chained audit ledger. Item-level addressability is what lets a single message be produced without an all-or-nothing restore, and the audit chain is what lets the production carry a chain of custody.

The point

Reasonable steps to preserve ESI means preserving the ESI, not the subset that happens to be easy to read. The difference between a mailbox hold and defensible preservation is measured in the workloads a hold does not reach — and in whether your backup is honest about the few it genuinely cannot.