DLP Policies: concepts and groups

Introduction to Data Loss Prevention Policies

Data Loss Prevention (DLP) Policies are a key element of security in Microsoft Power Platform. These policies define clear rules on how connectors can be used in Power Apps and Power Automate, protecting organizational data from accidental exposure to untrusted or unauthorized systems. The goal is to prevent automated flows or apps from transferring sensitive information from internal sources, such as Dataverse or enterprise databases, to external connectors like social networks or public messaging services.

Without properly configured DLP policies, makers and developers could create solutions that expose confidential data to significant risks. For this reason, Microsoft recommends setting up DLP policies before users begin building apps or flows.

Scope levels: Tenant and Environment

DLP policies can be defined at two distinct scope levels: tenant and environment.

• Tenant level: Tenant-level policies apply to all or selected Power Platform environments within a Microsoft 365 tenant. Only global or service administrators can create and manage these policies. They are used to ensure consistency and uniform data protection across the organization.
• Environment level: Environment-level policies apply only within a single Power Platform environment. These cannot override tenant-level policies but can make them more restrictive. They can be managed by environment administrators and allow for more granular security in specific contexts, such as development, testing, or production environments.

When multiple DLP policies overlap, the most restrictive configuration always takes precedence. This ensures that data remains protected even when multiple policies coexist.

Connector groups in DLP Policies

DLP policies organize connectors into logical groups that determine how they can be combined. This categorization is fundamental in preventing corporate data from being accidentally shared with untrusted services.

Group	Description	Examples
Business data	Connectors in this group can only be used together. It’s recommended to place all connectors accessing sensitive business data here.	Dataverse, SQL Server, SharePoint, Dynamics 365
Non-business data	This is the default group for all connectors. It includes connectors that don’t handle sensitive or business-critical data.	Twitter, RSS Feed, Weather Service
Blocked	Connectors in this group are completely disabled and cannot be used in flows or apps.	Non-compliant connectors or unapproved internal tools

Managing connector groups enables administrators to control not only which connectors can be used but also how they interact. For example, a flow that combines a “business” connector like SQL Server with a “non-business” connector like Twitter will automatically be blocked by the DLP policies.

Advanced DLP Policy configuration

Beyond simple connector classification, DLP policies allow more detailed configurations, including:

• Defining which connector actions are allowed or blocked (for example, allowing data reading but not writing).
• Restricting which endpoints a connector can connect to.
• Selective blocking based on internal compliance or security parameters.

These advanced settings help organizations align governance with specific security standards such as ISO 27001 or GDPR.

Best practices for implementation

For effective application of DLP policies, Microsoft and Power Platform architecture experts recommend:

• Creating and applying DLP policies before makers start developing apps and flows, avoiding retroactive configurations that are difficult to manage.
• Using the Center of Excellence Starter Kit to monitor and manage existing DLP policies.
• Establishing a consistent multi-environment strategy, clearly separating development, test, and production environments.
• Ensuring tenant-level policies are less restrictive than environment-level ones to avoid unexpected conflicts and blocks.