You built the DLP policy. The compliance checkbox is checked. Three months later, sensitive data walks out the door anyway. This is not a hypothetical: it is the most common outcome for Microsoft 365 DLP deployments that were done right on paper but wrong in practice.

This post covers the five mistakes that consistently undermine Microsoft Purview DLP deployments in mid-market organizations, what the enforcement limits actually look like, and what a properly structured DLP policy set should include.

Microsoft Purview DLP is not one system; it is four separate enforcement engines that do not share policy scope. Most IT teams configure one engine and assume they are covered. The result is a policy that looks complete in the portal and does nothing for Teams chats, endpoint devices, or SharePoint files uploaded in bulk.

A DLP policy in Microsoft Purview is a rule set that detects and acts on sensitive information across Microsoft 365 services. Each policy defines which services to monitor (Exchange, SharePoint, OneDrive, Teams, or endpoint devices), which sensitive information types to detect, and what action to take when a match occurs: audit, warn, block, or notify. Policies are configured in the Microsoft Purview compliance portal and enforced separately by each service’s native engine.

Mistake 1: Treating Microsoft Purview DLP as a Single System

The most damaging architectural misunderstanding in DLP deployments is treating “Microsoft Purview DLP” as a unified enforcement layer. It is not. When you create a policy in the Purview compliance portal, you are writing instructions that will be interpreted separately by up to four different enforcement engines: Exchange Online, SharePoint and OneDrive, Microsoft Teams, and Windows endpoint devices.

Each engine has its own enforcement model, its own latency, and its own limitations. A policy scoped to Exchange will not protect Teams messages, even if the content is identical. A policy covering SharePoint document libraries will not catch a file being copied to a USB drive. These are not bugs; they are the architecture. The problem is that the Purview portal makes it easy to scope a policy to “all locations” with a single toggle, but what that actually enforces in each context requires reading the DLP policy reference documentation carefully.

Selecting “All locations” when creating a DLP policy does not mean all enforcement engines are active. Endpoint DLP requires devices to be onboarded to Microsoft Purview separately. If your Windows endpoints are not onboarded, endpoint rules in your policy are silently ignored with no error or alert.

In our work with mid-market GTA organizations, this is the single most common gap we find when reviewing existing DLP configurations: a well-written Exchange policy that was never extended to Teams or SharePoint, because the team assumed one policy covered everything.

Mistake 2: Not Knowing Your Licensing Ceiling Before You Design

Microsoft Purview DLP capabilities are split across licence tiers in ways that are not obvious until you try to enable a feature. Teams message DLP, endpoint DLP, and Adaptive Protection (which dynamically tightens controls based on insider risk signals) all require licences beyond what most mid-market organizations already have.

Feature M365 Business Premium M365 E3 M365 E5 / E5 Compliance
Exchange DLP Yes Yes Yes
SharePoint / OneDrive DLP Yes Yes Yes
Teams message DLP No No Yes
Endpoint DLP (Windows) No No Yes
Endpoint DLP (macOS) No No Yes (limited activities)
Adaptive Protection No No Yes
Exact Data Match (EDM) No No Yes

If your organization is on M365 Business Premium or E3, Teams DLP and endpoint DLP are not available without adding the Microsoft 365 E5 Compliance add-on. Knowing this before you build your DLP program means you can scope policies realistically, communicate gaps to leadership, and budget for the correct licence tier if Teams or endpoint coverage is required.

The M365 E5 Compliance add-on can be purchased on top of Business Premium or E3 for specific users who need endpoint or Teams DLP coverage, rather than upgrading your entire tenant. For mid-market organizations with 50 to 200 seats, this is often the most cost-effective path to full coverage.

Mistake 3: Ignoring Policy Priority Order and Conflict Resolution

When multiple DLP policies match the same event, Microsoft Purview applies the most restrictive action from the highest-priority policy. Priority is determined by the order policies appear in the Purview compliance portal: lower number equals higher priority. Most organizations never configure this deliberately. The result is that whichever policy was created first gets the highest priority by default, which is almost never the right outcome.

