DLP Policies: models and cases

Introduction to Data Loss Prevention Policies

Data Loss Prevention (DLP) Policies in Microsoft Power Platform are a cornerstone of organizational data governance. These policies act as control systems that prevent combinations of connectors or flows that could expose sensitive information to unauthorized systems. Their goal is to avoid the loss or unintended disclosure of critical data while maintaining the flexibility required to develop cloud solutions and automations.

Each policy defines which connectors can be used together, separating “Business” from “Non-Business” channels and identifying any “Blocked” connectors. Proper configuration of DLP is essential to ensure the Power Platform ecosystem remains secure and compliant with business policies.

According to Microsoft guidelines, DLP policies should be defined as early as possible, before makers and developers start building apps or flows, to prevent data exposure risks. When multiple policies are combined, the most restrictive rule always prevails: overlapping policies result in the strictest enforcement.

DLP Policy Models

DLP Policy models can be organized according to different approaches, depending on the organization’s complexity and digital maturity level. The main models include:

• Centralized model (Tenant-level): manages connectors and uniform rules across all environments. Ideal for organizations seeking total control and reduced policy fragmentation.
• Distributed model (Environment-level): allows individual teams to define specific rules for their environments while maintaining compliance with central directives.
• Hybrid model: combines both previous approaches, applying global baseline rules and local policies for sensitive or development environments.

In a hybrid model, for example, production environments may have strict policies, while development environments allow testing and prototyping with non-business connectors. This approach balances security and innovation, supporting controlled citizen development growth.

Figure 1 – Example of a hybrid DLP model with tenant-level policy and local environment rules

Practical Use Cases

DLP Policies must be modeled based on usage scenarios. Below are three common examples:

1. Citizen Developer

In the context of citizen developers, DLP Policies aim to enable low-code solution creation without compromising security. For instance, it is common to restrict the use of external connectors such as Twitter, Dropbox, or Gmail, allowing only internal connectors like SharePoint, Dataverse, and Outlook. This allows makers to automate business processes without risking the export of sensitive data to uncontrolled systems.

2. Enterprise Integrations

For integration scenarios between Power Platform and enterprise systems (ERP, CRM, or Azure), it is useful to define policies that separate business connectors for internal use from approved integration connectors. For example, the Business group may include Dataverse, SQL Server, and Azure Service Bus connectors, while third-party tools remain in the Non-Business or Blocked group depending on the risk level.

3. External Access and Public Scenarios

When Power Platform integrates with Power Pages or other external access scenarios, DLP management is essential to prevent accidental data exposure. Policies should block public network connectors and allow only connectors directed to Dataverse or protected internal APIs. This approach is typical for applications serving customers or external partners, where connector segmentation drastically reduces risks.

Tools and Monitoring

Monitoring and periodically reviewing DLP Policies are key aspects of governance. Microsoft offers tools such as the Center of Excellence Starter Kit, which includes Power BI dashboards to track connector usage, identify violations, and optimize configurations.

Through these solutions, you can:

• Analyze the most used connectors and their risk categories.
• Manage outdated or non-compliant policies.
• Detect flows attempting to combine connectors from different groups.
• Apply automatic review strategies using Power Automate.

For technical details, refer to Microsoft’s official documentation on Data Loss Prevention policies.