Microsoft Purview Data Loss Prevention — a deep dive

Microsoft Purview Data Loss Prevention (DLP) is the policy engine that detects when sensitive data — credit card numbers, government IDs, source code, custom-defined patterns — is shared in a way that could put it at risk, and takes action.

Where DLP applies

DLP policies span the Microsoft 365 surface:

• Exchange Online — outgoing email containing sensitive content.
• SharePoint and OneDrive — files at rest, files shared externally.
• Teams — chat and channel messages.
• Endpoint DLP — protected actions on managed Windows and Mac endpoints (USB copy, cloud sync upload, printing).
• Power BI — dataset and report content.
• Defender for Cloud Apps — sanctioned non-Microsoft SaaS apps.
• Microsoft 365 Copilot — newer integration that limits Copilot's use of labelled sensitive data.

Sensitive Information Types (SITs)

DLP detects content via sensitive information types: regular expressions plus contextual scoring (a credit-card number is more likely real if it appears near words like "card," "expiry," "CVV"). Microsoft ships hundreds of built-in SITs covering most regulated data types globally. Custom SITs let you define your own — internal customer numbers, source code, project codenames.

Exact Data Match (EDM) SITs let you match against a known list (e.g., your actual customer SSNs uploaded as a hash), avoiding false positives common with generic SITs.

Trainable classifiers use ML to identify content types — IP, source code, legal documents — that don't fit regex patterns.

Policy actions

A DLP policy combines a location (which workload), a condition (which content), and an action:

• Audit only — log, no user impact.
• Notify — show a tip to the user.
• Justify — require the user to provide business justification.
• Block with override — prevent the action but let the user override with justification.
• Block — hard block.
• Encrypt — automatically encrypt the message (Exchange).
• Remove sharing — strip external sharing links on a file (SharePoint).

The right action varies by data type and risk tolerance.

Rollout

A typical DLP rollout:

1. Inventory regulated data types the organisation handles.
2. Build policies in audit-only mode.
3. Tune SITs and exclusions against the audit findings (false positives are common).
4. Move highest-risk policies to notify, then block with override.
5. Pair with sensitivity labels so user-applied labels are also a DLP signal.
6. Add Endpoint DLP for managed devices.

Licensing

DLP for Exchange and Teams is included in Microsoft 365 E3. Endpoint DLP, advanced DLP capabilities, and the full Purview DLP feature set require E5 or Purview-specific add-ons.

Practical caveats

• DLP is signal-driven; it can't read intent. Tune relentlessly.
• Block-with-override is usually the right default; full block annoys users without much extra security.
• Endpoint DLP is powerful but requires Defender for Endpoint onboarding.
• DLP doesn't replace sensitivity labels — they work together.

Done well, DLP creates guardrails that catch the accidental exposures that make up most data-loss events, while staying out of the way for normal work.

Decision matrix — action by data class and workload

Start-of-rollout defaults that survive real usage. Read the row as "for this data class, in this workload, the action should be…" and adjust by regulatory obligation, not by user resistance.

| Data class | Exchange (outbound) | SharePoint / OneDrive (external share) | Teams (chat + channel) | Endpoint (USB / cloud upload) | |---|---|---|---|---| | Regulated PII (SSN, national ID, health record) | Block with override + policy tip | Block external share, notify owner | Block with override in external channel; audit internal | Block USB, warn on cloud upload | | Payment card data (PAN, CVV) | Block (no override) | Block external share (no override) | Block (no override) | Block USB and cloud upload | | Credentials (keys, tokens, connection strings) | Block with override; strip on override | Notify + revoke external link | Block with override | Block on all endpoints | | Company-confidential (labelled Confidential) | Notify + require justification | Notify + require justification | Audit | Warn | | Internal / general | Audit only | Audit only | Audit only | Audit only |

The pattern: hard block only where the regulator would, block-with-override where the business would, and warn everywhere else. Full hard-block on data that people legitimately need to email breeds shadow IT (personal Gmail, WhatsApp) — worse than a policy tip.

Worked example — a 900-seat healthcare co-op, first six months

A concrete rollout for a 900-seat organisation subject to health-data rules, with an in-house compliance officer and one M365 admin part-time on Purview:

