Microsoft Purview Data Loss Prevention
Enterprise DLP across Microsoft 365 and Windows endpoints — standard and custom SITs, Endpoint DLP and Generative AI upload protection.
Difficulty
Advanced
Environment
Microsoft 365 / Purview
Deployment
Production
Est. Implementation
4–6 weeks
Executive Summary
This project established a tenant-wide Data Loss Prevention capability using Microsoft Purview, extending detection and enforcement beyond Microsoft 365 workloads to Windows endpoints and Generative AI websites.
Built in three sequential phases — a standard Sensitive Information Type (SIT) policy for payment card data, a custom SIT for a proprietary data format (GSM), and an extension of that same protection to endpoint devices and AI chatbot uploads — the framework gives the business measurable, audit-ready controls mapped to ISO/IEC 27001, validated end to end before enforcement was switched on.
Business Problem
Sensitive data — payment card numbers and proprietary internal identifiers alike — could leave the organisation through email, collaboration tools, USB copies, local printing and Generative AI website uploads without consistent detection or enforced controls.
Two 2026-era gaps compound the risk: proprietary data formats are invisible to Microsoft's built-in Sensitive Information Types, and Generative AI tools accept pasted or uploaded content as context that cannot be retrieved once submitted. Leadership needed demonstrable controls across both cloud and endpoint, not best-effort handling.
Business Risks
- Accidental or malicious exfiltration of regulated payment data and proprietary identifiers
- No visibility into local, on-device activity such as USB copies, printing or browser uploads
- Sensitive files pasted or uploaded into public Generative AI tools with no retrieval option
- Audit findings due to missing preventative and detective controls
Compliance Concerns
- ISO/IEC 27001:2022 information protection controls
- PCI-relevant data handling requirements
- Auditability and evidence retention for regulated data
Solution Overview
The solution layered a built-in Credit Card Number SIT with a custom keyword-based GSM SIT inside a single "Finance Credit Card Protection" DLP policy, then extended that same policy to a Windows endpoint via Microsoft Defender for Endpoint onboarding — with no separate endpoint policy required.
Browser and domain restrictions blocked uploads to Microsoft's built-in "Generative AI Websites" sensitive service domain group, while Activity Explorer, DLP Alerts and DLP Reports gave a single monitoring surface spanning cloud and endpoint events. Every stage was validated in Simulation mode in Activity Explorer before the policy was switched to Enforcement.
Architecture
Architecture diagram placeholder
Technology Stack
Microsoft Purview DLP
Core policy and rule engine across cloud and endpoint
Sensitive Information Types
Built-in Credit Card Number SIT plus a custom keyword-based GSM SIT
Microsoft Defender for Endpoint
Device onboarding that feeds Purview Endpoint DLP
Endpoint DLP
File, clipboard, print and browser activity protection on Windows
Generative AI Website Protection
Block action on Microsoft's built-in AI chatbot domain group
Activity Explorer / DLP Alerts / Reports
Unified monitoring across cloud and endpoint events
Lab Environment
- Tenant
- securem365lsb.onmicrosoft.com (Microsoft 365 E5)
- Licensing
- Microsoft 365 E5 (Endpoint DLP requires E5 / E3 + Compliance add-on)
- Test device
- testing_machine — Windows 11, version 25H2
- Test user
- testuser1@securem365lsb.onmicrosoft.com
- Workloads
- Exchange, SharePoint, OneDrive, Teams + Windows endpoint
- Tooling
- Purview portal, Microsoft Edge with the Purview browser extension
Implementation
A phased, expandable walkthrough. Screenshots and evidence can be attached to each phase.
Create the "Finance Credit Card Protection" DLP policy using the built-in Credit Card Number SIT across all core workloads.
- Select protected locations — Exchange, SharePoint, OneDrive and Teams
- Build the rule condition on the Credit Card Number SIT
- Configure block action, policy tips and Simulation mode
Screenshots for this phase can be added here.
PowerShell
Illustrative example snippets — copy or download each script. Production values are placeholders.
Deploy a baseline DLP policy
# Illustrative scaffold based on New-DLPPolicyBaseline.ps1 — parameters are placeholders.
Connect-IPPSSession -UserPrincipalName admin@yourtenant.onmicrosoft.com
New-DlpCompliancePolicy `
-Name "Finance Credit Card Protection" `
-ExchangeLocation All -SharePointLocation All `
-OneDriveLocation All -TeamsLocation All `
-Mode TestWithoutNotifications
# A matching rule referencing the Credit Card Number and GSM SITs is then
# added with New-DlpComplianceRule.Export DLP policy and alert reports
# Illustrative scaffold — exports policy mode/sync status and alert summaries to CSV.
Get-DlpCompliancePolicy | Select-Object Name, Mode, Enabled |
Export-Csv -Path .\reports\dlp-policy-report.csv -NoTypeInformation
Get-DlpComplianceRule | Where-Object Policy -eq "Finance Credit Card Protection"Configuration Screenshots
Click any tile to open the lightbox. Real screenshots will replace these placeholders.
Phase 1 · Standard SIT — Credit Card Policy
Phase 2 · Custom SIT — GSM
Phase 3 · Monitoring — Activity Explorer & Alerts
Phase 4 · Endpoint DLP
Phase 5 · Generative AI Website Protection
Phase 6 · Simulation to Enforcement
Validation
Device & Policy Sync
Device configuration and policy sync status both confirmed Updated.
Generative AI Upload Blocked
Upload to ChatGPT blocked with the native organisation policy dialog.
OneDrive Policy Tip
Source file shows GSM detected as sensitive information.
DLP Alert Generated
Alert appears in the Alerts dashboard, scoped to the agent, Active.
Activity Explorer Event Chain
File created → modified → renamed → DLP rule matched, fully traceable.
Email Notification
Low-severity alert email received with rule and file details.
Challenges
Proprietary data invisible to built-in SITs
Microsoft's 327 built-in Sensitive Information Types do not cover an organisation's own identifiers. A custom keyword-list SIT (GSM) closed this gap using the same detection and enforcement engine.
Endpoint visibility gap
Cloud DLP alone cannot see USB copies, local printing or browser uploads after a file is downloaded. Onboarding the device via Defender for Endpoint extended the existing policy rather than requiring a second product.
Lessons Learned
- Detection and enforcement are independent settings — a rule can alert without blocking, and block without alerting.
- Endpoint DLP shares policies with cloud DLP; it does not duplicate them. There is no separate endpoint policy to build.
- Device sync status is the first thing to check when an endpoint block "doesn't work".
- The built-in Generative AI Websites domain group is preferable to a manually maintained list, which falls behind within weeks.
- Switching to Enforcement is reversible — this lowers the risk of testing it in a lab or pilot group first.
Business Impact
Cloud + endpoint enforced
Reduced Data Risk
ISO 27001 aligned
Improved Compliance
Generative AI upload block
AI Exfiltration Mitigated
Automated alerting
Administrative Efficiency
Skills Demonstrated
Related Certifications
Certifications this project maps to are highlighted.
Related Blog Articles
Placeholder cards — future TechCertGuide integration.
GitHub Repository
lokeshm-it/Microsoft-Purview-Data-Loss-Prevention
PublicEnterprise Purview DLP implementation — standard and custom SITs, Endpoint DLP and Generative AI protection.
Download Center
Project Case Study
PDF · Available soon
Architecture Diagram
PDF · Available soon
PowerShell Scripts
ZIP · Available soon
Technical Documentation
PDF · Available soon