The Hold That Never Lifted: Auditing eDiscovery Preservation That Outlived Its Case

Why a closed case is not a lifted hold

In Microsoft 365, an eDiscovery hold is a preservation instruction attached to a case. The case is the container; the hold is the mechanism. Closing or archiving the case does not, by itself, release anything. Microsoft’s documentation is explicit: content placed on hold is preserved “until you remove the content location from the hold or until you delete or release the hold” (Create holds in eDiscovery). The preservation state lives on the mailbox or site, not in the case file.

That distinction is where most stale-hold problems begin. A matter settles, the case is closed in the legal team’s tracker, and everyone assumes preservation has ended. Meanwhile the hold policy is still On, the mailbox is still accumulating content in Recoverable Items, and the SharePoint site is still writing deleted documents into the Preservation Hold Library. Nothing in the case closure event reaches into those locations and turns preservation off.

The practical consequence: “the hold lifted” should be defined as a per-location, all-sources-cleared state. Case closure is one input to that determination, not the determination itself.

The preservation stack has several independent sources

Before auditing anything, it helps to name the moving parts. Microsoft’s own guidance states that eDiscovery hold policies are only one of several hold sources: “Microsoft Purview retention policies, retention labels, Litigation Hold, delay holds, and Single Item Recovery can independently preserve content, and any one of them is enough to keep items in the Recoverable Items folder or in the Preservation Hold Library” (Manage holds in eDiscovery).

Define the terms plainly:

• eDiscovery hold — a hold policy created inside a case, scoped to mailboxes, sites, or both, with optional query and date filters.
• Retention policy — a Purview policy that retains or deletes content on a schedule, independent of any case.
• Retention label — a label applied to individual items that can declare them records or regulate their disposal.
• Litigation Hold — the older mailbox-level flag (LitigationHoldEnabled) that preserves all mailbox content indefinitely.
• Delay hold — a temporary preservation state applied automatically after a hold is removed.
• Single Item Recovery — a mailbox setting that keeps deleted items in Recoverable Items for a configured period.

Each of these is a separate switch. Turning off one does not turn off the others. An audit that checks only the case hold will report a location as released while three other sources are still preserving it.

Export first, change nothing

The cheapest defensible audit is an export-first one. Before releasing anything, capture the current state so the pre-closure condition is itself a record. Two artifacts do most of the work:

1. The hold policy list. On the Hold policies dashboard inside a case, Microsoft provides a Download list control that creates a .csv file of the hold policies and their column information (Manage holds in eDiscovery). Export this for every case that is closed or closing.
2. The per-location hold status. The Details tab of each hold policy shows, per data source, the location, hold status, source type, and location type. Capture this view — screenshot or export — before any change.

These two artifacts answer the first audit question: which holds are still On, and which locations do they cover? They do not answer the second question — whether any other source is also preserving the same location. For that, you need the mailbox and site hold inventory.

Reading the InPlaceHolds prefixes as a hold-source map

Exchange Online exposes a property called InPlaceHolds on each mailbox. It is a list of identifiers, each prefixed with a short code that tells you which kind of hold is responsible. Microsoft documents the mapping in the manage-holds page, and it is the single most useful diagnostic in this audit:

Source: Manage holds in eDiscovery.

The prefixes matter because they tell you who owns the release. A UniH entry is cleared by turning off or deleting the hold policy in the case. An mbx entry is cleared by excluding the mailbox from a retention policy — a different team, a different portal, a different change-control path. Conflating the two produces one of two failure modes: a phantom hold that nobody can find because the case is closed, or a premature release because someone turned off the case hold and assumed the mailbox was now unprotected.

To enumerate the hold sources on a mailbox, Microsoft’s guidance lists a sequence of cmdlets in Exchange Online PowerShell. The first is Invoke-HoldRemovalAssistant -Identity <user>, described as surfacing “all applicable hold sources in a single call” and recommended as the first step. It is followed by Get-OrganizationConfig | FL InPlaceHolds for tenant-wide and organization-scoped policies, Get-Mailbox <user> | FL LitigationHoldEnabled,InPlaceHolds,ComplianceTagHoldApplied,SingleItemRecoveryEnabled for mailbox-scoped holds, and Get-Mailbox <user> | FL DelayHoldApplied,DelayReleaseHoldApplied for delay holds (Manage holds in eDiscovery).

