Guide to Implementing a Data Loss Prevention Policy in Microsoft 365

What Is a Data Loss Prevention Policy in Microsoft 365?

A data loss prevention policy in Microsoft 365 is a named set of rules you create in the Microsoft Purview portal. Each policy watches specific places, looks for specific kinds of data, and takes a specific action when it finds a match.

Every policy has the same four parts. Locations say where it applies: Exchange email, SharePoint sites, OneDrive accounts, Teams chats and channels, Windows and macOS devices, Microsoft 365 Copilot, and a few others. Conditions say what counts as sensitive, using sensitive information types, trainable classifiers, exact data match, and sensitivity labels. Actions say what happens: audit, show a policy tip, block with override, or block outright. Notifications say who hears about it: the user, an admin, or both.

The structure is simple. The hard part is choosing the right data, the right scope, and an action people will accept.

Why Microsoft DLP Policies Break in 2026

Most Microsoft 365 DLP policies were written for a world of email attachments and shared folders. That world still exists, but it is no longer where most data leaves the company.

Three things changed. Copilot answers questions from every file a user can open, so one overshared SharePoint site becomes a chat reply. Employees paste customer data into ChatGPT, Claude, and Gemini from Chrome as often as from Edge. And AI agents connected over MCP move records between tools with no person watching each step.

A policy that only watches files and email misses all three. That is the core of why legacy DLP fails for AI, and it should shape every rule you write.

✨ How to Build a Data Loss Prevention Policy in Microsoft 365

Step 1: Find and classify your sensitive data first

You cannot write a good rule for data you have not found. Run a discovery pass across Microsoft 365 and the apps around it so you know where card numbers, health records, IDs, source code, and API keys actually live. Strac data discovery and classification scans SharePoint, OneDrive, and Office 365 email along with the rest of your SaaS and cloud stores, which gives you a real map before you write a single condition. If you need a primer, start with data classification.

Step 2: Pick a template or start from custom

In the Purview portal, open Data loss prevention, then Policies, then Create policy. Microsoft offers templates grouped by Financial, Medical and health, and Privacy, such as U.S. Financial Data, U.S. HIPAA Enhanced, and GDPR. Templates are a fast starting point, but they detect broad patterns. Use them to learn, then tighten them with custom sensitive information types that match your own record formats.

Step 3: Choose locations and scope

Pick the locations the policy covers and, where possible, scope it to the users, groups, sites, or admin units that handle that data. A finance policy does not need to run on every engineering channel. Narrow scope means fewer alerts, faster tuning, and less pushback.

Add the Microsoft 365 Copilot location for any policy that covers labeled content. That keeps Copilot from using those files and emails to answer prompts. For device rules, onboard Windows and Mac endpoints first, and plan for the controls that behave differently on macOS.

Step 4: Write rules with conditions and thresholds

Split each policy into two rules: a low-volume rule for one or a few matches and a high-volume rule for many. A single card number in an email is often a mistake; fifty card numbers in one attachment is an export. Set confidence levels and instance counts, add exceptions for approved partner domains, and reference sensitivity labels so your data classification work does double duty.

Step 5: Set actions, policy tips, and alerts

Start gentle. Turn on policy tips so users see why a message was flagged inside Outlook, Teams, or the file view. Use block with override and a business justification for gray areas, and save full blocks for high-volume matches. Send alerts to a real queue with an owner, not to a shared mailbox nobody reads.

Step 6: Run in simulation mode, then turn it on

Purview lets you run a new policy in simulation mode, with or without policy tips showing to users. Leave it there long enough to see real matches, check them against the content, and cut the noise. Then move rules to enforcement one location at a time. A policy you turn on without testing is a policy you will turn off a week later.

Step 7: Review on a schedule

Data moves, teams change, and new apps arrive. Review match volume, override reasons, and false positives every month, and retire rules nobody needs. Map the evidence to HIPAA, PCI DSS, SOC 2, and ISO 27001 as you go so audits are a report, not a project.

Where Microsoft DLP Policies Stop Short

Purview is strongest where Microsoft owns the app. The further data travels from Exchange and SharePoint, the thinner the policy gets. These are the gaps you should plan for, all covered in more depth in Office 365 DLP limitations.

• Block, not redact. A Purview rule can stop a Teams message or an email. It does not remove the four sensitive digits and let the rest through. Users hit a wall and look for a workaround.
• Non-Microsoft SaaS. A support agent pasting a card number into a Zendesk ticket or a sales rep dropping a passport scan into Salesforce is outside the policy.
• Browsers other than Edge. Inline AI protection depends on Edge for Business. Many teams work in Chrome.
• Agents outside Microsoft. Copilot Studio agents are covered. An MCP connection from Claude Desktop to a database or CRM is not.
• Images and screenshots. Sensitive data inside a photo of an ID card or a screenshot of a spreadsheet is easy to miss without strong OCR.

A block tells a user no. A redaction lets the work continue without the risky part. That one difference decides whether your DLP policy gets adopted or bypassed.

