Create and Deploy data loss prevention policies
There are many configuration options in a Microsoft Purview Data Loss Prevention (DLP) policy. Each option changes the policy's behavior. This article presents some common intent scenarios for policies that you map to configuration options. Then it walks you through configuring those options. Once you familiarize yourself with these scenarios, you're comfortable using the DLP policy creation UX to create your own policies.
How you deploy a policy is as important policy design. You have multiple options to control policy deployment. This article shows you how to use these options so that the policy achieves your intent while avoiding costly business disruptions.
Tip
If you're not an E5 customer, use the 90-day Microsoft Purview solutions trial to explore how additional Purview capabilities can help your organization manage data security and compliance needs. Start now at the Microsoft Purview compliance portal trials hub. Learn details about signing up and trial terms.
Before you begin
If you're new to Microsoft Purview DLP, here's a list of the core articles you should be familiar with as you implement DLP:
- Administrative units
- Learn about Microsoft Purview Data Loss Prevention - The article introduces you to the data loss prevention discipline and Microsoft's implementation of DLP.
- Plan for data loss prevention (DLP) - By working through this article you will:
- Data Loss Prevention policy reference - This article introduces all the components of a DLP policy and how each one influences the behavior of a policy.
- Design a DLP policy - This article walks you through creating a policy intent statement and mapping it to a specific policy configuration.
- Create and Deploy data loss prevention policies - This article, which you're reading now, presents some common policy intent scenarios that you map to configuration options. It then walks you through configuring those options, and gives guidance on deploying a policy.
- Learn about investigating data loss prevention alerts - This article introduces you to the lifecycle of alerts from creation, through final remediation and policy tuning. It also introduces you to the tools you use to investigate alerts.
SKU/subscriptions licensing
Before you start using DLP policies, confirm your Microsoft 365 subscription and any add-ons.
For information on licensing, see Microsoft 365, Office 365, Enterprise Mobility + Security, and Windows 11 Subscriptions for Enterprises.
Permissions
The account you use to create and deploy policies must be a member of one of these role groups
- Compliance administrator
- Compliance data administrator
- Information Protection
- Information Protection Admin
- Security administrator
Important
Be sure you understand the difference between an unrestricted administrator and an administrative unit restricted administrator by reading Administrative units before you start.
Granular Roles and Role Groups
There are roles and role groups that you can use to fine tune your access controls.
Here's a list of applicable roles. To learn more, see Permissions in the Microsoft Purview compliance portal.
- DLP Compliance Management
- Information Protection Admin
- Information Protection Analyst
- Information Protection Investigator
- Information Protection Reader
Here's a list of applicable role groups. To learn more, see To learn more about them, see Permissions in the Microsoft Purview compliance portal.
- Information Protection
- Information Protection Admins
- Information Protection Analysts
- Information Protection Investigators
- Information Protection Readers
Policy creation scenarios
The previous article Design a DLP policy introduced you to the methodology of creating a policy intent statement and then mapping that intent statement to policy configuration options. This section takes those examples, plus a few more and walks you through the actual policy creation process. You should work through these scenarios in your test environment to familiarize yourself with the policy creation UI.
There are so many configuration options in the policy creation flow that it's not possible to cover every, or even most configurations. So this article covers several of the most common DLP policy scenarios. Going through these gives you hands on experience across a broad range of configurations.
Scenario 1 Block emails with credit card numbers
Important
This is a hypothetical scenario with hypothetical values. It's only for illustrative purposes. You should substitute your own sensitive information types, sensitivity labels, distribution groups and users.
Scenario 1 prerequisites and assumptions
This scenario uses the Highly confidential sensitivity label, so it requires that you have created and published sensitivity labels. To learn more, see:
- Learn about sensitivity labels
- Get started with sensitivity labels
- Create and configure sensitivity labels and their policies
This procedure uses a hypothetical distribution group Finance team at Contoso.com and a hypothetical SMTP recipient adele.vance@fabrikam.com.
This procedure uses alerts, see: Get started with the data loss prevention alerts
Scenario 1 policy intent statement and mapping
We need to block emails to all recipients that contain credit card numbers or that have the ‘highly confidential’ sensitivity label applied except if the email is sent from someone on the finance team to adele.vance@fabrikam.com. We want to notify the compliance admin every time an email is blocked and notify the user who sent the item and no one can be allowed to override the block. Track all occurrences of this high risk event in the log and we want the details of any events captured and made available for investigation
| Statement | Configuration question answered and configuration mapping |
|---|---|
| "We need to block emails to all recipients..." | - Where to monitor: Exchange - Administrative scope: Full directory - 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 |
| "...that contain credit card numbers or have the 'highly confidential' sensitivity label applied..." | - What to monitor use the Custom template - Conditions for a match edit it to add the highly confidential sensitivity label |
| "...except if..." | - Condition group configuration: Create a nested boolean NOT condition group joined to the first conditions using a boolean AND |
| "...the email is sent from someone on the finance team..." | - Condition for match: Sender is a member of |
| "...and..." | - Condition for match: add a second condition to the NOT group |
| "...to adele.vance@fabrikam.com..." | - Condition for match: Recipient is |
| "...Notify..." | - User notifications: enabled - Policy tips: enabled |
| "...the compliance admin every time an email is blocked and notify the user who sent the item..." | - Policy tips: enabled - Notify these people: selected - The person who sent, shared, or modified the content: selected - Send the email to these additional people: add the email address of the compliance administrator |
| "...and no one can be allowed to override the block... | - Allow overrides from M365 Services: not selected |
| "...Track all occurrences of this high risk event in the log and we want the details of any events captured and made available for investigation." | - Use this severity level in admin alerts and reports: high - Send an alert to admins when a rule match occurs: selected - Send alert every time an activity matches the rule: selected |
Steps to create policy for scenario 1
Important
For the purposes of this policy creation procedure, you'll accept the default include/exclude values and leave the policy turned off. You'll be changing these when you deploy the policy.
Select the appropriate tab for the portal you're using. To learn more about the Microsoft Purview portal, see Microsoft Purview portal. To learn more about the Compliance portal, see Microsoft Purview compliance portal.
Sign in to the Microsoft Purview portal
Open the Data loss prevention solution and navigate to Policies > + Create policy.
Select Custom from the Categories list.
Select Custom from the Regulations list.
Choose Next.
Give the policy a name Name and a Description. You can use the policy intent statement here.
Important
Policies can't be renamed
Select Next.
Assign admin units. To apply the policy to all users, accept the default setting.
Choose Next.
Choose where to apply the policy. Select only the Exchange email location. Deselect all the other locations.
Choose Next.
On the Define policy settings page the Create or customize advanced DLP rules option should already be selected.
Select Next.
Select Create rule. Name the rule and provide a description.
Under Conditions select Add condition > Content contains
(Optional) Enter a Group name.
(Optional) Select a Group operator
Select Add > Sensitive info types > Credit Card Number.
Choose Add.
Still within the Content contains section, Select Add > Sensitivity labels > Highly confidential and then choose Add.
Next, beneath the Content contains section, choose Add group.
Leave the Boolean operator set to AND, then set the toggle to NOT.
Select Add condition.
Select Sender is a member of.
Select Add or Remove Groups.
Select Finance Team and then choose Add.
Choose Add condition > Recipient is.
In the email field, enter adele.vance@fabrikam.com and select Add .
Under Actions, select Add an action > Restrict access or encrypt the content in Microsoft 365 locations
Select Block users from receiving email or accessing shared SharePoint, OneDrive, and Teams files, and then select Block everyone.
Set the User notifications toggle to On.
Select Email notifications > Notify the person who sent, shared, or last modified the content.
Choose whether or not to Attach matching email message to the notification.
Choose whether or not to add Policy tips.
Under User ovverides, make sure that Allow overrides from Microsoft 365 apps and services ... is NOT selected.
Under Incident reports, set Use this severity level in admin alerts and reports to High.
Set Send alert every time an activity matches the rule toggle to On..
Choose Save.
Choose Next, then choose Run the policy in simulation mode.
Choose Next and then choose Submit.
Choose Done.
Scenario 2 Block sharing of sensitive items via SharePoint and OneDrive in Microsoft 365 with external users
For SharePoint and OneDrive in Microsoft 365, you create a policy to block sharing of sensitive items with external users via SharePoint and OneDrive.
Scenario 2 prerequisites and assumptions
This scenario uses the Confidential sensitivity label, so it requires that you have created and published sensitivity labels. To learn more, see:
- Learn about sensitivity labels
- Get started with sensitivity labels
- Create and configure sensitivity labels and their policies
This procedure uses a hypothetical distribution group Human Resources and a distribution group for the security team at Contoso.com.
This procedure uses alerts, see: Get started with the data loss prevention alerts
Scenario 2 policy intent statement and mapping
We need to block all sharing of SharePoint and OneDrive items to all external recipients that contain social security numbers, credit card data or have the "Confidential" sensitivity label. We do not want this to apply to anyone on the Human Resources team. We also have to meet alerting requirements. We want to notify our security team with an email every time a file is shared and then blocked. In addition, we want the user to be alerted via email and within the interface if possible. Lastly, we don’t want any exceptions to the policy and need to be able to see this activity within the system.
| Statement | Configuration question answered and configuration mapping |
|---|---|
| “We need to block all sharing of SharePoint and OneDrive items to all external recipients...” | - Administrative scope: Full directory - Where to monitor: SharePoint sites, OneDrive accounts - Conditions for a match: First Condition > Shared outside my org - Action: Restrict access or encrypt the content in Microsoft 365 locations > Block users from receiving email or accessing shared SharePoint, OneDrive > Block only people outside your organization |
| "...that contain social security numbers, credit card data or have the "Confidential" sensitivity label...” | - What to monitor: use the Custom template - Condition for a match: Create a second condition that is joined to the first condition with a boolean AND - Conditions for a match: Second condition, first condition group > Content contains Sensitive info types U.S. Social Security Number (SSN), Credit Card Number - Condition group configuration Create a second Condition group connected to the first by boolean OR - Condition for a match: Second condition group, second condition > Content contains any of these sensitivity labels Confidential. |
| “...We don't want this to apply to anyone on the Human Resources team...” | - Where to apply exclude the Human Resources Team OneDrive accounts |
| "...We want to notify our Security team with an email every time a file is shared and then blocked..." | - Incident reports: Send an alert to admins when a rule match occurs - Send email alerts to these people (optional): add the Security team - Send an alert every time an activity matches the rule: selected - Use email incident reports to notify you when a policy match occurs: On - Send notifications to these people: add individual admins as desired - You can also include the following information in the report: Select all options |
| "...In addition, we want the user to be alerted via email and within the interface if possible...” | - User notifications: On - Notify uses in Office 365 with a policy tip: selected |
| “...Lastly, we don’t want any exceptions to the policy and need to be able to see this activity within the system...” | -User overrides: Not selected |
When the conditions are configured, the summary looks like this:
Steps to create policy for scenario 2
Important
For the purposes of this policy creation procedure you'll leave the policy turned off. You change these when you deploy the policy.
Select the appropriate tab for the portal you're using. To learn more about the Microsoft Purview portal, see Microsoft Purview portal. To learn more about the Compliance portal, see Microsoft Purview compliance portal.
Sign in to the Microsoft Purview portal
Select Data loss prevention > Policies > + Create policy.
Select Custom from both the Categories list and the Regulations list.
Choose Next.
Give the policy a name Name and a Description. You can use the policy intent statement here.
Important
Policies can't be renamed.
Select Next.
Accept the default Full directory on the Assign admin units page.
Choose Next.
Choose where to apply the policy.
- Ensure that the the SharePoint sites and OneDrive accounts locations are selected.
- Deselect all other locations.
- Select Edit in the Scope column next to OneDrive accounts.
- Select All users and groups and then select Exclude users and groups.
- Choose +Exclude and then Exclude groups.
- Select Human Resources.
Choose Done and then choose Next.
On the Define policy settings page, the Create or customize advanced DLP rules option should already be selected. Choose Next.
On the Customize advanced DLP rules page, select + Create rule.
Give the rule a Name and a description.
Select Add condition and use these values:
- Choose Content is shared from Microsoft 365.
- Select with people outside my organization.
Select Add condition to create a second condition and use these values.
- Select Content contains.
Select Add > Sensitivity labels > and then Confidential.
Choose Add.
Under Actions, add an action with these values:
- Restrict access or encrypt the content in Microsoft 365 locations.
- Block only people outside your organization.
Set the User Notifications toggle to On.
Select Notify users in Office 365 services with a policy tip and then select Notify the user who sent, shared, or last modified the content.
Under User overrides, make sure that Allow override from M365 services is NOT selected.
Under Incident reports:
- Set Use this severity level in admin alerts and reports to Low.
- Set the toggle for Send an alert to admins when a rule match occurs to On.
Under Send email alerts to these people (optional), choose + Add or remove users and then add the email address of the security team.
Choose Save and then choose Next.
On the Policy mode page, choose Run the policy in simulation mode and Show policy tips while in simulation mode.
Choose Next and then choose Submit.
Choose Done.
Deployment
A successful policy deployment isn't just about getting the policy into your environment to enforce controls on user actions. A haphazard, rushed deployment can negatively impact business process and annoy your users. Those consequences slow acceptance of DLP technology in your organization and the safer behaviors it promotes. Ultimately making your sensitive items less safe in the long run.
Before you start your deployment, make sure you have read through Policy deployment. It gives you a broad overview of the policy deployment process and general guidance.
This section dives more deeply into the three types of controls you use in concert to manage your policies in production. Remember you can change any of these at any time, not just during policy creation.
Three axes of deployment management
There are three axes you can use to control the policy deployment process, the scope, the state of the policy, and the actions. You should always take an incremental approach to deploying a policy, starting from the least impactful/simulation mode through to full enforcement.
Recommended deployment control configurations
| When your policy state is | Your policy scope can be | Impact of policy actions |
|---|---|---|
| Run the policy in simulation mode | Policy scope of locations can be narrow or broad | - You can configure any action - No user impact from configured actions - Admin sees alerts and can track activities |
| Run the policy in simulation mode with policy tips | Policy should be scoped to target a pilot group and then expand the scope as you tune the policy | - You can configure any action - No user impact from configured actions - Users can receive policy tips and alerts - Admin sees alerts and can track activities |
| Turn it on | All targeted location instances | - All configured actions are enforced on user activities - Admin sees alerts and can track activities |
| Keep it off | n/a | n/a |
State
State is the primary control you use to roll out a policy. When you finished creating your policy, you set the state of the policy to Keep it off. You should leave it in this state while you're working on the policy configuration and until you get a final review and sign off. The state can be set to:
- Run the policy in simulation mode: No policy actions are enforced, events are audited. While in this state, you can monitor the impact of the policy in the DLP simulation mode overview and the DLP Activity explorer console.
- Run the policy in simulation mode and show policy tips while in simulation mode: No actions are enforced, but users receive policy tips and notification emails to raise their awareness and educate them.
- Turn it on right away: This is full enforcement mode.
- Keep it off: The policy is inactive. Use this state while developing and reviewing your policy before deployment.
You can change the state of a policy at any time.
Actions
Actions are what a policy does in response to user activities on sensitive items. Because you can change these at any time, you can start with the least impactful, Allow (for devices) and Audit only (for all other locations), gather and review the audit data, and use it to tune the policy before moving to more restrictive actions.
Allow: The user activity is allowed to occur, so no business processes are impacted. You get audit data and there aren't any user notifications or alerts.
Note
The Allow action is only available for policies that are scoped to the Devices location.
Audit only: The user activity is allowed to occur, so no business processes are impacted. You get audit data and you can add notifications and alerts to raise awareness and train your users to know that what they're doing is a risky behavior. If your organization intends to enforce more restrictive actions later on, you can tell your users that too.
Block with override: The user activity is blocked by default. You can audit the event, raise alerts and notifications. This impacts the business process, but your users are given the option to override the block and provide a reason for the override. Because you get direct feedback from your users, this action can help you identify false positive matches, which you can use to further tune the policy.
Note
For Exchange online and SharePoint in Microsoft 365, overrides are configured in the user notification section.
Block: The user activity is blocked no matter what. You can audit the event, raise alerts and notifications.
Policy scope
Every policy is scoped to one or more locations, such as Exchange, SharePoint in Microsoft 365, Teams, and Devices. By default, when you select a location, all instances of that location fall under the scope and none are excluded. You can further refine which instances of the location (such as sites, groups, accounts, distribution groups, mailboxes, and devices) that the policy is applied to by configuring the include/exclude options for the location. To learn more about your include/exclude scoping options, see, Locations.
In general, you have more flexibility with scoping while the policy is in Run the policy in simulation mode state because no actions are taken. You can start with just the scope you designed the policy for or go broad to see how the policy would impact sensitive items in other locations.
Then when you change the state to Run the policy in simulation mode and show policy tips, you should narrow your scope to a pilot group that can give you feedback and be early adopters who can be a resource for others when they come onboard.
When you move the policy to Turn it on right away, you broaden the scope to include all the instances of locations that you intended when the policy was designed.
Policy deployments steps
- After you've created the policy and set its state to Keep it off, do a final review with your stakeholders.
- Change the state to Run the policy in simulation mode. The location scope can be broad at this point so you can gather data on the behavior of the policy across multiple locations or just start with a single location.
- Tune the policy based on the behavior data so that it better meets the business intent.
- Change the state to Run the policy in simulation mode and show policy tips. Refine the scope of locations to support a pilot group if needed and make use of includes/excludes so that the policy is first rolled out to that pilot group.
- Gather user feedback and alert and event data, if needed tune the policy and your plans more. Make sure you address all the issues that your users bring up. Your users will most likely encounter issues and raise questions about things that you didn't think of during the design phase. Develop a group of super users at this point. They can be a resource to help train other users as the scope of the policy is increased and more users come onboard. Before you go to the next stage of deployment, make sure that the policy is achieved your control objectives.
- Change the state to Turn it on right away. The policy is fully deployed. Monitor DLP alerts and DLP activity explorer. Address alerts.