Purview DLP policy not triggering: where the match stops

A Purview DLP policy that never fires looks exactly like a Purview DLP policy that is working. In both cases the activity list is empty. Nothing in the portal separates a policy that correctly found no sensitive content from one that was never evaluated, never reached the device, or was quietly overruled by a rule somebody created three months earlier. That ambiguity is the real problem, and it is why data loss prevention troubleshooting so often starts in the wrong place.

The instinct is to rewrite the rule. It rarely helps, because the rule is rarely where the evaluation stopped. There are four earlier stop points, and three of them report success. This post walks them in the order they occur, along with the onboarding prerequisites that decide whether the policy could run at all, which sit on the same cliff edges set out in Microsoft Purview cost and licensing. Every Microsoft fact below was verified against Microsoft Learn on 27 September 2026.

Why a Purview DLP policy does not trigger, in order of likelihood

Work down this list before touching the rule. The order is deliberate: the cheapest checks are also the ones most often wrong.

Simulation mode is the answer more often than the rule is

Microsoft’s simulation mode documentation describes the feature as showing the impact of a policy on your production environment without enforcement. That is the entire explanation behind a large share of Purview DLP policy not triggering reports. The policy is triggering. It is recording matches. It has been told not to act on them.

Three details make this harder to spot than it ought to be. Policy tips can be shown while a policy is in simulation, so a tip appearing does not prove enforcement and a tip missing does not prove its absence. Scan results from a simulation are saved for 30 days, which means an older simulation presents as an empty policy rather than an expired one. And the configuration step offers to turn the policy on if it is not edited within fifteen days of the simulation, so a policy can start enforcing without anyone touching it, and can equally sit in simulation for months because somebody kept editing it just often enough.

How fast simulation results appear depends on the location, and the difference is large enough to change your diagnosis. Exchange, Teams, Devices and Fabric are scanned in real time, as the message is sent or the item is transferred. SharePoint and OneDrive instead report a status of In progress while the scan walks the content, with results updated as more matches are found. An empty result on a large tenant frequently means the scan has not reached the file you are testing with yet.

Devices as a location, and the two hour lag

Endpoint DLP carries a prerequisite the service side locations do not. A device has to be onboarded before it exists as far as any policy is concerned. Microsoft’s endpoint DLP getting started documentation scopes this to onboarded Windows 10 and Windows 11 devices, and onboarded macOS devices running any of the three latest released versions, with onboarding delivered through Group Policy, Configuration Manager, Intune, a local script, or a VDI configuration package. Nothing in the DLP policy editor warns you that the devices you assigned it to are not onboarded.

Once onboarding is done, the status column is where the diagnosis happens, and the endpoint DLP configuration and policy sync troubleshooting guide is explicit about two things worth writing down. First, it might take up to 2 hours for the status in the devices list to update. That is long enough for an engineer to decide the policy failed and start changing it, which is the worst available response. Second, the status reads Not available when there is no endpoint DLP policy at all, which is a different fault from a policy that failed to arrive and looks much the same at a glance. The device also has to be online for the policy update to happen, so check when it was last seen before blaming the policy.

Advanced hunting in the Defender portal answers the onboarding question faster than the devices list does, because the DeviceInfo table carries the state directly:

1// Onboarding state per device, most recent record only.
2// Answers the question the DLP devices list takes up to two hours to answer.
3DeviceInfo
4| where Timestamp > ago(7d)
5| summarize arg_max(Timestamp, OnboardingStatus, OSPlatform, OSVersion) by DeviceName
6| where OnboardingStatus != "Onboarded"

Rule precedence, and why the alert names a policy you did not expect

This is the stop point that produces the most wasted hours, because the rule you are testing did match and the portal will happily tell you so if you look in the right report. The Data Loss Prevention policy reference sets out the model for the hosted service locations plainly: each rule is assigned a priority in the order in which it was created, rules are processed in priority order, and where content matches several rules, the first rule evaluated that has the most restrictive action is enforced.

Read that carefully, because it has a consequence people miss. Evaluation does not stop at the first match. Matches for every rule are recorded in audit logs and DLP reports, and only the winning rule is applied. So a rule that appears to do nothing may be matching perfectly and losing to an older, more restrictive rule in a policy written by somebody who has since left. The documentation’s own worked example has four matching rules where the third is enforced and the other three are evaluated and discarded.

Endpoints work differently again. The same reference states that endpoint DLP applies the aggregate or sum of the most restrictive actions, resolved against policy priority, rule priority, policy mode, the actions themselves, authorisation groups and override options. The practical reading is that on Windows and macOS you are not looking for the one rule that won, you are looking at a combined outcome, and a single block with no override anywhere in your policy set will define the user experience regardless of how permissive everything else is.

Where the match itself stops

When one file triggers and a near identical one does not, the fault is almost always classification rather than the rule. Two limits account for most of it, and both are documented on the Configure endpoint data loss prevention settings page rather than anywhere near the policy editor.

The first is advanced classification scanning and protection. Turning it on sends items to the Microsoft Purview cloud based data classification service, which scans them, classifies them and returns the result to the local machine, and it is what enables exact data match, trainable classifiers, credential classifiers and named entities on an endpoint. Left off, those classifiers do not silently degrade, they simply never match, so a policy built on exact data match schemas will run on the endpoint and find nothing at all. The second is scope. Advanced classification covers Office file types, meaning Word, Excel and PowerPoint, plus PDF. Text files are scanned up to 64 MB, and image files up to 50 MB when optical character recognition is enabled.

The other common classification failure has nothing to do with endpoints. A condition that matches on a sensitivity label depends on that label being published to the right users, and an unpublished label is invisible to the policy in the same way it is invisible to Word. The publishing step is the one most often skipped, which is why it gets its own section in create sensitivity labels in Microsoft Purview.

The failure modes

I have not run endpoint DLP against a fleet. My tenant is a lab with no enrolled devices, so every device side claim above comes from Microsoft’s documentation and is dated accordingly rather than from something I watched happen. What I can say is that the shape of these failures is consistent: the portal reports on delivery and configuration, and the thing you actually want to know is whether the content was evaluated.

What I would do differently

Decide before you write a Purview DLP policy whether you are measuring or enforcing, and never let simulation be the default because it felt safer. A simulation nobody reviews is indistinguishable from a policy nobody wrote, and the fifteen day auto enable option exists precisely because policies get left in simulation and forgotten. If you want to measure, set a date to review it and put that date somewhere that is not the policy.

Build one rule per policy until the estate is stable. Precedence is the stop point with the worst diagnostics, and it is entirely self inflicted: several rules in one policy give you a combined outcome and a report you have to interpret, whereas separate policies give you separate results. Consolidate later, when you know which rules earn their place.

Prove the pipeline before you trust the policy. Turn on advanced classification, onboard one device, target one file type you know is in scope, and confirm an activity lands in Activity explorer. Only then add the condition you actually care about. The order matters because every stop point in this post fails silently, and a policy that has never produced a single recorded match has told you nothing about whether it works. For the device onboarding half of that exercise, the ordering habits in Intune troubleshooting apply unchanged: confirm the device is talking before you conclude the policy is wrong.

Last verified: 27 September 2026