Securing Your Power Platform Tenancy: A DLP Policy Playbook

Data Loss Prevention (DLP) policies are your first line of defense against unintentional data exposure in the Power Platform. As organizations embrace citizen development, unchecked connector access can lead to sensitive information flowing to unauthorized external services. This article outlines eight actionable tactics to strengthen your DLP posture, using the fictitious company Contoso Ltd. and its multi-environment architecture as a running example.

Contoso runs four environments: Production, Development, QA, and a Sandbox for experiments. Each environment requires a tailored DLP policy that balances maker agility with security. The default environment is treated as a high‑risk zone because every licensed user can create resources there. Contoso also applies a company‑wide baseline policy that blocks clearly dangerous connectors.

The following practices will help you implement a similar governance model.

1. Lock Down the Default Environment First

The default environment is the most exposed area in any tenant. All users with a Power Apps or Power Automate license receive the Environment Maker role there by default, and many have received no formal training. They can create apps and flows — but you can restrict the connectors they are allowed to use.

Contoso’s approach:

• Move all non‑blockable connectors (e.g., Microsoft 365 Users, SharePoint) into the Business group.
• Move all blockable connectors (e.g., third‑party services like Google Drive, Twitter) into the Blocked group.
• Set the default group for this policy to Blocked. Any new connector that Microsoft adds will automatically be blocked unless it is non‑blockable.
• Scope the policy to only the default environment.

This ensures that makers inside the default environment must request special permission before they can use any external data service.

2. Assign a Dedicated DLP Policy to Every Non‑Default Environment

No environment should be left without a DLP policy. As soon as an environment is provisioned, a corresponding policy must be in place.

Contoso’s process:

1. For a new Development environment, start by placing all non‑blockable connectors into the Business group.
2. Collaborate with the environment owner to identify additional connectors needed for the project (e.g., SQL Server, Salesforce, Adobe Sign). Move those into the Business group.
3. Relegate every other blockable connector to the Blocked group.
4. Set the default group to Blocked.

Repeating this for every environment gives each team a clear perimeter while avoiding a one‑size‑fits‑all restriction that could hinder legitimate work.

3. Apply Granular Control with Connector Endpoints and Actions

Moving a connector to the Business group does not have to mean unlimited access. Each blockable connector can be fine‑tuned by:

• Endpoint restriction: allow only specific URLs or IP ranges.
• Action restriction: permit only read‑only operations, for example.

Contoso’s SQL Server connector in the QA environment is configured to allow connections only to the QA server endpoint. The team also grants SELECT permission through connector actions, preventing accidental inserts or deletes during testing.

This level of control keeps datasets safe without completely disabling a connector.

4. Align a Single Policy Across DEV, QA, and Production

Applications move from development to testing to production. If each stage has a different DLP policy, behavioral discrepancies can appear and cause runtime failures.

Contoso creates one shared policy that includes the Development, QA, and Production environments. All three environments are added to the same policy so they inherit identical connector groups. This avoids surprise blocks when a flow is promoted from test to production.

The policy definition is maintained in a version‑controlled document, and any change is first reviewed against the application’s current resource usage.

5. Analyze Impact Before Modifying an Existing Policy

Changing a DLP policy after apps and flows have been built can crash them. The Power Platform CoE Starter Kit includes the DLP Editor app, which can simulate a policy change and list affected resources.

Contoso’s governance team runs the impact analysis every time they need to adjust a policy for an environment that already contains running solutions. They export the impact report, identify the owners of affected apps or flows, and contact them with a suggested resolution (usually a connector change or a request to move the resource to a different environment).

6. Deploy a Tenant‑Wide Baseline Policy

A tenant‑level DLP policy acts as a safety net. It applies to every environment and cannot be overridden by environment‑specific policies. When two policies conflict, the most restrictive setting wins.

Contoso uses a tenant‑wide baseline with the following settings:

• All connectors are initially placed in the Business group.
• A small set of connectors deemed “high risk” (e.g., anonymous HTTP services, known data‑leak vectors) are manually moved to Blocked.
• The default group is set to Business so that any future connector lands in the allowed category by default.

The tenant policy is deliberately not overly restrictive. Blocking too many connectors at the tenant level forces environment owners to fight against the baseline and increases administrative overhead. Instead, Contoso blocks only proven threats.

When scoping the policy, choose Add all environments so that no environment is left out of the baseline.

7. Customize the Governance Error Message

When a maker saves an app or flow that violates a DLP policy, they see a generic error message. You can replace that message with a custom one that includes contact information and a link to a request form.

Use the New-PowerAppDlpErrorSettings PowerShell cmdlet to set the governance message. Contoso configures it with an email address and a URL to a Microsoft Form that collects DLP change requests.

New-PowerAppDlpErrorSettings -TenantId 'TenantId' -ErrorSettings @{
ErrorMessageDetails = @{
  enabled = $true
  url = "https://contoso.sharepoint.com/sites/DLPRequests"
}
ContactDetails = @{
  enabled = $true
  email = "dlp-team@contoso.com"
}
}

After running the script, makers who trigger a DLP violation see your custom message and know exactly how to proceed.

8. Avoid Using Resource Exemptions

Power Platform DLP policies include PowerShell cmdlets that allow you to exempt specific apps or flows from a policy. Contoso’s rule: never use them.

Exemptions create inconsistencies, complicate future audits, and weaken the overall governance model. If a resource genuinely needs a different set of connectors, the right action is to move it to another environment that has a policy designed for those needs.

Final Recommendation

A well‑structured DLP strategy reduces risk without stifling innovation. Start by locking down the default environment, then systematically assign policies to every environment. Use granular configuration (endpoints and actions) to permit legitimate use cases, and always check the impact of changes. A tenant‑wide baseline and custom error messages complete the safety net. Finally, resist the temptation to grant exemptions — they only mask underlying environmental design gaps.

By following these eight practices, you can give your makers the freedom they need while keeping your organization’s data secure.

References

• Original article by Matthew Devaney: 8 Power Platform DLP Policy Best Practices
• Microsoft Learn: Data Loss Prevention policies
• Microsoft Learn: CoE Starter Kit – DLP Editor
• Microsoft Learn: Governance error message PowerShell commands