3.2 Data Loss Prevention: Policy Architecture and Alert Pipeline

12-16 hours · Module 3

Data Loss Prevention: Policy Architecture and Alert Pipeline

SC-200 Exam Objective

Domain 3 — Manage Incident Response: "Investigate and remediate compromised entities identified by Microsoft Purview data loss prevention (DLP) policies." Understanding how DLP policies generate alerts is prerequisite knowledge for investigating those alerts in subsection 3.3.

Introduction

Data Loss Prevention policies are the detection rules that identify when sensitive data is being handled inappropriately. DLP is to data what Defender for Endpoint is to devices — the detection layer that generates the alerts you investigate. But unlike endpoint detection (which looks for malicious behavior), DLP detection looks for policy violations — sensitive data crossing a boundary it should not cross.

As a SOC analyst, you do not create DLP policies (that is the compliance team’s responsibility). But you must understand how they work because the alert you investigate is the output of a policy evaluation. If you do not understand what the policy was looking for, what matched, and why the severity was set to High, you cannot effectively triage the alert. You will either over-investigate benign matches (wasting time) or under-investigate genuine exfiltration (missing data breaches).

This subsection teaches you how DLP policies are structured, how content classification works (the mechanism that decides whether something is “sensitive”), how the alert pipeline processes matches from initial detection through to the incident queue, and how endpoint DLP extends protection to device-level actions. This is the foundation for subsection 3.3, where you will investigate DLP alerts hands-on.

How DLP policies are structured

Every DLP policy has four components: the scope (what data stores to monitor), the conditions (what patterns or labels to detect), the actions (what to do when a match is found), and the user notifications (how to inform the user and generate alerts).

Figure 3.3: The four components of a DLP policy. Understanding each component is essential for investigating DLP alerts: the scope tells you where the data was, the conditions tell you what matched, the actions tell you what happened (or did not happen), and the notifications tell you why the alert appeared in your queue.

Scope determines which workloads the policy monitors. A policy can cover a single workload (only Exchange Online) or multiple workloads (Exchange + SharePoint + endpoints). The scope is relevant to your investigation because it tells you where to look for the matching content. An email DLP alert means the content was in an email — you investigate using email metadata. An endpoint DLP alert means the content was on a device — you investigate using device telemetry.

Policies can also be scoped to specific users, groups, or sites. A policy that monitors only the Finance department SharePoint site generates alerts only for data in that site. When you investigate the alert, you know the organizational context immediately: this is Finance data, not random corporate data.

Conditions define what the policy considers “sensitive.” This is the classification engine, and it operates through several mechanisms.

Sensitive Information Types (SITs) are pattern-matching rules that identify specific data formats: credit card numbers (Luhn algorithm validation + pattern matching), social security numbers (format pattern + keyword proximity), passport numbers, bank account numbers, healthcare identifiers, and hundreds of other formats. Microsoft provides over 300 built-in SITs covering regulatory frameworks worldwide (GDPR, HIPAA, PCI DSS, Australia Privacy Act, UK GDPR). When a DLP alert fires, the alert details show which SIT matched and the confidence level — “Credit Card Number detected with high confidence” means the pattern matched AND the surrounding keywords confirmed it is likely a real credit card number, not a random 16-digit number.

Sensitivity labels are classification tags applied to documents and emails — either manually by users or automatically by auto-labeling policies. Labels like “Confidential,” “Highly Confidential,” or “Internal Only” are defined by the compliance team. DLP policies can use labels as conditions: “Alert when a document labeled ‘Highly Confidential’ is shared with external recipients.” Label-based DLP is more precise than pattern-based DLP because the classification was intentionally applied, not inferred from content scanning.

Trainable classifiers use machine learning to identify document types that cannot be detected by pattern matching — legal contracts, financial statements, resumes, source code, medical records. The classifier is trained on a sample set of documents and learns the characteristics that define the document type. When DLP uses a trainable classifier as a condition, it evaluates whether the content resembles the trained document type.

