Create a data loss prevention (DLP) policy

Article
06/30/2022

To protect data in your organization, you can use Power Apps to create and enforce policies that define the consumer connectors that specific business data can be shared with. These policies are called data loss prevention (DLP) policies. DLP policies ensure that data is managed in a uniform manner across your organization, and they prevent important business data from being accidentally published to connectors such as social media sites.

DLP policies can be created at the tenant level or at the environment level and are managed from the Power Platform admin center.

Prerequisites

Tenant-level

Tenant-level policies can be defined to include or exclude specific environments. To follow the steps described in this article for tenant-level policies, one of the following permissions is required:

Microsoft Power Platform admin permissions
Microsoft 365 Global admin permissions

We refer to these roles throughout this article as tenant admins. More information: Use service admin roles to manage your tenant

Environment-level

To follow the steps for environment-level policies, you need to have Power Apps Environment Admin permissions. For environments with a Dataverse database, you need to be assigned the System Administrator role instead.

Note

If using the SingleEnvironment EnvironmentType parameter when using PowerShell to create a DLP policy, the user account used to create the policy MUST have Environment-level and MUST NOT have Tenant-level permissions as described above, or a Bad Request error will be returned and the policy will not be created.

Find and view DLP policies

To find and view DLP policies, see Find and view DLP policies.

The DLP policy process

The following are the steps you follow to create a DLP policy:

Assign the policy a name.
Classify connectors.
Define the scope of the policy. This step doesn't apply to environment-level policies.
Select environments.
Review settings.

These are covered in the next section.

Walkthrough: Create a DLP policy

In this example walkthrough, we'll create a tenant-level DLP policy. We'll add SharePoint and Salesforce to the Business data group of a DLP policy. We'll also add Facebook and Twitter to the Blocked data group. We'll leave the remaining connectors in the Non-Business data group. We'll then exclude test environments from the scope of this policy and apply the policy to the remaining environments, such as default and production environments in the tenant.

After this policy is saved, any Power Apps or Power Automate maker who is part of the DLP policy's environment can create an app or a flow that shares data between SharePoint or Salesforce. Any Power Apps or Power Automate resource that includes an existing connection with a connector in the Non-business data group won't be allowed to establish connections with SharePoint or Salesforce connectors, and vice versa. Also, these makers won't be able to add Facebook or Twitter connectors to any Power Apps or Power Automate resource.

In Power Platform admin center, select Policies > Data policies > New policy.

If no policies exist in the tenant, you'll see the following page.
Enter a policy name, and then select Next.

Review the various attributes and settings you can make on the Assign Connectors page.

Assign connectors.

Attributes

Attribute	Description
Name	The name of the connector.
Blockable	Connectors that can be blocked. For a list of connectors that can't be blocked, see List of connectors that can't be blocked.
Type	Whether connector usage requires a Premium license or is it included in the base/Standard license for Microsoft Power Platform.
Publisher	The company that publishes the connector. This value can be different from the service owner. For example, Microsoft can be the publisher of the Salesforce connector, but the underlying service is owned by Salesforce, not Microsoft.
About	Select the URL for more information about the connector.

Lists

Pivot	Description
Business (n)	Connectors for business-sensitive data. Connectors in this group can't share data with connectors in other groups.
Non-Business/ Default (n)	Connectors for non-business data, such as personal use data. Connectors in this group can't share data with connectors in other groups.
Blocked (n)	Blocked connectors can't be used where this policy is applied.

Actions

Action	Description
Set default group	The group that maps any new connectors added by Microsoft Power Platform after your DLP policy is created. More information: Default data group for new connectors
Search Connectors	Search a long list of connectors to find specific connectors to classify. You can search on any field in the connector list view, such as Name, Blockable, Type, or Publisher.

You can take the following actions:

Assign connectors actions.

	Description
1	Assign one or more connectors across connector classification groups
2	Connector classification group pivot tables
3	Search bar to find connectors across properties like Name, Blockable, Type, or Publisher
4	Connector classification group that maps any new connectors added by Microsoft Power Platform after your DLP policy is created.
5	Select, multi-select, or bulk-select connectors to move across groups
6	Alphabetical sort capability across individual columns
7	Action buttons to assign individual connectors across connector classification groups

Select one or more connectors. For this walkthrough, select the SalesForce and SharePoint connectors, and then select Move to Business from the top menu bar. You can also use the ellipsis () to the right of the connector name.

The connectors will appear in the Business data group.

Connectors can reside in only one data group at a time. By moving the SharePoint and Salesforce connectors to the Business data group, you're preventing users from creating flows and apps that combine these two connectors with any of the connectors in the Non-Business or Blocked groups.

