How to Implement Data Loss Prevention with Microsoft Purview
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Data Loss Prevention implementation commonly fails in two ways: policies that are too sensitive generate alert floods that overwhelm security teams and train users to click through override prompts, and policies that are too narrow miss actual data exfiltration. Microsoft Purview DLP provides the platform, but the policy logic requires careful tuning against your specific data types and user workflows. This guide covers building effective DLP policies from sensitive information type selection through production enforcement.
Define Your Sensitive Data Classification Scope
Before creating policies, define what data you are protecting and where it lives. Microsoft Purview's Content Explorer shows a sample of what sensitive information types currently exist across your Microsoft 365 tenant: Purview > Data Classification > Content Explorer. Review which sensitive information types are detected: this gives you a baseline of what Purview can already find before any policy is applied. Common starting scope for DLP: (1) Regulated data: PII (SSN, driver's license, passport), payment card data (PAN), protected health information (PHI), financial account numbers; (2) Business confidential: M&A information, product roadmaps, source code, employee compensation data; (3) Credentials: passwords, API keys, private keys (often missed in traditional DLP). For regulated data, use Microsoft's built-in sensitive information types which have been validated against regulatory definitions. For business-specific data, create custom sensitive information types using keyword dictionaries and regular expressions. Start with one data category per policy phase rather than trying to protect everything in one policy deployment.
Create DLP Policies in Simulation Mode
Create DLP policies in simulation mode first: this evaluates policy logic against real traffic and logs what would have been blocked without enforcing anything. Purview > Data Loss Prevention > Policies > Create Policy. Select template or custom. Under Locations, select Exchange email, Teams messages, SharePoint/OneDrive for the first policy; add Endpoint DLP in a subsequent phase. Under Conditions, add sensitive information types at High Confidence level (Low Confidence generates significantly more false positives). Under Actions, set to Simulation mode. Run simulation for 2-4 weeks. Review simulation results: Purview > Data Loss Prevention > Policy alerts in simulation mode. For each alert, evaluate: is this a true positive (actual sensitive data shared inappropriately) or false positive (legitimate business activity). Tune instance count thresholds: a policy triggering on a single SSN in an HR email is different from triggering on 100 SSNs in an email to an external address. Typical starting threshold: 3+ instances with High Confidence before generating an alert.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Configure Exchange and Teams DLP
Exchange DLP policies intercept email before delivery and can block, notify, or add encryption. After simulation validation, switch to enforcement mode. Recommended policy actions for email: (1) Block sharing of payment card data or SSNs externally: no business justification for emailing unencrypted SSNs outside the organization; (2) Encrypt email automatically when sensitive information is detected in the body or attachments using Microsoft Purview Message Encryption; (3) Send incident report to the security team for any external sharing of PHI. For Teams: DLP in Teams blocks messages in channels, chats, and meeting chats. A block in Teams generates an inline notification to the user explaining why the message was blocked and whether they can override. Configure: Purview > DLP Policy > Locations > Teams chat and channel messages. Note: Teams DLP does not currently scan files shared within Teams channels: those files go to SharePoint and are covered by SharePoint DLP rules. Test Teams DLP by sending a test message with synthetic PII (use obviously fake SSNs like 123-45-6789) to confirm the policy triggers correctly before applying to production.
Deploy Endpoint DLP for USB and Browser Controls
Endpoint DLP extends protection to Windows 10/11 endpoints, controlling file activities including USB copy, browser upload, print, and clipboard. Requirements: Windows 10 1809+, Microsoft Defender for Endpoint onboarded, E5 or E5 Compliance license. Enable in Purview: Settings > Device Onboarding (verify devices appear). Create Endpoint DLP policy: Purview > DLP > Create Policy > Locations > Devices. Configure activities to restrict: (1) Copy to USB removable media: block or allow with justification; (2) Upload to cloud services: block upload to non-approved services (configure allowed cloud storage list: corporate SharePoint, approved data rooms); (3) Print to local printer: audit or block depending on data sensitivity; (4) Copy to clipboard: audit only (blocking clipboard is disruptive to legitimate workflows). Endpoint DLP also integrates with Microsoft Defender for Endpoint alerts: a DLP block event correlates with the Defender device timeline showing what the user was doing before the blocked action. Test Endpoint DLP: create a test file with synthetic sensitive information, attempt USB copy, verify the block or justification prompt appears and the event logs in Purview activity explorer.
Tune False Positives Systematically
False positive reduction is the most time-consuming part of DLP deployment. Common false positive sources: (1) Internal HR systems that legitimately process SSN data: exclude the HR application's service account from DLP scope; (2) Automated reporting that includes financial account numbers: exclude the service account running the report; (3) Security testing and training content that contains synthetic PII: create a sensitivity label 'Security Testing' and add a policy exception for that label; (4) Encryption key material matching credit card patterns: add pattern exclusions for base64-encoded strings of certain lengths. Purview tuning options: Add exceptions by user, group, domain, or sensitivity label. Adjust confidence level from High to Very High (fewer matches, more confident). Increase instance count threshold (require 5+ instances rather than 1). Add corroborating keyword requirements to the sensitive information type (require 'SSN' or 'Social Security' within 300 characters of the pattern match). Track false positive rate: monthly review of DLP incidents, categorize each as true positive, false positive, or business-justified override. Target false positive rate under 5% of total DLP incidents before expanding scope.
Build DLP Alerting and Response Workflows
DLP incidents require a triage workflow. Configure alerts: Purview > DLP > Alerts. Set alert thresholds: generate an alert when a single high-severity policy match occurs (e.g., bulk SSN exfiltration), or aggregate low-severity matches into daily digest reports. Integrate with Microsoft Sentinel for SIEM-level analysis:
PurviewDLPActivity
| where TimeGenerated > ago(24h)
| where SeverityLevel == "High"
| where PolicyName contains_any ("Payment Card", "SSN", "PHI")
| summarize IncidentCount=count() by UserPrincipalName, PolicyName, Location
| where IncidentCount > 3
| order by IncidentCount desc
For automated response, use Microsoft Sentinel Playbooks (Logic Apps) to: notify the user's manager when they trigger a high-severity DLP incident, create a ServiceNow ticket for the security team, and trigger an Entra ID conditional access policy to require step-up MFA for the user account involved in a suspected data exfiltration incident. Build an SLA for DLP incident response: High severity incidents investigated within 4 hours, Medium within 24 hours, Low reviewed in weekly batch.
The bottom line
Purview DLP implementation requires four phases: classify what data to protect (use Content Explorer to baseline what Purview already finds), create policies in simulation mode and run for 2-4 weeks, tune false positives systematically using exceptions by user/group and confidence level adjustments, then enforce. Start with Exchange email DLP for regulated data (PII, PAN, PHI), add Teams and SharePoint after email is stable, and deploy Endpoint DLP for USB/browser controls last. Target false positive rate under 5% before expanding scope.
Frequently asked questions
How do I reduce false positives in Microsoft Purview DLP policies?
Reduce DLP false positives by using High Confidence level (not Low or Medium) in policy conditions, increasing the instance count threshold to require 3+ sensitive information type matches before triggering (a single SSN in an HR email is different from 100 SSNs), adding corroborating keyword requirements to sensitive information type definitions, and adding exceptions for service accounts used by legitimate HR or finance applications. Run policies in simulation mode for 2-4 weeks before enforcement and categorize every simulation alert as true positive, false positive, or business-justified before going live.
What license is required for Microsoft Purview Endpoint DLP?
Microsoft Purview Endpoint DLP requires Microsoft 365 E5 or Microsoft 365 E5 Compliance license. Devices must be running Windows 10 version 1809 or later and be onboarded to Microsoft Defender for Endpoint. Endpoint DLP cannot be deployed independently of Defender for Endpoint onboarding: the Defender sensor provides the activity monitoring that Endpoint DLP uses to intercept file copy, USB, and browser upload events.
How do I start a DLP program when the organization has no existing data classification?
Bootstrap a DLP program without pre-existing data classification: (1) Run Microsoft Purview in scan-only mode to discover where sensitive information types (PII, financial data, health information) actually exist in your environment — the built-in sensitive information types cover SSNs, credit card numbers, passport numbers, and hundreds of other formats without custom configuration. (2) Use the discovered locations to prioritize classification: the top 3-5 locations with the highest concentration of sensitive data are your first DLP protection targets. (3) Start with Exchange Online email DLP (the lowest-disruption policy type): block sharing of large volumes of PII externally via email. (4) Expand to SharePoint and OneDrive, then to Endpoint DLP for USB and browser uploads. Build the classification scheme to match where the data actually lives, not where you assume it should be.
What is the difference between Microsoft Purview DLP and Microsoft Purview Information Protection?
Microsoft Purview Information Protection (formerly Azure Information Protection / Microsoft Information Protection) is the labeling and encryption layer: it classifies documents and emails with sensitivity labels (Public, Internal, Confidential, Highly Confidential) and can apply encryption and access controls to labeled content. DLP is the enforcement layer: it monitors for policy violations and blocks or audits the movement of sensitive content. They complement each other: labels from Information Protection can be used as conditions in DLP policies (block sharing of any document labeled 'Highly Confidential' outside the organization), while DLP's sensitive information type detection can trigger automatic labeling recommendations in Information Protection. A mature data protection program uses both: labels for classification and user awareness, DLP for technical enforcement.
How do I prevent DLP policies from blocking legitimate business operations?
DLP policy design to avoid blocking legitimate operations: (1) Create business justification overrides for power users (legal, finance, executive) — they can override a DLP block by providing a business reason, which is logged for audit. (2) Use high-confidence thresholds and instance count minimums before blocking (3+ matches for credit cards, not 1). (3) Exempt specific sender/recipient pairs or SharePoint sites used for legitimate external sharing of sensitive data (legal discovery, financial audits). (4) Run in monitor-only mode for 30 days, review the top 20 false positive patterns, and add those patterns as exceptions before enabling enforcement. (5) Conduct a DLP policy review quarterly: business processes change, and an exception or exclusion that was appropriate 6 months ago may no longer be valid.
How do I extend Microsoft Purview DLP to cover data exfiltration via generative AI tools like ChatGPT and Copilot?
Microsoft Purview Endpoint DLP controls browser uploads to specific cloud services, which includes generative AI platforms accessed via web browser. In Purview > Settings > Endpoint DLP > Browser and domain restrictions, add the domains of AI platforms you want to block or audit (chat.openai.com, claude.ai, gemini.google.com) to your 'Sensitive service domains' list, then create a policy that restricts 'Upload to a restricted cloud service domain or access from an unallowed browser' activity. For Microsoft 365 Copilot specifically, Purview sensitivity labels flow directly into Copilot's behavior: documents labeled Highly Confidential are excluded from Copilot's context window when the policy is configured to block Copilot access at that label tier, preventing Copilot from summarizing or referencing the content. For browser-based ChatGPT and similar tools, Endpoint DLP detects when a user pastes or uploads content matching a sensitive information type into a monitored browser and can block the action or require a business justification. Test coverage gaps: Endpoint DLP does not control native application API calls or traffic from non-monitored browsers installed outside standard enterprise management -- confirm your endpoint management enforces browser policy to close those gaps.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.