Designing Purview DLP policies: locations, rules, conditions, actions and priority

Many "DLP isn't working" tickets are design problems: a policy scoped to the wrong group, locations that quietly limit the available conditions, or a rule that never acts because another one wins. In this post I'll take a Microsoft Purview data loss prevention (DLP) policy apart layer by layer, explain how rule and policy priority decide the outcome, and finish with a starter set you can put into simulation.

How it works: the anatomy of a DLP policy#

A policy answers four questions: what to protect (a template or your own definitions), where to look (locations and their scope), what to do on a match (rules) and how hard to enforce (simulation or on). You build it in the Microsoft Purview portal under Solutions › Data loss prevention › Policies › Create policy.

Locations and scope#

The main locations are Exchange email, SharePoint sites, OneDrive accounts, Teams chat and channel messages, Devices, cloud app instances, on-premises repositories, and Fabric and Power BI workspaces. Newer locations such as Microsoft 365 Copilot and managed or unmanaged cloud apps are only offered in the Custom template. Each location scopes differently:

• Exchange: scoped by group membership and effectively by sender. Microsoft's scoping table shows that mail from an out-of-scope sender isn't evaluated even when the recipient is in scope. An exclusion beats an inclusion, and a policy holds at most 50 group inclusions and exclusions.
• OneDrive: up to 100 individual users or 50 groups. Mix users and groups and DLP applies the policy only to the intersection, so put stray users into a group of their own.
• SharePoint: up to 100 sites, or the sites in an administrative unit.
• Devices: the user and the device must both be in scope, otherwise nothing is enforced.

Combining locations narrows what a policy can use. Only the conditions the chosen locations share are offered, and for content definitions a "no" in any location wins: Teams supports only sensitive information types (SITs), so a policy covering SharePoint and Teams can't match on sensitivity or retention labels, while the Copilot location works only with sensitivity labels.

Rules: conditions, exceptions, actions and the rest#

• Conditions start with Content contains: SITs, sensitivity labels, retention labels or trainable classifiers, grouped with Any of these or All of these. SITs carry a confidence level and instance counts. Location-specific context narrows the match; for email that includes recipient domain, sender group, headers, password-protected attachments and Content is shared from Microsoft 365 with people outside the organization.
• Exceptions use the same building blocks (the ExceptIf parameters in PowerShell, such as ExceptIfRecipientDomainIs).
• Actions depend on the location. For email, Restrict access or encrypt the content in Microsoft 365 locations (BlockAccess) blocks everyone or only external recipients, or encrypts; other actions deliver to the hosted quarantine, forward for approval, redirect, add recipients, prepend the subject, apply a disclaimer or set a header. Devices get Audit, Block with override or Block per activity.
• User notifications and overrides drive policy tips and notification emails, and decide whether users can override a block, with or without a business justification.
• Incident reports set the severity and whether an alert fires on every match or only when a volume threshold is reached.
• Additional options set the rule's priority and can stop further rules and policies from being processed after a match.

How priority decides which rule wins#

For Exchange, SharePoint and OneDrive, rules get their priority in the order they're created and are evaluated in that order. When an item matches several rules, the first evaluated rule with the most restrictive action is enforced. Microsoft's example:

So reports show more matches than enforced actions, and a notify-only rule at the top doesn't shield content from a stricter rule below it. Policies have their own priority too: 0 is the highest, no two policies share a value, and moving one shifts the others down (Set-DlpCompliancePolicy -Priority).

Devices work differently: endpoint DLP applies the sum of the most restrictive actions per activity across matching policies, so a policy blocking printing plus one blocking USB copies gives both blocks. Policies that are turned on take precedence over policies in simulation, and "no override" beats "allow override".

Step-by-step: a sensible starter set#

1. Review the default policies#

Every tenant gets four default policies: one for credit card numbers in externally shared documents and email, one for Teams, one for devices (audit only, with alerts but no policy tips) and one for the Microsoft 365 Copilot location. Keep, edit or replace them so you don't double up alerts.

2. Templates for regulated data, custom for your own#

Financial, Medical and health, and Privacy templates map regulations to SITs. For account numbers, project codes or customer lists, build a custom sensitive information type or use exact data match.

3. One purpose per policy#

A practical split: email and files shared externally (Exchange, SharePoint, OneDrive), Teams messages, device egress, and labeled content in Copilot (see DLP for Microsoft 365 Copilot). Separate policies keep every condition available.

4. Two tiers of rules#

A low-volume rule that notifies, and a high-volume rule that blocks with override and asks for a justification. Add exceptions, such as a partner domain, only after the data owner agrees.

5. Simulate, then review the order#

Run the policy in simulation (walked through in from simulation mode to enforcement), then confirm the priorities from Security & Compliance PowerShell:

Connect-IPPSSession
Get-DlpCompliancePolicy | Sort-Object Priority | Format-Table Name,Priority,Mode
Get-DlpComplianceRule -Policy "DLP - Customer data" | Sort-Object Priority |
  Format-Table Name,Priority,Disabled,BlockAccess

Verify#

• Send dummy test data that should hit only the low tier, then enough to hit the high tier: the first shows a tip, the second is blocked with an override option.
• The audit log and DLP reports record a match for every rule that matched, including the ones whose actions weren't applied.
• Mode shows Enable for live policies and TestWithNotifications or TestWithoutNotifications for simulations.
• Email results are covered in email blocked by Purview DLP, and alerts in investigating DLP alerts.

Tips and gotchas#

• Limits: 600 DLP rules per tenant, 64-character policy and rule names, and 100 KB per policy. DLP scans the first 2 million characters of extractable text and three nesting levels; beyond that it emits a "Document didn't complete scanning" signal, which you can catch with the Any email attachment's content didn't complete scanning condition.
• Simulation on devices: with policy tips shown in simulation, a device Block action runs as Block with override, so tell pilot users.
• Noise: tune confidence and instance counts before adding exceptions; see tuning DLP false positives.

References#

• Data Loss Prevention policy reference (Microsoft Learn)
• Data loss prevention Exchange conditions and actions reference (Microsoft Learn)
• Set-DlpCompliancePolicy (Microsoft Learn)