How to set up a Power Platform DLP policy

But then we have the Power Platform, this easy-to-use tool with over 1,000 connectors that makes it easy for any user, without any IT knowledge, to create a flow that copies data from SharePoint to Dropbox or from their company OneDrive for Business to a personal OneDrive.

In this post, we’ll learn how you can create and manage your data loss prevention (DLP) policies.

What are data loss prevention policies?

Data loss prevention policies function as guardrails, helping you enforce rules on which connectors can be used together in the same app or flow. 

For example, you might allow users to work with SharePoint or OneDrive but prevent them from combining those with third-party services like Dropbox. You can even go further by blocking connectors completely or restricting specific connector actions. 

Good to know: DLP policies apply to both Power Apps and Power Automate, not just flows.

Creating a DLP policy – step by step

You can create and manage DLP policies using either the Power Platform admin center or PowerShell. But it’s honestly easier via the Admin Center, so let’s create one together.

First, navigate to the Power Platform Admin Center at https://admin.powerplatform.microsoft.com/home, and under the Security category, go to Data and Privacy, and finally, select Data Policy. From here, click on the New Policy button at the top.

The first thing you will do is give your policy a meaningful name, such as the HR Data Policy.

When creating a DLP policy, connectors must be grouped into two categories: 

• Business connectors 
• Non-business connectors 

These group names are arbitrary—you can think of them as Group A and Group B. The rule is simple: connectors from different groups can’t be used together in the same app or flow. 

You also have the option to block all connectors, including Microsoft Premium and third-party connectors, entirely. However, note that some Microsoft 365 connectors like SharePoint and Teams cannot be blocked.

So, right now, let’s say I only move the Office 365 Users, SharePoint, and OneDrive for Business connectors to Business and leave everything else in Non-Business; the following flow would be disabled. We have a mix of connectors in the Business group and connectors in the Non-Business group.

However, I would be able to create a flow that takes posts from X and puts them on Teams since both the X connector and the Teams connector are non-business. So, as long as they’re in the same group, you can use them.

If there are connectors you do not want to use at all, you can simply block them, as seen in the screenshot below.

Not all connectors are created equal. Some offer the ability to fine-tune their behavior by allowing or blocking specific actions.  Select a connector, go to configure connector, and then you will be able to configure connector actions.

For example, you may want to allow users to read data from SQL Server but not insert or delete records. This level of control gives admins more flexibility to tailor policies to business needs without completely disabling useful services.

Before we go further, I also want to talk about Desktop Flows, which are Microsoft’s Robotic Process Automation solution. Data Policies also apply to Desktop flows, but only in Managed environments that require premium licensing. So, if you want Desktop flows to respect your data policies, make sure you create them in Managed environments.

Now, it will take you a bit of time to assign your connectors, but before we move on to the next topic, remember that the Microsoft Power Platform gets new connectors almost weekly. So, what do we do with new ones?

You can configure the default group for new connectors between Business, Non-business, and Blocked.

It’s now time to decide the Scope. Where do you want to apply those policies? Remember that we want to offer flexibility to our users, so we might want to block social media sites for the HR or R&D departments but allow them for the Marketing department. The Power Platform allows you to apply it to either all environments, selecting one or multiple environments, or all except certain environments.

In my case, I will choose to only apply it to the default environment.

And finally, we need to review everything!  Something to be very careful about is that we do not know what impact this Policy will have yet on our environment. Microsoft doesn’t offer a built-in way to see how many apps or flows we will disable with this policy. 

The only way to see it currently is to use the Microsoft Power Platform Center of Excellence (CoE) Starter Kit, an open-source solution by the community and sponsored by Microsoft that includes an Impact Analysis tool that helps you understand the effect of your DLP policy ahead of time. It’s open-source and available on GitHub. It’s a fantastic tool, but it doesn’t have any support by Microsoft, so be careful as you install it.

Ok our policy is now created, and within minutes, my flow is disabled, and if I go edit it, I have an error telling me:  

“Your flow violates your org’s data loss prevention policy (DLP). This operation violates admin data policy ‘HR Data Policy’, which restricts the use of business connector ‘shared_office365users’ with non-business connector ‘shared_approvals’.” 

That’s it! We have now created our data loss policy and started protecting our environment.

DLP policies reduce risks and enable productivity

DLP policies are a must-have for any organization that takes data governance seriously. With the ability to categorize connectors, block access, and restrict individual actions, Power Platform gives admins powerful tools to reduce risk while still enabling productivity.

Make it part of your regular admin routine to check for new connectors and review existing policies. With some planning and the right tooling, you can strike the right balance between control and innovation in your Power Platform environment.