Exact Data Match (EDM) is the highest-precision classification method. You provide a table of specific sensitive values (actual customer account numbers, actual employee IDs, actual patient names) and DLP matches against those exact values. EDM has near-zero false positive rates because it matches specific known values, not patterns. However, it requires the compliance team to maintain the source data table.

Confidence levels and instance counts refine the conditions further. A SIT match has a confidence level (Low, Medium, High) based on how strongly the pattern and supporting evidence match. The policy can specify minimum confidence and minimum instance count — “Alert only when 5 or more credit card numbers are detected with high confidence.” This prevents alerts on single-instance matches that are often false positives (a test credit card number in a development email) while catching bulk data exposure (a spreadsheet containing hundreds of customer credit card numbers).

When you investigate a DLP alert, the alert details show the specific SIT or classifier that matched, the confidence level, the instance count, and a content preview showing the matched text with sensitive values redacted. This information drives your triage decision: a high-confidence match with 50 instances of credit card numbers in an email to an external Gmail address is clearly a data breach. A low-confidence match with 1 instance in an internal Teams message is likely a false positive.

The alert pipeline: from policy match to incident queue

When DLP evaluates content and finds a match, the process follows a pipeline from detection through to the alert you investigate.

Figure 3.4: The DLP alert pipeline. Content is scanned by the DLP engine, matched against policy conditions, the configured action is applied, an alert is generated with calculated severity, and the alert lands in the Defender XDR incident queue where the SOC analyst investigates it.

Step 1: Content scanning. The DLP engine evaluates content at the point of action — when an email is sent, when a file is shared, when a document is uploaded to a cloud service, or when content is copied to a clipboard or USB drive (endpoint DLP). The scanning is inline for email (before delivery) and near-real-time for file sharing and endpoint actions.

Step 2: Pattern matching. The engine evaluates the content against every active DLP policy condition. If a credit card SIT detects a pattern that matches the Luhn algorithm and nearby keywords include “credit card,” “expiration,” or “CVV,” the SIT returns a high-confidence match. If the pattern matches the algorithm but no supporting keywords are present, it returns a medium or low-confidence match.

Step 3: Action execution. Based on the policy configuration, the engine takes the specified action. For blocking policies, the email is rejected, the file share is blocked, or the endpoint action is prevented. For audit-only policies, the action proceeds but the event is logged. For override policies, the user sees a policy tip and can provide a business justification to proceed.

Step 4: Alert generation. If the policy is configured to generate alerts, the DLP engine creates an alert with the calculated severity. Alert severity depends on the policy rule configuration: each rule specifies its severity (Low, Medium, High) based on the instance count and confidence level. A policy might generate a Low alert for 1-4 credit card numbers and a High alert for 5 or more. The alert includes the policy name, the matched rule, the SIT or classifier that triggered, the confidence level, the instance count, the content preview, and the user who triggered the match.

Step 5: Incident correlation. The alert enters the Defender XDR correlation engine. If the same user has other recent alerts (an anomalous sign-in, an endpoint alert, or another DLP alert from a different workload), the engine may correlate them into a single incident. This correlation is how DLP alerts connect to broader security investigations — a compromised account that downloads sensitive files AND sends them externally generates both an identity alert and a DLP alert, correlated into one incident.

Policy tips vs alerts vs incidents

DLP generates three types of notifications that serve different audiences. Understanding the distinction prevents confusion during investigation.

Policy tips are user-facing notifications that appear in the application (Outlook, SharePoint, Teams) when content matches a DLP condition. A yellow or red banner warns the user that the content they are about to share contains sensitive data. Policy tips can allow override (the user provides a justification and proceeds), block with override (the user must provide a justification), or block without override (the action is prevented and cannot be bypassed). Policy tips are visible only to the user who triggered the match. They are not alerts — they do not appear in the SOC queue.

Alerts are the notifications that appear in the Defender portal incident queue. Not every policy match generates an alert — the compliance team configures whether each rule generates alerts and at what severity. Audit-only policies may log the match without generating an alert. The relationship between policy tips and alerts is configurable: a policy can show a policy tip to the user AND generate an alert for the SOC, or only show the tip, or only generate the alert.

