Microsoft Purview DLP: Building Policies That Actually Work in Healthcare

HIPAA's Security Rule (§164.312) requires covered entities and business associates to implement technical safeguards that guard against unauthorized access to PHI transmitted over electronic communications networks. Microsoft Purview Data Loss Prevention is the native M365 tool for meeting that obligation. Getting it right in a healthcare environment takes more than applying the built-in HIPAA template and calling it done — here is how to build DLP policies that actually protect PHI without burying your clinical and administrative staff in false positives.

Why Does HIPAA Require Data Loss Prevention in Microsoft 365?

HIPAA does not prescribe specific technology controls, but it does require that covered entities implement policies and procedures to prevent, detect, contain, and correct security violations. DLP addresses the "prevent" leg of that requirement for data in motion — email, Teams messages, SharePoint documents, OneDrive files, and endpoint file transfers. Without DLP, there is no technical barrier preventing a staff member from emailing a patient list to a personal Gmail account or attaching a spreadsheet of PHI to a Teams message with an external guest.

Beyond the compliance obligation, DLP incidents are a leading source of HIPAA breach notifications. The HHS Office for Civil Rights breach portal consistently shows that unauthorized disclosures — data sent to the wrong person or exfiltrated by an insider — account for a substantial share of reported breaches. DLP can catch the most common of these patterns before they become reportable events.

What Sensitive Information Types Does Microsoft Purview Detect for Healthcare?

Microsoft Purview ships with over 300 built-in sensitive information types (SITs). The ones most relevant to healthcare in the US include:

• U.S. Social Security Number (SSN) — high-confidence pattern with keyword proximity
• U.S. Individual Taxpayer Identification Number (ITIN)
• Drug Enforcement Agency (DEA) Number — specifically relevant to clinical prescribing environments
• U.S. National Provider Identifier (NPI)
• U.S. Health Insurance Claim Number (HICN) and Medicare Beneficiary Identifier (MBI)
• All Medical Terms And Conditions — a broad classifier detecting clinical terminology in context
• International Classification of Diseases (ICD-9/ICD-10) — detects procedure and diagnosis codes

Built-in SITs use pattern matching (regular expressions) plus supporting evidence (keywords, checksums). High-confidence matches require both the pattern and proximity keyword evidence. Medium and low-confidence matches relax those requirements. In clinical document repositories, medium-confidence matches on SSN or MBI can produce substantial false positive volumes — plan your confidence thresholds accordingly.

You can also build custom SITs for data patterns specific to your EHR system — patient MRN formats, facility-specific identifiers, or encounter codes. Custom SITs use the same regex and keyword framework as built-ins and can be referenced in DLP policies alongside built-in types.

How Do You Build a Microsoft Purview DLP Policy for Healthcare?

Start in the Microsoft Purview compliance portal (purview.microsoft.com) under Data Loss Prevention → Policies → Create policy. Microsoft provides a HIPAA template under "Medical and Health" that pre-loads a useful baseline set of SITs, but treat it as a starting point rather than a finished product. The template applies broad rules at medium confidence — appropriate for some environments, too aggressive for others.

Structure your policy with at least two rules: a high-volume rule and a low-volume rule. The high-volume rule triggers when a large number of PHI instances are detected in a single item — this is your exfiltration signal. The low-volume rule triggers on even a single high-confidence match outside of expected internal flows. Different actions and severity levels are appropriate for each.

Low-volume rule (1–9 instances, high confidence):

• Action: Policy tip to the sender; notify the security team
• Override allowed: Yes, with business justification
• Severity: Medium

High-volume rule (10+ instances, any confidence):

• Action: Block the activity; notify security team; require justification to override
• Override allowed: Optional, depending on your risk tolerance
• Severity: High

Exclude known internal clinical workflows from triggering — for example, traffic between your EHR integration account and your data warehouse, or messages between clinical staff via a dedicated distribution group used for care coordination. Use sender/recipient domain conditions, security group membership, and communication direction (internal vs. external) to narrow scope and reduce noise.

Which Microsoft 365 Workloads Does Purview DLP Protect?

