Governance & DLP

Why governance matters

Power Platform is deliberately easy to build in — which means without guardrails, an estate sprawls into hundreds of apps and flows nobody can inventory, secure, or support. Governance is the set of proactive controls that let you say *yes* to makers while keeping data inside trust boundaries you can defend to an auditor.

It works in layers: data policies (DLP) decide which connectors can be combined; Managed Environments add premium control and visibility per environment; environment strategy and groups decide where makers build; the CoE Starter Kit (and increasingly the admin center itself) gives you inventory and compliance automation; and tenant-level controls draw the outer boundary. This guide covers each layer. For the naming and ALM discipline that sits alongside it, see Naming & ALM; for per-flow standards, see Best Practices.

Data policies (DLP)

Data loss prevention policies — now called data policies — are guardrails that enforce *which connectors can be used, and which can be used together*, in each environment. They classify every connector into one of three data groups; connectors in different groups can never be combined in the same app or flow, so business data can’t flow into a consumer connector and leave the organisation.

Rules that bite in practice

• Two groups never mix. The moment a resource uses one Business connector, it can’t use any Non-Business connector — and vice versa. This is the whole mechanism: data can’t cross the boundary you draw.
• New connectors default to Non-Business — keep it that way. One group must be the *default* for connectors Microsoft adds after your policy is created. Leave it as Non-Business and promote to Business deliberately, so a brand-new connector can’t silently inherit business-data access.
• HTTP connectors are classifiable — and child flows depend on them. HTTP, HTTP Webhook, and When an HTTP request is received can be grouped like any connector. Because child flows share an internal dependency on the HTTP connector, the group you choose for HTTP affects whether child flows run in that environment.
• Policies are connector-aware, not connection-aware. A data policy can’t tell whether the SQL connector points at a dev or prod server — it only governs the connector itself. Use environment separation and endpoint filtering for that.
• Never per-user. Policies apply at the environment or tenant level only; you can’t scope DLP to an individual.

Granular connector control

Classifying a whole connector is blunt. Four finer controls let you allow a connector but restrict *how* it’s used — and a newer model (ACP) flips the default to deny.

SQL Server
  Allow:  contoso-sql.database.windows.net
  Deny:   *

HTTP
  Allow:  https://api.contoso.com/*
  Deny:   *

Policy scope, precedence & automation

• Two scopes. Policies apply at the tenant level (all environments, all-except, or a chosen set) or the environment level. By default a tenant has *no* policies — nothing is restricted until you create one.
• Environment policies can’t override tenant policies. A tenant-wide policy is the floor; environment policies can only add restriction on top.
• Most restrictive wins. If several policies apply to one environment, the most restrictive combination of connector groupings is enforced.
• Tenant-wide default, relaxed per environment. Set a restrictive tenant baseline, then create environment policies that relax it only where a workload genuinely needs a connector — default-deny beats default-allow.

Beyond cloud flows

• Desktop flows (PAD). Data policies classify desktop-flow *modules* and individual actions as business / non-business / blocked. A flow that violates the policy is suspended and can’t run until the offending actions are removed or disabled.
• Copilot Studio agents. Data policies govern how agents connect to data and services inside and outside the organisation — configure them under the agent’s data-policy settings.

Manage policies as code

The Power Platform admin center is the primary UI, but the `Microsoft.PowerApps.Administration.PowerShell` module (and the data policy SDK / Power Platform API) lets you read, create, update, and remove policies for repeatable, source-controlled governance.

# Install once (run PowerShell as admin)
Install-Module -Name Microsoft.PowerApps.Administration.PowerShell -Force
Add-PowerAppsAccount

# List every DLP / data policy in the tenant
Get-DlpPolicy

# Inspect a single policy (connector groups, endpoints, scope)
Get-DlpPolicy -PolicyName <policy-guid>

