3.3 Investigating DLP Alerts in the Defender Portal

Investigating DLP Alerts in the Defender Portal

Introduction

Subsection 3.2 taught you how DLP policies generate alerts. This subsection teaches you what to do when those alerts arrive in your queue. DLP alert investigation follows a different pattern from endpoint or identity alerts because the primary question is not “what attack technique was used?” but “was sensitive data actually exposed, and if so, how much and to whom?”

The investigation outcome determines the response severity. If the DLP policy blocked the email before delivery, sensitive data did not leave the organization — the incident is an attempted exfiltration (containment already successful, investigation focuses on the user and intent). If the policy was audit-only and the email was delivered, sensitive data has reached the external recipient — the incident is a confirmed data breach (response includes data breach notification assessment, potentially regulatory reporting, and containment of the ongoing compromise if the account was stolen).

This subsection walks through the complete DLP alert investigation workflow using the Defender XDR portal, teaches you the KQL queries that surface DLP investigation context, and covers the documentation requirements for DLP incidents that may have regulatory notification implications.

The DLP alert investigation workflow

Step 1: Triage — assess the alert’s surface-level significance. Open the DLP alert in the Defender portal incident queue. Before examining any detail, read four pieces of information: the Sensitive Information Type that matched (credit card numbers, social security numbers, custom SIT), the confidence level (Low, Medium, High), the instance count (1 instance vs 200 instances), and the destination (internal Teams message vs external email to Gmail). These four data points give you an immediate severity estimate.

A single low-confidence match in an internal message → likely false positive, fast triage. Two hundred high-confidence matches in an email to an external address → potential data breach, full investigation. This initial assessment determines how much time you invest before moving to step 2.

Step 2: Content review — confirm the match is real. The DLP alert evidence panel shows a content preview with the matched text highlighted and sensitive values partially redacted. Examine the preview: is this actually a credit card number, or is it a product SKU that happens to be 16 digits? Is this actually a social security number, or is it a formatted phone number? Is the document actually confidential financial data, or is it a marketing brochure that discusses financial concepts?

Content review is where most DLP alerts are resolved. If the matched content is not genuinely sensitive, mark the alert as a false positive. If the content is genuinely sensitive, proceed to step 3.

For DLP alerts where the content preview is insufficient (large documents, multiple matches across different sections), you may need to examine the full document. Use the alert’s link to the source content (the email in Exchange, the file in SharePoint) to review the full context. For email DLP alerts, Threat Explorer (Module 1.3) can show the complete email metadata and content.

Step 3: Exposure check — was the data actually exfiltrated? This is the critical determination. The alert tells you sensitive data was detected in a policy-violating context. But was the data actually exposed?

Check the DLP action: was the email blocked, quarantined, or delivered? If blocked, the data stayed inside the organization — the incident is attempted exfiltration. If delivered, the data reached the external recipient — the incident is confirmed data exposure.

For SharePoint/OneDrive DLP alerts, check whether the sharing link was created (exposure) or whether the share attempt was blocked (attempt only). For endpoint DLP alerts, check whether the file copy to USB succeeded (exposure) or was blocked (attempt only).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

// Determine DLP alert outcome — blocked or delivered?
CloudAppEvents
| where Timestamp > ago(7d)
| where ActionType has "DlpRule"
| extend PolicyName = tostring(RawEventData.PolicyName)
| extend RuleAction = tostring(RawEventData.Actions)
| extend SITName = tostring(RawEventData.SensitiveInfoTypeName)
| extend Confidence = tostring(RawEventData.ConfidenceLevel)
| extend InstanceCount = toint(RawEventData.SensitiveInfoTypeCount)
| extend DestinationDomain = tostring(RawEventData.RecipientDomain)
| project Timestamp, AccountDisplayName, PolicyName, SITName,
    Confidence, InstanceCount, RuleAction, DestinationDomain
| order by Timestamp desc

Step 4: Context check — why did this happen? The exposure check tells you what happened. The context check tells you why, which determines the response track.

