Checklist
DLP policy design checklist
Based on the article: Designing Purview DLP policies: locations, rules, conditions, actions and priority · 5 min read
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).
- 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.
+6 more points in the full article.
Checklist
- 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:
powershellConnect-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.
ModeshowsEnablefor live policies andTestWithNotificationsorTestWithoutNotificationsfor simulations.- Email results are covered in email blocked by Purview DLP, and alerts in investigating DLP alerts.
Tips & 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.