Priya's first alert of the morning wasn't a phishing report or a failed login. It was a Purview DLP notification: a finance spreadsheet had been automatically quarantined out of a SharePoint library used by forty people across two departments, and half of them were now messaging the helpdesk asking why a file they needed for a 10am deadline had simply disappeared. Priya leads the three-person security operations function at a mid-sized logistics company, and this was her team's first live encounter with the File Quarantine DLP action since it went into general availability.
The moment the alert lands
The tombstone placeholder appeared in the library at 7.42am. By 8.15am, four separate Teams messages had reached Priya asking whether the file had been deleted by mistake. Nobody on the finance team knew what a DLP quarantine was, let alone that a placeholder file with a policy warning was the expected outcome rather than an error.
That gap, between what security tooling does silently and what end users experience as a missing file, is the first thing every quarantine incident has to bridge. Priya's team keeps a one-line explanation ready in the helpdesk knowledge base specifically so first-line support can answer "is this normal?" without escalating every case to security.
It didn't help that the deadline was real. The finance team needed the reconciliation figures for a 10am reporting call with a regional director, and a placeholder file with a compliance warning is not something most people know how to work around under time pressure. Priya's first job wasn't actually security analysis at all; it was calming down a manager who assumed the company had lost a day of work and telling her, correctly, that the file still existed and was recoverable within the hour.
Confirming what actually triggered it
Priya opened the matching alert in the Purview compliance portal. The rule that fired was one the company had configured months earlier to catch documents containing bank account numbers and routing details, aimed originally at preventing accidental external sharing of payroll files. The quarantined spreadsheet was a legitimate internal reconciliation file containing exactly that kind of data, shared only within the finance team's own library. Nothing external was involved. The rule had done precisely what it was configured to do; it just hadn't accounted for a purely internal file matching the same pattern.
This is the part of quarantine review that surprises teams new to it: the alert itself doesn't tell you whether to release the file. It tells you what matched and why, and the judgement about whether that match represents real risk still sits with a person. Priya's team spent about fifteen minutes confirming two things beyond the alert record. First, that the library in question had external sharing disabled at the site level, meaning the sensitive data genuinely hadn't left the organisation. Second, that the file's permissions hadn't been changed recently in a way that would suggest someone had tried to widen access around the time of the quarantine.
| Before the review | After the review |
|---|---|
| File assumed lost or corrupted by end users | File confirmed quarantined by a known, correctly-firing DLP rule |
| No record of why the rule matched this file | Alert reviewed, sensitive information type and rule name documented |
| Unclear whether to release, redact, or escalate | Decision made: release, since sharing was purely internal |
Deciding to release, not to fight the rule
Priya's team had a choice: treat this as a false positive and simply release the file, or use it as a trigger to narrow the DLP policy so purely internal files in this library stop matching. They chose both. The file itself was released the same morning once the finance team confirmed no external distribution had occurred. Separately, the policy was scoped down to exclude the specific document library where reconciliation files are stored, since that library has no external sharing enabled at the site level and the risk the rule was originally written for doesn't apply there.
This distinction matters for any security team building a quarantine response process. Releasing a file resolves today's incident. Adjusting the policy scope, or applying a sensitivity label the policy exempts, is what stops next week's identical incident from generating the same helpdesk scramble.
There was a third option Priya's team considered and rejected: leaving the rule exactly as it was and simply releasing each affected file by hand as it came up. For a rule that fires once a year, that might be the pragmatic choice. For a finance reconciliation library where similarly formatted files get uploaded weekly, it would have meant repeating the same forty-minute incident on a near-permanent basis. The decision to narrow the policy, rather than just work around it repeatedly, was really a decision about which cost the team was willing to carry long term.
Restoring access and checking what changed underneath it
With the release decision made, an administrator with quarantine site access restored the file to its original library, replacing the tombstone. Before closing the incident, Priya's team ran a quick check on the file's sharing state using ShareMaster's Shared Links & Permissions tool, confirming that no stray shared link had been created during the incident window and that permissions on the file still matched the finance team's expected membership. That check took under five minutes and closed a gap their previous, fully manual process used to skip entirely.
For the full technical restore sequence, see how to restore a file from SharePoint DLP quarantine, which walks through the Purview portal steps in detail.
Building the incident into a repeatable process
The most valuable output of the morning wasn't the single restored file. It was a two-page runbook Priya's team wrote afterward: how to identify a quarantine tombstone, where to find the matching Purview alert, who has authority to approve a release, and a standing rule that any policy-scope change gets logged alongside the incident it was triggered by. The next quarantine event, whenever it comes, will not require the same forty minutes of confused Teams messages before someone identifies what actually happened.
Six weeks later, a second quarantine event hit a different library. The on-call analyst followed the runbook, identified the cause within ten minutes, and had the file released before the affected team had even noticed the placeholder. Priya counts that as the real measure of whether the first incident was handled well: not that it never happens again, but that the second time costs a fraction of the first.
The broader lesson Priya took away wasn't really about DLP tooling at all. It was that a security control introduced without a matching operational process just moves the disruption from "sensitive data leaving the tenant" to "confused end users and a scrambling helpdesk." The quarantine action worked exactly as designed on day one. What was missing was everything around it: a way for support staff to recognise the situation, a clear owner for the decision, and a habit of writing down what happened so the next occurrence is cheaper than the first. None of that required new software. It required someone to sit down after the incident and turn a stressful morning into a repeatable process.
Frequently Asked Questions
Who should own a SharePoint DLP quarantine incident?
A named security or compliance lead should own it end to end: confirming the alert, coordinating with the file owner, deciding on release or remediation, and documenting the outcome.
How quickly should a quarantined file be reviewed?
There is no fixed Microsoft SLA, but most security teams treat quarantine of an active project file as a same-day review given the growing business impact of a locked file.
How do we stop repeated false-positive quarantines from the same team?
Narrow the rule's scope, add a scoped exception for the specific library or document type, or apply an exempt sensitivity label to the relevant template.