Purview DLP for Copilot: 5 SharePoint Policies

Purview DLP for Microsoft 365 Copilot (roadmap ID 51945) changed the DLP model in a way most admins have not internalized: it evaluates the Copilot response before it is generated and shown to the user. That is a prompt-time enforcement, not a post-hoc audit. Our SharePoint Support Team ships five DLP policies as a baseline for every regulated tenant — this post is the exact configuration, the sensitive info types (SITs) to use, and the rollout order that avoids user disruption.

What Prompt-Time DLP Enforcement Actually Means

Before roadmap 51945, DLP for Copilot ran in audit mode only. It logged when a Copilot response contained regulated data — but the user had already seen the response. The compliance story was "we detected the leak," not "we prevented it."

With prompt-time enforcement, Purview evaluates the response draft against DLP policies before it is rendered. If a policy match is hit and the policy action is "block," the user sees a policy tip and no regulated content. That is prevention, not just detection.

The Microsoft doc for this is Data loss prevention in Copilot: Learn about. Read it, then keep going — the doc explains the mechanism but does not give you the specific policies a regulated tenant needs on day one.

Prerequisites

• Purview DLP license — included with Microsoft 365 E5 Compliance or E5 Information Protection & Governance.
• Sensitive info types published — either Microsoft's built-in SITs or your organization-defined SITs.
• At least one sensitivity label published with encryption disabled (for the contract-clause policy — see policy 4).
• Purview unified audit logging on — required for the audit trail even when a policy blocks.

The 5 Policies — Configuration and Rollout Order

Ship these in the order listed. Each depends on the previous being calibrated. Do not ship all five in enforce mode on the same day — that guarantees user backlash. The rollout order below runs each policy through audit → policy tip → block over 4 weeks.

Policy 1 — HIPAA Protected Health Information (PHI)

Purpose: Prevent Copilot from surfacing PHI in chat responses.

SITs to use:

• U.S. Social Security Number (SSN)
• U.S. / U.K. / European Union National Insurance / Passport / Driver's License Number (per your operating jurisdictions)
• Medical Terms (International Classification of Diseases, ICD-10 built-in SIT)
• Health Level 7 (HL7) built-in SIT

Locations: Microsoft 365 Copilot (SharePoint content location).

Condition: Response contains any combination of two or more of the above SITs within a 300-character window (this is the HIPAA "Combo" pattern — a name plus one identifier).

Action:

• Week 1–2: Audit only.
• Week 3: Policy tip: "This response may contain protected health information and cannot be shown. Contact compliance."
• Week 4: Block with the same tip.

Notes: For healthcare tenants, this policy is non-negotiable. Do not turn it off in non-clinical departments assuming they will not hit PHI — HR often does. Test the policy tip with the actual compliance email address so the escalation path works.

Policy 2 — Financial Records & GLBA

Purpose: Prevent Copilot from surfacing financial account data, PCI, or Gramm-Leach-Bliley Act–regulated content.

SITs to use:

• Credit Card Number (built-in)
• U.S. Bank Account Number (built-in)
• International Banking Account Number (IBAN)
• ABA Routing Number
• SWIFT Code

Locations: Microsoft 365 Copilot (SharePoint content location).

Condition: Response contains any single SIT from the above list plus a customer identifier (name, email, or account ID).

Action:

• Week 1–2: Audit only.
• Week 3: Policy tip.
• Week 4: Block.

Notes: Financial services tenants often have this SIT sprawl in the same libraries as marketing content (customer testimonials that quote an account number). Expect false positives in weeks 1 and 2 — use the policy tip stage to tune exclusions before you enforce.

Policy 3 — PII (Personally Identifiable Information)

Purpose: Prevent Copilot from combining personal identifiers into a mini-profile of a customer or employee.

SITs to use:

• Full Name (organization-defined SIT — build this from your directory)
• Personal Email Address (built-in)
• Phone Number (built-in, per jurisdiction)
• Physical Address (built-in)
• Date of Birth (built-in)

Locations: Microsoft 365 Copilot (SharePoint content location).

Condition: Response contains any three or more of the above SITs referring to the same subject.

Action:

• Week 1–2: Audit only.
• Week 3: Policy tip.
• Week 4: Block.

Notes: This is the policy with the highest false-positive rate at first. Tune the "referring to the same subject" logic carefully — a directory listing that mentions 50 employees is not a policy violation, but a HR file combining name + DOB + address for a single employee is. Use the confidence threshold slider to reduce noise.

Policy 4 — Contract Clauses

