Endpoint DLP and Alert Response
Extend data loss prevention to endpoint devices, and master the workflow for reviewing and responding to DLP alerts, events, and reports.
DLP beyond the cloud
Cloud DLP protects data in M365 apps. But what about when a user copies patient data to a USB drive, prints it, or uploads it to a personal Dropbox? That’s where Endpoint DLP steps in.
Endpoint DLP extends data protection to the device itself — monitoring file activities like copy to USB, print, upload to cloud, and copy to clipboard. It uses the same DLP policies and SITs you’ve already configured, but the enforcement happens at the endpoint level.
Configuring Endpoint DLP
Prerequisites
| Requirement | Detail |
|---|---|
| Device onboarding | Devices must be onboarded to Microsoft Purview (uses Defender for Endpoint onboarding) |
| Supported platforms | Windows 10/11, macOS (three latest released versions) |
| Licensing | M365 E5, M365 E5 Compliance, or standalone Endpoint DLP licence |
| Management | Devices managed via Intune or Configuration Manager |
Endpoint DLP settings
Global settings for Endpoint DLP are configured in Purview compliance portal > Data loss prevention > Endpoint DLP settings:
| Setting | What It Controls |
|---|---|
| Unallowed browsers | Browsers that can’t access sensitive data (e.g., block Chrome for certain data) |
| Unallowed apps | Applications that can’t access sensitive files |
| Service domains | Cloud services where upload is monitored (Dropbox, personal OneDrive, etc.) |
| File path exclusions | Paths exempt from monitoring (e.g., temp folders used by approved apps) |
| Unallowed Bluetooth apps | Block Bluetooth sharing from specific apps |
Adding devices to DLP policies
Once devices are onboarded, add “Devices” as a location in your DLP policy:
| Setting | Configuration |
|---|---|
| Location | Devices (all onboarded, or specific groups) |
| Conditions | Same as cloud DLP — SITs, sensitivity labels, file types |
| Activities to monitor | Copy to USB, print, upload to cloud, copy to clipboard, access by unallowed apps |
| Action | Audit, warn, or block each activity independently |
Elena’s Endpoint DLP design
For MedGuard Health devices containing patient data:
| Activity | Action | Justification |
|---|---|---|
| Copy to USB | Block | Patient data must never leave on removable media |
| Warn with override | Some departments need to print — require justification | |
| Upload to personal cloud | Block | No patient data on personal Dropbox/Google Drive |
| Copy to clipboard | Audit only | Too disruptive to block clipboard — monitor and investigate patterns |
Exam tip: Endpoint DLP vs Defender for Endpoint
The exam distinguishes between these two related but different capabilities:
- Endpoint DLP (Purview) — focuses on data loss prevention. Monitors file activities involving sensitive data. Prevents data exfiltration.
- Defender for Endpoint — focuses on threat protection. Detects malware, suspicious processes, and vulnerabilities. Responds to security incidents.
Both use the same onboarding mechanism, but they serve different purposes. Endpoint DLP is compliance; Defender for Endpoint is security. Both can be active on the same device.
DLP alerts, events, and reports
DLP alerts dashboard
Purview compliance portal > Data loss prevention > Alerts shows DLP policy matches:
| Column | What It Shows |
|---|---|
| Severity | High, Medium, Low, Informational |
| Status | New, In Progress, Resolved, Dismissed |
| User | Who triggered the alert |
| Policy | Which DLP policy matched |
| Location | Where the activity occurred (Exchange, SPO, endpoint, etc.) |
| Activity | What the user tried to do (share, email, print, copy to USB) |
| Time | When the activity occurred |
Alert investigation workflow
When Elena receives a High severity DLP alert:
- Review the alert — what data was involved, who triggered it, where
- Check context — was it accidental (user emailed wrong recipient) or intentional (data theft attempt)?
- Take action:
- False positive → dismiss the alert, adjust the policy to reduce noise
- Accidental → educate the user, consider the policy tip effectiveness
- Intentional → escalate to security team, preserve evidence, consider insider risk investigation
- Close the alert — set status to Resolved or Dismissed with notes
- Update policy — if the alert revealed a gap or generated false positives
DLP reports
| Report | What It Shows |
|---|---|
| DLP policy matches | How many times each policy was triggered, by workload |
| DLP incidents | Individual incidents with details for investigation |
| DLP false positive overrides | How often users override DLP warnings with justifications |
| Top sensitive information types | Which SITs are detected most frequently |
Deep dive: Tuning DLP policies to reduce alert fatigue
Alert fatigue is a real risk with DLP. Elena’s approach:
- Start with audit-only policies to understand baseline alert volumes
- Review false positive rates — if over 30%, the SIT confidence level is likely too low
- Use high confidence for blocking actions, medium confidence for warnings
- Configure user overrides for business-justified scenarios — these generate override reports instead of block alerts
- Use alert aggregation — combine multiple low-severity events into a single alert instead of flooding the dashboard
- Review DLP reports monthly to identify trends and adjust policies
The goal is actionable alerts, not a flood of noise.
Key concepts to remember
Knowledge check
Elena discovers that MedGuard Health staff are copying patient data spreadsheets to personal USB drives. Cloud DLP policies don't prevent this because the activity happens on the device. What should Elena implement?
Dev reviews the DLP alerts dashboard for a client and sees 500 alerts in the past week — 80% are false positives from the credit card SIT matching internal product codes that look like card numbers. What should Dev do?
🎬 Video coming soon
Congratulations! You’ve completed all 4 domains of the MS-102 study guide. Review any modules you found challenging, then test your knowledge with the practice questions.