Phase 3 – Investigation

The DLP Triage Framework.

Overview

A DLP alert arrives. The analyst opens it. Now what?

Most teams have an instinct at this point to look at who sent it, glance at the policy name, make a quick call. Sometimes that works. More often, it produces inconsistent outcomes. That is the same type of alert gets dismissed by one analyst and escalated by another, depending on what they happened to notice first.

Triage isn’t a gut check, rather It’s a repeatable process. This post covers what that process looks like.

Quick recap

In the previous post, we covered communication and escalation patterns. Specifically, what has to happen at each handoff between tiers for an incident to move forward cleanly.

Triggered → Documented → Bounded

Before any of that handoff discipline applies, Tier 1 needs to make a structured triage decision. That decision is what this post is about.

What triage is trying to answer

Triage has one job, that is to determine whether this alert represents real risk worth escalating to Tier 2 investigation, or whether it can be closed at this layer with documented rationale.

That sounds simple. However inn practice, it requires answering three questions simultaneously:

• Severity: how significant is the potential exposure if this is a real incident?
• Intent: is the behavior more consistent with accidental action or deliberate exfiltration?
• Exposure: what data was involved, and how far has it potentially traveled?

None of these questions can be answered by looking at the alert title alone. They require context. Here is usually where most triage processes fails, not because that analysts lack skill, but because they haven’t been given a consistent framework for what context to gather and in what order.

Severity classification

Microsoft Defender XDR assigns a severity level to DLP alerts based on the policy configuration, but that severity reflects the policy author’s intent at design time, not a real-time assessment of the specific event. A High severity alert for a credit card number (CCN) detection in a low-risk context is not the same operational priority as a High severity alert involving a bulk export of Highly Confidential files to an external domain by a user who triggered three similar alerts last week.

A working severity model for triage purposes needs to account for both dimensions:

The critical discipline here is that severity should be assessed at triage, not inherited from the policy. The policy severity is merely a starting point, it is not a conclusion.

Intent assessment

Determining whether behavior was accidental or deliberate is the hardest part of triage, and also the part most likely to be skipped in favor of a binary escalate/dismiss decision.

Intent can rarely be confirmed at Tier 1. That’s not the goal here. The goal is to assess which direction the available evidence points, and flag the cases where intent is genuinely ambiguous for Tier 2 to resolve.

Indicators that suggest accidental behavior:

• First occurrence for this user with no prior DLP history
• Action consistent with the user’s role and normal work patterns
• Low-risk destination (internal recipient, approved domain)
• User submitted a business justification override at the point of policy trigger
• Data sensitivity is moderate and exposure scope is limited

Indicators that suggest deliberate or elevated-risk behavior:

• Repeated pattern across multiple alerts for the same user in a short window
• Destination is external, personal, or an unmanaged device
• Action occurred outside normal working hours or from an unusual location
• User bypassed a policy tip without a documented justification
• Data sensitivity is high and the volume of data involved is significant
• The user is under an active HR review or has a recent termination date approaching

None of these indicators is conclusive on its own of course . The value is in reading the combination. A single external email from a long-tenured employee in finance to a known business partner is a different risk profile than the same alert from a departing employee at 11pm to a personal Gmail account.

The 4-Context Investigation Model

The framework that makes triage consistent is structured context gathering. Rather than reviewing alerts in an ad-hoc way and picking up whatever happens to be visible first, a structured approach ensures the same information is gathered for every alert before a triage decision is made.

I tend to refer to this as the 4-Context Investigation Model, not because the four dimensions are novel, but because explicitly naming them makes triage a structured exercise rather than a free-form one.

User context

Who performed the action, and what do we know about them?

• Identity and department
• Role and typical data access patterns
• DLP alert history: first occurrence or repeat behavior?
• Current employment status: active, notice period, recently off-boarded?
• Any active HR or security flags on this user?

Activity Explorer surfaces the user’s recent activity history and is the primary tool for building user context at triage. The Defender XDR incident queue surfaces whether this user appears in other recent incidents.

Data context

What data was involved, and what is its classification?