The practical consequence: if you have a broad informational policy set to audit-only that was created early in your deployment, and a stricter block policy created later, the audit policy will win for any content matching both. Your block rule never fires. This is not visible in normal portal views; you need to check Activity Explorer to see which policy matched and what action was taken.

Use a naming convention that reflects intent and scope from the start: for example, “01-PCI-Block-Exchange,” “02-SIN-Warn-SharePoint,” “03-Confidential-Audit-All.” The numbered prefix makes priority order visible in the portal list without clicking into each policy. Document the intended priority order in a DLP runbook and review it whenever a new policy is added.

Mistake 4: Treating False Positive Management as a Launch Task

Every Purview DLP deployment generates false positives. The volume depends on how broadly your sensitive information types are scoped and how much your organization’s legitimate work involves content that resembles sensitive data. Financial services, legal, and healthcare firms are especially prone to high false positive rates because credit card numbers, Social Insurance Numbers, and health identifiers appear regularly in day-to-day documents.

The mistake is treating false positive resolution as something you do at launch and then move on from. In practice, the alert queue grows continuously. Without a defined review workflow, it becomes a backlog that no one looks at. When the alert queue is ignored, legitimate violations get buried alongside noise, which defeats the purpose of the system entirely.

A workable false positive workflow has three components: a defined owner for the DLP alert queue (usually the IT security lead or a shared security operations function), a weekly triage cadence during the first 90 days of any new policy, and a documented threshold for when a false positive rate triggers a policy tune-up. Microsoft added the ability to classify alerts as false positives, true positives, or benign in the DLP Alerts dashboard in late 2025, which makes this workflow significantly easier to track over time. Use it.

Mistake 5: Assuming SharePoint DLP Coverage Is Real-Time

DLP enforcement on SharePoint and OneDrive operates on the search crawler index, not on the file upload event itself. When a file lands in SharePoint, it is not immediately scanned for sensitive content. It is evaluated when the search crawler processes it, which can take anywhere from minutes to several hours depending on crawl queue depth and file volume.

This matters most during bulk data migrations or large file imports. If your organization migrates a file share to SharePoint, thousands of files enter the environment before DLP has had a chance to evaluate any of them. For organizations subject to PIPEDA breach notification obligations, this is a real compliance exposure window, not a theoretical one.

If you are planning a SharePoint migration, notify your DLP policy owner before the migration begins. Consider restricting broad access permissions on the destination library during the crawl period and applying sensitivity labels to known-sensitive files before migration to add a secondary control layer while DLP catches up.

What Microsoft Purview DLP Cannot Protect Against

Understanding where enforcement ends is as important as knowing what it covers. These are the gaps no Purview DLP policy can close on its own:

  • Images and screenshots: Purview DLP does not inspect image files or screen captures for sensitive content. A Social Insurance Number or credit card number in a scanned PDF or screenshot is invisible to the policy engine.
  • ZIP and compressed archives: Files inside a ZIP archive are not inspected. Sensitive content inside a compressed file bypasses detection entirely.
  • BYOD and unmanaged personal devices: Endpoint DLP requires Intune management or Purview device onboarding. Personal devices used for work are not covered unless enrolled in device management.
  • Third-party SaaS applications: Purview DLP does not extend to Slack, Google Drive, Salesforce, or any non-Microsoft SaaS tool. Data moving to or from those platforms is outside scope.
  • Camera and verbal disclosure: Someone photographing a screen or reading sensitive data aloud cannot be detected by any DLP system. These insider risk scenarios require procedural controls, not technical ones.

These gaps are not reasons to avoid Purview DLP; they are reasons to layer it with complementary controls including managed detection and response, Purview Insider Risk Management, and Conditional Access policies that restrict where sensitive data can be accessed from.

A Minimum Viable DLP Policy Set for Mid-Market Canadian Organizations

Based on deployments across GTA mid-market clients, this is the minimum policy set that provides meaningful coverage across M365 for organizations on E3 or Business Premium. Organizations on E5 should extend each policy to include endpoint and Teams locations where applicable.

