Power Platform Data Loss Prevention (DLP)

What is Power Platform Data Loss Prevention?

Power Platform Data Loss Prevention, usually shortened to DLP, is a governance control over connectors. Administrators decide which connectors may be used and which connectors are allowed to share data with each other inside the same app, flow or agent. Microsoft now groups this under the broader name data policies.

The goal is to stop someone from accidentally sending business data from an approved service to a personal or unapproved one. A flow that copies SharePoint documents to a consumer storage account can be blocked while it is still being designed, before any data moves.

Read on its own, the name data loss prevention sounds broader than it is. The policy governs connector use within Power Platform. It does not replace access rights, sensitivity labels, endpoint security or the controls in the source and destination systems.

Connector groups and blocking

In classic data policies, each connector sits in one of three groups: business, non-business or blocked. A connector in the business group cannot be used together with a non-business connector in the same resource. A blocked connector is not available at all where the policy applies, as far as the connector type supports blocking. A short list of core Microsoft connectors, including the Dataverse connector, cannot be blocked.

The grouping does not say a connector is safe or unsafe by itself. It describes the data boundary the organisation wants to hold. Outlook and SharePoint might sit in the business group, while a personal storage service sits in non-business. New connectors land in the default group, which starts as non-business, so you deliberately move a connector to business only after weighing the impact.

Custom connectors need separate attention. Their host and actions can reach your own APIs, so an administrator has to know which service sits behind a custom connector and how it authenticates before classifying it.

Scope of a policy

A data policy can apply at the tenant level or to selected environments. A tenant-wide baseline sets a minimum boundary, and extra environment rules can apply stricter limits to production or to sensitive data. An environment policy cannot override the tenant policy, and where several policies touch the same combination, the most restrictive one wins.

Exceptions that are too broad make a policy hard to understand; rules that are too strict push makers toward unmanaged workarounds. Test a change in a controlled environment and look at which existing apps, flows and agents it touches. A policy change hits both design time and runtime, so a resource using a forbidden combination can no longer be saved or run, and it takes time for a change to be enforced everywhere.

A worked example

An HR team builds a flow that reads staff documents from SharePoint and sends notifications through Teams. Both connectors are in the business group. A maker later adds a personal cloud storage connector to share files more easily.

Because that connector is in non-business, the policy blocks the combination with SharePoint in the same flow. The maker then picks an approved business storage location or requests a reviewed exception. The policy does not stop someone with broad SharePoint rights from reading the wrong documents; that stays a matter of source permissions, data minimisation and process design.

DLP versus other security layers

Least privilege decides what data a user or a technical identity may reach in a source system. DLP decides which connectors can be combined within Power Platform. You need both. Data classification and sensitivity labels describe how sensitive information is and how to handle it, while endpoint and network controls limit channels outside Power Platform, and audit logs help you investigate afterwards.

An HTTP or custom connector can reach very different endpoints behind one connector name. Where it is supported, use connector endpoint filtering and connector action control to narrow what a connector can do, and limit the identity behind it. Do not trust the visible connector name alone.

Where connector policies are heading

Microsoft is adding finer connector controls beyond the three classic groups. Advanced connector policies take a default-deny stance: every connector is blocked unless it is explicitly allowed, configured per environment or through environment groups, and enforced while a maker is still authoring. They currently cover certified connectors, so classic data policies stay in use for custom and HTTP connectors. Check the current Microsoft documentation and note which policy mode you are using before you apply a new feature broadly.

Rolling out and managing a DLP policy

Start by taking stock of your environments, connectors and the data flows that matter. Then agree a baseline grouping with people from security, platform administration and the business processes involved. Roll changes out in stages: analyse the affected resources, warn the owners and test recovery.

Record every exception with a purpose, an owner, an end date and a compensating control. Monitor violations and runtime errors after each change, and revisit the policy when new connectors, agents or business services appear. A workable DLP policy is concrete enough to hold a data boundary and clear enough that makers know in advance which integrations are allowed.