For SharePoint and OneDrive sites, the equivalent sequence is Invoke-HoldRemovalAssistant -Identity <siteUrl-or-userUPN>, then Get-OrganizationConfig | FL InPlaceHolds, then Get-RetentionCompliancePolicy | Where-Object { $_.SharePointLocation -or $_.OneDriveLocation } to list retention policies targeting sites or OneDrive accounts.

Export the output of each command to a dated file. That file is the evidence that the audit was performed against the actual state, not against a tracker.

The delay-hold trap

Removing a hold is not the same as releasing preservation. Microsoft documents that “a delay hold is automatically applied after a hold is removed and preserves items for up to 30 days” (Manage holds in eDiscovery). The flags to check are DelayHoldApplied and DelayReleaseHoldApplied.

This has two consequences for the audit. First, a location that has had its case hold turned off will still show as preserved for up to 30 days. A closure checklist that stops at “hold turned off” will misreport the location as unprotected when it is still preserving. Second, when the delay expires, the location becomes genuinely unprotected — and if the audit was never re-run, nobody notices the transition. The delay hold is a tail, and the audit has to cover the tail.

The same page also warns against a common shortcut: “LitigationHoldEnabled is False, so the mailbox isn’t on hold” is described as insufficient. The check must also include InPlaceHolds, ComplianceTagHoldApplied, DelayHoldApplied, DelayReleaseHoldApplied, and the organization-level InPlaceHolds output.

Identity drift: the hold that silently stopped covering

A hold is applied to a location identified by a UPN or a site URL. If that identifier changes — a user is renamed, a site is moved, a tenant domain changes — the hold does not automatically follow. Microsoft states that “eDiscovery doesn’t continuously monitor workload or location-level changes after a hold operation completes” and that if mailbox or site identities change, the hold policy data sources must be updated and the hold reapplied to restamp the policy (Manage holds in eDiscovery).

The failure mode is quiet. The hold policy still shows as On. The case is still open. But the location it was meant to cover is no longer matched, and content is no longer being preserved. The audit has to include a restamp step — edit the hold policy data sources, select Apply hold or Policy actions > Retry policy — and a post-restamp status check to confirm the location is actually on hold.

The same page lists the error states that surface when a location cannot be held: Invalid email address or URL, Mailbox not found, Site not found, Site failed to apply hold, and Hold changed outside eDiscovery. Each of these is a signal that the hold is not doing what the case file says it is doing.

Query-based hold residue

Query-based holds preserve only content that matches a search query. That sounds narrow, but the mechanics leave residue in both directions.

Microsoft documents that when a query-based hold is created, “all content from selected locations is initially placed on hold” and then “any content that doesn’t match the specified query is cleared from the hold every seven to 14 days” (Create eDiscovery holds in an eDiscovery case). The clear is not immediate. It is also conditional: the same page states that a query-based hold “won’t clear content if more than five holds of any type are applied to a content location, or if any item has indexing issues.”

For SharePoint sites, the residue is more visible. Deleted documents move to the Preservation Hold Library even if they do not match the query, and a timer job later compares the library against the hold and removes non-matching items. Until that job runs, the library contains content the hold was never meant to preserve.

The audit implication: “the query was narrow” is not evidence that the location is clean. The Preservation Hold Library has to be inspected directly, and the hold count on the location has to be checked, because more than five holds will block the clear.

Group membership is a snapshot, not a subscription

When a hold is scoped to a distribution list, mail-enabled security group, Microsoft 365 group, Teams group, or Viva Engage group, membership is captured at the moment the policy is created. Microsoft states that “members added to the group later are not automatically placed on hold; members removed from the group remain on hold until you update or release the policy” (Create holds in eDiscovery).

