Microsoft has quietly armed security teams with one of the most aggressive data loss prevention controls yet for cloud collaboration. In mid-July 2026, the file quarantine feature in Microsoft Purview reached worldwide general availability, according to the Microsoft 365 roadmap. It allows DLP policies to automatically yank sensitive files out of SharePoint Online and OneDrive for Business locations and lock them in an administrator-only quarantine site. A tombstone file is left behind with a message explaining what happened and who to contact.

But that yank comes with a catch that many organizations may not fully appreciate until it’s too late: restoring a quarantined file does not bring back its original sharing permissions, sharing links, or version history beyond the latest version. If a policy misfires—or even works as intended on a business-critical file—the IT team may hand the file back, while the business owners are left scrambling to rebuild the collaboration model from scratch. The feature is powerful, but it’s not a blanket upgrade over conventional DLP blocking. For many, the safer path is to pilot it narrowly and keep standard blocking controls in place for everything else.

From Blocking to Moving: What File Quarantine Actually Does

Traditional DLP policies in Microsoft Purview can block access to a file when it matches a sensitive information type or label, but the file stays in its original location. Blocking can prevent unauthorized sharing, restrict download, or alert the compliance team. The file remains part of the team’s daily work—maybe a spreadsheet that gets coauthored every morning or a proposal kept in a shared library with established links.

Quarantine changes that completely. When a policy rule matches, Purview moves the file from its working location to a dedicated SharePoint site that you designate during setup. At the original path, a .txt tombstone file appears with a message you configure, along with the relative path of the quarantined file. The feature works across SharePoint sites and OneDrive accounts, but the quarantine destination must be a SharePoint site—you can’t dump quarantined files into a OneDrive folder.

Microsoft’s official documentation (still carrying a “preview” label at the time of writing, though the feature is now GA) walks through the configuration steps clearly. You first set up the quarantine site in your tenant, restrict it to admins only, and configure the tombstone message in the Purview portal by going to Data loss prevention > Settings > File quarantine. Only then can you create a DLP policy and select the action “Block everyone and move file to quarantine location.” The policy wizard prompts you to complete the quarantine settings if you haven’t already.

Licensing is straightforward but exclusive: File Quarantine requires Microsoft 365 E5. It’s not part of E3 or lower plans.

Who Should Use Quarantine—and Who Shouldn’t

This isn’t a feature you flip on globally and forget. Quarantine is isolation, not just a stronger access denial. It’s best suited for content where the security risk of leaving the file in place—even momentarily—outweighs the operational cost of temporarily breaking collaboration. Think: a document containing unredacted credit card numbers that was accidentally synced to a broad team site, or a design file labeled “Highly Confidential” that landed in an open OneDrive folder. In those cases, immediate removal buys time for a human review before the content spreads further.

But for run-of-the-mill DLP enforcement on active work files, quarantine can be a sledgehammer. If a policy triggers on a financial workbook that your sales team uses daily and distributes through sharing links, the quarantine action won’t just block access—it will vanish the file from the team’s workflow. When compliance restores the file (and that’s a manual process—end users can’t recover it themselves), it will appear as the latest version, but without the previous sharing links or the granular permissions that granted access to collaborators, external partners, or automated processes. Someone will have to re-add all those people and rebuild any custom access. If the file was part of an approval workflow or referenced by a retention policy, those connections may also need to be reconstructed.

So, quarantine should be reserved for narrowly defined content and highly trustworthy detection. If you’re still tuning your sensitive information types or haven’t thoroughly tested how your labels apply across your SharePoint estate, stick with alert-only or traditional block-and-report policies.

A Practical Pilot Plan

The road to safe adoption starts with a simulation. Microsoft explicitly recommends that you run any quarantine policy in simulation mode first, and for good reason. Simulation mode lets you see what would have been quarantined without actually moving any files. Use Activity Explorer and the DLP alerts dashboard to study the matches. Do broad sensitive info types catch too many legitimate business files? Are you triggering on the right sensitivity labels? Only when you’re confident the policy would only catch the files you truly need to isolate should you think about flipping the switch.

