Data Loss Prevention with Microsoft Purview

What this guide covers

Data Loss Prevention is easy to misread. Vendors sell it as a net that catches every leak. The documentation makes it sound like a sprawl of policies, locations, conditions, and actions with no obvious starting point, and the policy wizard quietly assumes you already know what to detect, where, and what to do when it fires.

In practice, DLP is only as good as two things: how accurately it identifies sensitive content, and how disciplined you are about what happens when it finds it. Get either wrong and you end up with a wall of false positives nobody reads, or a policy so timid it protects nothing. The traps that decide which way you fall are the ones the docs bury on separate pages. The location you choose silently constrains which conditions and actions even exist, so bolting Teams onto a working SharePoint policy can drop your label-based detection with no error. Encrypting a file to protect it can hide its contents from the DLP engine you were counting on to read them.

This book is the connected account Microsoft never publishes in one place. It walks the product from what it costs and can see, through a hands-on trial build, into the detection engine, across every workload including endpoints, and out to the failure modes you only meet after a quarter in production. Every license boundary, condition, and portal path is grounded against current Microsoft Learn and validated in a live Microsoft 365 E5 lab. You do not need a production tenant to follow along; a trial and a single test device are enough.

Chapter map

1. What DLP Actually Is (and Isn't)
2. Licensing and Prerequisites
3. The Detection Foundation: Sensitive Info Types, EDM, and Trainable Classifiers
4. Building DLP Policies: Conditions, Actions, and Precedence
5. DLP Across the Cloud Workloads: Exchange, SharePoint, OneDrive, and Teams
6. Endpoint DLP: Devices, Restricted Activities, and Just-in-Time Protection
7. DLP in Microsoft Defender for Cloud Apps
8. Adaptive Protection: Wiring DLP to Insider Risk
9. Alerts, Investigation, and Tuning Out the Noise
10. Operational Limits, Gotchas, and Troubleshooting

Appendices: PowerShell and Graph for DLP; Microsoft Learn Bibliography; Production Readiness Checklist.

Who it is for

This is for the security engineer or consultant standing up Purview DLP in a real tenant for the first time, the compliance or privacy officer who has to judge what DLP realistically enforces before signing off on it, and the SOC analyst who will triage the alerts and wants to understand the policy machinery upstream; it is not a cert-cram, but the data loss prevention and classification depth it covers in practice is exactly what SC-401, Administering Information Security in Microsoft 365, expects you to know.

See where you are

7 questions from this guide's territory (3 easy, 4 medium), with the explanation after each. Nothing is stored and nothing is sent anywhere.

The rest of Microsoft Purview Field Guides

One product per book, a lab appendix in every one, and a companion page like this one for each.

• 
  Field guide

  Audit, Alerts, and Investigation with Microsoft Purview

  The what-happened ticket arrives with a deadline, and the event you need aged out of the audit log months ago. The investigation surface, in the order you use it.

  Kindle$12.99Get it on AmazonCompanion page
• 
  Field guide

  Communication Compliance with Microsoft Purview

  One Microsoft Purview tool reads your employees' messages, inspecting Teams, Exchange, Viva Engage, Copilot prompts, and connected third-party sources for harassment, threats, and regulatory violations.

  Kindle$12.99Get it on AmazonCompanion page
• 
  Field guide

  eDiscovery and Legal Holds with Microsoft Purview

  When legal hands you a hold notice, the clock is real and the stakes include sanctions. Holds preserve and searches collect, so a matter you searched but never held can quietly lose data before anyone notices.

  Kindle$12.99Get it on AmazonCompanion page
• 
  Field guide

  Insider Risk Management with Microsoft Purview

  There is no button that blocks the leak.

  Kindle$12.99Get it on AmazonCompanion page
• 
  Field guide

  Data Retention and Records Management with Microsoft Purview

  Nothing visibly breaks when retention is wrong.

  Kindle$12.99Get it on AmazonCompanion page
• 
  Field guide

  Sensitivity Labels and Data Classification with Microsoft Purview

  Classify your data once and the protection travels everywhere. That is the pitch.

  Kindle$12.99Get it on AmazonCompanion page

The hard set (3 questions)

The hardest SC-401 questions this guide publishes, none of them repeated from the placement quiz above: the answer first, why every other option is wrong, and the Microsoft Learn page behind it. The practice book for this exam holds the full bank.

Your endpoint DLP rollout covers Windows 10/11 devices. Users browse in Microsoft Edge, Google Chrome, and Mozilla Firefox. You need endpoint DLP to monitor and block sensitive uploads to restricted cloud-service domains across all three browsers. What must you deploy, and what is the platform constraint?

Correct answer: D. The Microsoft Purview extension for Chrome and the Microsoft Purview extension for Firefox; Edge needs no extension. The extensions are supported on Windows 10/11 devices only.

Edge is instrumented for endpoint DLP natively and needs no add-on. To extend endpoint DLP activity monitoring and protective actions (upload to a restricted service domain, print, copy to clipboard / removable storage / network share) to Chrome and Firefox, you install the Microsoft Purview extension for Chrome and the Microsoft Purview extension for Firefox respectively. Per Learn, these extensions are for Windows 10/11 devices. Where the extension is installed, it bypasses the unallowed-browser and unallowed-app restrictions for that browser, so monitoring works instead of a hard block.

Why the other options are wrong:

• A. Adding Chrome/Firefox to the Unallowed browsers list forces users to Edge; it does not give you monitoring within those browsers. Installing the extension is what enables in-browser monitoring, and it bypasses the unallowed lists where installed.
• B. There is no single universal package. Chrome and Firefox each have their own dedicated Microsoft Purview extension; Edge needs none.
• C. Endpoint DLP does not natively instrument Chrome and Firefox the way it does Edge. Without the Purview extensions, those browsers are treated as unsupported (and can be redirected to Edge or blocked).

Memory hook: Edge is built in. Chrome and Firefox each need their own Purview extension, and only on Windows. The extension is what turns a hard block into actual monitoring.

Microsoft Learn: DLP chrome

A DLP policy scoped to OneDrive has an include list containing Security Group B plus one individually listed user, User A. User C is a member of Security Group B but is not individually listed in the policy. According to the policy-scoping behavior described in the manuscript, is User C in scope?

Correct answer: B. No. When you mix individual users and groups in the same include list, DLP scopes the policy to the intersection: the union of the listed groups' members overlapped with the union of the individually listed users. User C is in Security Group B but is not individually listed, so User C falls out of scope.

Microsoft Learn's DLP policy reference explicitly documents this intersection trap: 'when users and groups are mixed in the scoping configuration,' DLP 'only scopes policies to users to the intersection of the listed groups and users.' Learn's worked example shows that with Group1, Group2, User3, and User4 in the include list, only User3 ends up in scope, because User3 is the only user that appears in both the union of group members and the union of listed users. Here the include list mixes Security Group B with individually listed User A, so the intersection rule applies. User C is in the group union through Security Group B but is not in the user union, so User C falls outside the intersection and out of scope.

Why the other options are wrong:

• A. The group type (mail-enabled vs. Microsoft 365) affects other scoping behaviors (like Teams channel protection) but the mixed-user-and-group intersection trap applies regardless of group type.
• C. Individual user listings do not override group listings to produce a union. Mixing creates an intersection, which typically produces a much smaller in-scope set than expected.
• D. The union behavior applies when you list only groups (no individual users). Once you mix individual users and groups, the behavior switches to intersection. This policy's include list contains an individually listed user (User A), so the groups-only union rule does not apply.

Memory hook: Mixed include = intersection. Groups only = union. The instant you add an individual to a group-based include list, you switch from OR to AND and start dropping members.

Microsoft Learn: DLP policy reference

You configure Adaptive Protection and an associated DLP policy. A user who is currently at Elevated insider risk level is attempting to share a Confidential-labeled document externally. The DLP policy is set to block sharing of Confidential-labeled documents when the Insider risk level for Adaptive Protection is Elevated. The policy has been enabled for 24 hours. The block is not firing. What is the most likely cause?

Correct answer: D. Adaptive Protection risk levels take up to 36 hours after being turned on before they begin driving DLP enforcement. The policy may simply not have finished activating.

After enabling Adaptive Protection, it can take up to 36 hours before risk levels begin applying and actions take effect. The full quick-setup pipeline can take up to 72 hours. A policy enabled for only 24 hours may not have fully activated. The recommendation is to tune the underlying IRM policy before enabling Adaptive Protection and to account for the 36-72 hour window before expecting blocks to fire.

Why the other options are wrong:

• A. The 'Insider risk level for Adaptive Protection' condition is supported in Exchange, Teams, and Devices; SharePoint is absent from the documented list. But the scenario never says the sharing happened from SharePoint, so the 36-72 hour activation window remains the far more likely root cause.
• B. Risk levels in Adaptive Protection are automatically assigned by Insider Risk Management based on user activity. No manual analyst escalation is required for the DLP condition to evaluate the risk level.
• C. There is no mandatory 7-day audit period before an Adaptive Protection-integrated DLP policy can block. The auto-created DLP policies from quick setup begin in audit mode, but an admin can switch to block without waiting 7 days.

Memory hook: Adaptive Protection: 36 hours minimum before risk levels drive enforcement. Full pipeline can take 72 hours. Tune IRM first, then enable. Don't test same-day.

Microsoft Learn: Insider risk management adaptive protection