Most Data Loss Prevention programs die in month two. The technology works. The rules fire. Users complain. The block policy gets rolled back to audit-only. Six months later, someone asks why DLP isn't stopping anything, and nobody has a good answer.
Purview DLP is genuinely good. It lives inside every Microsoft 365 Business Premium and E5 tenant already, and for most Australian businesses it's the best detection engine they'll ever own. The DLP programs that fail aren't failing on the tech. They're failing on the rollout sequence — which is what the rest of this is about.
Inventory before you rule-write
Before a single policy goes live, run Microsoft Defender for Cloud Apps activity discovery and the Purview content explorer. You need to know what sensitive data currently moves across your tenant, where it sits, and who's touching it.
The useful question isn't 'do we have credit-card data?' — it's 'which business unit has 80% of the credit-card data and what's their legitimate workflow for it?' Skip this and your DLP program will read like a trust tax on whichever team happens to handle regulated data.
Start in policy tips mode, not block
Purview DLP has three enforcement postures: audit, policy tip, and block. Start with policy tips for 30 days minimum. A policy tip warns the user inline — 'this email contains a credit card number; are you sure?' — and records the decision. It doesn't block anything.
Two things happen in policy-tip mode. First, you find out how many false positives your rules throw (target: <10% by end of month one). Second, users encounter the policy in the context where they're doing legitimate work — which builds a working mental model for when the block posture lands.
Tune per business unit, not tenant-wide
Tenant-wide DLP policies break more than they protect. Finance legitimately emails bank account numbers. HR legitimately sends TFNs to payroll. Sales legitimately mails out quotes with client names that look like PII.
Scope rules by location, by sender, by recipient domain. A 'credit card number leaving the tenant' policy that excludes payments@yourcompany.com sending to your payment processor's domain will have a false-positive rate an order of magnitude lower than the tenant-default.
Try it
Check your Purview and DLP licence coverage
Not all DLP features are in every M365 SKU — Endpoint DLP in particular. Run the M365 Usage Tool to confirm your licence covers the rules you're planning.
Step 1 of 4
How big is your organisation?
We'll use this to estimate your total spend and scale the recommendations. Change the seat count if you know it exactly.
Endpoint DLP for the USB / upload vectors
Email and Teams DLP catch the email exfiltration paths. Endpoint DLP (requires Microsoft 365 E5 / E5 Compliance) catches USB copies, cloud-storage uploads and browser paste events. For most mid-market businesses, the USB rule alone justifies the add-on.
Endpoint DLP also needs 30 days of audit time before enforcement. Marketing uploads to Dropbox. Engineers paste code into ChatGPT. Sales drops quotes into client extranets. None of these are malicious. All of them trigger if your policy is blunt. Tune first, enforce second.
Sensitivity labels + DLP together
DLP rules scoped to sensitivity labels (rather than raw content) are more accurate, less noisy, and more defensible to your users. If finance labels a document 'Confidential', a DLP rule that stops 'Confidential' content from leaving the tenant is something users understand. A rule that fires on any spreadsheet containing a nine-digit number is harder to defend.
This is also why the Purview sensitivity labels program should run first, or in parallel, to the DLP program — they reinforce each other. Labels without DLP leak. DLP without labels over-fires.
Block, with a hard-coded exception channel
When you move the highest-confidence rules to block, set up a manager-approved override path. In Purview, that's 'Allow override with justification' — the user can still send, but they have to type why. The audit log captures the justification; the manager gets the audit trail; you keep the workflow unblocked.
The override channel isn't a loophole. It's the escape valve that stops the DLP program from being the reason the sales team 'had to' set up a Shadow-IT Dropbox. Measure override usage — a healthy program has <2% override rate on block rules after 60 days.
What slips
- No inventory phase: rules written against imagined data. False positives swamp the program in month one.
- Tenant-wide policies: every team sees DLP noise on content that isn't sensitive for them. Trust evaporates.
- Straight to block: users meet DLP in anger, not in education. The program becomes the IT team's problem, not a business capability.
- No override path: users build Shadow IT to route around you. You now have a bigger problem than the one DLP was meant to solve.
- Labels and DLP as separate projects: they're one program. Sequence them together.