Data Loss Prevention Policies in Power Platform: A Practical Setup Guide

A Power Platform tenant without clear Data Loss Prevention policy is one accidental flow away from moving customer data into the wrong system. The harder problem is not creating a policy; it is designing one that protects data without breaking every useful automation the business already depends on. Treat DLP as an engineering control, not an admin checkbox.

Connector groups define the real boundary

Start with connector intent. Every connector in a DLP policy sits in one of three groups: Business, Non-Business, or Blocked. The platform rule is simple and unforgiving: a single app or flow cannot move data between Business and Non-Business connectors. Blocked connectors cannot be used at all where the policy applies.

That means classification is not about whether a connector is popular. It is about whether data from that connector is allowed to combine with data from another group. Dataverse, SQL Server, SharePoint, Office 365 Outlook, and Teams often belong in Business for internal process apps. Social, consumer storage, public messaging, and generic HTTP usually land in Non-Business or Blocked unless there is a reviewed use case.

Connector group	Typical use	Runtime impact	Senior engineer check
Business	Approved systems of record and internal collaboration	Can exchange data with other Business connectors	Confirm data owners agree
Non-Business	Productivity, public, or lower trust services	Cannot exchange data with Business connectors	Validate real business need
Blocked	Disallowed or high risk connectors	New and existing usage is prevented	Document the exception path

Classify by data movement, not brand. SharePoint can be low risk for a team task list and high risk for regulated records. Outlook can be required for approval notifications and dangerous for broad exports. DLP does not understand your intent; it only enforces group boundaries. Your classification model must be explicit enough that makers understand the why.

Scope determines the blast radius

Use tenant policies for baseline guardrails. A tenant-level policy applies broadly and is the right place for hard rules: block consumer connectors, restrict generic HTTP patterns, and keep unknown custom connectors out of production environments. The default policy should be conservative because it catches new environments and teams you have not reviewed yet.

Use environment policies for workload nuance. Environment-level policies let you approve a narrower connector mix for a specific workload. A finance environment might allow Dataverse, SQL Server, Outlook, Approvals, and a vetted ERP connector. A marketing sandbox might allow a different set but still block customer data exports.

This is the operating model I recommend for most enterprises:

Default tenant policy
- Business: Microsoft 365 core, Dataverse, approved enterprise data stores
- Non-Business: low risk maker productivity connectors
- Blocked: consumer storage, public social, generic web scraping, unreviewed AI endpoints

Production environment policy
- Business: only connectors required by the approved solution
- Non-Business: empty or tightly justified
- Blocked: everything not explicitly allowed

Prefer multiple policies over one overloaded policy. A single mega policy becomes unreadable. Separate baseline, production, departmental, and exception policies make review easier and reduce accidental changes.

Custom connectors need a stricter lane

Assume custom connectors are data exfiltration capable until reviewed. A custom connector can wrap an internal API, a partner service, or a developer endpoint. That flexibility is useful, but it bypasses the comfort of known connector behavior.

Create a registration process with owner, API purpose, authentication type, data classification, endpoint list, and expiration date. If the connector sends regulated or customer data outside the Microsoft cloud boundary, it needs architecture review, not just maker approval.

A lightweight inventory record can be enough:

{
  "connectorName": "Contoso ERP Orders",
  "owner": "Finance Platform Team",
  "environment": "Finance Production",
  "classification": "Business",
  "authType": "OAuth2",
  "approvedHosts": ["api.erp.contoso.com"],
  "reviewAfter": "2026-11-30"
}

Do not classify all custom connectors as Business. That is the fastest way to defeat your own DLP model. Classify approved enterprise API connectors as Business only after review. Put experimental connectors in Non-Business or Blocked by default.

Endpoint filtering closes the generic connector gap

Generic connectors need endpoint rules. Connectors such as HTTP, HTTP with Microsoft Entra ID, SQL, and some storage connectors can reach many destinations. Group classification alone may not be enough because the same connector can call a trusted internal API or an arbitrary external endpoint.

Endpoint filtering lets admins restrict connector usage to approved hosts or paths where supported. Use it when you cannot block a connector entirely but must prevent open-ended access. The practical pattern is to allow exact enterprise hosts, deny wildcard behavior, and review every exception as an integration request.

# Requires Microsoft Power Platform admin modules and an authenticated admin session.
Install-Module Microsoft.PowerApps.Administration.PowerShell -Scope CurrentUser -Force
Add-PowerAppsAccount

$environmentName = "Default-00000000-0000-0000-0000-000000000000"
Get-AdminDlpPolicy | Select-Object DisplayName, PolicyName, CreatedTime
Get-AdminPowerAppEnvironment -EnvironmentName $environmentName

Automate reporting before enforcing. Pull policy inventory, connector usage, and flow ownership into a review dashboard. DLP surprises are avoidable when you know which flows use which connectors before you move a connector to Blocked.

A default policy should be boring and durable

Your default policy is not where innovation happens. It is the safety net for new environments, experiments, and abandoned prototypes. Keep it strict enough to prevent obvious leakage but not so strict that makers immediately ask for personal environments outside governance.

A strong default policy usually blocks consumer file storage, personal email, public social media, and unrestricted HTTP. It allows core Microsoft 365 connectors that most makers need, but it does not automatically bless every connector Microsoft ships. New connectors should start in the least privileged usable group until reviewed.

Make exceptions expire. If a team needs a connector temporarily for migration, set a review date. Permanent exceptions without owners become governance debt.

Diagnose DLP breakage like a production incident

When a flow stops after a DLP change, do not guess. First identify the policy scope. Then inspect the connectors in the flow, their groups, and whether any action violates a boundary. Most failures are caused by a connector moved between Business and Non-Business, a connector newly blocked, or a child flow that uses a different connector mix than the parent.

Use this checklist:

1. Confirm the environment and every DLP policy that applies.
2. List all connectors used by the app, flow, child flows, and custom connectors.
3. Compare connector groups in the effective policy.
4. Check whether Business and Non-Business connectors appear in the same flow or app.
5. Review endpoint rules for generic connectors.
6. Re-save the flow after policy correction and test with the original trigger data.

Communicate the fix in policy language. Do not tell a maker the platform is broken. Tell them the flow combines Outlook in Business with a connector in Non-Business, or that HTTP is blocked for that environment. Clear diagnosis turns DLP from mysterious governance into predictable engineering.

DLP works when it is opinionated, documented, and reviewed like code. Classify connectors by data movement, scope policies by workload, treat custom connectors carefully, and diagnose failures from the effective policy. That is how you keep makers productive without turning the tenant into an unmanaged integration bus.