Check the user’s account status: is this account compromised? Check the Defender XDR incident — are there correlated identity alerts (anomalous sign-in, impossible travel, token replay) for the same user? If yes, this is data exfiltration by an attacker using a compromised account. The DLP alert is a symptom of the broader compromise, and the response includes full incident response procedures from Module 1.2.

If the account is not compromised, check the user’s intent: is this an insider threat (deliberate data theft by an employee), a policy violation (the user knowingly sent data externally but believed it was acceptable), or an accident (the user attached the wrong file, selected the wrong recipient, or did not realize the content was classified as sensitive)?

Intent determines the response track. Attacker exfiltration → full incident response + data breach notification. Insider threat → escalate to IRM case management with HR and legal coordination. Policy violation → manager notification + policy retraining. Accident → user notification + no further action (for first occurrence).

Step 5: Remediate, document, and close. Based on the exposure check and context check, take the appropriate remediation actions.

For confirmed data exposure via compromised account: contain the account (Module 1.2 response actions), assess the data exposed (what types of sensitive data, how many records, whose data), determine notification requirements (GDPR requires notification within 72 hours if personal data of EU residents is exposed), document the complete incident in the incident report including the DLP evidence, and work with the compliance team to update the DLP policy from audit-only to block mode if this gap enabled the exposure.

For attempted exfiltration (blocked by DLP): document the attempt, investigate the account to determine whether it is compromised or the user is acting deliberately, and close the alert with appropriate classification (True Positive — blocked, or True Positive — escalated to IRM).

For false positives: mark the alert as False Positive, document the false positive pattern (what matched incorrectly and why), and report the pattern to the compliance team for policy tuning.

DLP investigation in KQL: beyond the portal view

The portal provides the alert view. KQL provides the investigation depth — answering follow-up questions that the portal interface does not surface directly.

Scope the user’s DLP history. Has this user triggered DLP alerts before? A first-time alert has different significance than a user who triggers alerts weekly.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// DLP alert history for a specific user
CloudAppEvents
| where Timestamp > ago(90d)
| where ActionType has "DlpRule"
| where AccountDisplayName has "morrison"
| summarize AlertCount = count(),
    Policies = make_set(tostring(RawEventData.PolicyName), 5),
    SITs = make_set(tostring(RawEventData.SensitiveInfoTypeName), 5),
    ExternalDomains = make_set(tostring(RawEventData.RecipientDomain), 10)
    by bin(Timestamp, 7d)
| order by Timestamp desc

Scope the campaign — did the compromised account send sensitive data to multiple recipients? If the DLP alert shows one email to an external address, check whether there were additional emails to other external addresses that did not trigger DLP (because they contained different types of sensitive data not covered by the policy, or because the data volume was below the policy threshold).

1
2
3
4
5
6
7
8
9

// All external emails from the compromised account during the compromise window
EmailEvents
| where Timestamp between (datetime(2026-03-18 09:00) .. datetime(2026-03-18 12:00))
| where SenderFromAddress has "j.morrison"
| where RecipientEmailAddress !has "northgateeng.com"
| extend HasAttachment = (AttachmentCount > 0)
| project Timestamp, RecipientEmailAddress, Subject, HasAttachment,
    AttachmentCount, DeliveryAction
| order by Timestamp asc

Correlate DLP alerts with identity events. The most powerful DLP investigation technique is combining DLP data with sign-in data to determine whether the user who triggered the alert is the legitimate account holder or an attacker.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

// Correlate DLP alert with sign-in activity — same user, same time window
let dlpUser = "j.morrison@northgateeng.com";
let dlpTime = datetime(2026-03-18 09:14);
let window = 2h;
union
    (CloudAppEvents
        | where Timestamp between ((dlpTime - window) .. (dlpTime + window))
        | where AccountId =~ dlpUser
        | where ActionType has "DlpRule"
        | project TimeGenerated = Timestamp, Phase = "DLP",
            Detail = strcat("DLP: ", tostring(RawEventData.PolicyName)),
            SourceIP = IPAddress),
    (SigninLogs
        | where TimeGenerated between ((dlpTime - window) .. (dlpTime + window))
        | where UserPrincipalName =~ dlpUser
        | where ResultType == "0"
        | extend Country = tostring(LocationDetails.countryOrRegion)
        | project TimeGenerated, Phase = "Auth",
            Detail = strcat("Sign-in from ", Country, " via ", AppDisplayName),
            SourceIP = IPAddress)