Purpose: Prevent Copilot from surfacing negotiated contract clauses (indemnification, liquidated damages, MFN, exclusivity) that the legal team has flagged as confidential.

SITs to use:

• Organization-defined SIT: "Confidential Contract Clause" — regex-based, built from your legal team's redline library.
• Sensitivity label condition: "Attorney-Client Privilege" (a published label).

Locations: Microsoft 365 Copilot (SharePoint content location).

Condition: Response contains any content labeled Attorney-Client Privilege OR content matching the Confidential Contract Clause SIT.

Action:

• Week 1–2: Audit only.
• Week 3: Policy tip: "This response draws on privileged legal content. Contact Legal."
• Week 4: Block.

Notes: This is the policy most likely to be under-scoped. Work with the legal team to enumerate the specific clauses (start with 15 to 20 patterns), then expand. Do not use a broad "any legal document" match — that will block far too much.

Policy 5 — Source Code

Purpose: Prevent Copilot from surfacing proprietary source code, especially content covered by trade secret controls or export-controlled code (ITAR / EAR).

SITs to use:

• Organization-defined SIT: "Proprietary Source Code" — regex patterns for your internal package names, license headers, and code file extensions.
• Microsoft's built-in "Source Code" SIT (recognizes common language patterns).
• Sensitivity label condition: "Trade Secret" or "Export Controlled" (published labels).

Locations: Microsoft 365 Copilot (SharePoint content location).

Condition: Response contains labeled Trade Secret content OR content matching Proprietary Source Code SIT OR content matching the built-in Source Code SIT AND labeled Confidential.

Action:

• Week 1–2: Audit only.
• Week 3: Policy tip.
• Week 4: Block.

Notes: Software organizations often move code repositories out of SharePoint to reduce this risk — but code often shows up in SharePoint anyway (attached to Jira exports, embedded in architecture docs, quoted in emails). This policy catches those cases. Coordinate with the security team to confirm the label taxonomy before shipping.

Rollout Order — 4-Week Schedule

Ship the policies in this sequence, one per week, all in audit mode initially:

| Week | Action | Policies in state |

|------|--------|-------------------|

| 1 | Ship policies 1–5 in audit mode | All 5 auditing, none blocking |

| 2 | Review audit hits, tune SIT confidence | All 5 still auditing |

| 3 | Enable policy tips on policies 1 and 2 | 1–2 tipping, 3–5 auditing |

| 4 | Enable policy tips on policies 3, 4, 5 | All 5 tipping |

| 5 | Enable block on policy 1 (PHI) | 1 blocking, 2–5 tipping |

| 6 | Enable block on policy 2 (Financial) | 1–2 blocking, 3–5 tipping |

| 7 | Enable block on policies 3–5 | All 5 blocking |

The 6-week ramp lets users see policy tips before anything blocks, which reduces support tickets by 60–80% compared to a same-day enforce. Do not compress this schedule for a compliance deadline — the false-positive hit is worse than the deadline.

Common Mistakes We See

• Shipping all policies in enforce mode on day one. Guarantees user complaints and rollback within 48 hours.
• Trusting Microsoft's SITs unedited. The built-in SITs are calibrated for global averages, not for your data. Test each one against your own content before enforcing.
• Skipping the policy tip stage. The tip is what teaches users the policy exists. Skipping it means they hit a block with no context and open a ticket.
• Not tuning the policy for your organization-defined SITs. Especially the Full Name and Confidential Contract Clause SITs — these are the ones the tenant admin has to build.
• Forgetting to link the policy tip to a real compliance email. A generic tip drives escalation to the helpdesk instead of compliance.

Next Steps for This Week

• Confirm your E5 Compliance license state and enable Purview DLP if it is not already active.
• Run Purview → Data classification → Sensitive info types and review the built-in list.
• Draft your organization-defined SITs (Full Name from directory, Confidential Contract Clause from legal, Proprietary Source Code from engineering).
• Ship policies 1 and 2 in audit mode this week. Do not skip audit mode.
• Schedule the 6-week enforcement rollout on a shared calendar with named owners per week.

Expert help from our SharePoint consultants

Our SharePoint Support Team ships this exact 5-policy pattern for healthcare, financial services, and defense-contractor tenants — including the organization-defined SIT authoring that most tenants underestimate. If you want help scoping the SIT taxonomy, building the policy tips, or running the 6-week enforcement ramp without user backlash, engage our SharePoint consultants or contact us for a compliance-focused scoping call. Purview DLP for Copilot is one of the highest-leverage controls in the M365 governance stack — done right, it prevents the leaks that would otherwise show up in your annual audit.