DLP Policies for Microsoft Copilot: Configuration Guide

Microsoft 365 Copilot can find, summarize, and present any document a user has permission to access. That includes the HR spreadsheet with salary data shared with Everyone during a compensation review, the legal memo with settlement terms stored in a broadly accessible SharePoint library, and the product roadmap deck a departing employee copied to their OneDrive before resignation. Without Data Loss Prevention policies explicitly configured for the Copilot workload, every one of these scenarios becomes a data exposure incident waiting for a natural language query to trigger it.

DLP for Copilot is not an extension of your existing DLP strategy. It is a distinct workload that requires dedicated policy configuration in Microsoft Purview. Policies that cover Exchange, SharePoint, and OneDrive do not automatically extend to Copilot interactions. If you deployed Copilot without adding it as a monitored location in your DLP policies, you have an uncontrolled data exposure engine operating across your entire Microsoft 365 environment.

This guide covers the DLP policy types you need, step-by-step configuration in Microsoft Purview, monitoring and alerting setup, enforcement strategies for different data sensitivity levels, and industry-specific policy templates.

Why Existing DLP Policies Do Not Cover Copilot

When you configured DLP policies for SharePoint and Exchange, you defined rules like "Block emails containing more than 5 Social Security Numbers" or "Warn users sharing documents labeled Highly Confidential with external recipients." These policies monitor specific workloads: email traffic, file sharing, and chat messages.

Microsoft 365 Copilot is a separate workload. When a user asks Copilot to "summarize all documents about Project Atlas," Copilot queries the Microsoft Graph, retrieves relevant documents from SharePoint, OneDrive, and Exchange, and generates a response. That response is not an email, a file share, or a chat message---it is an AI-generated output that exists in a distinct processing pipeline.

Unless you explicitly add the Microsoft 365 Copilot location to your DLP policies, Copilot operates outside your DLP enforcement boundary. The same data that would be blocked if emailed or shared via SharePoint flows freely through Copilot responses.

This is not a bug. It is a configuration requirement that Microsoft documents but that most organizations miss during deployment. Our readiness assessment checks for this gap specifically, and it is present in over 80% of organizations we evaluate.

The Five Core DLP Policies for Copilot

Every organization deploying Microsoft 365 Copilot should configure a minimum of five DLP policies targeting the Copilot workload. These policies address the most common and highest-risk data exposure scenarios.

Policy 1: Personally Identifiable Information (PII)

What it detects: Social Security Numbers, driver's license numbers, passport numbers, national identification numbers, date of birth combined with name, and other PII patterns defined in your jurisdiction.

Recommended enforcement: Block for high-confidence matches (3+ PII elements in a single response). Warn with override justification for single-element matches.

Sensitive Information Types (SITs) to include:

• U.S. Social Security Number (SSN)
• U.S. Driver's License Number
• U.S. Passport Number
• EU National Identification Number
• Date of Birth + Full Name (custom SIT)

Configuration notes: Set confidence threshold to High (85%+) for block actions and Medium (75%+) for warn actions. This reduces false positives while maintaining protection against genuine PII exposure.

Policy 2: Financial Data

What it detects: Credit card numbers, bank account numbers, financial account identifiers (CUSIP, ISIN, SWIFT codes), and patterns associated with financial statements and projections.

Recommended enforcement: Block for payment card data (PCI DSS requirement). Warn for financial identifiers and projections.

SITs to include:

• Credit Card Number (all major networks)
• International Banking Account Number (IBAN)
• SWIFT Code
• ABA Routing Number
• Custom SIT for internal financial document patterns

Configuration notes: Financial services organizations should set enforcement to Block for all financial SITs. Non-financial organizations can use Warn for financial identifiers while maintaining Block for payment card data. See our financial services compliance guide for sector-specific requirements.

Policy 3: Healthcare Data (PHI)

What it detects: Medical record numbers, health plan beneficiary numbers, DEA numbers, diagnosis codes (ICD-10), procedure codes (CPT), and combinations of health information with patient identifiers.

Recommended enforcement: Block for all PHI-related matches. HIPAA does not have a "warn" threshold for PHI disclosure.

SITs to include:

• All 18 HIPAA identifiers
• Medical Record Number (custom SIT)
• DEA Number
• ICD-10 Diagnosis Codes
• Health Plan Beneficiary Number

Configuration notes: Healthcare organizations must configure PHI detection with maximum sensitivity. False positives are acceptable---false negatives are HIPAA violations. Enable audit logging with 7-year retention for HIPAA compliance. See our healthcare compliance guide and our detailed HIPAA compliance for Copilot guide.

