Microsoft Purview - Data Loss Prevention Fundamentals

Summary

Every Microsoft Purview DLP policy comes down to three moving parts: where it looks, what it's looking for, and what happens when it finds a match. The locations are the workloads it can reach: Exchange Online, SharePoint, OneDrive, Teams, Copilot experiences, and endpoint devices once a file has already left the cloud. The conditions are usually a sensitive information type, like a credit card number or a passport ID, though a sensitivity label or a keyword pattern works too, and conditions can be combined to narrow down exactly what counts as a match. The actions range from a quiet audit entry to a hard block, and a single rule can combine several of them at once. None of this is safe to turn on at full strength on day one. Microsoft's own guidance is to run a new policy in simulation first, read the alerts it produces, and only then start notifying or blocking real users. Get that sequence backward, and a security control turns into an outage nobody asked for.

Locations

A policy only ever looks where you point it. When you build one in the Microsoft Purview compliance portal, or through Security & Compliance PowerShell, you choose which workloads it covers: Exchange email, SharePoint sites, OneDrive accounts, Teams chats, and now Copilot experiences too, so a rule can catch what someone pastes into Microsoft 365 Copilot the same way it catches an email attachment.

A policy can also mix several locations in one definition, which is how most production policies work. A Social Security number sitting in a SharePoint document is just as much a problem as one attached to an email, so there is rarely a reason to scope a policy to just one place.

Conditions

Conditions define what counts as a match. Most rules key off a sensitive information type, things like a credit card number, a passport ID, or a Social Security number, and Microsoft Purview ships with a large built-in library of these that gets updated over time. A rule can also require a minimum number of matches before it fires, which matters more than it sounds. One Social Security number in an email might be a routine HR form. A spreadsheet with two hundred of them looks like a breach, and a policy should treat those two situations differently.

Sensitivity labels work as a condition too. A rule can require both a Confidential label and a detected credit card number in the same document before it does anything, which sets a meaningfully higher bar than either condition on its own.

Actions

Actions define what happens once a rule's conditions are met, and a policy has more than one option. A hard block stops the action outright, whether that's sending an email or sharing a file. Block with override still stops it by default, but lets a user push through after typing a business justification, which suits cases that are legitimate more often than not. A policy tip just notifies the user in the moment, explaining what the rule found without stopping anything. An audit entry quietly logs the event for an administrator to review later.

None of these are exclusive. A single rule commonly blocks the action, shows the user a policy tip explaining why, and sends a report to a security team, all at once.

Staged Rollout

Microsoft's own guidance is to never launch a new policy straight into enforcement. The safest starting point is simulation mode, sometimes called test mode: the policy evaluates every match and logs it, but blocks nothing and notifies no one. That's the only real way to see how a new rule behaves against actual traffic before it can disrupt anyone's work.

Once the alert volume looks reasonable, the next stage turns on user notifications, so people start seeing policy tips before anything is blocked. A user who pushes back on a false positive at this stage is handing you exactly the feedback a policy needs before it starts blocking things for real. Only after that does a policy move to full enforcement. Skipping a stage doesn't make the rollout faster. It just moves the testing into production, where the people finding the bugs are the ones the policy was supposed to help.

Endpoint DLP

Endpoint DLP extends everything above onto the device itself, once a file has already left the cloud. It can restrict or audit specific actions: copying to a USB drive, printing, taking a screen capture, moving a file to a network share, or pasting sensitive content into a website, including a generative AI chat site reached through a browser. Each of these can be set to simply audit the activity, block it outright, or warn the user first.

Turning on endpoint restrictions requires the Compliance Administrator or Compliance Data Administrator role in Microsoft Entra ID, worth checking before a rollout stalls on a permissions problem instead of a policy one. A restriction that blocks or warns should always come paired with a notification. A restriction nobody sees just looks like a broken clipboard, not a deliberate policy, and that same clipboard-level protection is starting to extend past Microsoft's own apps too, which is where this series picks up next.

Conclusion

A DLP policy is never really one setting. It's three: where you look, what you're looking for, and what happens when you find it. Start every new policy in simulation, let real traffic show you where the false positives sit, and only reach for a hard block once the alerts have earned your confidence. Endpoint DLP just extends that same logic further, from a SharePoint site to a USB port to a browser tab. Get the sequence right and the policy disappears into the background, doing its job. Get it backward and it becomes the thing every user in the building learns to work around.