Create DLP Policy in Office 365 for Power Power Platform: How to Create Data Loss Prevention (DLP)?

In this “Create DLP Policy in Office 365” article, we will learn about how to create a DLP policy for Power Platform in Office 365, what a DLP policy is in Power Platform, and how to create a DLP policy for your Power Platform environment to safeguard your organisation’s data from unauthorised access. I will explain this concept in very simple terms.

What is the DLP policy in Power Platform?

Data loss prevention (DLP) policies come under Power Platform Governance. If you implement a data loss prevention (DLP) policy for your Power Platform environment, your environment will be secured. Let’s explain this concept in more realistic ways. Your organization’s data is hosted on the SharePoint Online site and/or the dataverse table, and you don’t want your employees to read these data and publish it on social media sites like X (formerly known as Twitter), LinkedIn, Facebook, etc.

Your organization employee can do it intentionally or unintentionally, then how to restrict them so that you can secure your data from being unauthorizedly accessed and getting published on social media sites. Here the role of data loss prevention (DLP) policies comes in. We can implement data loss prevention (DLP) policies in the respective environment; we can have more than one DLP policy for an environment; and we can even implement the DLP policy at the tenant level.

Now the questions arise: if we have multiple data loss prevention (DLP) policies for an environment and at the tenant level as well, then which DLP policy will be triggered? The answer is that the most restrictive policy wins here, meaning the most restrictive policy will be triggered or applied if you have multiple DLP policies deployed in an environment. I will write a separate article on this concept later.

Connector Classification: How does DLP policy work in a power platform environment?

The data loss prevention (DLP) policies work based on the various connectors’ availability in the defined environment. We need to categorize the connector into three sections:

• Business
• Non-Business
• Block

By default, all connectors will be in the non-business category. Even though we can change the default connector configuration to block, enabling the default connector as a business is not recommended. Either we should keep the default connector setting as “business” or “blocked.”.

Now, let’s understand what the meaning of this default connector setting is? What exactly does it technically do? Well, if you set the default connector setting to “blocked,” then if any new connectors are released by Microsoft or any third-party company, that connector by default will be listed in the blocked category; the same rule applies to the non-business category.

Now, let’s understand how connectors communicate with other connectors in different connector categories. The answer is no; the connectors cannot communicate with the other categories of connectors; this is the actual job of the data loss prevention (DLP) policy. Let’s elaborate on this concept: if the connectors are categorized as blocked, those connectors cannot be used anywhere in your flows; if the connectors are categorized as non-business, those connectors cannot be used along with business category connectors; and vice versa. Let’s understand this concept diagrammatically.

DLP Policy Diagram Explanation:

For this explanation as an example, I have kept the “SharePoint and Office 365 Outlook” connectors in the business category, “Microsoft Teams and Viva Engage” in the non-business category, and “X (Twitter) and LinkedIn” in the blocked category. Now let’s understand how this works in a Power Automate flow.

You are going to create Power Automate flows (either instant flow, automated flow, or scheduler flow) where you can add SharePoint connectors and Office Outlook connectors, but the moment you try to add connectors from non-business categories like Microsoft Teams or Viva Engage connectors, the DLP policy will not allow you to add your non-business connectors with the business connectors, and vice versa, you have created flows with non-business connectors like Microsoft Teams and Viva Engage, and you are trying to add business connectors like SharePoint and Office 365 Outlook, but you cannot add them due to the DLP policy restriction.

As far as blocked connectors are concerned, as the name implies, we cannot use blocked connectors with any connectors, whether they are business or non-business connectors. For example, as in the diagram shown, the X (Twitter) and LinkedIn connectors cannot be used with the business and non-business connectors due to the DLP policy restriction.

Let’s take the above diagram and explanation into practical action.

Create DLP Policy in Office 365 for Power Platform: How to create a DLP policy in Power Platform step by step demo

To create a DLP policy in Power Platform, you should have either Power Platform Administrator or Global Administrator privileges. Let’s create a sample DLP policy step by step.

Login to your Power Platform Admin Centre site.

Click on the “Data policies” link from the left side “polices” menu.

Click on the “+ New Policy” link.

Enter the name of your DLP Policy.

You can enter something meaningful, like “DLP Policy for Default Environment.”

Click on the “Next” button.

We can see the assigned connectors on the DLP policy screen.

By default, all connectors listed fall under the non-business category, as the default connector setting is non-business. If you want to change this default connector setting, you can do this from the screen. Click on the “Set default group” gear icon and select the group you need for your business, then click on the “Apply” button.

As I am not changing my default group, let’s go ahead with the out-of-the box default group to set up the DLP policy for my default environment.

Select the connector, and then at the top, you will get the option to “Move to Business,” “Blocked (if it is block-able),” or “Move to Non-Business.”.

Likewise, I have moved SharePoint and Office 365 Outlook to the business category and X (Twitter) and LinkedIn to the block category section.

Business category connector in DLP policy:

Blocked category connector in DLP policy:

Note: We can even configure the connector setting: should we allow only to read the data from the data source or write the data as well? Please have a look at the below instructions on how to configure this.

Select the connector you want to configure; for example, I have selected the Salesforce connector.

Click on the three-dot ellipse menu.

Click on the connection actions from the configure connector menu.

For each action, there is a toggle button. You can enable or disable these actions based on your business needs; by default, all actions are in enabled mode.

Note:

• The above connector configuration step was out of the DLP policy creation scope; just as I showed how to configure the connector settings, let’s continue to create the DLP policy process.

 

Then, click on the “Next” button.

We will get the “Custom connector patterns” screen; leave it as it is.

Click on the “Next” button.

We will get the define scope configuration screen. The options are as below:

• Add all environments: This is the tenant-level configuration; by default, this will be selected, and the policy will apply to your tenant.
• Add multiple environments: This is what I have selected for my requirement, where we can add one or more specific environments.
• Exclude certain environments: If you want to exclude certain environments from the tenant-level DLP policy, we can select them.

Define scope in Power Platform DLP policy deployment

 

Click on the “Next” button.

We can see all available environments from your tenant.

Select the Power Platform environments that you want to add to the DLP policy. I have selected my default environment, which I renamed Personal Productivity Development, then click on the “+ Add to Policy” link.

We can see that the default environment, Personal Productivity Development, has been added to the DLP policy.

Click on the “Next” button.

We can see the “Review and create policy” screen.

Click on the “Create policy” button.

We can see that a new policy has been successfully created, which gets displayed in the data policies library.

Now, let’s test this policy practically.

Note:

• The beauty of this DLP policy tool is that it gets deployed immediately if you just have Power Automate flows in your Power Platform environment.
• The moment you create a policy for your environment, it will be in action immediately. For Power Automate Flows, your DLP policy will be in action immediately or in a few minutes; however, for Power Apps, the scenario is different; it might take a number of hours to get it deployed; it depends on the number of Power Apps you have in your DLP-applied environments, so be patient on this. Let’s test that in the below section.

DLP Policy in Power Platform Testing

To test this DLP policy, I have created a sample Power Automate flow where I have added connectors from all three categories: business (SharePoint and Office 365), non-business (Microsoft Teams), and blocked (X (Twitter)). Now, when we try to save this flow, we will get the DLP restriction error saying that we cannot use the business and non-business connector together.

DLP Policy in Power Platform Testing

 

And we cannot use the blocked connector in the flow as it is defined in the DLP policy.

 

In order to work this flow, let’s remove the block category connector X (Twitter) and non-business (Microsoft Teams) or business connectors (SharePoint and Office 365 Outlook). This will allow us to save successfully and work it properly.

Now, the same flow has been saved successfully and is ready to run.

 

The above DLP demo will work fine for the new environments where there are no flows or apps developed yet in those environments. But how about the environments where already lots of flows and Power Apps are running in production using the mixed connectors (non-business and business)? We need to handle these environments differently.

Power Platform DLP Best Practices to follow while implementing DLP policies for existing environments

Different organizations might have different types of strategies to implement DLP policies in their organisations; however, we may consider that the following could be some of the best practices we may follow while implementing DLP policies in existing environments.

Get an active connector report

Get the active connector report from all your Power Automate flows and Power Apps. To get this report, you can use the Power Platform Centre of Excellence (CoE) or your Power Automate environment connections report.

Keep all active connectors in the business category

You must keep all your active connectors in the business category; otherwise, your existing Power Automate flows or Power Apps will fail.

Keep all block-able connectors in the Block category

Filter all blockable items and move all of them to the blocked category.

 

The remaining connectors you can assign into the business and non-business categories based on your organisation’s data policy and needs.

Maintain connector classification uniformity across your related environments (development, testing, and production).

Maintain connector classification uniformity across your grouped environments, like Dev, Test, and Prod. This will ease the administrative effort and keep your environment clean.

Apply governance to your DLP Policy

Periodically, you need to review your DLP policy and keep your Power Platform environment safe and secure.

Summary: Create DLP Policy in Power Platform – Data Loss Prevention (DLP)

Thus, in this article, we have learned about how to create a Data Loss Prevention (DLP) policy, what the data loss prevention (DLP) policy in Power Platform is in detail, and how to create a DLP policy for the Power Platform environments to safeguard your organisation’s data from unauthorised access. We have also learned with a live demo how to create a DLP policy that restricts the use of connectors from business to non-business category connectors and vice versa. We also learned what the best practices are that we should follow while implementing DLP policies in power platform environments.

 

See Also: Power Platform Articles

 

If you found this article helpful and enjoyed it, please consider sharing it with your friends and colleagues. Please don’t forget to subscribe to our site to receive our latest articles directly in your inbox. 🙂

 

If you’ve found value in my articles and want to support the growth of this tech knowledge hub, consider buying me a virtual coffee. Every coffee you buy is a vote for the continuation of quality tech content. Your contribution goes a long way in covering hosting fees, acquiring new tools, and maintaining the site for everyone’s benefit.

About Post Author