How to Restore a File From SharePoint DLP Quarantine

A file that vanishes from a document library and leaves behind a placeholder with a name like "File removed due to a policy violation" has almost certainly been caught by a Microsoft Purview Data Loss Prevention rule using the File Quarantine action. This guide covers the full restore path: confirming what happened, getting the right sign-off, releasing the file, and making sure it doesn't immediately land back in quarantine.

What DLP File Quarantine actually does

When a DLP policy configured with the quarantine action matches a file in SharePoint Online or OneDrive for Business, the file is moved out of its library and into an admin-controlled quarantine site. A tombstone, a small placeholder file, is left behind in the original location so users understand the file was removed rather than simply deleted or corrupted. The real file, including its version history up to that point, sits in the quarantine site until an administrator takes action.

This is a deliberate design choice on Microsoft's part. Quarantine is meant to be reversible. Unlike a hard delete, nothing about the file is destroyed; it is relocated and access is restricted until someone with the right permissions reviews it.

Quarantine differs from the older, blunter approach of simply blocking a whole library's external sharing until an administrator manually intervenes. Because the action operates at the file level, everything else in the library, and every other user's work, keeps functioning normally while the one flagged item sits in review. That precision is useful for admins, but it also means quarantine incidents can look very small from the security team's side while feeling disruptive to the one team whose file just vanished. Managing that gap in perception is as much a part of the response as the technical steps.

It's also worth knowing where the quarantine action fits in a Purview DLP policy compared with softer alternatives. Many organisations start with a policy that only notifies a compliance reviewer when it detects sensitive content, without touching the file. Quarantine is the next step up: instead of a passive notification, the file is actively removed from circulation until it's reviewed. Teams that adopt quarantine for the first time often underestimate how quickly a single misconfigured or overly broad rule can generate a wave of false positives across a busy library, which is why the review and remediation steps below matter as much as the mechanics of the release itself.

Step 1: Confirm it's quarantine, not a permissions issue

Before assuming DLP is involved, rule out the more common explanation: a permissions change or a sync conflict. The tombstone placeholder is the clearest signal. If users report a file is "missing" but no placeholder exists in its place, check permissions and the site's recycle bin first using a standard file recovery walkthrough before assuming quarantine.

What the tombstone tells you

Opening the tombstone typically shows a short message identifying that a data loss prevention policy affected the file, sometimes with a case or alert reference number. That reference is what you'll look up in the next step.

Step 2: Find the matching alert in Purview

1. Sign in to the Microsoft Purview compliance portal with an account that has DLP alert access.
2. Go to Data Loss Prevention, then Alerts.
3. Filter by the affected site or search for the file name if it's still indexed in the alert metadata.
4. Open the matching alert and note the policy name, the sensitive information type detected, and the timestamp.

The alert record is also the place to check who else was notified. Many DLP policies are configured to email the file owner directly when a quarantine action fires, sometimes before the security team has even seen the alert themselves. If that's the case in your tenant, the file owner may already be halfway through their own investigation by the time you open the case, so a quick check of the notification history saves you from duplicating work or giving contradictory guidance to the same person.

Step 3: Decide whether to release the file

Not every quarantine action is a false positive, and not every true positive means the file should stay locked away forever. Three outcomes are common:

The detection was accurate and the content is genuinely sensitive

The right move is usually to redact or remove the sensitive portion, then re-upload a corrected version, rather than releasing the original as-is.

The detection was a false positive

A document that merely resembles a sensitive pattern, a training document with fabricated account numbers, for example, can typically be released without changes once a compliance reviewer confirms the match was incorrect.

The content is sensitive but the sharing was appropriate

Sometimes the file is exactly what the policy is designed to catch, but the recipient had a legitimate business reason to receive it. In that case a sensitivity label exemption or a scoped policy adjustment, rather than a one-off release, is the more durable fix.

Whichever outcome applies, write it down. A short note in the alert record, or in whatever ticketing system your security team uses, saves the next reviewer from re-deriving the same reasoning if a similar file trips the same rule three months later. Teams that skip this step tend to re-litigate the same judgement call every time it recurs, which is a slower and less consistent process than checking a prior decision.

Step 4: Release the file from the quarantine site

1. Navigate to the DLP quarantine site (a Purview administrator or compliance admin will have the site URL; it is not linked from regular navigation).
2. Locate the file by name, original library path, or the alert reference number.
3. Select the restore or release action, which returns the file to its original document library, overwriting the tombstone placeholder.
4. Confirm the restore in the Purview alert to close out the incident record.

Only accounts with explicit access to the quarantine site can perform this step. Site owners and the file's original author cannot self-service a release; the workflow is intentionally gated to compliance or security roles.

If your organisation runs several quarantine sites, one per business unit or region, keep a short reference of which site corresponds to which set of source libraries. Locating the wrong quarantine site, or discovering that the account handling the incident doesn't have access to the one that actually holds the file, is a common source of delay in the first few incidents a team handles before the process settles down.

Step 5: Check shared links and permissions after restore

A file that sat in quarantine for days or weeks may have outdated sharing. Anyone who needed the file during the incident may have been sent a copy through another channel, and any shared links created before quarantine should be re-verified rather than assumed to still be correct.

ShareMaster's Shared Links & Permissions tool can pull up every sharing link and unique permission grant on the restored file in one view, so you can confirm the audience matches who should actually have access post-incident, rather than checking site by site.

Try Shared Links & Permissions free for 14 days

Step 6: Prevent the same file from being re-quarantined

Restoring a file without changing anything about it usually means the next content scan matches it against the same policy and quarantines it again. Before closing out the incident, confirm one of three things happened: the sensitive content was removed or redacted, a sensitivity label was applied that the policy exempts, or the policy itself was adjusted to reflect an approved exception. Skipping this step is the single most common reason the same file reappears in quarantine within days.

It's worth building a short internal record of quarantine incidents over time, even a simple spreadsheet: which library, which policy, what the resolution was. After a handful of entries, patterns tend to emerge. A single library that generates repeat quarantines usually points to a rule that's too broad for that library's normal content rather than to a genuine ongoing risk, and that pattern is far easier to spot with a written log than by relying on memory across a team that handles the occasional incident once every few weeks.

Frequently Asked Questions

Who can restore a file from SharePoint DLP quarantine?

Restoration requires access to the DLP quarantine site, normally limited to Purview compliance administrators or a designated security team, not the file's original owner or regular site members.

Does the file keep its version history after quarantine?

Yes. The file, including versions saved before quarantine, is preserved in the quarantine site and returns with its history intact when restored.

Can I stop the same file from being quarantined again?

Only by addressing the underlying match: removing or redacting the sensitive content, applying an exempt sensitivity label, or adjusting the policy scope. A plain restore with no other change typically repeats the quarantine on the next scan.

Learn more about Shared Links & Permissions