Data Loss Prevention policies are the governance conversation most teams have after something goes wrong. A connector nobody was tracking just moved sensitive data to a personal account. A flow exfiltrated HR records. The HTTP connector, quietly available, made everything reachable from everywhere.
The best time to design DLP policies is before any of that happens. The second best time is now.
How DLP works in Power Platform
DLP policies in Power Platform work by classifying every connector into one of three buckets:
- Business: connectors that can talk to each other within the same policy
- Non-Business: connectors that can talk to each other, but not to Business connectors
- Blocked: connectors that cannot be used at all in environments covered by this policy
The critical insight: apps and flows can only connect Business connectors to Business connectors, and Non-Business to Non-Business. The boundary between them is your data protection boundary.
The layered policy approach
I recommend designing DLP as two layers:
Layer 1: Tenant-wide baseline policy
This policy applies to every environment in the tenant unless explicitly excluded. It establishes your minimum security posture. Typical design:
- Microsoft 365 connectors (SharePoint, Teams, Outlook, Dataverse) → Business
- Consumer apps (Twitter, Gmail, Dropbox, personal OneDrive) → Non-Business or Blocked
- HTTP connector → Blocked (enable per-environment by exclusion if needed)
- Premium connectors not approved for general use → Blocked
Layer 2: Environment-specific policies
Stricter policies apply to your production environments. More permissive policies (with explicit approval) apply to dev environments where makers need to test integrations.
The layered approach lets you lock down production without strangling innovation in development. Teams can experiment in Dev under a less restrictive policy, then the strict production policy catches anything that should not go live.
The connectors that always cause problems
From experience across multiple enterprise tenants, these are the connectors that trigger the most policy conversations:
- HTTP with Azure AD: powerful, legitimate, also easily misused. Restrict to specific environments.
- SQL Server: often needed, but which databases? Be explicit about what SQL Server access means in your org.
- SharePoint: almost always Business, but watch for flows that move data between SharePoint sites that should stay separate.
- Custom connectors: each one needs a review. Build a lightweight approval process.
- AI Builder and Copilot Studio: newer connectors that touch data in unexpected ways. Define policy before makers start using them at scale.
What to document
Every DLP policy decision should be documented in a policy register:
- Policy name and scope (which environments)
- Why each connector classification was chosen
- Who approved the policy design
- Review date (I recommend quarterly)
- Exception process — how can teams request a connector to be reclassified?
The documentation is not bureaucracy. It is the thing that lets you onboard a new admin six months from now without starting from scratch.
The mistake most tenants make
They create one DLP policy for everything and call it done. No layering, no per-environment variation, no review cadence.
Three months later a new connector appears that nobody thought about. It defaults to the wrong classification. A maker uses it. Something moves that should not have moved.
DLP policy design is not a one-time event. Set a quarterly calendar reminder to review your connector classifications and add any new connectors that have been released since your last review.
Microsoft adds new connectors regularly. Your policy needs to grow with the platform.
