Purview DLP policy design starts with one sentence

Most Purview DLP policy design begins in the policy wizard. Someone picks a template, accepts the preconfigured conditions, scopes it to everything, and turns it on. The tuning happens afterwards, in production, against users who are already annoyed.

Microsoft’s own guidance starts somewhere else entirely: write a single sentence describing what the policy is for, before opening the wizard at all. That sounds like process theatre. It is not. The sentence is a forcing function, and the reason it works is that a DLP policy requires five separate decisions that nobody makes deliberately when they start from a template.

The five decisions

Every DLP policy, without exception, requires you to answer these:

1. What you want to monitor
2. The policy scoping, meaning whether an unrestricted administrator or an administrative unit restricted one owns it
3. Where you want to monitor
4. The conditions that must match for the policy to apply to an item
5. The action to take when those conditions are met

A template answers one and a half of those. It gives you the what, and a starting set of conditions you are expected to edit. The other three and a half are yours, and they are where policies go wrong.

Microsoft’s worked example is a fictitious statement covering all five: detect Office documents containing health care information covered by HIPAA, stored in OneDrive and SharePoint, protect against that information being shared in Teams chat and channel messages, and restrict everyone from sharing with unauthorised third parties.

Read that again and notice what it forces. It names a document type, a regulation, two storage locations, one communication channel, and one action. Each of those is a decision someone has to own. Written as a sentence, the gaps are obvious. Configured in a wizard, they are just fields with defaults.

Location is not a filter, it is a constraint

This is the single most under-appreciated point in DLP design, and it is stated plainly in the documentation.

The locations you pick determine whether you can use sensitive information types, sensitivity labels and retention labels at all, and they determine which actions are available to you. Location is not a scoping choice made after the policy is designed. It is an input that constrains the design.

The available locations are broader than most teams realise:

Two of those deserve attention because they are new ground for most estates. Fabric and Power BI workspaces bring the analytics estate under the same policy engine, which matters if your sensitive data has already been copied into a semantic model. And Microsoft 365 Copilot, in preview, means DLP is now a control on what an assistant can surface, not only on what a person can send.

If the data estate is where your exposure actually sits, our view on how a data platform should be assessed starts with the same question DLP does, which is who is accountable for which data.

Simulation mode is not a dress rehearsal

Microsoft is unambiguous that policies should run in simulation mode before enforcement, and simulation mode is genuinely good. It replaced the older Test and Test with policy tips states, and it isolates results in their own dashboard so a policy under evaluation does not pollute the alerts from policies that are actually running.

The numbers are worth knowing before you plan around it:

But there are three specific ways a simulation does not behave like production, and we see all three misread.

The evaluation asymmetry. For SharePoint and OneDrive, simulation evaluates all existing items as well as new and changed ones. For Exchange, Teams and Devices, it evaluates only items that are new during the simulation. Fabric items are evaluated if they are updated or refreshed after the simulation starts.

That asymmetry is not a bug, it follows from how each workload is scanned. But it means a fourteen day simulation gives you a near-complete picture of your document estate and a fourteen day sample of your email and endpoint behaviour. Those are different kinds of evidence, and treating the second as a full inventory is how organisations conclude that email is a low-risk channel.

Worth noting that this is not only a simulation artefact. In production, DLP does not scan or match previously existing email stored in a mailbox or archive at all. New messages are scanned; history is not. SharePoint and OneDrive scan both.

Rule ordering does not apply. The Stop processing more rules setting does not work in simulation mode, even when it is turned on. A multi-rule policy that relies on ordering to avoid double-counting will therefore produce more matches in simulation than it will in production, and the difference is invisible unless you know to look for it.

Alerts go somewhere else. While a policy is in simulation, its alerts appear only in the simulation alerts tab. They do not reach the DLP alerts console and they do not flow into the Defender portal. If your operational readiness plan involves the security operations team practising triage during the simulation, that plan does not work as written.

Complex rules, and the policy tip trap

The rule builder supports boolean logic with AND, OR and NOT, and nested groups. That is genuinely powerful, and it changed how exceptions work: the old Exceptions functionality is now expressed as a NOT condition inside a nested group. If you are carrying policy documentation written before that change, it describes a user interface that no longer exists.

