Microsoft Purview DLP: getting started without drowning your team in alerts
Microsoft Purview Data Loss Prevention (DLP) promises to stop sensitive information from leaking through email, file sharing or removable media. Deployed without preparation, it mostly produces thousands of unread alerts and users blocked without understanding why. Here is how to lay solid foundations.
What a DLP policy actually detects
A DLP policy relies first on sensitive information types (SITs): credit card numbers, IBANs, national ID numbers, passport numbers and so on. Microsoft ships several hundred built-in types, and you can create your own from regular expressions and keywords. Each match carries a confidence level (low, medium, high) and an instance count. These two parameters make the difference between a useful rule and a noisy one: a single card number in an email does not warrant the same response as a five-hundred-row export.
Depending on your licence, other classification methods are available: trainable classifiers, exact data match (EDM), and sensitivity labels used as conditions. Check what your subscription includes before designing rules around these features.
Policy locations
| Location | What is controlled |
|---|---|
| Exchange Online | Outgoing messages and attachments |
| SharePoint Online | Documents stored and shared on sites |
| OneDrive | Personal files, especially when shared externally |
| Teams | Chat and channel messages |
| Devices (Endpoint DLP) | Copy to USB, printing, web upload, clipboard; requires device onboarding and an appropriate licence |
There is no need to enable every location at once. Start where the risk is most tangible, often outbound email and external sharing from OneDrive and SharePoint.
Always start in simulation mode
Purview lets you run a policy in simulation mode: matches are logged but no action is applied to users. This is the most important step of the rollout. Let the policy run for several weeks, then review the results with business owners: which flows are legitimate (payroll sending IBANs to the bank, HR exchanging data with a provider) and which are not?
This work lets you tune thresholds, exclude specific recipients or sites, and avoid blocking a critical business process on the day you switch enforcement on.
Policy tips: educate before you block
Policy tips show a warning directly in Outlook, Office apps or SharePoint when a user is about to share sensitive data. A sensible progression:
- Simulation, with no notification at all.
- Policy tip only, to raise awareness.
- Block with override and a logged business justification.
- Strict block, reserved for the most sensitive cases.
The justifications users enter when overriding are a valuable source: they reveal real-world usage and poorly calibrated rules.
Avoiding alert fatigue
One alert per match is the surest way to make DLP useless. Reserve alerts for high-impact rules, use aggregation thresholds (number of events or volume over a period) and define who handles what. Low-severity matches can be reviewed in Activity explorer without generating notifications.
Key point. A DLP policy that blocks from day one is almost always disabled a week later. The simulation phase is not wasted time: it is what makes the policy acceptable and sustainable.
What an audit checks
- Whether DLP policies are actually enforced, not left in simulation for months.
- Which locations are covered compared with the organisation's sensitive data flows.
- How confidence and instance-count thresholds are calibrated.
- Alert configuration and the existence of a triage process.
- Granted exceptions and their justification.