Consultancy Governance: Default Environment Cleanup and DLP

With budget for two additional environments, use Default, Dev, and Prod as the core, and make the default environment a restricted personal-productivity zone.

• Default: no business data, no production apps. Restrict who can create apps and flows through a security group. This contains shadow IT without deleting history.
• Dev: shared maker environment for finance, HR, and delivery. Use solution-aware development, connection references, and a test SharePoint site or Azure SQL database. Makers can experiment here.
• Prod: managed solutions only, deployed by the platform team. End users access apps and flows here.

DLP design: create a tenant-level policy scoped to all environments with three groups:

• Business: SharePoint, Outlook, Dataverse, Azure SQL, Approvals.
• Non-business: personal Gmail, consumer social connectors.
• Blocked: HTTP and the unapproved custom connector until security review.

Add a stricter policy scoped to the HR environment: HR data connectors only in Business, with no external sharing connectors. Finance gets a policy that blocks social media. Delivery’s client Azure SQL endpoint goes in Business, using the Azure SQL connector with a service principal or SQL authentication stored in a connection, not a custom HTTP connector. If the client API is truly HTTP-only, route it through Azure API Management and publish a reviewed custom connector, still blocked by default elsewhere.

Do not migrate all 240. Run an inventory and triage first using the Power Platform admin center and, if available, the CoE Starter Kit. Classify each resource by owner status, business criticality, data sensitivity, and usage.

• Ownerless or unused: disable or delete after a retention period and notify the former owner’s manager. Keep an export for audit if required.
• Business-critical: contact the owner, document the data sources, and move the app and its dependencies into a solution in Dev. Export and import as managed into Prod. Recreate connections as connection references.
• Personal productivity: leave in Default, but restrict the connector policy so it cannot touch HR or finance data.

Going forward:

1. No production deployments from Default or Dev without a managed solution.
2. Use a publisher per department, environment variables for site URLs and SQL endpoints, and connection references for every connector.
3. Require a solution checker run and a named owner before Prod import.
4. Use deployment pipelines or a documented export/import process; do not let makers edit Prod directly.
5. Review the custom connector through security, then add it to the Business group only in Delivery’s environment, not tenant-wide.

Treat the Gmail flow as a data-loss incident, not a cleanup task. First disable the flow, revoke the maker’s custom connector access, and remove the connector from the environment. Preserve the flow run history and connector definition as evidence. Notify the security team and the data owner; determine which invoice attachments left the tenant and whether the recipient mailbox is controlled. Block personal email connectors in DLP and add the custom connector to Blocked.

For the custom connector, require a security review of the endpoint, authentication method, data classification, and whether the API is approved for the data being sent. If Delivery genuinely needs the external API, publish it through Azure API Management with authentication, logging, and rate limits, then create a reviewed custom connector that is allowed only in Delivery’s environment. Do not simply re-enable the existing connector because a maker says it is needed.

Finally, communicate the change: explain why the flow was stopped, what the approved path is, and how to request an exception. A governance model that only blocks without an approved alternative will push makers back to personal email and shadow connectors.