1. Weeks 1–2 — inventory and label taxonomy. Data classification workshop with compliance and clinical leads produced four labels (Public / Internal / Confidential / Restricted-PHI). Regulated data types: patient identifiers, insurance numbers, clinician credentials. No custom SITs on day one — the built-in "US Health Insurance Number" and equivalents covered the majority.
2. Weeks 3–6 — audit-only across the estate. DLP policies deployed in audit-only for all four workloads. First-week findings: 340 emails/day triggering the PHI policy, of which about 60 were true positives (referrals, insurance responses) and the rest false — mostly clinician numbers matching the SIT pattern by coincidence. Two SIT exclusions and one document-fingerprint-based EDM classifier for the internal patient-ID format brought false positives below 10%.
3. Weeks 7–10 — notify mode. Policy tips turned on. Clinician training happened alongside — the tip carried a one-line link to the referral guidance. Support tickets: 12 in week 7, 3 in week 10. Compliance officer became the escalation route for real edge cases.
4. Weeks 11–14 — block-with-override where PHI leaves the tenant. External Exchange, external SharePoint shares, external Teams channels moved to block-with-override; internal stayed on notify. One documented case in week 12 where a legitimate insurer email was overridden; the override log went to the compliance officer, who added the insurer domain to the allow list.
5. Weeks 15–20 — Endpoint DLP. Defender for Endpoint onboarding checked (already in place). Endpoint policies deployed: block USB copy of PHI-labelled files, warn on cloud upload to non-approved domains, allow to OneDrive and the approved research-partner SFTP. Managed macOS caught the second-largest slice of true blocks.
6. Weeks 21–26 — labels as the primary DLP signal. Sensitivity labels rolled out to the org, auto-labelling configured for the SIT-detectable content, and the DLP policies rewritten so the primary condition became "content is labelled Restricted-PHI" with SIT match as the fallback. Cleaner, more auditable, and the labels double as encryption policy inside the tenant.

Six-month scoreboard: 8 real prevented exposures in the block window, ~180 override-with-justification events (of which 15 flagged for compliance review), zero regulatory findings on the next annual audit. Ongoing cost: about 4 hours/month of Purview policy tuning after the initial push.

MSP checklist

DLP scales worse than most Purview features for partners — every customer needs its own labels, SITs, and thresholds — but the pattern below stops per-tenant work from ballooning:

• Bake a baseline into tenant onboarding. A "starter DLP" set: audit-only policies for the top regulated data types the customer's sector cares about, wired to the customer's own compliance mailbox from day one. Charge for the tuning conversation, not the policy authoring.
• Never share an SIT across tenants unless the pattern is truly generic — customer-specific IDs and formats belong in that tenant's EDM data source, not in a partner-wide library. Confusing customer data with a partner-wide test set is a breach on its own.
• Log DLP alerts into the partner SIEM and the customer's own — the partner sees the pattern across the book of business, the customer keeps evidence for their own audits.
• Endpoint DLP requires Defender for Endpoint onboarding, which means a Defender licence and a device baseline you can't hand-wave. Price the two together.
• Get override log ownership decided before block-with-override goes live. MSPs are frequently made the default reviewer by accident, which is not a role most partners want to hold for someone else's business decisions.

Wrong-fit cases

• You want to stop insider exfiltration. DLP catches the accidental and the naive; a determined insider will screenshot, retype, or use a personal device. Pair with Insider Risk Management and Adaptive Protection for behavioural detection — see what is insider risk management.
• You want to classify unstructured intellectual property. Regex is the wrong tool for a legal brief or a design spec. Use trainable classifiers (built-in for source code, financial, legal, HR, plus custom trainable classifiers) as the DLP condition rather than an SIT.
• You want to protect data at rest indefinitely. DLP is action-time — it does not sweep the whole tenant re-tagging historical files. Use auto-labelling policies in sensitivity labels for the retrospective sweep, then feed the labels into DLP.
• You want to block data leaving a specific department. DLP conditions are content-based, not org-based, at their core. Combine with location targeting (specific SharePoint sites, specific groups) rather than trying to describe "the finance team's data" as an SIT.
• You need real-time device control on unmanaged devices. Endpoint DLP requires Defender for Endpoint onboarding. Unmanaged devices need Conditional Access app control or Defender for Cloud Apps session policies as the enforcement point instead — see Defender for Cloud Apps explained.

Common failure modes

• Straight-to-block on day one. Nine times out of ten the SIT catches things it shouldn't, users lose work, and the policy is pulled. Audit first, always.
• No feedback loop for the false positives. The policy tip needs to say who to contact if the block is wrong, and that contact needs a queue that gets read. Otherwise every override goes through unreviewed and the policy becomes theatre.
• Ignoring sensitivity labels. Labels are a much stronger DLP condition than SITs — they capture human judgement about what the document actually is. DLP + labels is the mature configuration; DLP alone is the interim state.
• Endpoint DLP without device compliance in Conditional Access. Users switch to a personal laptop, DLP doesn't apply, and the control is bypassed by design. Endpoint DLP only helps if the compliant-device policy is what gets the user to their data.
• One giant policy per workload. Debugging becomes impossible. Split by data class (payment, PII, credentials, IP) so a rule change touches one policy, not the whole estate.

Related reading

• Purview sensitivity labels — a deep dive — the primary partner control.
• Purview auto-labelling policies — retroactive classification that feeds DLP conditions.
• What is Microsoft Purview — the umbrella and the licensing shape.
• Defender for Cloud Apps — session policies for unmanaged devices and third-party SaaS.
• Purview insider risk management — behavioural detection to complement DLP.