Incidents are created when the Defender XDR correlation engine groups one or more DLP alerts (potentially with other alert types) into a single investigation unit. A single DLP policy match may generate one alert that becomes one incident. Or a user who triggers multiple DLP alerts across different workloads may have all those alerts correlated into one incident, combined with identity alerts if the account is also flagged as compromised.

Not every policy match is an alert, and not every alert is an incident

When investigating a DLP alert, check the original policy configuration to understand the threshold. If the policy generates alerts for every single-instance match, your queue will be noisy. If it only generates alerts for high-confidence bulk matches, each alert is more significant. Understanding the policy's alerting threshold tells you how much investigation effort the alert warrants — a policy tuned for high-severity-only alerts deserves more attention than a policy that alerts on everything.

Endpoint DLP: device-level data protection

Endpoint DLP extends DLP monitoring to actions on the device itself — not just cloud services. When a user copies a sensitive file to a USB drive, prints it, uploads it to a personal cloud storage site via a browser, copies sensitive text from a document to the clipboard, or accesses the file through an unallowed application, endpoint DLP can detect and optionally block the action.

Endpoint DLP requires devices to be onboarded to MDE (Module 2) because it uses the MDE sensor to monitor file operations. The DLP engine evaluates files at the operating system level, checking content against SITs and sensitivity labels before the action completes. If a user attempts to copy a document labeled “Highly Confidential” to a USB drive and the DLP policy blocks USB sharing of Highly Confidential content, the copy operation is prevented and an alert is generated.

For investigation, endpoint DLP alerts include device-specific context: the device name, the file path, the action attempted (copy to USB, upload via browser, print), and the application used. This context is critical for determining whether the action was intentional (a deliberate attempt to exfiltrate data) or accidental (a user saving a file to the wrong location).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
// Endpoint DLP alerts — find USB exfiltration attempts
CloudAppEvents
| where Timestamp > ago(7d)
| where ActionType has "DlpRule"
| where Application == "Microsoft Defender for Endpoint"
| extend PolicyName = tostring(RawEventData.PolicyName)
| extend RuleName = tostring(RawEventData.RuleName)
| extend TargetAction = tostring(RawEventData.Actions)
| extend Sensitivity = tostring(RawEventData.SensitiveInfoType)
| project Timestamp, AccountDisplayName, PolicyName, RuleName,
    TargetAction, Sensitivity, DeviceName = tostring(RawEventData.DeviceName)
| order by Timestamp desc

DLP policy testing: understanding override and false positive patterns

Before investigating DLP alerts, understand two patterns that dominate the alert queue.

Override patterns. When a policy allows user override, the user provides a business justification and proceeds. The DLP alert still fires, but the override justification is included in the alert details. During investigation, check the justification: “Sending to approved vendor per contract requirement” is a legitimate override. A blank justification or “test” suggests the user is bypassing the policy without valid reason. High override rates on a specific policy may indicate the policy is too broad or the user population is not trained on data handling procedures.

False positive patterns. DLP’s pattern matching is not perfect. A 16-digit product SKU can match a credit card SIT. A test environment email containing sample data triggers the same alert as production data exposure. A marketing document discussing “credit card processing fees” may match credit card SITs at low confidence. During investigation, the content preview in the alert details shows the matched text — examine it to determine whether the match is a genuine sensitive data instance or a false positive pattern.

Track false positive rates per policy and per SIT. If a specific SIT generates 80% false positives in your environment, raise this with the compliance team for policy tuning — adding exclusion conditions for known false positive patterns (test data, marketing content, specific applications) reduces alert noise without reducing protection.

Try it yourself

In the Purview portal (purview.microsoft.com), navigate to Data Loss Prevention → Policies. Examine the default policies in your lab environment (if any exist). Click into a policy to see its structure: the workloads it covers (scope), the sensitive information types it detects (conditions), the actions configured (block, audit, override), and the notification settings (alerts, policy tips). If no policies exist, create a test policy that detects credit card numbers in Exchange Online with audit-only action. Then send yourself an email containing a test credit card number (use 4111 1111 1111 1111, a standard test number). Check the Defender portal for a DLP alert within 15-30 minutes.

