How to Restore a File From SharePoint DLP Quarantine

A file that vanishes from a document library and leaves behind a text file with the same name 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, moving the file back, and what the file has lost by the time it returns.

What DLP file quarantine actually does

File quarantine is a DLP policy action for SharePoint and OneDrive. Microsoft lists it as a preview feature for E5 licences. When a file matches a rule with the quarantine action, Microsoft documents this sequence: every existing permission and sharing link on the file is removed, a system account moves the file into an admin-defined quarantine site (keeping the original folder structure), and a tombstone text file with the original name plus .txt is left in its place. The tombstone shows a message your administrators configured and the file's relative path inside the quarantine site, but not the full quarantine address.

The action only applies to files created or modified after the policy was switched on. Files that were already sitting in the library when the policy started are not quarantined by it, which is worth knowing when someone asks why one file was taken and its older neighbour was not.

Quarantine differs from the softer block action. Blocking restricts access but leaves the file where it is; quarantine removes it from the location altogether, including from its owner. Because the action works at the file level, everything else in the library keeps functioning 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.

Many organisations start with a policy that only notifies a compliance reviewer when it detects sensitive content, without touching the file. Teams that adopt quarantine for the first time often underestimate how quickly a single overly broad rule can generate a wave of false positives across a busy library, which is why the review 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 is the clearest signal. If users report a file is "missing" but no .txt file with its name 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 shows the message your administrators wrote when they set quarantine up, typically who to contact, plus the relative path of the file inside the quarantine site. That path is what the person doing the restore needs, so ask the user to send it rather than a screenshot of the error.

Step 2: Find the matching alert in Purview

1. Sign in to the Microsoft Purview portal with an account that has DLP alert access.
2. Go to Data loss prevention, then Alerts.
3. Filter by the affected site or policy, or search for the file name.
4. Open the matching alert and note the policy and rule that matched, the quarantine file location, the file owner and the original file path.

The alert record is also the place to check who else was notified. Many DLP policies are configured to notify the file owner directly when an 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 and store a corrected version, rather than releasing the original as-is. The rule that caught it will not catch the restored copy again, so nothing automatic stops the original going back into circulation.

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 location was appropriate

Sometimes the file is exactly what the policy is designed to catch, but it had a legitimate business reason to be where it was. In that case a scoped policy adjustment, rather than a string of one-off releases, is the more durable fix, because the next file like it will be quarantined by the same rule.

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.

Step 4: Move the file back from the quarantine site

Microsoft is explicit that there is no automated restore and no restore action in the Purview portal. Releasing a file is a manual move:

1. Open the quarantine site (the compliance admin who configured quarantine will have its address; it is not linked from regular navigation) and locate the file. The folder structure mirrors the original location.
2. Confirm the original path from the alert details or the audit log.
3. Move the file from the quarantine site back to that original location. The person doing this needs access to both sites.
4. Delete the tombstone .txt file from the original location, then update the alert's status so the incident record shows it was resolved.

Site owners and the file's original author cannot self-service a release, because they have no access to the quarantine site. Microsoft recommends that whoever manages that site is chosen with the same care as accounts that can view sensitive content in Data Explorer, since the site holds every file the policy has caught.

Step 5: Re-share the restored file

Microsoft's post-restore notes are short and worth reading before you tell the user it's sorted. Original sharing permissions are not restored, so the file comes back with whatever it inherits from its folder. Only the latest version comes back; earlier versions are not preserved through quarantine and restore. Anyone who relied on a sharing link to the file needs a new one.

Once the file has been shared again, ShareMaster's Share Link Finder can report the sharing links and unique permissions across the library it sits in, so you can confirm the new audience is the one you intended rather than checking item by item.

Try the Share Link Finder free

Step 6: Stop the next file landing in quarantine

The restored file itself is safe from a repeat: Microsoft states the rule that quarantined it will not quarantine it again, even if the file or the rule is later edited. Other DLP rules continue to apply to it. The risk is the next file like it. If the detection was a false positive, adjust the rule or its scope so similar files stop matching; if it was accurate, make sure the corrected version, not the original, is the one in use.

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?

Whoever administers the quarantine site, and they also need access to the file's original location, because the restore is a manual move rather than a button in the Purview portal. The file's owner and site members cannot release it themselves.

Does the file keep its version history after quarantine?

No. Microsoft documents that only the latest version is restored; earlier versions are not preserved through quarantine and restore. Original sharing permissions and links are not restored either.

Can I stop the same file from being quarantined again?

The rule that quarantined it will not quarantine the restored file again, even if the file or the rule later changes. Other DLP rules still apply, so a restored file can still be caught by a different policy, and the content is unchanged unless someone redacts it.

Source: Learn about DLP file quarantine for SharePoint and OneDrive, Microsoft Learn.