There is a limitation attached to that power, and it is the kind of thing that surfaces three weeks after go-live. For Word, Excel and PowerPoint on the desktop, Microsoft states it flatly: tips appear only for policies built from a short list of conditions and actions, and if any other condition or action is present, the tip will not appear.

That much is documented. What follows is not, and it is where most of the pain actually lands.

Eligible on paper, silent in production

Microsoft’s Outlook reference lists Recipient domain is as a supported policy tip condition on current desktop builds. Its DLP design guidance separately says complex conditions limit tips across Word, Outlook, Excel and PowerPoint. Both statements are current, and read together they look contradictory.

They are not. The predicate is eligible. Client-side evaluation still fails once the rule looks like a production rule rather than an example. In our engagements, on modern builds with full E5 licensing, three things break the tip while the block still happens:

Inverted logic. A positive Recipient domain is match works. Pair it with an exception, meaning *except if recipient domain is one of our approved partners*, and the desktop client frequently fails to resolve the exception state locally. No tip fires. The user clicks send. Exchange transport evaluates the full rule in the cloud, matches, and bounces the message.

Attachment inspection. If the rule inspects labelled or sensitive attachments, particularly non-Office formats such as PDFs or password-protected files where local metadata extraction fails before send, the client cannot evaluate the content in time to show anything. Cloud transport inspects it immediately and blocks.

Policy sync timing. Even on E5 tenants, if connected experiences or policy sync tokens delay the rule schema reaching the local client cache, transport enforces the block before the desktop client knows a tip was required.

The shape is the same in all three. The user sees no warning, assumes the message is fine, sends it, and receives a generic bounce. From where they sit, Outlook is broken.

This is what produces the complaint that DLP is opaque, and it is the pattern behind the P1 tickets we see during executive and legal rollouts in financial and professional services, where the rule is almost always some version of *block externally except to approved audit domains*. The same policy behaves perfectly in Outlook on the web, which is what makes the diagnosis slow.

The fix is a design choice, not a product setting. Rules that users meet often should be expressed as simple content conditions. Push the compound logic into rules users are not expected to trip.

Where we would start, and it is not with blocking

Our position is that the first policy in any tenant should be scoped narrowly and should not block anything.

The argument for a broad monitoring policy is that it gives you an inventory. The argument against is that a blanket audit across every Microsoft 365 service produces a telemetry deluge, and a security team that has learned to ignore the dashboard is worse off than one that never had it.

So: one highly specific data type, tied to a clear business risk. Raw card numbers or banking IBANs leaving for external domains is the usual starting point, because nobody has to be persuaded it matters. Run it non-blocking until it is tuned, then expand horizontally to the next data type.

What we would not do is attempt tenant-wide classification and multi-channel blocking in a single policy iteration. That is the version that generates the deluge, and it is the version most first attempts look like.

Microsoft’s own lifecycle supports this framing. It separates plan, prepare and deploy, and the planning section is explicit that DLP adoption may require a change to business processes and a culture shift for users. That is a change management statement sitting inside technical documentation, and it is there because the technical part is the easier half.

The related discipline is the same one that governs a labelling rollout. If you are running both, the defaults you choose for sensitivity labels decide how much a DLP policy can rely on labels as a condition, which is why the two projects should not be sequenced independently.

What deep content analysis actually does

Worth being precise, because “DLP scans for credit card numbers” undersells it and leads to bad condition design.

The engine matches primary data against keywords, evaluates regular expressions, applies internal function validation such as checksum tests, and looks for secondary data matches in proximity to the primary match. It also applies machine learning and other methods for content that does not reduce to a pattern.

That proximity behaviour is why instance count and confidence level are the two settings that most change a policy’s false positive rate. Microsoft calls instance count leakage tolerance, which is a better name for it: how many occurrences of a thing constitute an incident rather than a mention. A policy set to fire on one instance of a national identifier will find every document that quotes a format example.

What an untuned policy actually produces

Here are our own numbers, because this is the part where a general warning is useless and a figure is not.