Purview DLP operates across five primary workloads in Microsoft 365, and you should evaluate each separately for healthcare:

Exchange Online: Inspects email body, subject, and attachments in transit. Policy tips surface in Outlook (web and desktop) before the message is sent. This is typically the first workload to enable DLP for healthcare since email is the primary PHI exfiltration vector.

Microsoft Teams: Inspects Teams messages (chat and channel) and shared files. Clinical teams increasingly use Teams for care coordination — the PHI risk is real. External guest access makes this particularly important. Note that Teams DLP policy tips appear only in the Teams web and desktop clients, not in mobile clients as of 2025.

SharePoint Online and OneDrive for Business: Scans documents at rest and in motion. DLP can block sharing of documents containing PHI with external users. In healthcare, shared drives containing patient lists, billing records, and clinical notes are common sources of unauthorized disclosure through external sharing links.

Endpoint DLP: Extends protection to Windows 10/11 endpoints managed by Intune or Configuration Manager. Can block copying PHI to USB drives, printing to non-corporate printers, or pasting into unapproved applications like personal cloud storage upload pages. Requires onboarding devices to Purview — done via Intune policy or a Group Policy object.

How Do You Test and Tune a Purview DLP Policy Without Breaking Workflows?

Every new DLP policy should be deployed in simulation mode first. Simulation mode evaluates all content against your policy rules and logs what would have happened — blocks, policy tips, alerts — without actually taking any action. Run simulation for at least two weeks before moving to enforcement. Review the DLP reports and Activity Explorer during this period to understand the false positive landscape.

Common false positives in healthcare environments include: SSN-format strings in medical record numbers (same 9-digit pattern), NPI numbers appearing in internal billing workflows you did not intend to trigger on, and DEA numbers in legitimate prescribing system integrations. Use exceptions and exclusions in your policy conditions to suppress confirmed false positive patterns. Document each exception so they can be reviewed in future policy updates.

Once simulation data shows the policy is accurate, move to Test mode with policy tips enabled — users see the tip but can still send. This surface-level friction reduces accidental disclosures while you complete your tuning cycle. Only move to Enforce (block) mode after at least one week of Test mode with acceptable false positive rates.

What Is Adaptive Protection and How Does It Work with Purview DLP?

Purview's Adaptive Protection feature, available with Microsoft 365 E5 or the Purview add-on, integrates DLP with Insider Risk Management. Insider Risk Management uses behavioral signals — unusual file download volumes, accessing sensitive data outside normal hours, using removable storage immediately after receiving a separation notice — to assign dynamic risk levels to users.

Adaptive Protection allows DLP policies to automatically apply stricter controls to elevated-risk users without requiring manual policy updates. A user flagged by Insider Risk at "elevated" level might trigger a block rule where other users at the same confidence threshold would only receive a policy tip. This is particularly valuable in healthcare where the insider threat profile (disgruntled employee exfiltrating patient data ahead of a departure) is a documented HIPAA breach scenario.

How Do You Monitor Purview DLP Alerts and Respond to Incidents?

Purview generates DLP alerts that appear in the Alerts queue in the compliance portal. Configure alert policies with appropriate severity thresholds — a single high-confidence SSN match in an external email should generate an immediate alert; a low-confidence match on internal mail might warrant daily digest reporting. Route high-severity DLP alerts to your security team's incident management system via the Microsoft Graph Security API or a SIEM connector.

The Activity Explorer in Purview provides a timeline view of all DLP-matched activities, filterable by user, workload, policy, sensitivity label, and date range. Use it during incident investigation to reconstruct what a user did with a file or message that triggered a DLP policy. Audit log retention for DLP events follows your tenant's unified audit log retention policy — extend it to 1 year (included in E5) to ensure you have the evidence chain required under HIPAA's documentation requirements.

Review your DLP policy performance quarterly. Sensitive information types, clinical workflows, and external sharing patterns change. A policy tuned to your environment today may be generating unnecessary noise or missing new risk patterns in six months. Schedule a quarterly review with your compliance, security, and clinical operations teams to keep policies current and defensible under audit.