For connectors like SharePoint that are not blockable, the Block action will be grayed out and a warning will appear.
Review and change the default group setting for new connectors, if you need to. We recommend keeping the default setting as Non-Business to map any new connectors added to Microsoft Power Platform by default. Non-Business connectors can be manually assigned to Business or Blocked later by editing the DLP policy, after you've had a chance to review and assign them. If the new connector setting is Blocked, any new connectors that are blockable will be mapped to Blocked, as expected. However, any new connectors that are unblockable will be mapped to Non-Business because by design they can't be blocked.

In the upper-right corner, select Set default group.

After you've completed all the connector assignments across the Business/Non-Business/Blocked groups and set the default group for new connectors, select Next.
Choose the scope of the DLP policy. This step isn't available for environment-level policies, because they're always meant for a single environment.

For the purpose of this walkthrough, you will exclude test environments from this policy. Select Exclude certain environments, and on the Add Environments page, select Next.

Review the various attributes and settings on the Add Environments page. For tenant-level policies, this list will show the tenant-level admin all the environments in the tenant. For environment-level policies, this list will only show the subset of environments in the tenant that are managed by the user who has signed in as an Environment Admin or as a System Administrator for environments with Dataverse database.

Add environments.

Attributes

Attribute	Description
Name	The name of the environment.
Type	The type of the environment: trial, production, sandbox, default
Region	The region associated with the environment.
Created by	The user who created the environment.
Created (On)	The date on which the environment was created.

Lists

Pivot	Description
Available (n)	Environments that aren't explicitly included or excluded in the policy scope. For environment-level policy and tenant-level policies with scope defined as Add multiple environments, this list represents the subset of environments that aren't included in the policy scope. For tenant-level policies with scope defined as Exclude certain environments, this pivot represents the set of environments that are included within the policy scope.
Added to policy (n)	For environment-level policy and tenant-level policies with scope defined as Add multiple environments, this pivot represents the subset of environments that are within the policy scope. For tenant-level policies with scope defined as Exclude certain environments, this pivot represents the subset of environments that are excluded from the policy scope.

Pivot

Description

Available (n)

Environments that aren't explicitly included or excluded in the policy scope. For environment-level policy and tenant-level policies with scope defined as Add multiple environments, this list represents the subset of environments that aren't included in the policy scope. For tenant-level policies with scope defined as Exclude certain environments, this pivot represents the set of environments that are included within the policy scope.

Added to policy (n)

For environment-level policy and tenant-level policies with scope defined as Add multiple environments, this pivot represents the subset of environments that are within the policy scope. For tenant-level policies with scope defined as Exclude certain environments, this pivot represents the subset of environments that are excluded from the policy scope.

Actions

Action	Description
Add to policy	Environments in the Available category can be moved to the Added to policy category by using this action.
Remove from policy	Environments in the Added to policy category can be moved to the Available category by using this action.

Select one or more environments. You can use the search bar to quickly find the environments of interest. For this walkthrough, we'll search for test environments - type sandbox. After we select the sandbox environments, we assign them to the policy scope by using Add to policy from the top menu bar.

Because the policy scope was initially selected as Exclude certain environments, these test environments will now be excluded from the policy scope and the DLP policy settings will be applied to all the remaining (Available) environments. For environment-level policy, you can only select a single environment from the list of available environments.

After making selections for environments, select Next.
Review the policy settings, and then select Create Policy.

The policy is created and appears in the list of DLP policies. As a result of this policy, SharePoint and Salesforce apps can share data in non-test environments—such as production environments—because they're both part of the same Business data group. However, any connector that resides in the Non-Business data group—such as Outlook.com—won't share data with apps and flows by using SharePoint or Salesforce connectors. Facebook and Twitter connectors are altogether blocked from being used in any app or flow in non-test environments such as production or default environments.

It's good practice for admins to share the list of DLP policies with their organization so that users are aware of the policies before they create apps.

This table describes how the DLP policy you created affects data connections in apps and flows.

Connector matrix	SharePoint (Business)	Salesforce (Business)	Outlook.com (Non-Business)	Facebook (Blocked)	Twitter (Blocked)
SharePoint (Business)	Allowed	Allowed	Denied	Denied	Denied
Salesforce (Business)	Allowed	Allowed	Denied	Denied	Denied
Outlook.com (Non-Business)	Denied	Denied	Allowed	Denied	Denied
Facebook (Blocked)	Denied	Denied	Denied	Denied	Denied
Twitter (Blocked)	Denied	Denied	Denied	Denied	Denied

Because no DLP policy has been applied to test environments, apps and flows can use any set of connectors together in these environments.

Use DLP PowerShell commands

See Data Loss Prevention (DLP) policy commands.