On a first-draft policy using a default Microsoft template at a low instance count, false positive rates routinely sit between 40% and 60%. The offenders are almost always the same: tracking numbers, internal invoice IDs and alphanumeric order references colliding with low-confidence credit card or national identifier checksums. Nothing exotic, just the reference formats your own business already uses.

Where we land after tuning:

The gap between those two rows is the whole design. A single credit card number in an email is a conversation to have with someone. Fifty of them is an incident, and only the second deserves a block the user cannot pass.

How long this takes

In a disciplined deployment, the path from an approved intent statement to active blocking runs four to six weeks:

One practical note, because the arithmetic looks wrong against the fifteen day simulation limit above. Weeks one to three are not a single simulation run. You copy the policy, change the tuning, and run the copy, which is the pattern Microsoft describes for exactly this purpose. The original stays untouched until the copy behaves.

Anyone promising enforcement inside a fortnight is either skipping the tuning or has a tenant with no data in it.

Where this connects

DLP does not stand alone, and designing it as though it does is why so many deployments feel disconnected from the rest of the estate.

Labels, DLP and access hygiene are three controls over the same content, and the way the wider Microsoft 365 estate is configured determines how much work each of them has to do. A tenant with sane external sharing defaults needs a smaller DLP surface than one without.

And the commercial question, meaning what an estate exposes to an assistant that can read across it, is a different article and a different lane. Purview as a governance platform covers the broader control set that DLP is one part of.

Where to start

Before opening the policy wizard, write the sentence. One policy, one paragraph, five answers: what, who administers it, where, on what conditions, and what happens when it matches.

If you cannot complete the sentence without a placeholder, that placeholder is a decision somebody has to make, and it is cheaper to make it now than to discover it in a simulation report.

Then deploy in simulation, and read the results knowing what the simulation does and does not tell you. Fifteen days of Exchange evidence is a sample. Fifteen days of SharePoint evidence is close to a census.

Veratas designs and deploys security and compliance controls across Microsoft 365 and the data estate, including the policy design work that decides whether DLP lands or gets switched off.

If you have a DLP deployment that produces alerts nobody triages, talk to our team. That is usually a scoping problem, not a tuning problem.

Frequently asked questions

What is the first step in Purview DLP policy design? Writing a policy intent statement, before any configuration. Microsoft’s guidance is that a single sentence should summarise the business intent of every policy, and that this statement drives the conversations that produce the actual configuration. It has to answer five things: what to monitor, who administers the policy, where to monitor, the matching conditions, and the action to take.

How long can a DLP policy run in simulation mode? Up to 15 days, and the results are kept for 30 days. Simulation is not a point-in-time snapshot, which is why the duration matters.

Does simulation mode show me everything a policy would catch? Not evenly. SharePoint and OneDrive evaluate all existing items plus new and changed ones. Exchange, Teams and Devices evaluate only items that are new during the simulation. So document estates are covered thoroughly and email and endpoint behaviour is sampled over the simulation window rather than inventoried.

Why can users see a DLP block but no explanation? In the Office desktop clients, when a policy uses complex conditions, users only see policy tips for rules built on the content contains sensitive information condition. A rule based on sensitivity labels or recipient domains can block without producing a useful tip, so the rules users meet most often should be expressed as content conditions.

Does DLP scan email that already exists in mailboxes? No. DLP scans new email messages and matches against those. It does not scan or match previously existing items stored in a mailbox or archive. SharePoint and OneDrive behave differently and do scan existing items as well as new ones.

How long does a DLP policy take to start working? About an hour after it is turned on. Policies are stored centrally then synced out to Exchange, OneDrive, SharePoint, the Office desktop applications and Teams before they begin evaluating content.

What happened to exceptions in DLP rules? They are now expressed as a NOT condition in a nested group inside the conditions, rather than as a separate exceptions section. The rule builder supports AND, OR and NOT with nested groups, and you have to create groups in order to use multiple operators.

Divya Pal Singh

Azure and Business Intelligence Architect with 17+ years of experience delivering cloud data and analytics solutions. Focus areas include Azure data platforms, ETL and ELT architecture, and enterprise BI on Microsoft Azure.