• File name, type, and size
• Sensitivity label applied to the file or email
• Sensitive Information Types (SITs) matched: and at what confidence level
• Number of SIT matches: a single partial match is very different from 47 high-confidence matches
• Whether the data is subject to regulatory requirements (PII, financial records, health information)

The SIT match count and confidence level are particularly important:

A policy match on a low-confidence single SIT instance in a large document is a very different risk profile from a policy match on 50 high-confidence credit card numbers in a file classified as Highly Confidential.

The alert title won’t tell you this, you have to look at the evidence detail.

Activity context

What specifically happened, and was it consistent with normal behavior?

• Action type: share, download, upload, email, print, copy to USB
• Destination: internal, external domain, personal cloud storage, unmanaged device
• Timing: within or outside normal working hours?
• Volume: single file or bulk operation?
• Whether the user triggered the policy tip and how they responded (overrode it, dismissed it, or it was auto-applied silently)

Advanced Hunting in Defender XDR allows Tier 1 analysts to build a more complete activity picture when the incident detail alone doesn’t provide sufficient context:

AlertEvidence
| where DetectionSource == "Microsoft Data Loss Prevention"
| where AccountName == "<user>"
| project Timestamp, Title, EntityType, EvidenceRole, AdditionalFields
| order by Timestamp desc

AlertEvidence
| where DetectionSource == "Microsoft Data Loss Prevention"
| where AccountName == "<user>"
| project Timestamp, Title, EntityType, EvidenceRole, AdditionalFields
| order by Timestamp desc

Environment context

Where did this happen, and does that location add or reduce risk?

• Workload: Exchange, SharePoint, OneDrive, Teams, Endpoint
• Device: managed corporate device or unmanaged personal device?
• Network: corporate network, VPN, or external connection?
• Geographic location: expected location for this user or anomalous?

Endpoint DLP events in particular carry richer environment context than Exchange or SharePoint events, device compliance state, network connection type, and application used are all surfaced as part of the event. That context matters:

the same file copy action on a managed device within the corporate network has a different risk profile than the same action on an unmanaged personal laptop connected to a public Wi-Fi network.

Putting it together – the triage decision

With all four context dimensions gathered, the triage decision becomes a structured assessment rather than a judgment call:

Two outputs – escalation or closure – both with documented rationale. The documentation is not optional. An escalation without a documented reason gives Tier 2 nothing to work with. A closure without a documented reason leaves no audit trail and no basis for pattern detection over time.

Common triage failure patterns

• Escalating everything above a threshold: Some teams set a rule: anything High or above goes to Tier 2 automatically. This produces a consistent process but defeats the purpose of triage. Tier 2 becomes a second Tier 1, working through the same volume with more access but no better context than Tier 1 had.
• Dismissing on policy name alone: “That policy fires all the time for the finance team, it’s always a false positive.” Sometimes true. But a recurring false positive pattern is a policy tuning problem, not a reason to dismiss without review. And when that same policy eventually fires on a real incident, the habit of dismissing it creates a genuine gap.
• Skipping context when volume is high: When the queue is full, context gathering gets compressed. Analysts start making faster decisions with less information, which produces less consistent outcomes. The fix is queue management discipline and escalation criteria tightening. Faster and shallower triage is not the solution here.

A note on tooling at Tier 1

The primary tools for triage in a Purview DLP environment are:

• Defender XDR incident and alert queue: primary triage interface
• Activity Explorer: user activity history and label state
• Advanced Hunting: extended context queries where incident detail is insufficient
• DLP Alerts dashboard in Purview: alternative alert management view, particularly useful for compliance-oriented teams

Tier 1 access to these tools should reflect the RBAC model from Post 4, metadata and activity access, no sensitive content viewing. The 4-Context Investigation Model is designed to be executable entirely within those access boundaries. If Tier 1 triage regularly requires content access to reach a triage decision, the model is operating at the wrong layer.

What’s coming next

The 4-Context Investigation Model tells you what to gather. The next post goes into what to do with it. Specifically, how context enrichment at Tier 2 turns the raw inputs from triage into an investigation decision, and why the quality of contextual data is what separates a documented outcome from a guess.