This produces two stale-hold patterns. A person who left the group years ago may still be on hold because the policy was never updated. A person who joined after the hold was created may not be on hold at all, even though the case file says the group is covered. Both are audit findings, and both are resolved by re-adding the group as a data source and reapplying the hold — not by assuming the group membership is current.

A lightweight closure checklist

The following procedure is reversible and anchored to exportable artifacts. It is a recommendation, not a documented Microsoft procedure; the individual commands and portal actions it references are documented at the links above.

1. Export the hold policy list for every closed or closing case. Save the .csv with a dated filename.
2. Export the per-location hold status from the Details tab of each hold policy. This is the pre-release baseline.
3. Run the hold-source enumeration for each location named in those holds: Invoke-HoldRemovalAssistant, organization-level InPlaceHolds, mailbox-level InPlaceHolds, ComplianceTagHoldApplied, SingleItemRecoveryEnabled, DelayHoldApplied, DelayReleaseHoldApplied. Save the output.
4. Map each hold source to its owner using the prefix table. A UniH entry goes to the case owner; an mbx entry goes to the retention policy owner; a grp entry goes to the group policy owner.
5. Check for identity drift. Compare the UPNs and site URLs in the hold policy against the current directory. If they differ, restamp the policy and re-check status.
6. Release the case hold only after steps 1–5 are complete and the other hold sources have been dispositioned by their owners.
7. Re-run the enumeration after release and record the delay-hold state. Note the date on which the delay hold is expected to expire.
8. Re-run the enumeration again after the delay hold expires to confirm the location is genuinely unprotected.
9. File the closure packet: the exported hold inventory, the per-location status before and after release, the list of cleared sources with the command or portal action used, and a dated note of when disposition authority resumes.

The packet is the reversible part. If a hold was released in error, the packet shows exactly which source was cleared, by whom, and when — which is the information needed to reapply it.

What resumes when the hold lifts

Releasing a legal hold does not mean content is deleted. It means the preservation override is removed and the location returns to whatever disposition schedule governs it. The FDA’s legal hold policy states the principle plainly: “When a legal hold has been lifted, normal disposition schedules and disposal practices applying to impacted records and information may resume” (FDA Legal Hold Policy, SMG 3205.1).

For federal agencies, the governing schedule is usually a General Records Schedule. NARA states that “use of the GRS is mandatory” and that agencies must use the GRS unless they can justify an agency-specific schedule (What are the General Records Schedules). The closure packet should name the schedule that applies to the location, because “retention resumes normally” is not a statement about anything in particular until the schedule is identified.

NARA’s FERMI use cases treat the lift as a distinct records-management event, not an afterthought: ERM.020.L1.05 — Lift hold on electronic records identified by scope determination (NARA FERMI Use Cases for Maintenance and Use). The scope determination is the audit. The lift is the action that follows it.

Frequently asked questions

Does closing an eDiscovery case release its holds?

No. Content is preserved until the location is removed from the hold or the hold is deleted or released (Create holds in eDiscovery). Case closure is a separate event from hold release.

Why does a mailbox still show as on hold after the case hold was turned off?

Because another hold source is still active. Check InPlaceHolds for mbx, skp, or grp prefixes, and check DelayHoldApplied and DelayReleaseHoldApplied. A delay hold is applied automatically after a hold is removed and preserves items for up to 30 days (Manage holds in eDiscovery).

Can a hold stop covering a mailbox without anyone noticing?

Yes. eDiscovery does not continuously monitor location-level changes. If a UPN or site URL changes, the hold policy data sources must be updated and the hold reapplied (Manage holds in eDiscovery).

Why is there content in the Preservation Hold Library that does not match the hold query?

Query-based holds initially preserve all content from the selected locations, then clear non-matching content every seven to 14 days. The clear is blocked if more than five holds apply to the location or if items have indexing issues (Create eDiscovery holds in an eDiscovery case).

What should be in the closure packet?

The exported hold policy list, the per-location hold status before and after release, the hold-source enumeration output, the list of cleared sources with the action used, and a dated note naming the disposition schedule that resumes. The packet is the evidence that the release was deliberate and reversible.