A useful DLP policy starts with one specific risk
Microsoft Purview Data Loss Prevention detects sensitive information and can monitor, warn, or restrict sharing in covered locations. A policy that tries to protect every type of data everywhere usually creates noise. Start with a measurable intent, such as reducing external transmission of customer records from Exchange, SharePoint, and OneDrive.
DLP is neither backup nor retention. Labels describe and protect content, retention governs its lifecycle, and backup supports recovery after loss. DLP primarily acts when content matches defined conditions and is used or shared in a specified way.
Define the scenario before opening the wizard
Write an intent statement naming the data, risky action, users, locations, and desired outcome. A fictional example is: warn DLP-Pilot-Users when they externally share at least two high-confidence customer identifiers, then block without justification only after the pilot succeeds.
Sensitive information types use patterns, corroborative evidence, proximity, and confidence. A payment-card-like number in training material is not necessarily a leak. Test the combination of type, count, confidence, context, and destination rather than an isolated keyword.
- Name a business owner who can separate a real risk from a valid process.
- Define locations and exclusions before creating the rule.
- Write exit criteria: valid-match rate, explained exceptions, and no blocked critical process.
Scope, prerequisites, and licenses are not universal
Purview DLP can cover Exchange Online, SharePoint Online, OneDrive, Teams messages, and devices, but available actions differ by location. An email rule does not behave like a USB-copy restriction. Endpoint DLP requires supported devices onboarded into Purview; browsers, applications, and file formats also have specific limitations.
Entitlements depend on the product, location, and capability. Core Microsoft 365 protection does not automatically license Endpoint DLP, advanced features, or every analytics experience. Check Microsoft’s service description and comparison tool against the subscriptions actually assigned to covered users, and validate device-onboarding requirements.
Use least privilege. Microsoft documents Compliance Administrator, Compliance Data Administrator, Information Protection, and Security Administrator role groups plus more granular DLP roles. Separate creation, approval, and investigation where practical.
Inventory the current configuration read-only
Before adding a policy, inventory rules, modes, priorities, and locations. The following script reads configuration from Security & Compliance PowerShell and changes nothing. Run it with an authorized role from an approved administrative session, then remove sensitive identifiers and paths before sharing output.
Also inventory Exchange transport rules, sensitivity labels, SharePoint sharing controls, and current exceptions. Two controls can affect the same user action; testing must identify which one produced a tip or block.
# Read-only inventory. ExchangeOnlineManagement is required.
Connect-IPPSSession
Get-DlpCompliancePolicy |
Select-Object Name,Mode,Priority,Enabled,ExchangeLocation,
SharePointLocation,OneDriveLocation,TeamsLocation |
Sort-Object Priority
Get-DlpComplianceRule |
Select-Object Name,Policy,Disabled,Priority,BlockAccess,
NotifyUser,GenerateIncidentReportCreate the first policy in simulation
In the Microsoft Purview portal, open Solutions > Data Loss Prevention > Policies, then create a custom policy or start from a relevant template. Scope it to a small group and a few test sites. Add a rule for external sharing of fictional customer data with a high-confidence condition and a realistic threshold.
Select Run the policy in simulation mode. Simulation evaluates the policy without enforcing restrictions and separates matches from enforced-policy results. Showing policy tips in simulation tests the user message, but it does change the experience: enable it only after a silent baseline and communication to the pilot.
- Stage 1 — silent simulation: measure matches and false positives.
- Stage 2 — simulation with tips: validate wording, help, and user understanding.
- Stage 3 — small enforced ring: allow justified override where risk and process support it.
- Stage 4 — expansion: block only high-confidence scenarios with a tested rollback.
A practical example without real personal data
Fictional Contoso North wants to reduce external transmission of customer files. It begins with Exchange, SharePoint, and OneDrive, ten volunteers, and two test sites. All test values are synthetic; no real person or production record is used.
The low-confidence rule records matches for tuning and blocks nothing. The high-confidence rule initially generates a tip and alert. After the pilot, it may prevent external sharing while allowing documented justification for an approved workflow. A very high-risk path may be blocked without override, but only after business validation.
Test case: External sharing of fictional customer data
Policy: CA-DLP-Customer-Data-Pilot
Pilot: DLP-Pilot-Users and DLP-Pilot-Sites
Data: synthetic values only; never copy production records
Expected results
1. Internal sharing, no sensitive data -> no match
2. External sharing, one low-confidence hit -> record for tuning
3. External sharing, multiple high-confidence hits -> policy tip/alert
4. Approved business workflow -> justified override in pilot
5. Unauthorized external recipient -> block after enforcement approvalRead results before switching enforcement on
In Simulation results, Activity explorer, and the DLP alerts dashboard, review the file or message, detected type, confidence, user, location, destination, and simulated action. An alert is not proof of malicious intent. Confirm context with the business owner and restrict content access to investigators who need it.
Measure accuracy by scenario and process, not only total event count. Track valid matches, false positives, ignored tips, overrides, unique users, and affected critical workflows. Fewer alerts may indicate better tuning—or a policy narrowed too far.
| Signal | Validation question | Possible tuning |
|---|---|---|
| Many false positives | Do type, confidence, and proximity fit the document? | Raise confidence/count or add context |
| Repeated valid workflow | Are destination and owner approved? | Minimal, owned, expiring exception |
| No matches | Are scope, format, and location actually covered? | Fix the test before declaring the risk absent |
| Many overrides | Is the tip clear or the rule too broad? | Revisit intent and interview the pilot |
Manage exceptions as controlled debt
An exception should never be the entire finance department forever. Give it a rationale, owner, minimum technical scope, compensating control, and review date. Prefer a precise destination, site, or restricted group over a global user exclusion.
Policy tips and justified overrides help when users have context the policy cannot see. They are not appropriate for every risk. Review repeated justifications: they can reveal a workflow to redesign, a training need, or a poorly calibrated rule.
Enforce gradually and prepare rollback
Moving from simulation to enforcement is a production change. Export or document scope, mode, and rules first. Enable one ring at a time, provide a support channel, and allow for propagation. Test new actions rather than relying on an event already evaluated.
If impact occurs, return the affected policy or rule to simulation, or disable only the new rule under the approved plan. Do not delete the whole policy: retaining configuration and events supports diagnosis. Confirm the workflow is restored and that other policies still protect data.
- Stop criteria: critical process blocked, unexplained spike, misleading tip, or alerts exceeding response capacity.
- Expansion criteria: representative tests passed, acceptable scenario accuracy, approved exceptions, and ready support.
- Periodic review: owners, licensing, locations, sensitive types, exceptions, and application changes.
Make DLP an operational control, not a rule collection
Effective DLP connects classification, sharing, identity, devices, alerts, and investigation procedures. Keep a register of policy intents, owners, simulation results, exceptions, and enforcement decisions. Train the service desk to distinguish a tip, override, and actual block.
Start with a few high-value risks, then improve them using pilot evidence. A Microsoft 365 assessment can map data, licenses, sharing paths, and ownership before wider deployment; this guide does not replace an environment-specific assessment.
About the author
Marc-Antoine Lambert
Montréal-based senior IT consultant and Team Lead specializing in architecture, cybersecurity, Microsoft infrastructure, networking and business continuity.
Discuss your environment →