✨ Strac: One Data Layer for Microsoft 365 and Everything Around It

Microsoft 365, redacted instead of blocked. Strac connects to Office 365 email, Microsoft Teams, SharePoint, and OneDrive by API, with no agent to install. It detects PII, PHI, PCI data, source code, and secrets in message text, attachments, PDFs, Word files, spreadsheets, and images, then masks only what matters. See the best SharePoint and OneDrive DLP solutions for how this compares.

The SaaS your Microsoft policy cannot see. SaaS DLP applies the same rules to Slack, Google Drive, Salesforce, Zendesk, and more than 50 other apps, so one policy follows the data instead of stopping at a vendor boundary.

Every browser and every AI tool. Browser DLP runs in Chrome and Edge and redacts sensitive data before it reaches ChatGPT, Claude, Gemini, or Copilot. It also shows which AI tools people actually use, which is the first step in managing shadow AI.

Devices across the whole fleet. Endpoint DLP covers Windows, macOS, and Linux under one policy set, including the Mac controls Purview leaves thin.

Agents and MCP. MCP DLP inspects every tool call an agent makes and redacts sensitive fields in the response, so even a hijacked agent cannot pull raw customer data. Browse the MCP integrations.

Data at rest. DSPM scans SharePoint, OneDrive, Azure storage, and other cloud stores, then revokes public links, applies labels, or redacts fields before Copilot or an agent can surface them. For Azure specifics, read DLP for Azure.

Remediation follows one order on every surface:

• Redact / mask: remove the sensitive element from Teams, Outlook, Slack, tickets, docs, Google Drive, SharePoint, and Box while the rest stays usable.
• Block: stop the send, upload, paste, or share when redaction is not enough.
• Warn and coach: tell the user why in the moment, in Teams, Slack, or the browser.
• Revoke access: pull public links and external shares on OneDrive, SharePoint, Google Drive, and Box.

A 90-Day Plan for Your Microsoft DLP Policy

Days 0 to 30, discover. Run Strac data discovery across Microsoft 365 and your top non-Microsoft apps. Map where regulated data sits and which AI tools people use. Publish sensitivity labels for your highest-risk SharePoint sites.

Days 30 to 60, protect. Build your first Purview policies from templates, tighten them with custom types, and run them in simulation mode. Turn on Strac redaction for Teams, Outlook, Slack, support tools, and browser AI, starting with PCI and PHI.

Days 60 to 90, prove and scale. Move tested Purview rules to enforcement, extend Strac to endpoints and MCP, and export evidence for your auditors.

Readiness checklist:

• ☐ Sensitive data found and classified before rules are written
• ☐ Each policy has low-volume and high-volume rules
• ☐ Every new policy ran in simulation mode before enforcement
• ☐ Copilot location added to policies that cover labeled content
• ☐ Chrome covered for AI pastes, not only Edge
• ☐ Non-Microsoft SaaS, Mac endpoints, and MCP agents redact in real time

👉 Related reading:

• Data loss prevention with Microsoft Purview
• Data loss prevention in Microsoft Teams
• Email data loss prevention
• Microsoft Purview alternativ

The Bottom Line

A well-built data loss prevention policy in Microsoft 365 is the right baseline: find the data, scope the rule, test it in simulation, then enforce. But data does not stay inside Microsoft, and a policy that can only block will always be fighting its own users. Identity, network, and browser controls all fail eventually; the data layer is the backstop, and redacting sensitive data on every action keeps a mistake from becoming a breach. Book a demo to see Strac protect the data your Microsoft policy cannot reach.

🌶️ Spicy FAQs for Data Loss Prevention Policy in Microsoft

Is a DLP policy the same as a sensitivity label?

No. A sensitivity label marks what a file or email is; a DLP policy decides what can happen to it. Policies can read labels as conditions, so the two work as one system, and a well-labeled tenant makes every rule more accurate.

Why isn't a Purview DLP policy enough if we already pay for E5?

Purview covers the Microsoft estate well, but Slack, Salesforce, Zendesk, Chrome, Mac restricted apps, and MCP agents sit outside its inline reach. Strac adds real-time redaction on those surfaces without replacing the Purview policies you already run.

Can a strict DLP policy avoid slowing people down?

Yes, if it redacts instead of blocks. Strac masks the sensitive element and lets the message, file, or prompt continue, while Purview keeps labeled content away from Copilot. People keep working, and the risky data never leaves.

Can one Microsoft DLP policy stop every leak into AI tools?

Not on its own. Inline AI protection depends on Edge for Business or network routing, and personal devices or other browsers slip past. That is why the data layer matters: Strac redacts sensitive data in any browser before it reaches the model.

Where does a Microsoft DLP policy fit in AI data governance?

It is the Microsoft 365 rule layer inside a wider program. AI data governance also covers shadow AI, agents, and non-Microsoft data. Read AI DLP and MCP DLP for the full picture.