DLP

Data loss prevention (DLP) is the family of Microsoft Purview policies that detect when sensitive data is being shared or moved and take action — block, warn, or audit. Out-of-the-box and custom sensitive information types identify credit-card numbers, government IDs, source code, and many other patterns. DLP policies apply across Exchange (outbound email), SharePoint and OneDrive (file sharing), Teams (chat and channel messages), and endpoint DLP on managed Windows and Mac devices. Higher tiers add detection inside Microsoft 365 Copilot interactions and across non-Microsoft cloud apps via Defender for Cloud Apps. DLP requires Microsoft 365 E5 or appropriate Purview add-ons.

How a policy actually decides

A DLP policy is built from conditions (which sensitive information types, how many instances, what confidence level) and actions (block sharing, block with override and a business-justification prompt, or just audit and let it through while logging). The confidence level matters more in practice than admins expect: a "credit card number" sensitive information type match at low confidence is just a 16-digit number pattern with a valid checksum — it will false-positive against invoice numbers, tracking numbers, and other 16-digit sequences unless the policy requires corroborating evidence (nearby keywords like "card" or "expiry", or a higher confidence tier). Most rollouts start every rule in audit-only for two to four weeks specifically to tune the sensitive information type thresholds against real traffic before ever blocking a user.

Worked example

A tenant wants to stop customer national ID numbers leaving via email to external recipients, but not block internal use. The policy scopes to Exchange, condition "content contains" the relevant sensitive information type at high confidence, with an exception for recipients inside the organisation's own domains, and an additional exception for a small legal-team distribution group that legitimately handles this data with customers under signed data-processing agreements. The action is block with override: the sender sees a policy tip explaining why, and can click through with a typed justification if they believe it's a false positive — that justification is logged and reviewable, rather than silently blocking legitimate business and generating help-desk tickets with no context.

Endpoint DLP and Copilot

Endpoint DLP extends the same policies to actions on a managed device itself — copying a sensitive file to USB, uploading it to a personal cloud storage app in a browser, printing it, or copying its contents to the clipboard for pasting elsewhere. It requires the device to be Intune- or Configuration Manager-managed and onboarded to Microsoft Purview's endpoint agent. Separately, DLP for Microsoft 365 Copilot (part of the broader Copilot data-security story) can prevent Copilot from summarising or surfacing content that a DLP policy has flagged as restricted, which matters specifically because Copilot's retrieval respects a user's existing permissions — DLP adds a content-sensitivity layer on top of permissions, catching cases where a user technically has access to a file but the content itself shouldn't be casually surfaced in an AI-generated answer.

Common pitfalls

The most frequent rollout failure is skipping the audit-only tuning phase and going straight to block, which generates a wave of false-positive help-desk tickets and burns organisational goodwill for the whole DLP programme. The second is scoping a policy too broadly (all of SharePoint, every site) instead of starting with the highest-risk locations (the sites and mailboxes that actually handle the sensitive data type in question) and expanding once the policy is proven. DLP policies also interact with sensitivity labels — a document labelled "Highly Confidential" can be a DLP condition in its own right, which is often a cleaner signal than pattern-matching the content itself.