Power Platform Governance in Regulated Industries

Summary: Power Platform governance in regulated industries means applying a layered control model across your Microsoft tenant: tiered DLP policies, risk-segmented environments, Managed Environments with Pipelines, and Entra ID access controls. Without these, citizen-developed apps produce audit gaps, data residency violations, and ungoverned shadow IT within weeks of a broad licence rollout.

Power Platform governance is the practice of controlling who can build, deploy, and connect applications and automated flows within a Microsoft Power Platform tenant, using policies, environment controls, and access management to prevent data loss and maintain regulatory compliance.

A DLP policy in Power Platform is a data loss prevention rule that classifies connectors into Business, Non-Business, and Blocked categories, preventing sensitive enterprise data from flowing to unsanctioned destinations such as personal email accounts or consumer file-storage services.

Key Takeaways

• Shadow IT is structurally inevitable in Power Platform without proactive governance — the same self-service capability that accelerates delivery also bypasses IT controls by design.
• DLP policies must be tiered, not uniform: a blanket block kills legitimate productivity; a connector classification strategy by environment risk level is the correct approach.
• Environment strategy is governance architecture — most regulated organisations need at minimum four environment tiers: default, sandbox, production, and a restricted regulated-data environment.
• The CoE Starter Kit is a starting point, not a finished governance framework — regulated sectors require substantial customisation before it is audit-ready.
• Microsoft Purview integration is non-negotiable for financial services and healthcare organisations subject to UK GDPR, FCA SYSC, or NHS Data Security Standards.

Introduction: The Governance Problem No One Plans For

Most Power Platform rollouts follow the same arc. An organisation purchases licences — often bundled into an existing Microsoft 365 agreement — and enables the platform broadly to accelerate digital delivery. Within three to six months, the number of apps, flows, and automated processes in the default environment has grown faster than anyone anticipated, and no one has a clear picture of what data those solutions are touching.

This is not a failure of the technology. It is a failure of governance planning, and it is almost universal.

For organisations in regulated sectors — financial services, insurance, pharmaceuticals, NHS trusts, utilities, and critical national infrastructure — the consequences of this failure are not just operational. They are regulatory. A Power Automate flow exporting customer transaction records to a personal OneDrive because a connector was left open is not a minor IT issue. It is a potential breach of FCA SYSC 8 obligations, UK GDPR Article 32, or PCI DSS requirement 7, depending on what data moved and where.

The Cloud Security Alliance's State of SaaS Security 2025 report found that 63% of organisations reported external data oversharing and 56% confirmed employees had uploaded sensitive data to unauthorised SaaS applications. Given that Power Automate can route data to a personal Gmail account in four clicks without a DLP policy in place, these figures are directionally consistent with what governance practitioners observe during Power Platform audits.

Why Does Power Platform Create a Higher Risk Profile in Regulated Industries?

The Self-Service Paradox

Power Platform's core value proposition — enabling business users to build solutions without writing code — is also its core governance challenge. In a traditional IT delivery model, every application goes through a development pipeline with security review, change management, and deployment controls. In Power Platform's default configuration, a business analyst with a Power Apps licence can build and publish a canvas app connected to SharePoint, Dataverse, and an external API in the same afternoon, with no IT involvement whatsoever.

For an unregulated business, this is mostly fine. For an NHS trust handling patient-identifiable data, a Tier 1 bank processing payment instructions, or an insurer holding sensitive health declarations, it is a structural control gap.

Without DLP policy controls, a citizen developer can build a flow that extracts data from a production Dataverse environment and pushes it to a personal Google Sheet. That flow will run reliably, silently, and indefinitely until someone notices.

What Regulators Actually Expect

UK financial services firms regulated by the FCA and PRA are subject to SYSC requirements that mandate robust controls over technology systems handling client data. The Senior Managers and Certification Regime (SMCR) creates named individual accountability for operational resilience failures, which explicitly includes third-party and technology risk.

For NHS organisations, the Data Security and Protection Toolkit (DSPT) requires organisations to demonstrate appropriate technical controls over personal data processing — including automation tools. A Power Automate flow that processes patient data is subject to the same governance obligations as any other system in scope.

Under UK GDPR, Article 25 requires that data protection controls are embedded into processing activities from the outset. The 2025/26 DSPT cycle — now aligned to the NCSC Cyber Assessment Framework — requires NHS Trusts, ICBs, and Operators of Essential Services to undergo independent audits of their identity, access, and data governance controls. For FCA-regulated firms, the operational resilience deadline of 31 March 2025 brought Power Platform-dependent business services into scope under PS21/3 for the first time.

What Is the Right Environment Strategy for a Regulated Power Platform Deployment?

Why the Default Environment Is a Liability

