Microsoft Power Platform is designed so that people can build apps and flows quickly without waiting for IT. That is its value, and it is precisely why SCSB argues that governance has to be decided before adoption spreads rather than after. The organisations SCSB meets in difficulty are rarely the ones that adopted the platform deliberately; they are the ones that discovered they had adopted it.
This article sets out the platform's actual default position, the constraint that shapes every governance design, what data policies genuinely control, and what an organisation should settle before anyone builds anything.
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.
Set that beside a second documented fact, from Microsoft's guidance on securing the default environment: every employee in your organisation has access to the default Microsoft Power Platform environment.
Taken together, an organisation that has never configured Microsoft Power Platform still has a Microsoft Power Platform footprint — open to every employee, with no data guardrails applied. SCSB's first action on any governance engagement is therefore not to design a policy but to look: what apps, flows and makers already exist in the default environment. That inventory routinely surprises the people who commissioned the review, and it is the only honest basis for deciding what to do next.
Policies apply to environments, never to people
This constraint shapes every governance design and is commonly misunderstood.
Microsoft records that data policies can be scoped at the environment level and the tenant level, and states explicitly that policies can't be applied at the user level, only at the environment or tenant level. Two related rules follow: environment policies cannot override tenant-wide policies, and where multiple policies apply to one environment, the most restrictive applies to the combination of connectors.
So a requirement such as "let the finance team use this connector but not everyone else" is not a policy setting at all. It is an environment design decision. If different groups need different connector access, they need different environments. This is why Microsoft describes establishing data policies as going hand in hand with environment strategy, and why SCSB refuses to treat them as separate workstreams — a governance plan without an environment plan cannot be implemented as written.
Connector classification: three groups, and two different defaults
Microsoft's connector classification documentation describes three data groups: Business, Non-Business and Blocked. Connectors in different groups cannot be used together in the same app or flow, so classification determines what can be built. The group names carry no special meaning — Microsoft notes they are simply labels, and that the grouping is what signifies.
When a new policy is created, all connectors are placed in the Non-Business group by default. Blocking is not unlimited: all third-party connectors can be blocked, and all Microsoft-owned premium connectors except Microsoft Dataverse, but connectors driving core platform and productivity scenarios cannot be. Microsoft 365 Outlook, Microsoft Teams, SharePoint, Microsoft Power BI, OneDrive for Business, Approvals and Notifications are among those that can only be classified as Business or Non-Business.
Here is a nuance worth reading carefully, because Microsoft's guidance differs by scope and both statements are current. For the default data group applied to new connectors generally, Microsoft advises keeping Non-Business, and says so firmly — the reasoning being that connectors should be evaluated before business data is allowed to reach them. But for a policy applied specifically to the default environment, Microsoft recommends configuring Blocked as the default group, so that new connectors remain unusable until an administrator has reviewed them.
SCSB reads these as consistent rather than contradictory: the default environment is open to everyone, so it warrants the stricter posture. One caveat applies either way — where the default group is set to Blocked and Microsoft adds a connector that cannot be blocked, that connector is marked Non-Business automatically instead.
For finer control, connector action control can permit some actions on a connector while blocking others, such as allowing read but not modify, and can set whether newly added actions are allowed or blocked when a connector is updated. Connector endpoint filtering governs which specific endpoints a maker may connect to, but applies to six connectors only — HTTP, HTTP with Microsoft Entra ID, HTTP Webhook, SQL Server, Azure Blob Storage and SMTP — and only where the maker specifies the endpoint as a static value.
Microsoft has also introduced advanced connector policies, which invert the model: a strict allowlist in which connectors are blocked unless explicitly allowed, and which can restrict certified connectors including those that classic policies cannot block. Custom and HTTP connectors are not yet supported there, so classic data policies remain necessary for those.
What data policies do not do
SCSB flags this because it is the assumption that most often turns a governance framework into false assurance.
Microsoft states that data policies are connector aware, but that they don't control connections made using the connector — in Microsoft's words, data policies cannot determine whether a connector is being used to connect to a development, test or production environment.
A policy that permits the SQL Server connector permits it against any SQL Server the maker can authenticate to. The policy governs which connectors may be combined; it does not govern which database, site or mailbox is on the other end. Endpoint filtering closes part of that gap for the six connectors named above, and only for static endpoint values. Everything else remains a matter of what the maker's own credentials can reach — which means identity and access management is doing at least as much governance work as the data policy, and should be reviewed alongside it.
Fewer policies, not more
The 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 at design and runtime, and multiple 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.
Microsoft's recommendation is to manage policies centrally at tenant level, using environment policies only to classify custom connectors or handle exceptions. The symptom of ignoring this is a maker whose flow will not save, with no clear indication of which policy blocked it. SCSB treats simplicity here as an operability requirement rather than a shortcut.
Securing the default environment specifically
Because everyone can reach it, Microsoft treats the default environment as a distinct task. Its recommendations include:
- Communicate intent. Rename the default environment from TenantName (default) to something descriptive such as Personal Productivity Environment, and configure maker welcome content so people learn the intended use as they arrive.
- Assign administrator roles judiciously. Limit the powerful Power Platform administrator role to a few users, and consider whether environment admin or system administrator is more appropriate.
- Avoid standing access. Use just-in-time features of the identity provider and Privileged Identity Management in Microsoft Entra ID, with a documented emergency access process for break-glass situations.
- Understand the sharing default. Sharing with Everyone is disabled by default and Microsoft recommends keeping it that way. The Everyone group contains all users who have ever signed in to the tenant, including guests, and its membership can be neither edited nor viewed. Where broad sharing is wanted, a named security group is the safer instrument.
- 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. Customise the error a blocked maker sees so it carries an explanation and a route to ask, rather than an opaque failure.
Two further controls deserve attention. Managed environment features enable sharing limits, usage insights and restriction of access to allowed IP locations. And tenant isolation, which applies across all environments including the default, governs whether data can move to and from other tenants through connectors that use Microsoft Entra ID authentication.
PDPA 2010 and apps nobody commissioned
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, on a schedule nobody documented, under credentials belonging to someone who has since changed role.
Data policies are a technical control that supports those obligations. They do not by themselves establish compliance, and classification, retention and transfer decisions remain the organisation's own. Where a determination on current requirements is needed, the Personal Data Protection Commissioner is the authority to consult, alongside the organisation's legal or compliance advisers. SCSB's contribution is to describe accurately what the platform does and does not control, so that assessment rests on correct facts.
What to establish first
- Inventory what already exists — apps, flows and makers in the default environment.
- Decide the environment structure before the policy structure, because policies follow environments.
- Classify connectors deliberately, noting that everything starts as Non-Business.
- Keep the number of policies per environment minimal, and manage centrally at tenant level.
- Review identity and access alongside the policy, since policies do not govern which endpoint a connector reaches.
- Restrict standing administrative access and document an emergency access process.
- Confirm sharing limits and configure a governance message before adoption widens.
Not every organisation needs a governance framework proportionate to a large enterprise. A small organisation with a handful of makers and no personal data in scope may be served adequately by a single tenant-level policy, a renamed default environment and a named owner — and SCSB would recommend exactly that rather than a programme. The threshold at which more is warranted is usually personal or regulated data in maker-built apps, several business units building independently, or a platform footprint that has already grown without anyone deciding it should.
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. It is not security, legal or data-protection advice for a particular organisation, does not determine the appropriate governance model for any tenant, and does not establish compliance with the PDPA 2010 or any other requirement. Platform behaviour, defaults and available controls are set by Microsoft and change over time. Confirm the current position against Microsoft's published material.
Microsoft, Microsoft 365 Outlook, Microsoft Dataverse, Microsoft Entra ID, Microsoft Power BI, Microsoft Power Platform, Microsoft Teams and SharePoint are trademarks of the Microsoft group of companies.