Design a data loss prevention policy

Taking the time to design a policy before you implement it will get you to the desired results faster, and with fewer unintended issues, than creating it and then tuning by trial and error alone. Having your policy designs documented will also help you in communications, policy reviews, troubleshooting, and further tuning.

If you are new to Microsoft Purview DLP, it's helpful to work through these articles before you start designing a policy:


If you're not an E5 customer, you can try all the premium features in Microsoft Purview for free. Use the 90-day Purview solutions trial to explore how robust 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.

Policy design overview

Designing a policy is mostly about clearly defining your business needs, documenting them in a policy intent statement and then mapping those needs to policy configuration. You'll use the decisions you made in your planning phase to inform some of your policy design decisions.

Define intent for the policy

You should be able to summarize the business intent for every policy you have in a single statement. Developing this statement will drive conversations in your organization and, when fully fleshed out, this statement directly links the policy to a business purpose and provides a roadmap for policy design. The steps in the Plan for data loss prevention (DLP) article will help you get started on your policy intent statement.

Remember from DLP policy configuration overview that all DLP policies require that you:

  • Choose what you want to monitor
  • Choose where you want to monitor
  • Choose the conditions that must be matched for a policy to be applied to an item
  • Choose the action to take when the policy conditions are met

For example, here's a fictitious first draft of an intent statement that provides answers to all four questions:

"We are a U.S. based organization, and we need to detect Office documents that contain sensitive health care information covered by HIPPA that are stored in OneDrive/SharePoint and protect against that information being shared in Teams chat and channel messages and restrict everyone from sharing them with unauthorized third parties".

As you develop a policy design, you'll likely modify and extend the statement.

Map business needs to policy configuration

Let's break the example draft statement down and map it to DLP policy configuration points.

Statement Configuration question answered and configuration mapping
"We are a U.S. based organization, and we need to detect Office documents that contain sensitive health care information covered by HIPPA... - What to monitor: Office docs, use the U.S. Health Insurance Act (HIPAA) template
- Conditions for a match: (preconfigured but editable) - item contains U.S. SSN and Drug Enforcement Agency (DEA) number, International Classification of Diseases (ICD-9-CM), International Classification of Diseases (ICD-10-CM), content is shared with people outside my organization
- drives conversations to clarify the triggering threshold for detection like confidence levels, and instance count (called leakage tolerance).
...that are stored in OneDrive/SharePoint and protect against that information being shared Teams chat and channel messages... - Where to monitor: Location scoping by including or excluding OneDrive and SharePoint sites and Teams chat/channel accounts or distribution groups.
...and restrict everyone from sharing those items with unauthorized third parties." - Actions to take: You add Restrict access or encrypt the content in Microsoft 365 locations
- drives conversation on what actions to take when a policy is triggered including protective actions like sharing restrictions, awareness actions like notifications and alerts, and user empowerment actions like allow user overrides of a blocking action

This example doesn't cover all the configuration points of a DLP policy, it would need to be expanded. But it should get you thinking in the right direction as you develop your own DLP policy intent statements.


Keep in mind that the location(s) you pick impact whether you can use sensitive information types, sensitivity labels and retention labels as well as the actions that are available. See, Data Loss Prevention policy reference.

Complex rule design

The above HIPPA content in SharePoint and OneDrive is a simple example of a DLP policy. The DLP rule builder supports boolean logic (AND, OR, NOT) and nested groups.


  • All existing Exceptions are replaced with a NOT condition in a nested group inside of the Conditions.
  • You need to create groups in order to use multiple operators as shown in the video.


When an action in Office desktop client apps, (Word, Outlook, Excel, and PowerPoint) matches a policy that uses complex conditions, the user will only see policy tips for rules that use the Content contains sensitive information condition.

Here's a video that shows how you'd map two complex policy intent statements to policies in the rule builder.

  • Example 1 We need to block emails to all recipients that contain credit card numbers, OR that have the 'highly confidential' sensitivity label applied, but do NOT block the email if it is sent from someone on the finance team to

  • Example 2 Contoso needs to block all emails that contain a password protected file OR a zip document file extension ('zip' or '7z'), but do NOT block the email if the recipient is in the domain OR the domain, OR the sender is a member of the Contoso HR group.

Policy Design Process

  1. Complete the steps in Plan for data loss prevention (DLP) - by working through this article you will:

    1. Identify your stakeholders
    2. Describe the categories of sensitive information to protect
    3. Set goals and strategy
    4. Define your policy deployment plan
  2. Familiarize yourself with Data Loss Prevention policy reference so that you understand all the components of a DLP policy and how each one influences the behavior of a policy.

  3. Familiarize yourself with What the DLP policy templates include.

  4. Develop your policy intent statement with your key stakeholders. Refer to the example earlier in this article.

  5. Determine how this policy fits into your overall DLP policy strategy.


Policies can't be renamed once they are created. If you must rename a policy, you will have to create a new one with the desired name and retire the old one. So decide on the naming structure that all your policies will use now.

  1. Map the items in your policy intent statement to configuration options.

  2. Decide which policy template you will start from, predefined or custom.

  3. Go through the template and assemble all information required before you create the policy. It's likely that you will find that there are some configuration points that aren't covered in your policy intent statement. That's ok. Go back to your stakeholders to iron out the requirements for any missing configuration points.

  4. Document the configuration of all the policy settings and review them with your stakeholders. You can re-use your policy intent statement mapping to configuration points, which is now fully fleshed out.

  5. Create a draft policy and refer back to your policy deployment plan.

See Also