But simulation mode alone isn’t enough. The real test is a controlled pilot with synthetic files that mirror real work. Create a dedicated test SharePoint site and a few test OneDrive accounts. Upload files that intentionally match your policy, files that almost match, and files that should not match. But don’t just test in isolation; put those test files in scenarios that mimic actual collaboration:

  • Place a file in a shared library and have multiple test users expect to access it.
  • Sync a file via the OneDrive sync client and observe the user experience after the policy acts.
  • Co-author a document with a colleague when the policy triggers.
  • Put a test file behind an approval workflow or automation.
  • Create multiple versions before quarantine, then restore and verify exactly which version returns (you’ll likely only get the latest one).
  • Duplicate a file name in a controlled way to see what happens if a new upload has the same name as a previously quarantined file—Microsoft’s preview documentation flagged a risk that a later upload with the same name could overwrite the quarantined copy. Whether that’s been fixed in the GA release isn’t clear yet, so include it in your pilot’s failure criteria.

The pilot should also test the operational response: Do alerts give enough detail (file owner, original path, quarantine location)? Can your help desk handle user inquiries? And crucially, how long does it take from “file quarantined” to “file fully restored and usable by the business”? If that timeline is longer than what the affected process can tolerate, quarantine isn’t appropriate for those files.

The Restore Runbook Is Your Production Readiness Test

Quarantine turns DLP from a security control into a service operation. Someone must own the restore process end to end. Before you let a policy enforce quarantine in production, create a slim runbook that assigns clear responsibilities:

  • Incident assessment: Who decides if the quarantine was a false positive or a true positive? (Compliance analyst)
  • Authorization: Who approves a restore? (Data owner, maybe legal)
  • Technical execution: Who actually performs the restore in the Purview portal? (Compliance admin or SharePoint admin)
  • Collaboration rebuild: Who re-adds sharing permissions, recreates links, and notifies collaborators? (Often a mix of IT and the file owner)
  • Validation: Who confirms the file works again—coauthoring, sync, workflows? (The business owner and IT)

Your runbook should also log each incident, capturing enough detail to distinguish a true false positive from a correct quarantine that happened to break a legitimate but undocumented business dependency. Over time, that log will help refine your policies and reduce operational pain.

Note that restoring a file only brings back the latest version. If you need earlier versions for audit or business continuity, you may need to retrieve them from version history in the original location (if it was enabled and if the site still has them) or from backup. Microsoft’s documentation is clear: the restore does not bring back sharing links or permissions. You’ll need to manually re-establish those.

When Blocking Still Wins

For the vast majority of DLP use cases, conventional blocking remains the safer, lower-cost option. Blocking can still restrict access, prevent downloads, or limit external sharing without physically moving the file. Users might see a policy tip or get an access denied message, but the file stays put. When the issue is resolved—maybe the sensitive info was misidentified, or someone removed the offending content—collaboration resumes without a rebuild.

Microsoft has also been rolling out other granular DLP actions, such as blocking specific guest users from accessing SharePoint and OneDrive content (highlighted in a July 2026 update). These can often provide targeted protection without the nuclear option of full file quarantine. And with Purview’s expanding Copilot integration, accurate labeling and sensitivity classification are more important than ever, because a mislabeled file might not just be quarantined—it might get excluded from Copilot processing entirely, causing a different form of business disruption.

What’s Next

File Quarantine is one of several new Purview controls maturing rapidly. Keep an eye on the Microsoft 365 roadmap for enhancements to the restore process—many admins have already asked for an option to preserve sharing links and permissions. Microsoft’s preview documentation hinted at future improvements, though no concrete timelines have been promised. In the meantime, treat quarantine as a specialized tool: test it on high-stakes, well-defined content classes, and pair it with a well-oiled restore machine. For everything else, let blocking catch the noise while quarantine handles the real dangers.