Power Platform Governance: CoE, DLP & Environments [2026]

Power Platform governance rests on four controls: an environment strategy that separates production from experimentation, DLP policies that isolate connectors into groups which cannot be mixed in one flow, the CoE Starter Kit for inventory and ownership, and ALM so apps exist in source control rather than only in production. All four are available at no additional licence cost, and most estates run none of them.

The actual risk

The failure people imagine is a badly built app. The failure that happens is a flow, built with good intentions, that reads from Dataverse and writes to a personal OneDrive \u2014 because no connector policy said it could not, and nobody was watching.

That is not a hypothetical shape. It is what an ungoverned low-code estate makes easy, and the person who builds it is usually trying to solve a real problem nobody gave them a supported way to solve.

1. Environment strategy

Every ungoverned tenant has the same configuration: one default environment where everyone can build, with production data in it. The default environment is created for you, every licensed user can create in it, and it cannot be deleted.

The single highest-value action in most tenants is restricting environment creation to an approved process, then treating the default environment as explicitly untrusted instead of pretending it does not exist.

2. DLP: how connector isolation works

A DLP policy sorts every connector into one of three groups: business, non-business, or blocked. The rule is simple and strong \u2014 connectors from different groups cannot be used in the same flow or app.

That single constraint is what stops the Dataverse-to-personal-storage flow from being buildable at all. It does not depend on anyone noticing, reviewing or approving, which is what makes it a control rather than a policy document.

Place Dataverse, SharePoint and SQL in business. Place personal storage, social and consumer connectors in non-business. Block what has no legitimate use. The groups do the enforcement.

3. The CoE Starter Kit

Microsoft publishes a solution that inventories your tenant: every app, flow, bot and custom connector, who made it, when it was last used, and whether its owner still works there.

Orphaned assets are the finding that justifies the exercise. Every mature tenant has flows running in production whose author left, which nobody can modify and nobody dares disable. You cannot govern an estate you cannot enumerate, and this is how you enumerate it.

4. ALM, and why it is the real dividing line

An app that exists only in production, with no solution packaging and no source control, cannot be reviewed, rolled back or handed over. It is a single point of failure whose failure mode is a resignation letter.

1. Everything lives in a managed solution, not as loose components.
2. Solutions move dev to test to production through a pipeline, never by hand.
3. Source control holds the unpacked solution, so changes are diffable.
4. Every production app has a named owner who is not the person who built it.

Where to start

In order, because each step makes the next one possible: deploy the CoE Starter Kit to find out what you have, write a DLP policy that isolates connectors, restrict environment creation, then move production apps into managed solutions with a pipeline.

The first two can be done in a week and remove most of the exfiltration surface. The second two take longer and are what turn a collection of apps into a platform.