Every Power Platform tenant has a default environment, and every licensed user in the tenant has access to it automatically. The default environment has several characteristics that make it unsuitable for anything beyond personal productivity: all licensed users can create apps and flows without restriction; Dataverse for Teams creates unmanaged data containers invisible to central IT; there is no native approval workflow for publishing; and DLP policy conflicts default to the most permissive policy.

A Four-Tier Environment Architecture

Tier 1 — Default / Personal Productivity: personal automation, Microsoft 365 integration only. No external connectors. Restrictive DLP policy.

Tier 2 — Sandbox / Development: citizen development with oversight. Business connectors permitted. Non-production data only. Managed Environments enabled.

Tier 3 — Governed Production: business-critical applications with IT sign-off. Full ALM via Pipelines. No direct maker access — deployments through pipeline only.

Tier 4 — Regulated Data Environment: applications handling regulated data. Separate Dataverse instance with UK data residency. Managed Environments with all controls active. Customer Managed Keys. Network isolation via virtual network data gateway. Access limited to named individuals.

Managed Environments: What They Actually Control

Managed Environments provide maker welcome content, sharing limits, solution checker enforcement, usage insights, and weekly digests to environment admins. For regulated organisations, Managed Environments are not optional — they provide controls that simply do not exist otherwise.

DLP Policies: Moving Beyond the Binary Block

Why Blanket Restrictions Fail

The instinctive response to Power Platform governance risk is to lock everything down. This approach produces a predictable outcome: users work around the controls. Shadow IT migrates to personal tenants, trial tenants, or alternative tools. The regulated organisation ends up with less visibility, not more.

The correct approach is a connector classification strategy that permits legitimate productivity use whilst preventing data exfiltration and boundary violations.

The Connector Classification Framework

Power Platform DLP policies classify connectors into three buckets: Business, Non-Business, and Blocked. Business connectors can connect to each other. Non-Business connectors can connect to each other. The two groups cannot connect to each other within the same flow or app — this is the mechanism that prevents sensitive enterprise data from flowing to consumer services.

DLP Policy Tiers for Regulated Environments

The HTTP Connector Problem

The HTTP with Azure AD connector allows makers to call arbitrary endpoints authenticated via Azure Active Directory, effectively bypassing DLP connector classification. The HTTP Request trigger can expose Power Automate flows as publicly accessible API endpoints. Both should be blocked in all environments other than Governed Production and Regulated Data where explicit use cases have been reviewed.

How Do You Detect and Remediate Shadow IT in Power Platform?

Microsoft's own internal deployment acknowledged in September 2025 that its default Power Platform environment had accumulated tens of thousands of workflows and apps before governance controls were introduced. For most enterprise tenants, discovery audits routinely surface three to five times more citizen-developed solutions than IT teams expected. In one documented case from a regulated aerospace manufacturer, 47% of Power Apps had no identified owner after the original maker left the organisation.

Discovery Using the CoE Starter Kit

The Centre of Excellence (CoE) Starter Kit is Microsoft's governance toolkit for Power Platform, providing apps, flows, and dashboards that surface tenant-wide activity. Core components for shadow IT identification include the Power Platform Admin View, DLP Request Process, Compliance Detail Request, and App Quarantine.

What the CoE Starter Kit Does Not Do

• It is not a managed, supported Microsoft product — it is an open-source toolkit requiring internal maintenance.
• It does not provide real-time alerting; most inventory updates run on scheduled flows with multi-hour latency.
• It does not integrate natively with SIEM tools.
• The compliance questionnaire process relies on makers self-reporting — there is no automated data classification.
• It does not address guest user or external collaborator access controls.

Love Code Less, working across OutSystems, Mendix, Appian, Pega, Power Platform, Salesforce, and ServiceNow, observes this pattern in almost every first engagement — the controls framework built on top of the CoE is what determines audit readiness.

Microsoft Purview Integration: Making Power Platform Auditable

The Audit Log Gap

Power Platform audit events are written to the Microsoft Purview audit log and available for export via the Management Activity API. Audit logging in Power Platform is not comprehensive by default: flow run history is stored in Power Platform's own infrastructure, not Purview; custom connector usage is logged at the connector level but not the data payload level; Dataverse audit logging is separate and must be configured per-table, per-column.

Configuring Purview for Power Platform Governance

Purview integration covers Sensitivity Label Enforcement, Data Loss Prevention Policies (at the data content level, distinct from Power Platform DLP), and Compliance Manager Integration for mapping controls to assessments such as FCA, UK GDPR, and ISO 27001.

Forwarding Audit Logs to Microsoft Sentinel

Power Platform audit events can be ingested via the Microsoft Power Platform connector for Sentinel or via the Office 365 Management Activity API. This enables near-real-time alerting on DLP policy violations, anomaly detection on connector usage patterns, correlation with identity events from Entra ID, and retention beyond the native 90-day window — critical for organisations subject to FCA SYSC 9 retention requirements of up to seven years.

Identity and Access Controls: Entra ID as the Governance Layer

