Why Microsoft Purview DLP Requires 4 Policies for Every Business Rule

The Promise vs. The Reality

Data Loss Prevention sounds straightforward: detect sensitive information, apply an action (block, warn, or audit), done. If you have experience with legacy DLP solutions like Forcepoint or Symantec, that is roughly how it works. You define what is sensitive, you define the action, and the policy applies consistently regardless of how data leaves your environment.

Microsoft Purview does not work that way.

We have inherited DLP implementations where organisations spent months troubleshooting “broken” policies, only to discover the policies were not broken at all. They were working exactly as Microsoft designed them. The problem was that Microsoft built four different DLP engines with four different capability sets, then put them under one brand name.

The Architecture: Four Engines, One Name

When Microsoft markets “Unified DLP,” they are describing a single management interface — not a single enforcement engine. Behind that interface, you are dealing with four distinct enforcement engines. While Endpoint DLP and Web DLP are configured together in the same policy location, they still represent separate enforcement surfaces alongside Exchange, SharePoint & OneDrive, and Teams:

Each engine has different detection timing, different enforcement capabilities, and different scope models:

• •Teams can only block or allow — there is no “warn and let the user override” option.
• •Endpoint & Web DLP can distinguish between a personal USB and a corporate-approved device, and control uploads to SaaS apps and personal cloud storage.
• •SharePoint & OneDrive DLP can restrict sharing links but cannot prevent someone from downloading and emailing the file.
• •Exchange DLP is the most mature engine — supporting transport rules, encryption, and recipient-based restrictions.

The consequence: a single business requirement like “Block external sharing of Confidential files” cannot be implemented as one policy. You need four.

This is not a Purview bug. It is the architecture. If you do not account for it from day one, you will spend months asking why “the policy is not working” when it is working exactly as designed — just not on the channel you expected.

The Scope Trap: Users vs. Sites

This catches experienced administrators off guard, and has significant implications for your data protection strategy.

Why This Matters

A Finance user downloads a confidential file from the Finance SharePoint site (protected by SharePoint & OneDrive DLP). They upload it to the Marketing SharePoint site.

Your Finance DLP policies do not follow the file. The file is now in Marketing’s territory, subject to Marketing’s site-level policies — or no policies at all if Marketing does not have DLP configured for their SharePoint and OneDrive locations.

This is why mature Purview implementations maintain both user-scoped policies (Endpoint & Web) and site-scoped policies (SharePoint & OneDrive). You cannot rely on one to cover the other.

Policy Governance: Naming Conventions That Scale

When you are managing 40+ policies, discoverability becomes critical. We have seen organisations with policies named “Financial Block Policy” or “New DLP Rule 2” — impossible to troubleshoot when something goes wrong.

When a user reports that they cannot share a file, you should be able to look at the policy name and immediately know which channel it covers and what action it takes. After auditing dozens of Purview implementations, this is surprisingly rare.

The Pitfalls Microsoft Does Not Warn You About

The documentation describes what each channel can do. It does not describe what happens when you try to force a unified approach.

• •“Block with override” on Teams — Does not exist. The policy either blocks or it does not. If you enable override at the policy level, Teams will ignore it and default to block.
• •Grouping Endpoint with Teams in one policy — Endpoint has 10+ granular actions; Teams has 2. When grouped, the policy evaluates at the lowest common denominator. You lose Endpoint granularity.
• •Expecting real-time SharePoint & OneDrive enforcement — SharePoint & OneDrive DLP evaluates on file activity (upload, share), not continuously. A file modified after upload might not trigger re-evaluation until the next sharing action.
• •Web DLP without Defender for Cloud Apps — Web DLP for SaaS apps requires Defender for Cloud Apps integration. Without it, you only cover managed browsers, not the full exfiltration surface.

Beyond Configuration: Governance and Integration

Implementing the 4-policy rule is just the start. Maturing your DLP strategy means shifting from simple blocking to an ongoing data governance model. This requires regular dashboard reviews, workflow-driven notifications to guide users instead of drowning admins, and monthly classifier tuning.

Furthermore, DLP does not operate in a silo. To build a truly resilient defence, connect DLP signals with Insider Risk Management to correlate data movement with user intent. Script custom regular expressions for complex patterns, and ensure policy tips are enabled across all workloads to educate employees at the exact moment of risk.

The Honest Assessment

Microsoft Purview is genuinely powerful — once you understand what it actually is. It is not a unified DLP solution. It is four specialised engines with a shared console.

Organisations that succeed treat each engine as a distinct implementation project. They budget for the 4x multiplier. They design naming conventions before creating policies.

Organisations that struggle try to force Purview into the “write once, apply everywhere” model. They create one policy, enable all locations, and spend months troubleshooting inconsistent behaviour.