To stop credit card numbers and personal data leaking out of Microsoft 365, create a Microsoft Purview data loss prevention (DLP) policy under Data loss prevention > Policies > + Create policy, scope it to Exchange email, SharePoint sites, OneDrive accounts, Teams chat and channel messages and onboarded devices, and add rules that detect sensitive information types such as Credit Card Number. Run every new policy in simulation mode first, show policy tips to a pilot group, and only then turn it on. Policies generally take effect about an hour after you enable them.
Who this is for and what you will have at the end
This guide is for Microsoft 365 administrators and security engineers who have been asked to stop card numbers, national ID numbers and similar personal data from leaving the organisation through email, file sharing, chat or a USB stick.
At the end you will have:
- A policy that blocks email containing card numbers or a "Highly confidential" label, with a documented exception.
- A rule that blocks external access to sensitive files in SharePoint and OneDrive.
- Teams chat and channel protection that hides sensitive messages.
- Onboarded Windows devices with Endpoint DLP rules for USB, printing, clipboard and cloud upload.
- A staged rollout plan and a way to verify each stage.
How a DLP policy is put together
Every DLP policy has the same building blocks, whatever template you start from:
- Locations decide where the policy applies.
- Rules combine conditions (what to look for, such as a sensitive information type or a sensitivity label) and actions (what to do on a match).
- User notifications and incident reports control policy tips, emails and alerts.
- Policy state controls whether actions are enforced.
The locations you will use in this guide, and how each can be narrowed:
| Location | Include or exclude by |
|---|---|
| Exchange email | Distribution groups |
| SharePoint sites | Sites |
| OneDrive accounts | Accounts or distribution groups |
| Teams chat and channel messages | Account or distribution group |
| Devices (Windows 10, Windows 11, three latest macOS versions) | Users and groups, plus devices and device groups |
Policy states are the main rollout control:
| State | What happens |
|---|---|
| Keep it off | Policy is inactive. Use while you design and review. |
| Run the policy in simulation mode | No actions are enforced; events are audited and visible in simulation and Activity explorer. |
| Run the policy in simulation mode and show policy tips | Still no enforcement, but users get policy tips and notification emails. |
| Turn it on right away | Full enforcement. |
Prerequisites
- Licensing. Office 365 and Microsoft 365 E3 include DLP for Exchange, SharePoint and OneDrive, including files shared through Teams. DLP for Teams chat and channel messages requires E5-level licensing (Office 365 E5/A5/G5, Microsoft 365 E5/A5/G5, or the E5 Compliance and Information Protection and Governance add-ons). Check the Microsoft 365 security and compliance licensing guidance for Endpoint DLP before you onboard devices.
- Roles. To create and deploy policies, use an account in one of these role groups: Compliance administrator, Compliance data administrator, Information Protection, Information Protection Admin or Security administrator. To turn on device onboarding you need the Entra Security admin, Compliance admin or Global admin role; device management doesn't support Purview roles.
- Sensitivity labels. If you want label-based conditions (for example "Highly confidential"), create and publish the labels first.
- Devices. Windows 10 22H2 or supported Windows 11 builds, Microsoft Entra joined, hybrid joined or registered, anti-malware client version 4.18.2110 or newer with real-time protection and behaviour monitoring enabled, and a current Microsoft 365 Apps build.
Step 1: Write the policy intent first
Microsoft's design guidance starts with a one-paragraph intent statement that you then map to settings. For example: "Block email to any recipient that contains credit card numbers or carries the Highly confidential label, unless a Finance team member sends it to adele.vance@fabrikam.com. Notify the sender and the compliance admin, allow no overrides, and raise a high-severity alert every time." Each clause maps to one setting, which makes review with legal and business owners much easier and gives you a test plan.
Step 2: Block card numbers in Exchange email
- Sign in to the Microsoft Purview portal, open Data loss prevention and go to Policies > + Create policy.
- Select Enterprise applications & devices.
- Select Custom in Categories and Custom in Regulations, then Next. (If you prefer, pick a predefined financial or privacy template for your country and adjust it.)
- Enter a Name and Description. Paste the intent statement into the description.
- On Assign admin units, keep the default to cover all users.
- On the locations page select only Exchange email.
- On Define policy settings keep Create or customize advanced DLP rules and select Next.
- Select Create rule, name it, then under Conditions select Add condition > Content contains.
- Select Add > Sensitive info types > Credit Card Number > Add. In the same group, select Add > Sensitivity labels > Highly confidential > Add.
- To add the exception, select Add group, leave the operator as AND and switch the toggle to NOT. Add Sender is a member of (choose the Finance distribution group) and Recipient is (enter the partner address).
- Under Actions select Add an action > Restrict access or encrypt the content in Microsoft 365 locations > Block users from receiving email or accessing shared SharePoint, OneDrive, and Teams files > Block everyone.
- Turn User notifications on, select Notify the person who sent, shared, or last modified the content, and decide whether to add Policy tips.
- Under user overrides, leave Allow overrides from Microsoft 365 apps and services cleared if nobody may override.
- Under Incident reports, set Use this severity level in admin alerts and reports to High and turn on Send alert every time an activity matches the rule.
- Select Save > Next, choose Run the policy in simulation mode, then Submit and Done.
Step 3: Stop sensitive files being shared externally from SharePoint and OneDrive
Create a second rule (or a second policy) scoped to SharePoint sites and OneDrive accounts:
- Conditions: Content contains > the sensitive information types you care about, plus Content is shared from Microsoft 365 > with people outside my organization.
- Action: Restrict access or encrypt the content in Microsoft 365 locations > Block only people outside your organization.
- Notifications: Notify users in Office 365 service with a policy tip, plus the people you want informed.
Unlike Exchange, DLP in SharePoint and OneDrive scans existing items as well as new ones and raises alerts whenever it finds a match. You can only add SharePoint sites to a policy after they have been indexed. To protect new files until DLP has scanned them, Microsoft also documents marking new files as sensitive by default in SharePoint.
Step 4: Add Teams chat and channel messages
Edit the policy, go to Choose locations to apply the policy and select Teams chat and channel messages. Allow about an hour for the change to sync.
How enforcement behaves:
- A blocked message is hidden from recipients and the Activity feed shows "Preview Unavailable". The sender gets an activity entry saying "Your message has been blocked" and can use What can I do? to override or report it, if you allowed that.
- Teams DLP doesn't send notification emails; users see message flags only.
- Files shared in chats and channels are protected by the SharePoint and OneDrive locations, so keep those in scope.
- In chats with external organisations, the tenant that started the chat or thread is the one whose policies apply. In shared channels, each sender is evaluated against their own home tenant's policies.
Scope matters for channels:
| Policy scoped to | 1:1 and group chats | Standard, private and shared channel messages |
|---|---|---|
| Individual user accounts | Protected | Not protected |
| Security or distribution groups | Protected | Protected |
| Microsoft 365 groups | Protected | Protected |
If you scope a Teams policy to individual users, channel messages aren't covered. Use groups.
Step 5: Onboard devices and add Endpoint DLP
- In the Purview portal go to Settings > Device onboarding > Devices and select Turn on device onboarding. It usually takes about 60 seconds; Microsoft asks you to allow up to 30 minutes before contacting support.
- Devices already onboarded to Microsoft Defender for Endpoint appear in the list automatically. For the rest, select Onboarding, pick a Deployment method (Intune, Configuration Manager, Group Policy, local script or VDI) and download the package.
- Allow
MpDlpService.exethrough firewalls, third-party antivirus and application control, and configure the device proxy if endpoints use one. - Create a policy with the Devices location and the same card-number condition. For each activity choose Audit only, Block with override or Block (the Allow action exists only for the Devices location).
Endpoint activities you can audit and restrict include Upload to a restricted cloud service domain or access from an unallowed browser, Paste to supported browsers, Copy to clipboard, Copy to USB removable device, Copy to a network share, Print, Copy or move using unallowed Bluetooth app and Copy or move using RDP. Service domains, unallowed browsers, printer groups and removable USB device groups are configured under Data loss prevention settings > Endpoint settings.
For an Endpoint DLP rule to apply, both the user and the device must be in the policy scope.
Step 6: Roll out in stages
- Leave the finished policy in Keep it off for a final stakeholder review.
- Switch to Run the policy in simulation mode. Scope can be broad here because nothing is enforced.
- Review matches in the simulation overview and Activity explorer, then tune instance counts, exceptions and sensitive information types.
- Switch to Run the policy in simulation mode and show policy tips, narrowed to a pilot group with includes and excludes.
- Collect feedback and override justifications, fix false positives, and train a few super users.
- Switch to Turn it on right away and widen the scope to all intended locations.
Note that Stop processing more rules doesn't work while a policy is in simulation mode.
Optional: create the same policy with PowerShell
Connect to Security & Compliance PowerShell, then create the policy in simulation mode and add a rule. This example covers the SharePoint and OneDrive part of the scenario, where BlockAccessScope applies; build the Exchange, Teams and device rules in the portal as described above, or as separate policies. Mode accepts Enable, Disable, TestWithNotifications and TestWithoutNotifications.
Connect-IPPSSession -UserPrincipalName admin@contoso.com
New-DlpCompliancePolicy -Name "Card data - SharePoint and OneDrive" -SharePointLocation All -OneDriveLocation All -Mode TestWithoutNotifications
New-DlpComplianceRule -Name "Card numbers to external" -Policy "Card data - SharePoint and OneDrive" -ContentContainsSensitiveInformation @(@{Name="Credit Card Number"; minCount="1"}) -AccessScope NotInOrganization -BlockAccess $true -BlockAccessScope PerUser -GenerateIncidentReport admin@contoso.comBlockAccessScope PerUser blocks external users, All blocks everyone except the owner and last modifier, and PerAnonymousUser blocks "Anyone with the link" access. Use Get-DLPSensitiveInformationType to list the exact type names in your tenant.
Verify the policy works
- Distribution status. Check that the policy reached every workload:
Get-DlpCompliancePolicy -Identity "Card data - SharePoint and OneDrive" -DistributionDetail | Format-List Name,Mode,DistributionStatus- Activity explorer. Filter on the DLP rule matched activity to see matches; DLP rule undo shows overrides and matches that no longer apply. Activity explorer holds the last 30 days.
- Alerts. DLP alerts appear in the Purview DLP alerts dashboard for 30 days and in the Microsoft Defender portal under Incidents & alerts for six months.
- Devices. Under Device onboarding > Devices, confirm Configuration status and Policy sync status for each endpoint.
- Functional test. Send a test message containing a sample card number to a fabrikam.com test mailbox, share a test file externally, post the number in a Teams chat and copy a test file to USB. Each should produce a match in simulation and a block once enforced.
Troubleshooting
| Symptom | Cause and fix |
|---|---|
| Old emails with card numbers aren't flagged | Expected. Exchange DLP evaluates new messages only; it doesn't scan existing mailbox or archive items. Use eDiscovery search for historic content. |
| Teams channel messages aren't protected | The Teams location is scoped to individual users. Scope it to security, distribution or Microsoft 365 groups. |
| External chat isn't blocked | The other organisation started the chat, so its policies apply, not yours. |
| Policy changes don't seem to apply | Allow about an hour for policy changes, and 24 hours for Authorized Groups changes on endpoints. |
DistributionResults shows errors | Microsoft notes this property is unreliable. Use DistributionStatus and the portal sync status instead, and confirm with a functional test. |
| Device doesn't appear or doesn't sync | Check the anti-malware client version (4.18.2110 or newer), real-time protection, Entra join state, proxy settings and that MpDlpService.exe isn't blocked. |
| File saved straight to USB wasn't caught | Endpoint DLP can't inspect data that is never saved locally first. |
| SharePoint site can't be added to the policy | The site hasn't been indexed yet. Wait and retry. |
Closing checklist
- Intent statement written and approved for each policy.
- Exchange, SharePoint, OneDrive and Teams locations scoped to groups, not individual users, where channels matter.
- Devices onboarded,
MpDlpService.exeallowed, sync status healthy. - Every policy started in simulation, then simulation with tips for a pilot, then enforced.
- Alerts routed to the Defender portal and someone assigned to triage them.
- If you are rolling out Microsoft 365 Copilot, extend the same labels to Copilot with Purview DLP for Copilot. For the wider access model, see zero trust remote access architecture.
References
- https://learn.microsoft.com/en-us/purview/dlp-learn-about-dlp
- https://learn.microsoft.com/en-us/purview/dlp-create-deploy-policy
- https://learn.microsoft.com/en-us/purview/dlp-create-policy-cc-email
- https://learn.microsoft.com/en-us/purview/dlp-microsoft-teams
- https://learn.microsoft.com/en-us/purview/endpoint-dlp-learn-about
- https://learn.microsoft.com/en-us/purview/endpoint-dlp-getting-started
- https://learn.microsoft.com/en-us/purview/device-onboarding-overview
- https://learn.microsoft.com/en-us/powershell/module/exchangepowershell/new-dlpcompliancepolicy
- https://learn.microsoft.com/en-us/powershell/module/exchangepowershell/new-dlpcompliancerule
- https://learn.microsoft.com/en-us/powershell/module/exchangepowershell/get-dlpcompliancepolicy
- https://learn.microsoft.com/en-us/powershell/exchange/connect-to-scc-powershell