Role-Based Access Control

• Power Platform Administrator: tenant-wide admin rights. Maximum two to three named individuals, governed by PIM with just-in-time activation.
• Environment Administrator: full control over a specific environment. Named individual with documented accountability.
• Environment Maker: can create resources in an environment. The most broadly assigned role and the one requiring the most careful scoping.
• Basic User: can run apps shared with them but cannot create resources. The correct assignment for end users in Governed Production and Regulated Data environments.
• Dataverse Roles: separate from the above; control access to Dataverse tables and columns.

Conditional Access and Power Platform

Regulated organisations should enforce device compliance (only Intune-enrolled devices can access Regulated Data environments), unconditional MFA for all Power Platform admin roles, location restrictions on environments processing regulated data, and continuous access evaluation for high-privilege sessions. External makers should not exist in Governed Production or Regulated Data environments.

Application Lifecycle Management in Regulated Environments

Why ALM Matters for Compliance

Power Platform's default model has no equivalent of traditional change management controls. A maker with Environment Maker rights in a production environment can modify a flow and publish the change immediately, with no review and no approval. For regulated organisations, this is unacceptable. The FCA's operational resilience requirements under PS21/3 require firms to map and protect important business services from disruption — which includes the automation pipelines that underpin those services.

Implementing ALM with Power Platform Pipelines

Microsoft Power Platform Pipelines (available with Managed Environments) provides a structured deployment mechanism: solutions are developed in Sandbox; deployment to Governed Production requires pipeline execution with approval from named individuals; deployment to the Regulated Data environment requires a secondary approval gate; all deployments are logged with deploying identity, approving identity, timestamp, and solution version. Pipelines can be extended using Azure DevOps or GitHub Actions.

Source Control for Power Platform Solutions

Power Platform solutions should be exported and committed to source control (Azure DevOps or GitHub) as part of the ALM process. This provides version history, rollback capability, code review for custom connectors and Power Fx expressions, and audit evidence for regulatory inspections — the ability to show exactly what version of a flow was running on a specific date.

Building a Governance Framework That Survives Contact with Reality

The Minimum Viable Governance Stack

1. Environment audit and remediation — document every environment, its purpose, its makers, and its deployed solutions. Quarantine or delete environments with no identified owner.
2. DLP policy implementation — at minimum, a tenant-wide DLP policy that blocks consumer file storage and consumer communication connectors.
3. Default environment lockdown — apply a restrictive DLP policy and disable the ability of non-admin users to create new environments.
4. Managed Environments for production — enable Managed Environments for all environments handling anything other than personal productivity.
5. Purview audit log review — establish a regular monthly review of Power Platform audit events with named responsibility.
6. Maker governance programme — a lightweight approval process for new makers in non-default environments.

By 2025, Gartner expected 75% of employees to create shadow IT solutions, up from 50% in 2020. In a Power Platform tenant without DLP controls, that figure represents potential policy violations at enterprise scale.

Common Mistakes and How to Avoid Them

Mistake 1: Treating DLP policy as a one-time configuration. Assign ownership and review quarterly.

Mistake 2: Assuming Managed Environments solve the problem. They operate at the environment level and do not compensate for an inadequate environment strategy.

Mistake 3: Ignoring Power Pages and Copilot Studio. These have distinct governance requirements that require separate assessment.

Mistake 4: Conflating Power Platform DLP with Microsoft Purview DLP. Both are needed in regulated environments; neither is a substitute for the other.

Mistake 5: No maker offboarding process. Flows owned by departed employees continue to run with the former employee's credentials and permissions.

Frequently Asked Questions

What is the difference between Power Platform DLP policies and Microsoft Purview DLP policies?

Power Platform DLP policies control which connectors can interact with each other within apps and flows, operating at the connector classification level. Microsoft Purview DLP policies operate at the data content level, scanning for sensitive information types within documents and communications. Regulated organisations typically need both.

Can we use the CoE Starter Kit as evidence of governance for an FCA or DSPT audit?

The CoE Starter Kit provides visibility and inventory capabilities that support a governance programme, but it is not itself a governance control. Auditors will look for DLP policies, access controls, ALM processes, and audit log review evidence.

How do we handle Power Platform solutions built by third-party vendors or system integrators?

Vendor-built solutions should be deployed to governed environments under the same ALM controls as internally developed solutions. Vendor makers should be granted Environment Maker rights only in Sandbox environments during development and should have access removed post-deployment.

What licensing is required to implement Managed Environments?

Managed Environments require either Power Apps Premium, Power Automate Premium, or a standalone Managed Environments licence for each user in the environment.

How should we handle Power Platform in a hybrid cloud environment where some data cannot leave on-premises infrastructure?

The on-premises data gateway allows Power Platform to connect to on-premises data sources without exposing them to the internet. For strict data residency requirements, the virtual network data gateway provides a network-isolated connection path.