Governance Playbook: DLP Policy Design for Power Platform

What You’ll Learn

This playbook provides ready-to-use DLP policy templates for Power Platform. You’ll learn how to classify connectors, design policies for different environment tiers, handle exceptions, and avoid the common mistakes that either block productivity or create security gaps.

Why DLP Policies Exist

Data Loss Prevention policies control which connectors can share data with each other within Power Platform. Without DLP policies:

• A maker could build a flow that sends Dataverse customer records to a personal Twitter account
• Sensitive HR data could be forwarded to an unapproved third-party service
• Financial data could be exported to personal OneDrive or Dropbox
• Internal APIs could be called from unapproved custom connectors

DLP policies are your primary technical control for preventing data leakage in the low-code environment.

How DLP Policies Work

Every DLP policy classifies connectors into three groups:

Group	Purpose	Data Sharing
Business	Approved corporate connectors	Can share data with each other
Non-business	Personal or unapproved connectors	Can only share data within this group
Blocked	Prohibited connectors	Cannot be used at all

The critical rule: connectors in different groups cannot share data. A flow cannot read from a Business connector (e.g., SharePoint) and write to a Non-business connector (e.g., personal Gmail).

Scope

DLP policies apply at either:

• Tenant level: Affects all environments (use sparingly)
• Environment level: Affects only selected environments (preferred)

When multiple policies apply to an environment, the most restrictive combination wins. This is important — adding a tenant-wide policy can unexpectedly break environment-specific policies.

Starter Templates

Template 1: SMB (< 50 makers)

A single policy that balances security with usability. Suitable for organisations without strict compliance requirements.

Business group (approved for corporate data):

SharePoint
OneDrive for Business
Office 365 Outlook
Office 365 Users
Microsoft Teams
Microsoft Dataverse
Microsoft Forms
Power Automate Management
Approvals
Planner
Excel Online
Word Online
OneNote
Azure AD

Non-business group (personal use only):

Twitter / X
Facebook
Gmail
Google Sheets
Google Drive
Dropbox
Slack
RSS
SMTP

Blocked:

(None — SMBs typically don't need to block connectors)

Apply to: All environments except developer sandboxes.

Template 2: Enterprise

Separate policies per environment tier, with stricter controls on production.

Development environments — permissive:

Business group: All Microsoft first-party connectors
Non-business group: All third-party connectors
Blocked: None

Production environments — restrictive:

Business group: Only connectors used by approved solutions
  SharePoint, Dataverse, Teams, Outlook, Approvals,
  OneDrive, Excel Online, Azure AD, Power Automate Management
Non-business group: Everything not explicitly approved
Blocked: Custom connectors without security review

Tenant-wide baseline (catch-all):

Business group: Core Microsoft connectors only
  SharePoint, OneDrive, Outlook, Teams, Dataverse
Non-business group: Everything else
Blocked: None (environment policies handle blocking)

Template 3: Regulated Industries (Finance, Healthcare, Government)

Maximum restriction with explicit approval for every connector.

All environments:

Business group: Explicitly approved connectors only
  Dataverse, SharePoint (specific sites only via connection),
  Office 365 Outlook, Azure AD, Approvals
Non-business group: All other connectors
Blocked:
  All social media connectors
  All personal email connectors (Gmail, SMTP)
  All personal storage (Dropbox, Google Drive, Box)
  HTTP connector (prevents arbitrary external calls)
  Custom connectors (require individual security review)

Additional controls:

• Enable HTTP connector only in specific environments with a separate DLP policy
• Custom connectors require documented security review before unblocking
• Regular quarterly review of the approved connector list

Connector Classification Guidelines

When deciding which group a connector belongs to, ask these questions:

Question	If Yes →	If No →
Does it access corporate data?	Business	Non-business
Is it a Microsoft first-party connector?	Likely Business	Evaluate case by case
Does it send data to an external service?	Evaluate security	Business (if internal)
Is it a custom connector?	Review before Business	N/A
Could it exfiltrate sensitive data?	Non-business or Blocked	Business

Special Cases

HTTP Connector: The most dangerous connector — it can call any URL. Block it in production unless specifically needed, and monitor its usage.

Custom Connectors: Default to blocked in production. Require a security review (API authentication, data handling, GDPR compliance) before allowing.

SQL Server Connector: Generally safe for Business group, but ensure connection strings point to approved servers only. Use connection references to prevent makers from connecting to arbitrary databases.

Azure Functions / Logic Apps: Business group if your organisation manages them, but only with approved function app URLs.

Exception Handling Process

No DLP policy survives contact with real business requirements without exceptions. Design a process for handling them:

Exception Request Flow

1. Maker submits request: Which connector, which environment, business justification
2. IT security review: Data classification, risk assessment, alternative solutions
3. COE approval: Business case validation, licensing impact
4. Implementation: Create environment-specific DLP policy override
5. Documentation: Record the exception with expiry date
6. Review: Revisit quarterly — is the exception still needed?

Common Exceptions

• Marketing team needs social media connectors: Create a marketing-specific environment with social connectors in the Business group, isolated from other business data
• Integration team needs HTTP connector: Create an integration environment with HTTP allowed, require all custom HTTP calls to go through a managed API gateway
• Finance needs a third-party ERP connector: Security review the connector, add to Business group in finance environments only

Monitoring and Enforcement

What to Monitor

• Policy violations: Power Platform admin centre shows blocked connector attempts
• New custom connectors: Alert when makers create custom connectors
• Cross-group data flow attempts: These indicate makers hitting DLP boundaries (may signal a policy that’s too restrictive)
• Environment creation: New environments may need DLP policy assignment

Using the COE Starter Kit

The Centre of Excellence Starter Kit includes DLP-specific monitoring:

• DLP Editor: Visual tool for managing DLP policies across environments
• Compliance dashboard: Shows which environments have which policies
• Connector inventory: Lists all connectors in use across the tenant
• Policy impact analysis: Preview the effect of a policy change before applying

Common Mistakes

1. One policy for everything: A single tenant-wide restrictive policy blocks makers from experimenting. Use environment-tier policies instead.

2. Blocking everything by default: If makers can’t build anything, they’ll find shadow IT alternatives. Start permissive in dev environments, restrictive in production.

3. Forgetting the HTTP connector: The HTTP connector bypasses all other connector controls — it can call any API. Block it in production unless explicitly needed.

4. Never reviewing policies: Connector classifications change. Microsoft adds new connectors. Business needs evolve. Review DLP policies quarterly.

5. Not testing policy changes: A DLP change can break existing flows instantly. Test changes in a non-production environment first, and communicate planned changes to makers.

6. Ignoring custom connectors: Custom connectors are the biggest security blind spot. They can call any external API with any authentication. Default to blocked and require security review.

Taking It Further

• Design your DLP policies interactively with the DLP Policy Planner
• Check connector classifications with the Connector Advisor
• Generate a complete governance policy document with the Governance Policy Generator
• Design your environment structure with the Environment Strategy Playbook