Insider Risk Level not being correctly picked up by DLP

SHORT VERSION

Before you chase Adaptive Protection, check two things that produce exactly this

pattern on their own. The policy tip you see does not identify the rule that

enforced the action, and a policy in simulation mode with tips turned on does not

apply the action you configured.

WHY THE POLICY TIP IS NOT A RELIABLE RULE INDICATOR

Purview shows only the policy tip from the highest priority, most restrictive rule

that the content matched, both across rules within a policy and across policies.

The documentation is explicit that custom policy tips show for the most restrictive

rule, not necessarily the rule that is performing the restriction. So a distinct tip

per rule tells you which rule won the tip contest, not which rule produced the

enforcement you observed. That alone can make it look like the wrong insider risk

level was picked up.

https://learn.microsoft.com/purview/dlp-use-notifications-and-policy-tips

WHY BOTH USERS END UP WITH BLOCK WITH OVERRIDE

The DSPM for AI - Block sensitive info from AI sites policy is created in test mode.

When a policy state is Run the policy in simulation mode and Show policy tips is on,

the action applied at runtime is not the action you configured. A configured Block is

applied as Block with override, and a configured Block with override is also applied

as Block with override. With tips off, both are applied as Audit.

That maps one to one onto your test results. Your elevated rule is Block and your

moderate and minor rule is Block with override, and both users end up with Block with

override, which makes the two rules indistinguishable at the endpoint. The runtime

table is in the endpoint section of the rule reference.

https://learn.microsoft.com/purview/dlp-policy-reference

So the first thing I would check is the policy state. Confirm it is Turn it on right

away, not simulation with policy tips.

CHECK WHETHER MORE THAN ONE POLICY IS IN PLAY

Endpoint DLP applies the aggregate of the most restrictive actions across every

matching rule and policy, and where the override option differs, no override wins

over allow override. If you also still have the Adaptive Protection quick setup

policy for Endpoint DLP running, the documentation states that when a user is

targeted by both a default Adaptive Protection device policy and an independent

device DLP policy, only the actions of the most restrictive policy are applied. Two

overlapping policies will produce results that look like the wrong risk level was

matched.

https://learn.microsoft.com/purview/dlp-adaptive-protection-learn

THE NINO CONFIDENCE DETAIL IS PROBABLY RELEVANT HERE

U.K. national insurance number has no checksum. It reaches high confidence only when

the pattern function and a keyword from Keyword_uk_nino are both found within a

proximity of 300 characters. Pattern alone is medium confidence.

That means the same NINO can land at medium or high confidence depending on what

surrounding text happens to be in the paste. If your two rules were built with

different confidence thresholds, or if the text you pasted on the second machine

carried slightly different context, you get a match on one rule and not the other

with what looks like identical data. Worth testing the exact string with the Test

function on the SIT, and worth checking that both rules use the same confidence level

and instance count.

https://learn.microsoft.com/purview/sit-defn-uk-national-insurance-number

PASTE TO BROWSER HAS ITS OWN CONSTRAINTS

The Paste to supported browsers activity evaluates the clipboard content at the

moment of the paste, independently of any source file classification, and it has

constraints that catch people out.

Pasted content is classified locally on the device. Advanced classification is not

used for the paste activity, so exact data match, named entities, trainable

classifiers and credential classifiers never trigger on a paste. Standard pattern

based SITs, which is what NINO is, do work.

The activity only works with Sensitive service domain groups. The flat Service

domains list has no effect on it. Also leave the global Service domains action set to

Block. Setting it to Allow is documented as making the policy behave erratically,

which would fit the inconsistency you are seeing between machines.

There is a documented lag between the paste and the classification response, and

during that lag you can see both a policy evaluation notification and a check

complete notification in Edge, or a policy evaluation toast in Chrome and Firefox.

Your observation that Purview sometimes lets the paste through after checking the

data is that behaviour, not necessarily a risk level problem.

On Windows, Chrome and Firefox require the Microsoft Purview extension. Edge is

native. If one test machine has the extension and the other does not, that alone

explains a machine to machine difference.

https://learn.microsoft.com/troubleshoot/microsoft-365/purview/data-loss-prevention/diagnose-paste-to-supported-browser-issues

LATENCY YOU HAVE TO ALLOW FOR

A new or edited policy takes up to roughly 60 minutes to sync to onboarded devices.

Changes to user or group membership take roughly 24 hours to come into policy scope.

Device sync status in the portal can take up to 2 hours to refresh, so a device

showing as synced is not proof that it holds the policy version you just edited.

Enabling Adaptive Protection can take up to 36 hours before insider risk levels and

DLP actions are applied to user activity.

https://learn.microsoft.com/purview/dlp-edlp-tshoot-sync

https://learn.microsoft.com/purview/insider-risk-management-adaptive-protection

ONE POINT THAT IS MY OWN ASSESSMENT, NOT DOCUMENTED BEHAVIOUR

Testing two users with different risk levels by signing in and out of the same PC is

not a clean test in my view. Each onboarded device carries a single associated DLP

UPN, and the Valid user attribute reflects whether the currently logged on user is in

scope of a device targeted policy. Policy sync itself is a device level operation. I

would run the two accounts on two dedicated devices, or at minimum confirm the device

picked up policy again after each sign in, before concluding that the wrong insider

risk level was evaluated. You can read DlpUpn and HasDlpValidUpn per device from the

DeviceInfo table in Advanced hunting.

HOW TO ACTUALLY PROVE WHICH RULE FIRED

Stop using the policy tip for this. Use Activity Explorer and open the paste event,

which names the policy and the rule that matched.

If you need to go deeper, endpoint DLP diagnostics show you what the device actually

holds. Always on diagnostics has been enabled by default on onboarded Windows devices

since mid April 2026, and you can request a collection from the Purview portal.

Otherwise run the MDE Client Analyzer with the -t switch, reproduce the paste, and

read the Actions value for each policy rule. EnforcementMode 1 is Audit, 2 is Warn

which is block with override, and 3 is Block. That tells you exactly which rules

reached the device and in which mode, which is the piece you are currently inferring

from tips.

https://learn.microsoft.com/troubleshoot/microsoft-365/purview/data-loss-prevention/analyze-endpoint-dlp-diagnostic-logs

WHAT I WOULD CHANGE IN THE TEST SETUP

I would split the two risk levels into two separate policies rather than two rules in

one policy, and disable one while testing the other. It costs nothing in coverage,

and it removes both most restrictive aggregation and policy tip precedence from your

test loop. Once you get clean, repeatable results per policy, you can merge them back

if you prefer a single policy.