Data Loss Prevention (DLP) in Microsoft Purview is a policy-based framework that identifies, monitors, and protects sensitive information across Microsoft 365 workloads, endpoints, and on-premises repositories. DLP works through deep content analysis — not simple text scans — combining regular expressions, keyword dictionaries, sensitive information types (SITs), machine learning classifiers, and label-based conditions.
DLP is the enforcement layer that acts on classification decisions made by Sensitivity Labeling and data posture signals surfaced by DSPM. The three systems work together: labels declare intent, DLP enforces it, DSPM monitors the gap.
Log all matches silently. No user impact. Establishes detection baseline and false-positive rate.
Show policy tips in-app. Email notifications to users. No block. Drives awareness and behavior change.
Allow with business justification required. Logs the override reason. Builds exception audit trail.
Hard block on sharing, transmission, or endpoint action. Reserved for high-confidence matches on Confidential and Restricted.
| Workload | DLP Scope | Key Actions | Notes |
|---|---|---|---|
| Exchange Online | Email send/receive | Block, Notify, Encrypt, Redirect | Covers external and internal mail |
| SharePoint / OneDrive | File sharing, upload, access | Block sharing, Quarantine, Restrict access | Covers guest sharing and anonymous links |
| Microsoft Teams | Chat messages, channel posts | Block message, Notify, Remove | Requires Teams DLP policy mode |
| Endpoint | Clipboard, USB, print, upload, screenshot | Audit, Warn, Block per activity | Requires Defender for Endpoint onboarding |
| On-Premises — Data Map (SHIR) | File shares, relational databases, multi-cloud sources | Scan, Classify, Catalog (metadata only) | Self-Hosted Integration Runtime connects sources to Purview Data Map; does not apply labels or enforce DLP actions |
| On-Premises — IP Scanner | File shares, SharePoint Server (at-rest files) | Apply label, Encrypt, Quarantine, Move, Alert | Information Protection on-premises scanner; applies sensitivity labels and protection actions to at-rest content |
| On-Premises — DLP | File repositories via on-premises scanner infrastructure | Audit, Alert, Restrict, Quarantine | Purview DLP on-premises; enforces DLP policies on at-rest repositories; requires IP scanner infrastructure |
| Power BI / Fabric | Reports, datasets, workspaces | Restrict access, Alert | Premium Gen2 workspaces required |
| Microsoft 365 Copilot | AI-generated responses, grounding data | Inherit label controls, Block oversharing | Label must be applied to source content |
DLP rules can use sensitivity labels as conditions — no SIT required. Example: If label = Restricted AND recipient is external → Block. This is the most reliable condition type because it does not depend on content pattern matching.
High-confidence rules combine a SIT match (e.g., SSN, account number, custom Legal SIT) with a label condition. This reduces false positives significantly and enables workload-specific enforcement — for example, blocking endpoint print only when both a custom SIT and the Confidential label are present.
The platform uses a SitPak methodology for non-standard sensitive information types. Rather than relying on built-in SITs that generate broad alerts, SitPaks build custom SITs using a combination of primary elements, supporting dictionaries, contextual facets, and bi-directional proximity to surface intent — not just pattern presence.
SitPak Structure
- Primary element: regex anchor (e.g., subpoena language, financial routing patterns)
- Supporting dictionary: contextual vocabulary confirming document type
- Facets: risk-amplifying attributes (amounts, dates, authority language, case references)
- Exceptions: training content, templates, mock examples
v2 Packed SIT (Single-SIT Method)
The 2026 SitPak model packages all patterns inside a single custom SIT using multiple pattern sets. This reduces administrative overhead while preserving contextual detection. Each thematic domain (Legal, Security, HR, Governance) has its own SitPak.
Subpoena · Search Warrant · Law Enforcement Inquiry · Preservation Request
Internal Investigation · Damage Assessment · Threat of Violence · Breach Impact
HR Investigation · Employee Investigation · Disciplinary · Workplace Review
CUI · TLP:RED · TLP:AMBER · Controlled Unclassified · Official Use Only
- Scope policies to specific locations rather than "All" initially — reduce noise and test coverage
- Use TestWithNotifications mode before enabling block actions
- Always define exception rules for known-good content (templates, training docs)
- Separate discovery policies from enforcement policies — keep them independent and independently tuneable
- Version every policy and rule — name includes domain, version, date, and mode (e.g., Legal-DLP-v1-Audit)
- Start with medium confidence (75) — not high — to avoid false negatives on first pass
- Use Activity Explorer to review match distribution before tightening proximity or confidence
- Export baseline before any SIT modification — use Get-DlpSensitiveInformationTypeRulePackage
- Simulate in Test mode for at least one full week before enabling notifications
- Document every SIT: owner, domain, corpus, confidence rationale, exception list
- Endpoint DLP requires Defender for Endpoint — confirm device onboarding before scoping
- Control activities independently: clipboard, print, USB, network upload, Bluetooth, screenshot
- Use scoped policies for high-sensitivity roles (Finance, Legal, Security) before broad rollout
- Test on a pilot device group — Endpoint DLP can block critical workflows if misconfigured
- Review Endpoint activity in Activity Explorer with the Endpoint filter applied
DLP policy fires on SIT match / label violation. Alert generated from Purview policy logic and surfaced primarily in Defender XDR, where DLP alerts are grouped into incidents, correlated with other Microsoft security alerts, enriched with evidence, and optionally synchronized into Sentinel or external SIEM/SOAR.
Alert enriched with SIT type, confidence score, user risk score (IRM), prior incident history. Subject-line schema applied: [Severity] [Source] [Brief] [TicketID].
Ticket created in ServiceNow/SOAR. Power Automate triggers eDiscovery hold at notification stage — preserves evidence before triage starts. Regulatory clock begins here.
L1 analyst assigns risk score. Risk-based queue ordering — highest risk first. Single-incident path or multi-incident/pattern path. FIFO is explicitly prohibited.
L2 analyst reviews content, access logs, and communications. Gathers evidence per RACI. PHI/patient-impact threshold determines whether L3 or Legal is pulled in immediately.
Action taken: block, quarantine, revoke access, patient/member notification (if required by HIPAA breach rule). Escalation to L3 for PHI-related incidents. All actions timestamped in ticket.
Closure category selected: true positive, false positive, accepted risk, or escalated. Closure evidence attached. Metrics fed back to Splunk KPI dashboards (Artifact 2).
Every future workflow uses the same schema: trigger, severity, RACI, SLA, steps, decision tree, evidence requirements, closure criteria, KPI feed. See Platform Workbook A4 for full template.
| Severity | Triage SLA | Investigation SLA | Ticket Subject Prefix | Escalation Trigger |
|---|---|---|---|---|
| Critical | 15 minutes | 4 hours | Critical event — | PHI disclosure confirmed / mass exfil |
| High | 2 hours | 24 hours | High event — | Repeated pattern / IRM score ≥ 70 |
| Medium | 24 hours | 5 business days | Medium event — | Business justification absent |
| Low | 5 business days | 10 business days | Low event — | Accumulation of 5+ low events |
Artifact 4 — Workflow Replication Order (5 Named Workflows)
Each workflow is documented end-to-end using the 7-stage lifecycle schema above. Build in this order — each adds complexity and prerequisite tooling over the prior.
- IRM Departing Employee — highest-risk exfiltration vector. Leverage IRM integration already in scope. Cross-references Insider Risk Management alerts to DLP events. Triage, evidence collection, and HR handoff documented.
- Auto-Label Failure — captures label misapplication and detection gaps. Documents the review-and-correct loop when auto-labeling produces wrong or missing labels on sensitive content. Engineering diagnostic path.
- Retention Disposition Exception — governance-critical. Documents the workflow when scheduled disposition is blocked: legal hold, unresolved review, regulatory exception. Connects Artifact 1 (retention) to Artifact 4 (workflow).
- eDiscovery Preservation Hold — legal interface workflow. Documents trigger → preserve → notify chain for when a hold is placed. Evidence preservation at Notify+Preserve stage is automated via Power Automate. Legal and compliance RACI defined.
- Communication Compliance — policy violation detection in Teams/Exchange. Documents triage and review workflow for flagged communications. Highest privacy sensitivity — requires defined reviewer roles and legal sign-off on scope.
See Deliverables Tracker — Artifact 4 for contracted scope and output checklist. See Platform Workbook A4 for full replication template schema.