Policy 4: Intellectual Property Protection

What it detects: Content from documents labeled Highly Confidential, Confidential - Internal Only, or equivalent sensitivity labels. This catches trade secrets, product roadmaps, M&A documents, and strategic plans.

Recommended enforcement: Block for Highly Confidential content. Warn for Confidential - Internal Only content.

Configuration approach: This policy uses sensitivity labels rather than SITs. Configure the DLP rule to detect when Copilot responses include content from documents with specific sensitivity labels applied. This requires that your sensitivity label deployment has meaningful coverage---if less than 30% of sensitive documents are labeled, this policy will have significant gaps.

Configuration notes: This policy is only effective if sensitivity labels are widely deployed. If your label coverage is below 30%, prioritize label deployment before relying on this DLP policy. Auto-labeling policies can accelerate coverage for common document types.

Policy 5: Cross-Boundary Data Leakage

What it detects: Data from one business unit appearing in Copilot responses for users in a different business unit. This is critical for organizations with information barriers (investment banking, legal firms, conglomerates with competing subsidiaries).

Recommended enforcement: Block for information barrier violations. Warn for cross-departmental access to restricted content.

Configuration approach: Combine DLP policies with Microsoft Purview Information Barriers. Configure barriers between business units that must not share information (e.g., investment banking and retail banking, legal teams representing opposing parties). Copilot respects information barriers when they are properly configured.

Configuration notes: Information barriers must be configured before DLP policies can enforce cross-boundary restrictions. Test thoroughly in a non-production environment---misconfigured barriers can disrupt legitimate cross-functional collaboration.

Step-by-Step Configuration in Microsoft Purview

Step 1: Add Copilot as a Monitored Location

1. Navigate to Microsoft Purview compliance portal
2. Select Data loss prevention > Policies
3. Open an existing policy or create a new one
4. In the Locations step, enable Microsoft 365 Copilot (preview) or Microsoft 365 Copilot depending on your tenant version
5. Select specific users, groups, or the entire organization
6. Save and proceed to rule configuration

Step 2: Configure Detection Rules

For each of the five core policies:

1. Add the relevant Sensitive Information Types or sensitivity label conditions
2. Set the confidence level threshold (High for block actions, Medium for warn actions)
3. Configure instance count thresholds (e.g., block when 3+ SSNs detected, warn when 1 SSN detected)
4. Add any exceptions (e.g., HR department users querying HR Dataverse tables)

Step 3: Configure Enforcement Actions

Configure the appropriate action for each rule:

• Block: Copilot suppresses the response entirely and displays a policy tip to the user
• Warn: Copilot displays the response with a policy tip warning and logs the event
• Warn with override: User can proceed after providing a business justification that is logged
• Notify: Response is delivered normally but an alert is sent to the compliance team

Step 4: Deploy in Simulation Mode

This step is non-negotiable. Deploy every DLP policy in test mode (simulation) for a minimum of 2 weeks before enabling enforcement. During simulation:

• Policies log matches without blocking content
• The DLP alerts dashboard shows what would have been blocked or warned
• False positive rates can be calculated and thresholds adjusted
• Legitimate Copilot interactions are validated against policy rules

Only move to enforcement after false positive rates drop below 5%. A higher false positive rate means users will learn to ignore or override DLP warnings, undermining the entire program.

Step 5: Configure Monitoring and Alerting

Set up the DLP monitoring infrastructure:

• DLP alerts dashboard: Review daily during the first month, weekly thereafter
• Email notifications: Configure alerts for high-severity DLP matches (blocked responses, override justifications)
• Purview Activity Explorer: Use for detailed investigation of specific DLP events
• Power BI dashboard: Build a custom dashboard connecting to Purview data for executive reporting

Advanced Configuration

Adaptive Protection Integration

Microsoft Purview Adaptive Protection automatically increases DLP enforcement for users flagged by Insider Risk Management. If a user shows elevated risk indicators (resignation, after-hours access, large downloads), their Copilot DLP policies automatically tighten from "warn" to "block" without manual intervention.

This integration is particularly valuable for Copilot because an insider threat actor can use natural language queries to extract sensitive data faster than any manual search. Adaptive Protection closes this gap by increasing scrutiny for high-risk users dynamically.

Cross-Tenant DLP

For organizations with multiple Microsoft 365 tenants, configure DLP policies consistently across all tenants where Copilot is deployed. Use Purview multi-geo capabilities to ensure DLP enforcement respects data residency requirements. This is especially critical for multinational organizations with EU data residency obligations under GDPR. See our GDPR compliance guide for European-specific requirements.