| order by TimeGenerated asc

This union query produces a timeline that shows the DLP alert alongside the authentication events. If the sign-in before the DLP alert came from an unusual country or IP, the account is likely compromised. If the sign-in is from the user’s normal location and device, the DLP alert may be an insider risk or an accident.

Documentation requirements for DLP incidents

DLP incidents that involve confirmed data exposure have documentation requirements beyond standard security incident reporting. These requirements exist because data exposure may trigger regulatory notification obligations.

What to document in every DLP incident:

The sensitive data types detected (credit card numbers, personal data, healthcare records, financial data). The volume of exposed data (number of instances, number of unique records, number of affected individuals if personal data). The exposure vector (email to external recipient, file shared via link, copied to USB, uploaded to cloud storage). The exposure duration (how long was the data accessible before containment — for email, this is the time between delivery and recipient reading; for file shares, this is the time between share creation and share revocation). The recipients (who received or could access the exposed data — specific email addresses, or “anyone with the link” for SharePoint sharing). Whether the data was encrypted (sensitivity labels with encryption protect data even if it is exfiltrated — the recipient cannot read it without authorization).

This documentation feeds directly into the data breach notification assessment. Under GDPR, if personal data of EU residents is exposed, the controller must notify the supervisory authority within 72 hours and affected individuals “without undue delay” unless the exposure is unlikely to result in risk to rights and freedoms. Under UK GDPR, the same 72-hour requirement applies to the ICO. Your incident documentation provides the evidence base for this assessment.

DLP alert classification: the four outcomes

Every DLP alert resolves into one of four classifications. Knowing these before you start investigating prevents wasted time and ensures consistent documentation.

Multi-workload DLP investigation: following the data trail

When a DLP alert fires in one workload (email), check whether the same user triggered DLP events in other workloads during the same window. An attacker who sends sensitive data via email may also download it from SharePoint, copy it to a USB drive, or upload it to a personal cloud service. A single-workload investigation misses the full exfiltration scope.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

// Multi-workload DLP check — did this user trigger DLP across multiple channels?
CloudAppEvents
| where Timestamp > ago(48h)
| where AccountDisplayName has "morrison"
| where ActionType has "DlpRule"
| extend Workload = tostring(RawEventData.Workload)
| extend PolicyName = tostring(RawEventData.PolicyName)
| extend SIT = tostring(RawEventData.SensitiveInfoTypeName)
| extend Action = tostring(RawEventData.Actions)
| summarize AlertCount = count(),
    SITs = make_set(SIT, 5),
    Actions = make_set(Action, 3)
    by Workload
| order by AlertCount desc

False positive management: closing the feedback loop

False positives waste SOC time and erode analyst confidence in DLP alerts. Every false positive should be tracked and reported to the compliance team for policy tuning. A structured false positive workflow prevents the same false positive from generating alerts indefinitely.

When you close a DLP alert as a false positive, document three things: the SIT that matched incorrectly (e.g., “Credit Card Number matched a 16-digit product SKU”), the content context (what the actual content was and why it is not sensitive), and a recommended tuning action (add an exclusion condition for this content pattern, or raise the minimum confidence level for this SIT). Report these to the compliance team weekly. Over time, this feedback loop reduces false positive rates and increases the signal-to-noise ratio of the alerts you investigate.

Track your false positive rate per DLP policy. If a policy generates more than 60% false positives, it needs tuning. If a specific SIT generates false positives in your environment that are not common elsewhere (a product numbering system that matches credit card patterns), the compliance team can add an exclusion condition specific to that pattern.

Knowledge check