Microsoft Purview DLP: From Policy Noise to Detection That Holds

Most organizations have Microsoft Purview DLP switched on. Most of them have also quietly muted the alerts, because the volume was unworkable within the first two weeks. We see this pattern repeatedly: a compliance team enables a handful of built-in policies, Exchange starts firing on every PDF that leaves the tenant, the SOC triage queue hits four figures, and someone sets the severity filter to "High only" so the noise disappears. The data is still leaving. Nobody is looking at it.

The gap is not a licensing gap or a policy gap. It is an engineering gap. Purview DLP does not self-tune. It needs the same treatment any detection pipeline needs: deliberate scope, calibrated confidence thresholds, and a defined path for signals to reach the analysts who can act on them.

Scope Before You Write a Single Policy

Purview DLP spans six workloads: Exchange, SharePoint, OneDrive, Teams (messages and meeting chat), Endpoint (Windows and macOS via MDE), and Power BI. Each has a different data flow, a different enforcement model, and a different false-positive profile.

The instinct is to cover everything from day one. Resist it. An Exchange policy that fires on "any document containing a credit card number" will hit expense reports, vendor invoices, and receipts your own finance team sends internally. Endpoint DLP watching file copy to USB on 15,000 devices with no exclusions will surface every employee moving a PowerPoint to their work-issued thumb drive.

Start with the highest-signal workload for your environment. For most M365 tenants, that is SharePoint and OneDrive, scoped to specific site collections that hold regulated data. Map those sites before you open the Purview portal. SharePoint Admin Center exports a site inventory; pipe it through a quick filter on sensitivity labels or storage owner, and you get a defensible scope in under an hour.

Policy simulation mode ("What If") is your friend here. Run every new policy in simulation for at least five business days before you flip it to enforcement. Purview surfaces simulation matches in the DLP reports without sending user notifications or blocking anything. Five days across a normal work week will show you the false-positive rate clearly.

Sensitive Information Types and the Alert Tax

Built-in Sensitive Information Types (SITs) use a combination of regex patterns, keyword lists, and checksum validation. The confidence bands matter enormously, and almost nobody documents what they set.

High confidence (85%+): tight pattern match with corroborating evidence. Low false-positive rate. Will miss documents where the number is formatted differently than the regex expects.

Medium confidence (75%): broader match, more detection coverage, but roughly 3-5x the false-positive volume in our experience across financial services tenants. That is not a number from a spec sheet; it is what we see in Purview DLP reports after running parallel simulation policies at different confidence bands on the same data estate.

The practical answer is to run High confidence in enforcement mode and Medium confidence in audit-only mode. You get the coverage data without the alert tax. Tune quarterly: if medium-confidence audit is surfacing real positives that high-confidence misses consistently, you promote specific rules, not the whole band.

For regulated data that does not fit the built-in SITs (internal project codes, proprietary identifiers, healthcare record numbers that do not conform to standard formats), trainable classifiers and custom SITs are available. Custom SITs built on exact data match (EDM) against a database of known-bad values have essentially zero false positives at the cost of operational overhead on the hash refresh schedule. Worth it for PII datasets where you know the values.

Adaptive Protection: Wiring Insider Risk into Enforcement

Adaptive Protection is the feature most teams skip because it requires Insider Risk Management to be active, and IRM requires its own policy configuration and a separate communication to HR and Legal. That overhead is real, but so is the value.

With Adaptive Protection on, Purview assigns each user a dynamic risk level (Elevated, Minor, Normal) based on IRM signals: unusual file exfiltration volume, downloading from SharePoint then uploading to personal storage, sequences of copy-to-USB following a resignation date match. The DLP engine then enforces different policy actions against users in each risk tier.

A Normal user copying a document with a medium-confidence credit card match to OneDrive gets an audit entry. The same action by an Elevated-risk user triggers a block-with-override and notifies the user's manager. Same policy, tiered response. This is the right architecture for orgs that cannot afford to block the Normal population aggressively.

The setup sequence that matters: activate IRM, let it run for 10-14 days so the baseline is meaningful, then enable Adaptive Protection. Turning it on against a cold IRM tenant means everyone starts at Normal and the risk signals do not converge for two weeks anyway.