Custom Sensitive Information Types

The built-in SITs cover common data patterns, but most enterprises have organization-specific sensitive data that requires custom detection:

• Internal project code names
• Customer account number formats
• Proprietary financial model identifiers
• Internal classification markings not aligned with standard sensitivity labels
• Industry-specific identifiers (clinical trial IDs, patent application numbers, case docket numbers)

Create custom SITs using exact data match (EDM) or keyword dictionaries. EDM is more accurate but requires structured source data. Keyword dictionaries are faster to deploy but generate more false positives.

Industry-Specific Policy Templates

Healthcare (HIPAA)

Configure detection for all 18 HIPAA identifiers, medical record numbers, DEA numbers, diagnosis codes, and health plan beneficiary numbers. Set enforcement to Block for all PHI-related SITs. Enable audit logging with 7-year retention for HIPAA compliance. Review policies quarterly and after any EHR system changes. See healthcare industry page for the full compliance framework.

Financial Services (SOC 2, PCI DSS)

Configure detection for PCI data (credit cards, bank accounts), financial identifiers (CUSIP, ISIN, SWIFT), and customer financial data patterns. Integrate with Communication Compliance for regulatory supervision requirements. Information barriers between investment banking and retail banking are a prerequisite. See financial services industry page for sector-specific configuration.

Government (FedRAMP, NIST 800-53)

Configure detection for CUI (Controlled Unclassified Information) markings, FOUO designations, and classification-adjacent content. Align DLP enforcement with NIST 800-53 SC-7 (boundary protection) and SC-13 (cryptographic protection) controls. Government tenants (GCC, GCC High) may have different Copilot feature availability. See government industry page for public sector deployment guidance.

Legal

Configure detection for attorney-client privileged communications, case-sensitive information, and matter-specific content. Information barriers between practice groups representing conflicting interests are mandatory. See legal industry page for law firm-specific requirements.

Ongoing Management

DLP configuration for Copilot is not a one-time project. It is an ongoing program that requires:

• Monthly review: Analyze DLP alerts dashboard for trends, false positive rates, and new data patterns
• Quarterly update: Review and update SITs, sensitivity labels, and enforcement thresholds based on three months of operational data
• Annual audit: Comprehensive DLP policy review aligned with annual compliance audits and regulatory changes
• Event-driven updates: Update policies after M&A activity, new regulatory requirements, organizational restructuring, or security incidents

Frequently Asked Questions

Does Copilot respect existing DLP policies?

Copilot respects DLP policies configured in Microsoft Purview, but only if those policies explicitly include the Copilot workload as a monitored location. Policies that cover only Exchange, SharePoint, and OneDrive do not automatically extend to Copilot interactions. You must add the Microsoft 365 Copilot location to each relevant DLP policy.

What happens when Copilot triggers a DLP policy?

Depending on your configuration, Copilot can block the response entirely, redact the sensitive content from the response, display a policy tip warning the user, allow the response with an override justification, or notify compliance administrators. Block is recommended for high-sensitivity data types like PII and PHI. Warn with override is appropriate for medium-sensitivity content.

How many DLP policies should I configure for Copilot?

Start with five core policies: PII protection (SSNs, driver licenses, passports), financial data (credit cards, bank accounts), healthcare data (medical records, diagnosis codes), intellectual property (content from Highly Confidential labeled documents), and cross-boundary leakage (data from separated business units). Add industry-specific policies based on your regulatory requirements.

How do I test DLP policies before enforcement?

Deploy every DLP policy in test mode (simulation) for a minimum of 2 weeks before enabling enforcement. During simulation, policies log matches without blocking content. Review the DLP alerts dashboard to identify false positives, tune detection thresholds, and validate that legitimate Copilot interactions are not disrupted. Only move to enforcement after false positive rates drop below 5%.

Getting Started

DLP configuration is one of the most critical pre-deployment activities for Microsoft 365 Copilot. If your organization has already deployed Copilot without Copilot-specific DLP policies, you are operating with an uncontrolled data exposure risk that should be remediated immediately.

Our governance services include full DLP configuration for Copilot with industry-specific policy templates, monitoring dashboard setup, and quarterly policy reviews. For organizations planning a deployment, our readiness assessment evaluates DLP readiness as one of 12 critical domains.

Contact us to schedule a DLP assessment for your Copilot deployment and get industry-specific policy templates configured in your environment.