# Create a new policy from a DLPPolicyDefinition object
#   (build $policy with its connector groups, then:)
New-DlpPolicy -NewPolicy $policy

Managed Environments

Managed Environments is a suite of premium governance capabilities you switch on per environment (any type). Once an environment is managed, it unlocks controls that simply don’t exist on a standard environment — the foundation most enterprise governance is built on.

Sharing limits & app access

Oversharing is the most common low-code data-exposure path. In Managed Environments you can cap how broadly makers share canvas apps, cloud flows, and agents.

Environment strategy

Environments are the primary security, DLP, and ALM boundary. A deliberate environment strategy decides where makers build and how independently teams ship — it’s the canvas every other control is applied to.

The naming, solution-layering, and ALM-pipeline side of this lives in Naming & ALM — environment *strategy* and environment *governance* are two halves of the same plan.

Environment groups & routing

Environment groups let you apply a single set of rules (sharing, solution-checker, AI features, deployment pipeline, IP firewall, and more) across many environments at once, instead of configuring each one by hand. Combined with default environment routing, governance travels with the environment automatically.

• Default environment routing sends new (or existing) makers into their *own* personal developer environment when they open Power Apps, Power Automate, or Copilot Studio — instead of cluttering the shared Default environment. Routed environments are Managed Environments by default.
• Route into a group. Point routing at an environment group so every newly provisioned developer environment is *born* governed — the group’s rules apply from the first minute, with no maker setup.
• Makers are admins, but can’t loosen the rules. A maker becomes the admin of their developer environment, yet settings governed by the group’s rules can only be changed by a Power Platform admin who edits the group.
• Lock the side doors. Disallow manual developer-environment creation in tenant settings, and scope routing to a security group, so makers can’t spin up an ungoverned environment outside the group.
• Multi-rule routing can direct different maker populations into different groups (by security group / portal), so region- or team-specific governance applies automatically.

Tenant & admin controls

The Power Platform admin center is mission control — environments, data policies, security, analytics, billing, and tenant settings all live there. These are the outer-boundary controls that apply across the whole tenant.

CoE Starter Kit

The Center of Excellence (CoE) Starter Kit is a reference solution that inventories every app, flow, and maker in your tenant and layers admin, compliance, and community tooling on top. It’s the canonical example of governing Power Platform *with* Power Platform.

• Inventory is the foundation. The Admin | Sync Template v3 flows populate the Dataverse tables every component builds on. You can scope inventory to a subset of environments via the *is All Environments Inventory* environment variable.
• Install in dependency order. Core → Governance/Audit → Nurture. The Creator Kit and an HTTP-with-Entra-ID connection are prerequisites for setup.
• It’s a starting point, not a security boundary. The kit facilitates monitoring and management; it doesn’t implement row-level security. Extend it carefully so you keep receiving Microsoft’s upgrades.

Auditing & monitoring

Governance you can’t evidence isn’t governance. Instrument the estate so access, changes, and failures are queryable after the fact.

• Dataverse auditing. Enable auditing at the environment level *and* on the specific tables you care about, to capture record create / update / delete and access. Mind the storage it consumes.
• Microsoft Purview activity logging. Power Platform and Power Automate activity flows into the Purview / Microsoft 365 audit log — the tenant-wide trail for who did what, including admin actions.
• Application Insights. In Managed Environments, export Dataverse and flow telemetry to Azure Monitor / Application Insights so traces, failures, and performance are queryable (KQL) across every app and flow — see the monitoring section of Best Practices.
• Analytics & alerts. Use the admin center analytics (and CoE dashboards) for trends, and a monitoring flow over the Power Automate Management connector to push failures to Teams / email / ITSM in real time.
• Tenant isolation & cross-tenant reports. Generate the cross-tenant connection report (one per tenant per day) to see which external tenants your connectors actually reach before you tighten isolation.

Governance rollout checklist

A pragmatic order to stand governance up — each step is cheap before sprawl and expensive after.