Why is my new DLP policy not blocking anything, hours after I turned it on?
Because it isn’t ready yet, and it won’t be for a while. You build a policy to block sharing to external domains or to keep Copilot from reaching certain mailboxes, you flip it to enforce, you send a test file to a personal Gmail address — and it sails right through. Nothing blocks. No policy tip. No override prompt.
Your instinct is that the policy is broken or misconfigured. It usually isn’t. The enforcement engine for these newer scenarios doesn’t act on a rule the moment the rule exists. It acts once the underlying content has been classified and indexed against that rule. Until the index catches up, the policy is real but toothless.
Which DLP policies actually behave like this?
The ones that reason about content and relationships at scale, not the ones that pattern-match a single item in transit. In practice, the slow group is:
- Block sharing to specific external users or domains across SharePoint and OneDrive.
- Restricting Copilot’s reach — for example, keeping Copilot from summarising or drawing on certain mailbox content or labelled sites.
Your old workhorse policies — “detect a credit card number in an outbound email and block it” — still fire in near real time, because that decision is made on one message as it moves. The new capabilities are different in kind. They need to know the state of a corpus before they can enforce a rule that depends on the corpus.
Why do these take days when the old ones take minutes?
Because you’re comparing two different jobs and pretending they’re the same one.
Traditional DLP distribution is a publishing problem. The service pushes your policy definition out to the workloads — Exchange transport, SharePoint, endpoints — and each workload starts evaluating items against it as they flow through. That’s a config sync. Minutes to a couple of hours, and it’s done.
The new scenarios are an indexing and classification problem. To block sharing based on content sensitivity, or to fence Copilot off from the right data, the service has to evaluate what already exists across your tenant and build an index it can enforce against. That’s not distributing a rule. That’s processing your data estate. On a large tenant that is a genuinely heavy background job, and it runs on Microsoft’s schedule, not yours.
Old model: ship the rule, enforce on the fly. New model: build the index, then the rule means something. The click is instant. The protection is not.
How long is “days,” realistically?
Plan for multiple days, not multiple hours. The testing that surfaced this saw activation land days after the policy was configured and showed green — well outside the window anyone would expect from normal DLP sync. There is no published SLA that says “your index will be ready in N hours,” and tenant size, content volume, and existing classification state all move the number. So don’t anchor on a specific figure. Anchor on the shape: you configure now, you’re actually protected later this week.
Doesn’t the policy status show me when it’s ready?
No — and that’s the trap. The distribution status tells you the policy reached the workloads. It does not tell you the index is built and enforcement is live. You can see a healthy, distributed policy and still have zero real protection, because those are two separate states that happen to both look like “on.”
Check the distribution status by all means, but treat it as necessary, not sufficient. Read-only look at what you’ve got in Purview:
The only status that counts is a controlled test: attempt the exact action you meant to block, from a real account, and watch it get stopped. Everything else is a proxy.
Is this a bug I should open a ticket for?
No. It’s how index-based enforcement works. Enforcing a rule that depends on the state of your content requires that content to be evaluated first, and evaluating a tenant’s worth of data takes time. You can dislike the lack of a clear “index ready” signal — I do — but the delay itself is architecture, not a defect. Opening a sev-B because your Friday policy wasn’t blocking by Friday afternoon just wastes your own time.
What’s fair to push Microsoft on: better visibility into index/enforcement readiness, distinct from distribution status. Right now admins are inferring readiness from test failures, which is a lousy way to run governance.
What does this quietly break in my incident response plan?
The assumption that DLP is a lever you can pull mid-incident. It isn’t, for these scenarios.
Picture the call: data’s leaking to an external domain, someone says “block external sharing with DLP, now.” If that policy doesn’t already exist and isn’t already indexed, you have not stopped the bleeding — you’ve scheduled a fix for sometime next week. Same with “cut Copilot off from that mailbox.” The control you reach for in the incident is the one that needs days of lead time you don’t have.
The lesson is blunt: index-based DLP is a preventive control, not a reactive one. If you need to stop something today, you need a mechanism that acts today.
So what do I actually deploy, and when?
Deploy early and in stages, on the assumption that “live” is days after “saved.”
- Configure well ahead of any date that matters. If a policy needs to be enforcing for an audit, a launch, or an offboarding wave, build it days before — not the morning of.
- Start in a test or simulation mode where the scenario supports it, so you can watch matches accumulate before anything hard-blocks. Don’t go straight to enforce on a live query of real content.
- Pilot on a scoped set — a handful of sites, a test OU, a pilot group — before tenant-wide. It won’t make the index faster, but it limits blast radius when your assumptions about readiness are wrong.
- Prove enforcement with a controlled test before you tell anyone it’s protecting them. The green status is not the proof. The blocked action is.
What do I tell stakeholders who think “deployed” means “protected”?
Give them a window, not a moment. The sentence that keeps you honest:
“The policy is configured as of today. Enforcement for content-based blocking activates over the following several days as the service indexes the data. We’ll confirm active protection by test, and I’ll tell you the date it’s genuinely on — not the date I clicked Save.”
Put the gap in writing. When leadership hears “DLP is deployed,” they hear “we’re safe now.” If you don’t name the risk window, you own the incident that happens inside it — the one where everyone assumed protection that wasn’t live yet.
What covers the gap during those days?
Controls that enforce on config, not on an index:
- Tenant and site-level external sharing settings in SharePoint/OneDrive. Restricting or turning off external sharing for a site takes effect fast and doesn’t wait on classification. Blunt, but it works now.
- Conditional Access to constrain who and what can reach the data at all, while the content-aware policy warms up.
- Sensitivity labels with encryption already applied to the sensitive content — protection that travels with the file regardless of whether a downstream DLP index is ready.
- For Copilot specifically: lean on labelling and existing access controls to shape what it can see, rather than waiting on a scope-restriction policy to index before it bites.
None of these are elegant. All of them are on in minutes. That’s the trade during the window.
The old mental model — DLP as a switch you flip and forget — no longer fits these content-aware policies. The engine is smarter now, and smarter costs time upfront. Build the policy before you need it, test the block before you trust it, and never promise a stakeholder protection you can only confirm by watching something fail to leak.
Deployed is not protected. Learn the difference before an incident teaches it to you.
