Microsoft DLP: Five Ways Data Loss Prevention Policies Quietly Fail
Microsoft DLP is one of the easier things in Microsoft 365 to switch on and one of the harder things to get genuinely working. A policy gets created, it appears in the Purview portal with a healthy green status, and from that point onwards most organisations assume sensitive data is being caught on its way out of the business.
Often it isn’t. Not because the policy is wrong in any obvious way, but because of how data loss prevention actually behaves in a live tenant. Policies sit in test mode indefinitely. Whole locations are left uncovered because the licence does not extend to them.
Default detection rules fire constantly on things that were never sensitive, and staff learn within a fortnight to click straight past the warnings. Alerts arrive in a mailbox nobody has opened since the policy was built.
None of these failures announce themselves. A DLP policy that catches nothing looks identical, from the admin centre, to one that is quietly doing its job. The dashboard shows a policy exists; it does not show whether anything is being stopped, or whether the things being stopped are the things that matter.
The difference between the two comes down to a handful of specific, checkable settings and habits. Knowing which ones to look at means you can answer the question your auditor, your insurer, or your board will eventually ask: not whether you have DLP, but what it has actually prevented.
Quick summary
DLP policies fail quietly rather than loudly, which is why so many tenants have policies that look correct and catch very little.
A DLP policy that has never blocked anything is not evidence that nothing needed blocking.
What Microsoft DLP is supposed to do
Microsoft Purview Data Loss Prevention identifies sensitive content, such as card numbers, National Insurance numbers or passport details, and applies rules when someone tries to share, copy or send it somewhere it should not go. Depending on how the policy is configured, it can warn the user, block the action outright, allow it with a recorded justification, or simply log what happened.
DLP is one part of the wider Purview platform, and if you want the broader picture of how it sits alongside sensitivity labels, retention and audit, our overview of what Microsoft Purview does covers that ground. What follows here is narrower: the specific ways DLP policies underperform once they are live.
One: policies left in simulation mode
Simulation mode exists for good reason. It lets you see what a policy would have caught without actually blocking anyone, which is exactly how a sensible rollout should begin. The problem is what happens next, which is frequently nothing at all.
A policy gets built, put into simulation, reviewed once, and then left there. Months later it is still monitoring and still not enforcing. The Purview portal shows the policy as active, because it is, but active in simulation is not the same as active in enforcement.
This is the same pattern that caused real compromises in the Microsoft 365 password spray attack, where Conditional Access policies had been correctly configured and then left in report-only mode. The control existed. It had simply never been switched on properly.
Worth knowing: full simulation mode is itself an E5 or Purview Suite capability. Organisations on E3 cannot test policies safely before enforcing them, which pushes them towards either deploying blind or not deploying at all.
Two: the locations nobody switched on
This is the gap that surprises people most, and it is a licensing constraint rather than a configuration oversight.
Microsoft 365 E3 includes DLP for Exchange Online, SharePoint Online and OneDrive for Business. It does not include:
- Teams chat and channel messages. Files shared in Teams are covered, because they live in SharePoint or OneDrive underneath, but the messages themselves are not inspected on E3.
- Windows and macOS endpoints. Copying a file to a USB stick, printing it, pasting it into a personal webmail tab or uploading it to consumer cloud storage all sit outside E3 DLP entirely.
- Third-party cloud apps, which require Defender for Cloud Apps to bring under DLP control.
Both Teams chat DLP and endpoint DLP require Microsoft 365 E5 or the Purview Suite add-on, and endpoint DLP additionally depends on devices being onboarded to Defender for Endpoint, since it uses that sensor for enforcement rather than installing anything separate.
The practical result is an organisation that uses Teams as its main communication channel, protects email and SharePoint diligently, and leaves the two routes staff actually use to move data uncovered. If you are weighing whether that gap justifies a licence change, our comparison of Microsoft 365 E3 and E5 sets out where the additional cost does and does not pay for itself.
Three: default detection rules and the false positive problem
Microsoft ships over a hundred built-in sensitive information types, each with default confidence levels and match thresholds. They are a reasonable starting point and a poor finishing point.
Left untuned, they produce a steady stream of matches on content that was never sensitive. Reference numbers that resemble card numbers. Test data in a spreadsheet. A supplier’s VAT number in an email footer. Each one generates a warning, and each warning slightly reduces the odds that the next genuine one gets read.
Tuning means sampling real matches from your own tenant, checking which are genuine, and adjusting confidence levels and instance counts accordingly. It is unglamorous work and it is the single thing that most separates a DLP deployment that works from one that merely runs.
Four: policy tips and overrides nobody reviews
Where a policy allows the user to proceed with a justification, that justification is recorded. Very few organisations ever read them.
This matters for two reasons. The justifications are a genuinely useful signal, showing where legitimate business processes are colliding with policy and need the policy adjusting rather than the staff working around it. They are also, occasionally, evidence of exactly the behaviour DLP was bought to catch.
A sensible rhythm looks like this:
- Review override justifications monthly rather than never
- Look for repeated patterns, which usually indicate a policy that needs refining rather than a user who needs training
- Escalate the small number that look genuinely concerning
Without that review, the override option quietly becomes a button that makes the warning go away.
Five: alerts arriving somewhere nobody looks
DLP incidents generate alerts, and alerts need a destination and an owner. In a surprising number of tenants they route to a generic administrator mailbox, a distribution list from a previous IT arrangement, or an address that stopped being monitored when someone left.
The fix is unglamorous but decisive: confirm where alerts currently go, confirm who is responsible for acting on them, and confirm that person knows they hold that responsibility. This is the same accountability gap that undermines Microsoft Secure Score recommendations, where the information is available and nobody owns the act of looking at it.
Common mistakes and pro tips
A few patterns come up repeatedly when DLP configurations are reviewed properly:
- Building policies around what the tool can detect rather than what the business actually needs to protect
- Enforcing aggressively from day one, which drives staff towards personal email and consumer file sharing, increasing risk overall
- Assuming endpoint DLP is running when devices were never onboarded to Defender for Endpoint
- Treating the initial rollout as the project, when the tuning that follows is where the value sits
A short pilot on one genuinely sensitive data type, tuned against real matches before enforcement widens, will produce a better outcome than a comprehensive policy set that everyone has learned to ignore.
Do you know what your DLP policies have actually blocked?
Our free Microsoft 365 risk and cost health check reviews which locations your policies cover, what your licensing actually entitles you to, and where sensitive data can still walk out of the business. No obligation, and if your policies are already doing their job we will say so.
The bottom line on Microsoft DLP
Data loss prevention is unusual among security controls in how convincingly it can appear to work while doing very little. There is no outage, no error, no red indicator. A policy in simulation mode, covering only the locations your licence reaches, matching on untuned defaults that staff have learned to dismiss, will sit in the portal looking exactly like a policy that is protecting the business.
Getting from one to the other is not complicated, but it is deliberate. It means knowing which locations you are entitled to cover, moving policies out of simulation once they have been tested, tuning detection against your own data, and giving somebody clear ownership of the alerts.
Our Microsoft 365 Support service includes configuring and tuning DLP policies as part of ongoing tenant management, so coverage matches your licensing, false positives get resolved rather than tolerated, and incidents reach someone who acts on them.
STRAIGHT ANSWERS
Frequently asked questions
Does Microsoft 365 E3 include DLP?
Yes, but only partially. E3 includes DLP for Exchange Online, SharePoint Online and OneDrive for Business. It does not cover Teams chat and channel messages, Windows or macOS endpoints, or third-party cloud applications. Those require Microsoft 365 E5 or the Purview Suite add-on.
Why is my DLP policy not blocking anything?
The most common reasons are that the policy is still in simulation or test mode, that it is scoped to locations where the activity is not happening, or that the sensitive information types it relies on are not matching your actual content. Checking the policy mode first will resolve a good proportion of cases.
What is the difference between DLP simulation mode and enforcement?
Simulation mode shows what a policy would have caught without taking any action against users, which makes it the right way to test before going live. Enforcement applies the configured action, such as warning or blocking. A policy left in simulation records activity indefinitely without ever preventing anything.
Does Microsoft DLP cover Teams?
It depends on both licensing and what you mean by Teams. Files shared in Teams are stored in SharePoint or OneDrive and are covered under E3-level DLP. Chat and channel messages themselves are only inspected with Microsoft 365 E5 or the Purview Suite add-on.
How often should DLP policies be reviewed?
A quarterly review is a reasonable baseline, covering false positive rates, override justifications and whether coverage still matches how the business works. Any significant change, such as adopting a new application or onboarding a new type of sensitive data, warrants a review at the time rather than waiting.
Related posts
Cyber Essentials Requirements in 2026: What Changed, and What Now Fails You Automatically
Ransomware Protection in Microsoft 365: How Attacks Get In and What Stops Them