What you should observe

The policy structure shows the four components from Figure 3.3: scope (Exchange Online), conditions (credit card number SIT), actions (audit only — no blocking), and notifications (alert generation enabled). The test email triggers a DLP match because the test credit card number passes the Luhn algorithm validation. The alert appears in the Defender portal incident queue with the policy name, the SIT match (Credit Card Number), the confidence level, and a preview of the matched content with the card number partially redacted. This is the same alert format you will investigate in subsection 3.3.

Knowledge check

Check your understanding

1. A DLP alert shows "Credit Card Number" SIT matched with "Low confidence" and 1 instance in an internal Teams message. How much investigation effort does this warrant?

Minimal. Low confidence with a single instance in an internal message is the classic false positive pattern — likely a product SKU, phone number, or random number that happens to match the credit card format. Check the content preview in the alert details: if the matched text is not a credit card number, mark as false positive and close. If the policy generates many of these, recommend tuning to the compliance team (raise the minimum confidence to Medium or High, or increase the minimum instance count).

Maximum — any credit card detection could be a data breach

None — low confidence alerts should be auto-closed

Escalate to compliance — they handle all DLP alerts

DLP alert triage requires context-aware assessment, not one-size-fits-all investigation depth. Low confidence, single instance, internal channel — these are all indicators of a likely false positive. The content preview is the fastest way to confirm or deny. If the preview shows an actual credit card number, escalate. If it shows a product code or test number, close as false positive. Tracking these patterns helps the compliance team tune policies to reduce noise.

2. A DLP alert shows "Credit Card Number" SIT matched with "High confidence" and 247 instances in an email to an external Gmail address. The sender is j.morrison, whose account was flagged as compromised by Defender for Identity 30 minutes before this email was sent. What is this?

A data breach via a compromised account. The sequence is clear: the account was compromised (identity alert), then used to exfiltrate a bulk dataset containing 247 credit card numbers to an external email address. This is a high-severity incident that combines identity compromise and data exfiltration. Immediate actions: confirm containment of the compromised account (Module 1.2), determine whether the email was blocked or delivered (check the DLP action — was this block or audit-only?), identify the source document containing the credit card numbers, and begin data breach notification assessment.

A false positive — DLP SITs are not reliable at high volumes

A compliance violation but not a security incident

An insider risk case — the user is exfiltrating data deliberately

This is the scenario where DLP alerts and security alerts converge. The identity compromise provides the motive (attacker exfiltrating data), the DLP alert provides the evidence (what data, how much, where it went). The correlation engine in Defender XDR should group these alerts into a single incident. The investigation priority is to determine whether the email was blocked (the data stayed inside) or delivered (the data is now in the attacker's possession), which determines whether this is an attempted exfiltration or an actual data breach.

3. A DLP policy is set to "audit only" (no blocking). A user sends an email containing sensitive data to an external recipient. What happens?

The email is delivered to the external recipient (no blocking occurs). The DLP engine logs the match and generates an alert in the Defender portal (if alerts are configured for the policy). The user may or may not see a policy tip depending on policy tip configuration. The key point for investigation: by the time you see the alert, the data has already been sent. Audit-only policies detect but do not prevent — they are appropriate for new policy testing (identifying false positives before enabling blocking) but create a response gap for genuine data exposure because the data leaves before you can intervene.

The email is blocked and returned to the sender

The email is quarantined for review

The email is delivered but the sensitive content is redacted

Audit-only is the DLP equivalent of ASR audit mode — it detects and logs but does not block. This is appropriate during policy testing (just as ASR audit identifies false positives before enabling block mode). But for production protection against data exfiltration, audit-only creates a detection-response gap: the data has already left by the time you investigate the alert. If a policy consistently identifies genuine sensitive data exposure in audit mode with few false positives, it should be upgraded to block mode.

← 3.1 Microsoft Purview for Security Operations 3.3 Investigating DLP Alerts in the Defender Portal →