Litigation hold is not a backup

A litigation hold is an instruction to preserve information that may be relevant to a legal matter — it suspends your normal deletion and retention rules so that evidence survives until the matter closes. In Microsoft 365, Google Workspace and Slack it is a real, built-in feature, and it works. What it is not, in any of them, is a backup. A hold freezes data in place inside the same tenant that holds your live data, under the same admin credentials, for the benefit of lawyers rather than operations. If you are counting a litigation hold as your recovery plan, Microsoft's own documentation disagrees with you — in writing.

What a litigation hold actually does

The mechanics differ by platform, but the shape is constant: when content is covered by a hold, a user deleting it does not make it go away. The deletion appears to succeed from the user's point of view, and a preserved copy is retained somewhere the user cannot reach, accessible to administrators and discovery tools.

That is a preservation guarantee, and it answers a legal question: can we produce this if we are asked? It does not answer the operational question: can we put this back where it was, at scale, quickly? Those two questions have different answers and need different tooling, which is the distinction this whole post turns on.

Microsoft 365: holds, Recoverable Items and inactive mailboxes

In Microsoft 365, Litigation Hold preserves mailbox content "including deleted items and original versions of modified items", holding them in the Recoverable Items folder. Microsoft now recommends Microsoft 365 retention policies over Litigation Hold for most preservation cases; In-Place Holds were retired for new use in Exchange Online as of 1 July 2020.

The most consequential behaviour concerns leavers. Microsoft's documentation sets out the default: "The employee's mailbox data is retained for 30 days after the account is removed. During this period, you can still recover the mailbox data by undeleting the account. After 30 days, the data is permanently removed." A hold changes that — but only if the sequencing is right: "if a hold is applied to the mailbox prior to deleting the Microsoft 365 account, the mailbox will be converted into an inactive mailbox."

Prior to. That ordering is the whole ball game, and Microsoft spells out the failure: "To prevent accidental or unintentional deletion, we recommend you confirm the hold before you delete the user account. If the hold isn't applied, the mailbox won't be converted into an inactive mailbox." Offboard someone on a Friday, apply the hold on Monday, and there is no hold to apply to.

Then there is the sentence that should end the backup conversation outright. Describing recovery from an inactive mailbox with an auto-expanding archive, Microsoft writes that it "can't be recovered or restored", that you should use content search to export the data instead, and that this "is supported for eDiscovery purposes only, and can't be used as a backup solution." That is not a competitor's marketing claim. It is the platform vendor telling you what the feature is for.

One more trap: holds attached to an eDiscovery case are tied to the life of the case. Microsoft warns that if such a hold "is released or the eDiscovery case is closed (or deleted), the inactive mailbox is permanently deleted." Closing a matter can destroy the data you were preserving.

Google Workspace: Vault holds and the licence dependency

Google Vault behaves the same way in principle and has a sharper edge in practice. Google states that "Holds override retention rules, so data on hold is protected from your normal data governance rules that might purge it otherwise", and describes the user-facing experience precisely: "When a message that's on hold is deleted by a user, the user can't access the message anymore but the message isn't purged."

The edge is what the hold depends on. If an administrator removes a user's Vault-supporting licence, holds stop protecting that user's data — and Google is blunt about the consequence: "Data marked for deletion can be immediately purged and can't be restored."

So in Google Workspace the preservation guarantee is downstream of a licence assignment. A routine cost-saving exercise, a reclaimed licence during offboarding, or a billing change can revoke it without anyone touching Vault. This is the same identity-shaped failure that governs Google Workspace email backup generally: the protection follows the account, and the account is an administrative object someone can change.

Slack: legal holds and the deleted-channel gap

Slack legal holds are available on Enterprise plans and managed by a dedicated Legal Holds Admin role. With a hold in place, Slack preserves "messages and files sent by all members in a conversation ... regardless of retention settings or if members edit or delete any content" — a strong guarantee, because it survives both the retention policy and deliberate user deletion. A hold can cover up to 1,000 custodians, and preserved data is reached through a JSON export or the Discovery API.

Note that access path. Even when Slack preserves the data perfectly, what you get back is an export — which is a file to search, not a restored workspace. That is the same limitation covered in detail in our Slack export post.

And there is a documented gap that deserves to be on anyone's risk register: "If a channel included in hold is deleted, message and file data won't be saved." The hold is scoped to custodians and conversations; delete the container and the preservation does not follow.

Atlassian Cloud: no equivalent at all

Jira and Confluence Cloud have no native legal-hold feature comparable to the other three. Legal discovery capability has been an open feature request on Atlassian's public tracker (CONFCLOUD-9985), and teams needing it fall back on permission restrictions, manual exports, or Marketplace apps. If your matter touches engineering records — tickets, specs, decision pages — the preservation story is whatever you have built, not something the platform provides.

Where holds and backups pull in opposite directions

The sharpest reason not to conflate the two is that they can be in genuine conflict.

GDPR gives individuals a right to erasure, and that right is not absolute. Article 17(3)(e) disapplies it where processing is necessary "for the establishment, exercise or defence of legal claims" — which is exactly what a litigation hold is for. So a hold can be the lawful basis for refusing to delete data that someone has asked you to delete.

A backup copy sitting outside that framework has no such protection, which is why the two need to be designed together rather than discovered separately during an incident:

• A hold without a backup leaves you able to produce evidence and unable to resume operations. You can prove what a deleted project plan said; you cannot put it back.
• A backup without hold-awareness can quietly re-create data you were legally obliged to erase, or expire a copy that was supposed to be frozen.
• Both, uncoordinated, is the common state, and the one that produces contradictory answers to a regulator.

The practical requirement is that retention schedules, holds and backup retention are one design decision, documented together. Our GDPR SaaS backup requirements post covers the retention side of that in more depth, and SaaS data protection covers how preservation controls fit alongside recovery ones.

What to put in place

A short, uncomfortable set of questions to take to your next review:

1. Can you name who applies a hold, and how fast? In Microsoft 365 the hold must exist before the account is deleted. In Slack it needs a Legal Holds Admin.
2. Does your offboarding process check for holds before removing licences? Google Vault holds die with the licence; M365 inactive mailboxes never form if the hold is late.
3. If a matter closes, what gets destroyed? Releasing an eDiscovery hold can permanently delete an inactive mailbox.
4. Can you restore, as distinct from produce? If the only answer is "export and search", you have discovery, not recovery.
5. Does anything cover Atlassian? Usually nothing does.

A litigation hold protects the business from a legal failure. An independent backup protects it from an operational one — accidental deletion, a departing employee, a compromised admin account, ransomware. Neither substitutes for the other, and the platforms are candid about which job they are doing. We help you work out which backup approach fits your stack and get it deployed so that the recovery half is covered properly.

Take the free backup assessment and we will map where your holds end and your recovery gaps begin, across Microsoft 365, Google Workspace, Slack and Atlassian.