Policy 1: Payment Card Data (PCI): Detect credit card numbers across Exchange, SharePoint, and OneDrive. Action: block external sharing, notify sender and compliance team. Run in audit mode for two weeks before enforcing to assess false positive volume.

Policy 2: Social Insurance Numbers (PII): Detect Canadian Social Insurance Numbers across Exchange, SharePoint, and OneDrive. Action: warn on external send, block bulk sharing above five instances. Include a policy tip that explains acceptable handling procedures.

Policy 3: Health Information (PHIPA): For organizations in or serving healthcare, detect health information types across Exchange and SharePoint. Action: block external sharing, alert the privacy officer. Coordinate with your PHIPA compliance lead before going live.

Policy 4: Confidential Label Enforcement: Block or warn on external sharing of any document carrying a “Confidential” or “Highly Confidential” sensitivity label. This requires Microsoft Purview Information Protection labels to be deployed and adopted first. Without label adoption by users, this policy does nothing.

Policy 5: Endpoint DLP (E5 or Compliance Add-On Required): Restrict copy-to-USB, print-to-unmanaged-printer, and browser upload of files containing sensitive information types from Purview-onboarded Windows devices. Deploy in audit mode first; endpoint DLP generates high false positive volume on initial deployment, especially in environments with legacy document workflows.

Run each new policy in audit mode for a minimum of two weeks before enforcing it. Use the Activity Explorer in the Purview compliance portal to review which rules are matching, which users are triggering alerts most often, and whether the match is legitimate or a false positive. A policy that generates hundreds of false positive alerts per week will create alert fatigue and lose stakeholder trust before it ever blocks a real violation.

Microsoft Purview DLP is a powerful control, but it requires deliberate architecture decisions. Know which engines you are actually configuring. Know your licensing ceiling before you design. Set policy priority intentionally. Build a false positive workflow before you go live. Document the enforcement gaps so the business understands what DLP does and does not cover. A policy that looks complete in the portal but was never tested end-to-end provides false confidence, and false confidence in a security control is worse than no control at all.

If you are reviewing your M365 DLP configuration or starting from scratch, the team at Balanced+ works with mid-market GTA organizations on managed cybersecurity services that include Purview DLP design, deployment, and ongoing alert management. A configuration review is often enough to surface the most critical gaps before they become incidents.

Frequently Asked Questions

What is a DLP policy in Microsoft 365?

A DLP policy in Microsoft 365 is a rule set configured in the Microsoft Purview compliance portal that detects sensitive information (such as credit card numbers, Social Insurance Numbers, or health data) across M365 services and takes automated action when a match is found. Actions can include auditing the event, displaying a policy tip to the user, blocking the action, or alerting a compliance administrator. Each policy applies separately to the enforcement engine of each selected service location.

Does one DLP policy cover Exchange, Teams, and SharePoint at the same time?

A policy can be scoped to multiple locations, but each location is enforced by a separate engine with its own behaviour and limitations. Teams DLP requires an E5 or E5 Compliance licence; without it, Teams is not covered even if selected in the policy scope. SharePoint enforcement is based on the search crawler index rather than real-time file events. Exchange enforcement is near-real-time. Each location should be verified independently to confirm enforcement is actually active.

How long does it take for a new DLP policy to take effect?

According to Microsoft’s DLP policy reference documentation, new policies and policy changes can take up to 24 hours to propagate fully across all M365 services. Exchange policies typically propagate faster, within one to two hours, while SharePoint and OneDrive policies depend on crawler scheduling. Do not test enforcement immediately after creating a policy; allow at least a few hours before concluding that a policy is not working.

What is the difference between audit mode and enforce mode in Purview DLP?

In audit mode, Purview DLP logs all policy matches and generates alerts but does not take any action on the content or notify users. This is the recommended starting point for any new policy, as it lets you assess match volume, identify false positives, and tune rules before any user-facing disruption occurs. Enforce mode takes the configured action (such as blocking a send or displaying a policy tip). Moving from audit to enforce should happen only after at least two weeks of alert review and active tuning.

Sources