Phase 3 – Investigation

From Investigation to Outcome.

Overview

Most DLP content stops at the investigation. This post covers what happens after, because getting to a decision is only half the job. The other half is doing something defensible with it.

Quick recap

In the previous post, we covered how Tier 2 builds a complete picture of an incident using VisionStack‘s 4-Context Investigation Model:

User Context – Data Context – Activity Context – Environment Context

The output of that process is an investigation decision: confirmed risk, no material risk, or genuinely ambiguous. This post picks up from that decision point and covers containment, remediation, and closure, the stages most DLP programs handle inconsistently, if at all .

Containment and remediation are not the same thing

They are frequently treated as interchangeable. They are not.

• Containment is immediate. Its goal is to stop the situation from getting worse. It doesn’t require knowing the full picture, it requires knowing enough to act. Revoking an external sharing link, blocking a user’s ability to send emails externally, or removing a file from a mailbox are all containment actions. They are bounded, reversible where possible, and timed to the investigation window.
• Remediation is structural. Its goal is to address the root cause so the same incident doesn’t recur. Correcting a mislabeled file, adjusting a DLP policy threshold that was generating false positives, tightening a sharing configuration that allowed the exposure in the first place, or initiating a user training workflow are all remediation actions. They are longer-term and require a clearer picture than containment does.

The sequencing matters. Contain first, remediate after. Reversing that order – or skipping containment entirely to wait for a “complete” picture – creates unnecessary exposure windows.

Containment actions in Purview and Defender XDR

The specific containment actions available depend on the workload involved and the RBAC permissions of the Tier 3 responder. Here is what is available natively:

Exchange Online

• Remove an email from a recipient’s mailbox using Defender XDR’s email advanced actions, available to Tier 3 via the Email & collaboration advanced actions (manage) permission
• Release or block a quarantined email via the quarantine management interface
• Apply a transport rule to block further outbound email from the user to specific domains, which requires Exchange Administrator coordination

SharePoint Online and OneDrive

• Revoke external sharing on a specific file or folder via the SharePoint admin center or via Defender XDR file actions
• Apply a sensitivity label change to the file to trigger downstream access controls, which is available to Tier 3 via Purview
• Remove the file from the site if it should not have been there in the first place

Endpoint DLP

• Isolate a device via Microsoft Defender for Endpoint if the incident warrants full device isolation. This is a significant action and should be used proportionally
• Block a specific application from accessing sensitive content via Endpoint DLP policy adjustment

Cross-workload

• Temporarily restrict a user’s ability to share or send content externally via a scoped DLP policy override or Conditional Access policy. This requires coordination with the Identity team
• Flag the user for enhanced monitoring in Microsoft Purview Insider Risk Management if the incident pattern warrants it

A few things worth stating clearly about containment:

• Containment actions taken without a documented investigation record create legal and operational exposure. If a user’s access is restricted and there is no documented rationale trail from alert through to that decision, the action is difficult to defend, to both internally and the user. The documentation isn’t bureaucracy; it’s what makes the action defensible.
• Containment should also be proportional. Isolating a device because a user shared a Confidential labelled file with a known business partner is a disproportionate response. The escalation criteria from Post 05 should inform the scope of containment, not just the decision to escalate.

Remediation actions

Remediation in the DLP context operates at two levels: the incident level and the programme level.

Incident-level remediation addresses the specific exposure:

• Correct the sensitivity label on a mislabeled file and document the correction
• Remove data from an unauthorized location, like personal cloud storage, USB and external mailbox, where technically possible
• Initiate a formal user notification or training requirement, coordinated through HR where appropriate
• Revise a business justification override that was approved but shouldn’t have been

Programme-level remediation addresses the systemic issue the incident revealed:

• Adjust a DLP policy rule that was too broad and generating excessive false positives, reducing noise without reducing coverage
• Tighten a sharing configuration that allowed the exposure, like SharePoint external sharing settings and email domain allow-lists
• Add a missing workload to an existing policy scope if the incident exposed a gap
• Update the escalation criteria if the incident type was not anticipated in the original triage framework

Programme-level remediation is the part most teams defer indefinitely. It requires someone to own the feedback loop between incident outcomes and policy configuration. In most organizations, that ownership isn’t clearly assigned. If it lives with the security engineer who maintains DLP policies, it needs to be formally triggered by the incident closure process, not discovered incidentally.

Closure criteria

An incident is not closed when the analyst runs out of things to check. It is closed when specific criteria are met.

A minimum closure record should contain:

• Incident classification: True Positive, False Positive, or Benign Positive (a policy match that was technically correct but represented no actual risk). I admit that I never knew the term (Benign Positive) before I did my research for this post .
• Severity confirmed: The assessed severity at closure, which may differ from the original alert severity
• Actions taken: A log of every containment and remediation action, with timestamps and the identity of who took each action
• Outcome: What the resolution was:
  • Data recovered,
  • Access revoked,
  • User notified,
  • Policy updated,
  • No action required
• Escalation record: Reference to any Governance, Legal, or HR engagement, including what was communicated and when
• Lessons learned: At least one observation about what this incident revealed, even if the answer is “nothing new”

The lessons learned field is the one most commonly left blank. It should not be optional. A closed incident with no lessons learned entry is a missed opportunity to improve, and in aggregate, it means the programme never gets smarter.

Classification matters more than teams think

The incident classification at closure – True Positive, False Positive, Benign Positive – feeds directly into programme improvement. If 60% of closed incidents are False Positives, the DLP programme has a policy tuning problem. If 80% are Benign Positives, the programme has an escalation criteria problem, too many low-risk events are making it through to full investigation.

Neither problem is visible without consistent closure classification. And neither gets fixed without someone reviewing that classification data on a regular cadence.

Microsoft Defender XDR’s incident management supports classification and determination fields natively. Use them consistently, as the data is only useful if it is applied uniformly across all analysts.

Post-incident review

Not every incident warrants a formal post-incident review. But some do, and the criteria for triggering one should be defined in advance rather than decided case-by-case.

Consider a post-incident review when:

• The incident involved regulated data with potential notification obligations
• The incident was a True Positive involving deliberate data exfiltration
• The incident exposed a gap in the DLP policy scope or the operating model
• The incident involved a containment failure. As in the policy fired correctly but the exposure was not stopped in time
• The same incident pattern has recurred more than twice in a rolling 90-day window

A post-incident review does not need to be a lengthy formal process. A structured 30-minute discussion with the relevant tier leads, producing a one-page summary with three outputs – what happened, what worked, what changes – is sufficient for most incidents. The output should be tracked, not filed and forgotten.

Connecting closure back to the programme

The DLP programme improves when incident outcomes inform policy, process, and access design. That feedback loop requires two things:

• Consistent closure documentation
• Someone with ownership of the improvement cycle.

Without the first, there is nothing to learn from. Without the second, the data sits in closed incidents and goes nowhere.

This is the point in the series where the operational model starts connecting back to the programme governance layer, which is where Phase 5 will pick up after the tooling and architecture posts in Phase 4 .

What’s coming next

Phase 3 is complete. We have covered triage, investigation, and closure. Phase 4 moves into the architecture and tooling layer. Specifically, where DLP incidents should live operationally, and how the choice of tooling model shapes what the programme can and can’t do.

The next post covers the core architecture decision every DLP team faces: Defender XDR, SIEM, ITSM, or a combination, and why that decision is harder than it looks.