Data Loss Prevention policies for Microsoft’s Power Platform are a safety shield for your organization’s data. In this article, we explain how DLP policies can protect you from unintentionally publishing company data on Twitter.

Why Data Loss Prevention policies are so important  

Data Loss Prevention policies or DLP policies are the cornerstones of protecting your company’s sanctuary: its proprietary data. Low code application tools such as Power Apps and Power Automate work with data. They can not only obtain or create it but also manipulate or delete it. And they can pull data from a wide variety of sources and services.

To access these data sources, developers use so-called „connectors”. Today, there are hundreds of these connectors. All of them allow access to a wide variety of sources. Alongside Microsoft’s own connectors, there are also many third-party providers. And the overall quantity is constantly growing. Each of these connectors, and each new one that is added, increases the potential use cases and the power of the applications that are created with them. At the same time, the growing number of connectors also enables the misuse of the same. Therefor posing a significant risk to companies. 

For example, imagine a scenario in which a user builds a flow in Power Automate. It pulls information from corporate systems, such as SharePoint or SalesForce. Finally, the flow sends it to Twitter or a private email inbox. All of this, without prior review. A nightmare scenario for any data protection professional. One that can effectively be prevented by the proper use of DLP policies. 

Protect your data

Data Loss Prevention policies give you as an admin, both on a global power platform (tenant) and on an environmental level, the ability to protect your data from misuse. Further, DLP policies allow you to set guard rails for the development and use of low code applications. A successfully implemented DLP gives the administrator the security of not allowing unnoticed data holes to occur. Simultaneously it provides developers with the assurance that they are not unknowingly violating policies. 

However, the practical implementation of Data Loss Prevention policies for the Power Platform is often a balancing act. On the one hand, the productivity of the company must be ensured through releases. On the other hand, data loss or misuse must be prevented through restrictions.

Levels: Tenant level / Environment level

DLP policies for the Power Platform can be defined at either the tenant level or the environment level. Policies at the tenant level apply to all non-excluded environments of the affected tenant. Establishing DLP policies at the tenant level is particularly useful for completely blocking certain services. Thus, if there are services you wish to exclude from use across your entire organization, you can obtain this security through tenant-level DLP policies. 

At the environment level, environment administrators can set policies for individual environments. This allows policies to be tailored to specific usage scenarios, maximizing security and productivity. 

Prerequisites to set DLP policies

To be able to enforce and implement policies on the different levels, you need different permissions. These permissions determine whether you can set policies for the entire tenant or only for individual environments. 

To enforce policies at the tenant level, you need Microsoft Power Platform admin, dynamics 365 admin, or Microsoft 365 Global administrator permissions. However, to create policies at the environment level, you only need Power Platform environment admin permissions. 

This gradation allows you to maintain full control over your tenant and efficiently distribute responsibilities at the same time. 

Business, non-business, blocked

If all prerequisites are met, you can start with the DLP policies for the Power Platform. To do this, you can find the DLP Policy Settings screen in the Power Platform Administration Center. 

Here you can move various connectors into designated buckets. They are divided into Blocked, Business, and Non-Business. Any connector that has been assigned to the Blocked bucket cannot be used in environments that are subject to this DLP policy. Connectors in Business and Non-Business buckets, on the other hand, can still be used within the Power Platform. Not together though. For example, suppose you have added SharePoint to the Business and Twitter to the Non-Business bucket. In this case, although you can use both connectors, you cannot use them within any application or workflow that accesses both services. This is an efficient way to prevent data from being lost or ending up where you don’t want it. 

As new connectors are released at a high rate, it is recommended to set up a default bucket for them. Further, it is highly recommended to choose the Blocked bucket as the default. Then assign connectors from there to the Business and Non-Business buckets as needed.

Combination of multiple DLP policies within one Environment  

As a tenant or environment administrator, you can set multiple DLP policies. All of which can apply to the same environment at the same time. All DLP policies are considered when evaluating Blocked, Business, and Non-Business classifications. As a preliminary remark, if a connector is in the blocked bucket in any of the relevant policies, it cannot be used in this environment. In this context, it is irrelevant whether the policy is an environment or a tenant policy. Being the most restrictive classification, blocked always receives the highest priority. 

However, complications or opacity can arise from combining multiple DLP policies within a single environment. For example, let’s say there are three policies applied to a single environment. Therefore, for the creation and use of any application or workflow in that environment, all three policies are audited. This means the connectors used are all checked to be assigned to the same buckets. And this is done across all three policies. The combination of multiple policies within an environment thus results in many possible combinations. Together, they determine whether an application or workflow may be used. 

To make DLP policies for the Power Platform clear, understandable, and, above all, efficient, it is advisable to keep the number of policies per environment as low as possible. In this way, you can maintain an overview yourself and enable developers to work quickly and efficiently.

Exemptions from DLP

Once applied, sooner or later there will be conflicts between your Data Loss Prevention policies and applications and workflows or their creators. This leads to problems especially when a connector is indispensable for an important workflow or application. In this case, you need to consider whether to adjust your policies or create a new environment for these scenarios. When neither option is viable because the case is an absolute exception, you can exclude certain cases from your DLP policy. 

To exclude an application or workflow from your policy you will need Microsoft’s PowerShell. This allows you to create an exception list using a script that excludes apps and workflows from your DLP policy. 

However, care should be taken to ensure that these exception lists do not become the norm. Like combined policies within an environment, exceptions also increase complexity and thus opacity. 

Impact on apps and flows 

As described in the previous sections, your DLP policies impact the creation and use of your applications and workflows within the Power Platform. So, if a developer attempts to access a blocked connector when creating an app or workflow, they will be presented with a design-time DLP error notification. 

However, new policies affect not only new apps and workflows but also those already created and in use. This means that a user trying to access an app recently affected by your policy will also receive an error message. The same applies to previously created workflows and is known as a runtime error.

Keep the balance

The balancing act described at the beginning should be clear at this point, but by no means scare you off. Instead, Data Loss Prevention policies for Microsoft’s Power Platform are your protection against data loss or accidental data leakage. Conscientiously and consistently applied, you create guard rails for your developers, between which they can move and develop with a clear conscience. 

If you have any further questions or concerns about Power Platform security and governance, please do not hesitate to contact us. 

Runpipe is an out-of-the-box collaboration and governance tool for your business using the Power Platform. Find more information on Power Platform Governance on our website or at Microsoft.