DLP policy not behaving as expected? Check the scope, rule and actual action.

Review the exact conditions, exceptions and activity that the rule requires. Check whether the intended information type or label is recognised, the match count/confidence criteria and any sharing/recipient/location condition. Read combined conditions carefully; a missing part can explain why the complete rule did not match.

Consider supported content formats, extraction or encryption constraints and workload-specific detection behaviour using the current documentation. A number that looks similar to a sensitive-information example may not meet its validation/context requirements. Do not use a real tax file number, customer record or secret simply to make a test match.

Keep an approved synthetic matching sample and an appropriate nonmatching sample in the authorised test plan, with the expected outcome written first. Protect any private diagnostic evidence. No match can reflect scope, content, activity, processing or a limitation; it is not automatically proof the platform is broken or that the information is safe to share.

Before changing anything, record the current policy/rule state, scope and intended result and agree preservation, impact and a rollback with the owner. Review whether the policy is off, in a simulation state or enforcing, and inspect the exact notification/override/action settings for the workload. Do not turn off an existing production protection to see whether the symptom goes away.

Microsoft’s policy reference describes different rule evaluation and combined-action behaviour for hosted services and devices. Overlapping policies can affect the result; do not assume the first rule, last edited policy or one visible notification is the only effective control.

Simulation is a diagnostic state with workload-specific behaviour. In particular, device actions can differ when simulation policy tips are enabled, and optional automatic transition to enforcement needs explicit ownership. Check the current documented behaviour for the selected settings; do not promise every simulation is consequence-free, immediately complete or incapable of restricting an activity.

Check the actual client/service support and rule notification settings before expecting a policy tip. Microsoft’s notification guidance explains that overlapping matches do not produce a tip for every rule. The displayed tip is not a complete list of everything evaluated.

Have the authorised owner correlate the event time, relevant activity, policy/rule and actual action with appropriately scoped diagnostic records. Check permitted override configuration and whether an override was actually used. Do not treat a match event, alert email or an allowed action as interchangeable evidence of a block.

Account for relevant policy delivery and event/report processing using the current workload guidance rather than a guessed universal wait. A blank report may reflect its time range, filters, permissions or evaluation scope. Protect evidence access and avoid exporting broad customer records or expanding collection just to obtain a screenshot.

Verify the approved matching and nonmatching scenarios in the supported intended contexts after the authorised deployment. Record actual scope, effective policy state, activity, action and appropriate notification/evidence. Also confirm the necessary ordinary workflow still functions under the required safeguards.

Keep the outcome specific to the tested location, users/devices, content and date. A pilot does not prove deployment to every location or detection of every sensitive item. Record exceptions, unsupported cases, pending processing and any further rollout or incident follow-up with an owner.

Return diagnostic settings and evidence handling to the approved state and arrange ongoing review, alert handling and staff guidance. Stop unrelated changes once the intended result is verified. A technical DLP outcome supports a defined protection requirement; it does not certify the whole organisation or replace privacy/legal and business responsibilities.

Provide the non-secret scenario, affected service/client, relevant time, intended action and observed evidence to the authorised policy owner. Keep customer content, secrets and unrestricted reports in an appropriate private channel. State whether there may have been a real exposure so incident response is not confused with routine tuning.

Our Microsoft 365 security review and Microsoft 365 support pages can start a scoped discussion. Agree actual entitlement, responsibilities, preservation and verification. Do not assume every subscription or support plan includes every workload, legal determination or ongoing alert response.

If the intended requirement cannot be met by the current supported scope, record the gap and appropriate owner decision. Use an approved alternative workflow or protection plan rather than bypass the rule with a personal account, unauthorised exemption or altered real document.