Power Platform Governance: What Applies Before Anyone Builds Anything
By default, no data policies are implemented in a Power Platform tenant, and every employee has access to the default environment. Governance is therefore something an organisation adds deliberately — and policies apply at environment or tenant level, never per user.
Power Platform is designed so that people can build apps and flows quickly without waiting for IT. That is its value — and the reason governance needs to be decided before adoption spreads, not after.
The starting position is no governance at all
Microsoft's data policy strategy guidance states the default plainly: "By default, no data policies are implemented in the tenant."
Combined with a second documented fact — "Every employee in your organization has access to the default Power Platform environment" — the implication is that an organisation which has never configured Power Platform still has a Power Platform footprint, open to everyone, with no data guardrails.
That is the actual starting point for most organisations, and it is worth confirming before assuming there is nothing to govern.
Policies apply to environments, never to people
This constraint shapes every governance design, and it is commonly misunderstood.
Microsoft records that data policies "can be scoped at the environment level and tenant level" and, explicitly, that "Policies can't be applied at the user level, only at the environment or tenant level."
So "let the finance team use this connector but not everyone else" is not a policy setting — it is an environment design decision. If different groups need different connector access, they need different environments. Governance and environment strategy are the same exercise, which is why Microsoft describes establishing data policies as going hand in hand with environment strategy.
New connectors start in the Non-Business group
Microsoft's connector classification documentation notes that when a new policy is created, all connectors are placed in the Non-Business group by default.
Because connectors in different groups cannot be combined in the same app or flow, the classification decision determines what can be built. An organisation that classifies without a deliberate view will either block legitimate work or permit data paths it did not intend — for example, business data reaching a personal storage or social connector.
Fewer policies, not more
An instinct to add a policy per team produces a specific documented problem. Microsoft advises creating a minimal number of policies per environment, noting there is no strict hierarchy between tenant and environment policies: all applicable policies are evaluated together, and "Multiple data policies applied to one environment will fragment your connector space in complicated ways and might make it difficult to understand issues your makers are facing."
The practical symptom is a maker whose flow will not save, with no clear explanation of which policy blocked it. Simplicity here is an operability decision, not laziness.
Securing the default environment specifically
Because everyone has access to it, Microsoft's guidance on securing the default environment treats it as a distinct task. Its recommendations include:
- Assign administrator roles judiciously — limit the powerful Power Platform admin role to a few users, and consider whether environment admin or system administrator would be more appropriate.
- Avoid standing access — use just-in-time features of the identity provider, with an emergency access process for break-glass situations.
- Prevent oversharing — the ease of sharing apps and flows can itself become the risk; sharing limits can be configured, including disabling sharing with Everyone.
- Limit custom connectors — these integrate home-grown services and are intended for technical users; URL-pattern rules can restrict them, and connections should use HTTPS.
- Set a governance message — so a blocked maker sees an explanation and a route to ask, rather than an opaque failure.
Malaysian context
Where apps or flows handle personal data, the organisation's obligations under the Personal Data Protection Act 2010 apply to that processing regardless of who built the app. A flow created by a well-meaning colleague can move personal data to a location nobody assessed. Data policies are a technical control supporting those obligations; they do not by themselves establish compliance, and classification and retention decisions remain the organisation's own, confirmed with its legal or compliance advisers.
What to establish first
- Confirm what already exists — apps, flows and makers in the default environment.
- Decide the environment structure before the policy structure; policies follow environments.
- Classify connectors deliberately, noting that everything starts as Non-Business.
- Keep the number of policies per environment minimal.
- Restrict standing administrative access and define an emergency access process.
- Configure sharing limits and a governance message before adoption widens.
Where automation design is the question rather than governance, that is addressed under SCSB's Microsoft 365 implementation service.
General-information limitation
This article is general information about Microsoft Power Platform governance concepts, not security, legal or data-protection advice for a particular organisation. It does not determine the appropriate governance model for any tenant, nor establish compliance with the PDPA 2010 or any other requirement. Platform behaviour and defaults are set by Microsoft and change over time. Confirm the current position against Microsoft's own published material.
To discuss your requirements, contact SCSB.
Microsoft product references source checked: 25 July 2026.
Microsoft, Microsoft Power Platform, Power Apps, Power Automate, Microsoft Copilot Studio and Microsoft Dataverse are trademarks of the Microsoft group of companies.