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. An inventory of existing apps, flows, makers and connections provides a practical starting point.
This article sets out the platform's actual default position, the constraint that shapes every governance design, what data policies genuinely control, and what to establish before business-critical adoption, and how to review workflows already in use.
Check the starting data-policy position
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 — broadly accessible unless deliberately governed; check the data policies, environment settings and identity controls actually in force. 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. Use the inventory to decide which existing workflows need review before adoption widens.
Classic data policies are scoped to environments and tenants
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. Where different groups need different classic connector policies, separate environments can provide that policy boundary. Identity, resource permissions and the actual connector remain separate parts of access design. This is why Microsoft describes establishing data policies as going hand in hand with environment strategy. Agree environment boundaries and connector policies together, while also reviewing identity and resource permissions.
Classic connector classification: three groups and different defaults
Microsoft's connector classification documentation describes three data groups: Business, Non-Business and Blocked. Under classic policies, Business and Non-Business connectors cannot be combined in the same app or flow; Blocked connectors cannot be used. 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. Microsoft documents connector endpoint filtering as a preview feature. It can allow or deny supported endpoints within a data policy, but support and limitations vary by connector and authentication method. Check the current supported list and test static, dynamic and environment-variable inputs; do not treat this preview as a complete production security boundary.
Microsoft’s advanced connector policies use an allowlist for certified connectors. Their scope and environment type matter: the ability to block connectors that classic policies cannot block is available in Managed Environments; those connectors remain non-blockable in non-managed environments. Custom and HTTP connectors are not currently supported by advanced connector policies.
Record whether the environment uses mixed mode or advanced-policy-only mode. In mixed mode, classic policies continue to be evaluated; in advanced-policy-only mode they are ignored for that scope. Do not assume a classic rule still protects a connection after changing modes. Microsoft also describes a workload-by-workload roll-out of design-time enforcement. Check the actual maker experience and runtime result before relying on a proposed policy design.
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.
Allowing a connector in a data group does not, by itself, restrict every destination or credential it can use. Supported endpoint-filtering rules can restrict some connections, subject to documented preview, dynamic-value and authentication limitations. Review those controls alongside identity, database and site permissions rather than assuming either that policies control every destination or that they control none.
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 connector and supported endpoint controls, including preview and runtime limitations.
- 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 may need only a limited set of policies and named owners, supported by proportionate access, connection, recovery and monitoring controls — 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 the organisation needs agreed workflow design, permissions, exception testing and handover, discuss SCSB’s Power Platform & AI Automation service. Microsoft 365 tenant and collaboration requirements can be considered separately under the Microsoft 365 implementation service.
Where the proposed workflow includes a custom agent, see Microsoft Copilot Studio Implementation for agent knowledge, permitted actions, testing and ownership. Agent-specific capabilities and policies must be checked for the selected experience.
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.