Create and deploy data loss prevention policies

Microsoft Purview Data Loss Prevention (DLP) policies include many configuration options. Each option changes the policy's behavior. The articles in this series cover some of the most common DLP policy scenarios. They walk you through configuring those options to give you hands-on experience with the DLP policy creation process. When you familiarize yourself with these scenarios, you gain the foundational skills that you need to use the DLP policy creation UX to create your own policies.

How you deploy a policy is as important as 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.

Orient yourself to DLP

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:

1. Administrative units
2. Learn about Microsoft Purview Data Loss Prevention - Introduces you to the data loss prevention discipline and Microsoft's implementation of DLP.
3. Plan for data loss prevention (DLP) - Work through this article to:
   1. Identify stakeholders
   2. Describe the categories of sensitive information to protect
   3. Set goals and strategy
4. Data Loss Prevention policy reference - Introduces all the components of a DLP policy and how each one influences the behavior of a policy.
5. Design a DLP policy - Walks you through creating a policy intent statement and mapping it to a specific policy configuration.
6. Create and Deploy data loss prevention policies - Explore common policy intent scenarios and see how they connect to configuration options. Then, follow a step-by-step guide to set up those options and get helpful tips for deploying your policy smoothly.
7. Learn about investigating data loss prevention alerts - Get to know how alerts progress—from creation all the way to final remediation and policy tuning. You’ll also discover the tools that help you investigate alerts along the way.

SKU/subscriptions licensing

For information on licensing, see

• Microsoft 365 Enterprise Plans
• Microsoft 365 Service Descriptions

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

Granular Roles and Role Groups

You can use these roles and role groups to fine tune your access controls.

Here's a list of applicable roles. To learn more, see Permissions in the Microsoft Purview 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 Permissions in the Microsoft Purview 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, introduces you to the methodology of creating a policy intent statement and then mapping that intent statement to policy configuration options.

• Help prevent sharing credit card numbers through email
• Help prevent sharing sensitive items via SharePoint and OneDrive with external users
• Help protect files that Endpoint Data Loss Prevention fails to scan
• Help protect files that Endpoint Data Loss Prevention doesn't scan
• Help protect against sharing of a defined set of unsupported files
• Disable Microsoft Purview data loss prevention scanning for some supported files and apply controls
• Help prevent sharing via Microsoft Edge for Business to unmanaged AI apps from managed devices
• Help prevent sharing Power BI reports with credit card numbers

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 processes and annoy your users. Those consequences slow acceptance of DLP technology in your organization and the safer behaviors it promotes. Ultimately, those consequences make your sensitive items less safe in the long run.

Before you start your deployment, make sure you 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. You can change any of these controls at any time, not just during policy creation.

Three axes of deployment management

Use three axes to control the policy deployment process: scope, state, and actions. Always take an incremental approach to deploying a policy, starting from the least impactful simulation mode through full enforcement.

Recommended deployment control configurations

State

State is the primary control you use to roll out a policy. When you finish creating your policy, set the state of the policy to Keep it off. Leave it in this state while you work on the policy configuration and until you get a final review and sign off. Set the state 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 actions 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 action 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, you configure overrides 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.

When you change the state to Run the policy in simulation mode and show policy tips, 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 deployment steps

1. After you've created the policy and set its state to Keep it off, do a final review with your stakeholders.
2. 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.
3. Tune the policy based on the behavior data so that it better meets the business intent.
4. 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.
5. Gather user feedback and alert and event data. If needed, tune the policy and your plans. 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.
6. Change the state to Turn it on right away. The policy is fully deployed. Monitor DLP alerts and DLP activity explorer. Address alerts.