Getting DLP Signals into Sentinel

The Microsoft 365 Defender connector (now the unified XDR connector in Sentinel) ingests DLP policy matches as incidents. They land in SecurityAlert with ProductName == "Microsoft 365 Defender" and the alert name contains the DLP policy name. That is the high-severity path.

For granular analysis, the OfficeActivity table captures every DlpRuleMatch event from Exchange, SharePoint, OneDrive, and Teams. Endpoint DLP events come through DeviceEvents via the MDE connector.

The query below runs in Sentinel to surface Block and BlockWithOverride actions, grouped by user and policy, with a minimum match threshold to filter one-off events:

// Purview DLP: users hitting block actions repeatedly within a session window
OfficeActivity
| where TimeGenerated > ago(24h)
| where Operation == "DlpRuleMatch"
| extend
    PolicyName = tostring(parse_json(tostring(ExtraProperties))["PolicyName"]),
    RuleName   = tostring(parse_json(tostring(ExtraProperties))["RuleName"]),
    Action     = tostring(parse_json(tostring(ExtraProperties))["Action"]),
    Workload   = tostring(parse_json(tostring(ExtraProperties))["Workload"]),
    SITNames   = tostring(parse_json(tostring(ExtraProperties))["SensitiveInfoTypeNames"])
| where Action in ("BlockAccess", "BlockWithOverride", "EncryptMessage")
| summarize
    MatchCount     = count(),
    Workloads      = make_set(Workload, 5),
    SITs           = make_set(SITNames, 10),
    AffectedItems  = make_set(OfficeObjectId, 20)
    by UserId, PolicyName, RuleName, bin(TimeGenerated, 4h)
| where MatchCount >= 5
| order by MatchCount desc

The >= 5 threshold is a starting point, not a rule. For a 500-person tenant with a tight SharePoint scope, three matches in four hours is already signal. For a 15,000-person tenant covering all of Exchange, start higher and let the data tell you where the knee of the curve is.

One thing to watch: OfficeActivity has an ingestion lag of 15-90 minutes depending on workload and tenant size. DLP incidents from the Defender connector are faster, often under 10 minutes. For near-real-time SOC triage, route through the Defender incident path. For historical hunting and quarterly tuning, OfficeActivity is richer.

Endpoint DLP Requires MDE First, Not After

Endpoint DLP is a feature of Purview, but its agent is Microsoft Defender for Endpoint. A device must be fully onboarded to MDE before Endpoint DLP policies reach it. We have seen teams spend two weeks troubleshooting why their Endpoint DLP policy shows zero matches, only to discover that 40% of their device fleet was still onboarding to MDE from a parallel project.

Check the MDE onboarding report before you scope an Endpoint DLP policy to any device group. The Purview portal will let you save a policy targeting unonboarded devices without complaint. It just does nothing.

macOS support for Endpoint DLP requires MDE 101.59.50 or later and a specific set of system extensions approved via MDM. If you are pushing Endpoint DLP to macOS without a confirmed MDM approval profile for the Purview extensions, you will get silent non-enforcement. Verbose diagnostic mode is available via mdatp on the endpoint and should be the first troubleshooting step, not the last.

Tuning the Feedback Loop

DLP is not a configure-and-forget control. The business changes: new SaaS apps get approved, new data types emerge, Teams external sharing policies shift. A policy that was well-tuned in January is generating noise or missing coverage by July.

Build a quarterly review into the process. The Purview DLP reports export to CSV from the compliance portal or are queryable via the Graph API at /v1.0/security/cases. Pull the top-false-positive rules, review the override reasons users submitted, and adjust confidence thresholds or add exclusions for known-clean patterns. The override reasons are the most underused signal in the entire platform: users tell you exactly why they overrode the block, and those reasons cluster predictably around process gaps, not malicious intent.

When to Call Us

If your DLP alerts are muted, your policies are in audit-only indefinitely, or you need to route Purview signals into a Sentinel detection pipeline that actually produces actionable incidents, reach out to us at /contact. We scope, configure, and operationalize Purview DLP as part of our detection engineering practice, including custom SIT development, Adaptive Protection deployment, and Sentinel workbook builds for ongoing DLP visibility.