Define and agree on the data storage solution that will be used as the foundation for the Power Platform Audit & Monitoring platform. The selected solution should support centralized storage, historical data retention, structured data transformation, and future Power BI reporting. The agreed solution is Azure SQL Database, using a Bronze / Silver / Gold data architecture to separate raw collected data, normalized data, and reporting-ready datasets.

Create a data collection process to retrieve the Copilot Studio credits capacity allocated to each Power Platform environment. The process will provide centralized visibility of how Copilot Studio credits are distributed across the tenant and store the resulting data in the storage solution defined in T-01. The collected allocation data will later be correlated with the consumption data from T-08 to provide allocated versus consumed capacity reporting. Resource Group: rg-gso-powerplatform-app-analytics App Registration: EuAh-S06-Prd-Scau-All-01 Secret Name: GSO-PP-Governance Automation Account: GSO-PP-Automation-Account Runbook: TBD

Create an ETL process to retrieve the complete Copilot Studio inventory across all Power Platform environments identified in T-02. The process will collect all available Copilot Studio agents and their relevant metadata and store the resulting data in the storage solution defined in T-01. The Copilot Studio inventory will later be correlated with environments, users, DLP policies, connectors and other governance datasets. Resource Group: rg-gso-powerplatform-app-analytics App Registration: EuAh-S06-Prd-Scau-All-01 Secret Name: GSO-PP-Governance Automation Account: GSO-PP-Automation-Account Runbook: TBD

Create a data collection process to provide centralized visibility of Power Apps licenses available and assigned across the tenant. The collected data will be used to monitor license allocation, identify assigned and available licenses, correlate licenses with users, and support Power BI reporting. The resulting data will be stored in the storage solution defined in T-01. Resource Group: rg-gso-powerplatform-app-analytics App Registration: EuAh-S06-Prd-Scau-All-01 Secret Name: GSO-PP-Governance Automation Account: GSO-PP-Automation-Account Runbook: TBD

Create an ETL process to retrieve the complete Power Apps inventory across all Power Platform environments identified in T-02. The process will collect both Canvas Apps and Model-driven Apps and store the resulting data in the storage solution defined in T-01. The application inventory will later be correlated with environments, users, DLP policies, connectors and other governance datasets. Resource Group: rg-gso-powerplatform-app-analytics App Registration: EuAh-S06-Prd-Scau-All-01 Secret Name: GSO-PP-Governance Automation Account: GSO-PP-Automation-Account Runbook: TBD

Create an ETL process to retrieve the complete workflow inventory across all Power Platform environments identified in T-02. The scope is not limited to Power Automate cloud flows. The dataset should include all available workflow and process types present in the environments, allowing them to be identified and analyzed separately. The workflow inventory will later be correlated with environments, users, applications, connectors and other governance datasets. Resource Group: rg-gso-powerplatform-app-analytics App Registration: EuAh-S06-Prd-Scau-All-01 Secret Name: GSO-PP-Governance Automation Account: GSO-PP-Automation-Account Runbook: TBD

Create a data collection process to monitor Copilot Studio credits consumption across the Power Platform tenant. The process will collect available credit consumption and allocation information and store the resulting data in the storage solution defined in T-01. The collected data will be used to provide historical usage visibility, identify consumption trends and support Power BI reporting. Resource Group: rg-gso-powerplatform-app-analytics App Registration: EuAh-S06-Prd-Scau-All-01 Secret Name: GSO-PP-Governance Automation Account: GSO-PP-Automation-Account Runbook: TBD

Create a PowerShell ETL process to retrieve the complete tenant user inventory required for Power Platform Audit & Monitoring. The runbook will collect user information and store the data in the storage solution defined in T-01. The user dataset will later be correlated with Power Platform environments, applications, flows, ownership information, and other governance data. Resource Group: rg-gso-powerplatform-app-analytics App Registration: EuAh-S06-Prd-Scau-All-01 Secret Name: GSO-PP-Governance Automation Account: GSO-PP-Automation-Account Runbook: TBD

Create a PowerShell ETL process to retrieve the complete Power Platform DLP policy inventory. The runbook will collect all tenant-level DLP policies, including their configuration and scope, and store the collected data in the data storage solution defined in T-01. The process will use the existing Azure governance infrastructure: Resource Group rg-gso-powerplatform-app-analytics App Registration EuAh-S06-Prd-Scau-All-01 Secret GSO-PP-Governance Automation Account GSO-PP-Automation-Account Runbook TBD The collected DLP information will later be correlated with the Environment inventory created by T-02 to provide tenant-wide governance visibility.

Create the initial PowerShell ETL process for the Power Platform Audit & Monitoring solution. The runbook will retrieve the complete Power Platform environment inventory and store the collected data in the data storage solution defined in T-01. The process will run under the existing Azure governance infrastructure: Resource Group rg-gso-powerplatform-app-analytics App Registration EuAh-S06-Prd-Scau-All-01 Secret GSO-PP-Governance Automation Account GSO-PP-Automation-Account Runbook TBD The environment inventory will act as the base dataset for the following Audit & Monitoring ETL processes.

A short, readable blueprint covering zone denominations and their properties, guardrails, enabled and disabled features, implied costs and responsibilities. Aligned to Ahold Delhaize global architecture principles, with regional deviations deliberately limited. By Blueprint, we mean overall tenant configuration (current & desired) that includes technical configuration, lincensing, and budget allocation (cross charge)

A platform-scoped RACI built on the blueprint, defining who is responsible and accountable for each governance activity across the global team, OpCo teams and business owners.

An intake route for new solutions with assessment criteria, and a defined lifecycle from build through BAU to decommission. Covers the assessment that determines which zone a solution belongs in.

Define the criticality scale, who assigns it, and how solutions are registered in the catalogue or CMDB with ownership and data classification. Today only 8% of ADUSA apps are catalogued.

How the blueprint is versioned, reviewed and changed, and how new Microsoft capabilities get a governance position before makers encounter them.

Take the decision between Fix the basics, Basics plus upscale and Strategic platform. Every downstream item depends on it, and the cost difference between them is smaller than the control difference.

Who is entitled to author, how licences are requested, assigned and reclaimed, and how that is enforced through group based licensing.

Thresholds, alerting and an owner for database, log and file capacity. Database capacity currently sits at 77% and is driven by a handful of environments.

How Copilot credits and AI Builder capacity are allocated to environments and monitored. Copilot credits are limited at 25,000 and the AI Builder licence type is deprecated for the next renewal.

How platform cost is attributed back to OpCos and business owners, so cost implications are visible to the people creating them.

Document what AD Group governs, what the OpCo owns and what is explicitly out of scope, before any scope discussion starts.

Establish who takes platform decisions, with what quorum and against what criteria, so environment admins stop changing settings without a governance body knowing.

The FTE case for the chosen scenario. Fix the basics adds none, Basics plus upscale and Strategic platform each add roughly three across the global and regional teams.

A standing forum that brings global and local governance and development teams together on initiatives, governance changes and new features.

What a region receives when it adopts the model: the blueprint, the RACI, the tooling, the dashboards and the support route.

A register of approved deviations from the blueprint, each with a named approver and an expiry date.

Point the Copilot Studio Authors setting at an Entra group of people who have been trained, rather than leaving authoring open across the tenant.

Apply the recommended restrictions on portal creation and trial or developer environment creation by non-admin users, in line with the chosen zone model.

Change the tenant capacity summary view so environment admins can see and act on their own capacity consumption.

Turn off support request visibility for all users so support tickets are not exposed tenant-wide.

Turn on auditing across environments and set retention. Microsoft flags 190 environments without auditing, and audit logging is currently prohibited but inconsistently applied.

A tracked plan to raise the security score from 37%, sequencing the high-impact items: client application access control, IP firewall and cookie binding, security groups on environments, guest access restriction and admin reduction.

Agree Green, Amber, Red and Black as the governance zones, with the business impact and risk assessment criteria that place a solution in each, and the project types that map to them.

Apply managed environments to the Red and Black zones first, then Amber, taking the sharing limits, enforced policies and security features that come with them.

Create environment groups per zone with the associated rules. None exist today.

Route makers into their own personal development environments rather than the default environment, using the welcome message to set expectations.

Establish the Red zone shared production environments that structurally used and properly supported solutions migrate into, owned by the regional teams.

A standard route to request an environment, including approval, naming, access group provisioning and registration of the responsible owner.

Define and run the route that moves existing solutions out of personal productivity into the zone that matches their actual business impact.

Decision from management on the Environments Landing Zones strategy proposed by Marius, Macaw and Microsoft; currently awaiting decision on Premium licensing and implementation.

Classify every connector as business, non-business or blocked, with a documented rationale. Connectors are currently not structurally classified and all 129 policies carry non-business connectors.

Add the safety fallback policy that applies where environments are not otherwise assigned. None exists today.

Bring the 17 environments currently outside any DLP policy under coverage.

Decommission the 4 duplicate policies and consolidate the 125 policies scoped to fewer than five environments, resolving the 62 environments carrying more than one policy.

Tighten the policy covering personal productivity, the riskiest environment, addressing the apps and flows using unrecommended connectors such as HTTP, SQL Server and file system.

DLP execution after Connector Classification: reduce and refactor the DLP policy estate in the tenant based on the agreed connector classification.

Enable desktop flow actions in DLP, having first assessed the impact on the 483 existing desktop flows. Once enabled this setting cannot be disabled.

Remove excessive environment admin and system administrator roles. Microsoft flags 122 environments for admin reduction; 200 environments carry 25 or more system administrators, and personal productivity alone has 94.

Establish the reference inventory of orphaned assets across apps, flows, desktop flows, AI Builder models and agents, so cleanup progress can be measured.

Run the one-off cleanup of assets eligible for removal: 2,929 apps and 17,527 flows globally, of which 1,963 apps and 13,522 flows sit in the default environment.

Replace campaign-based cleanup with an automated purge and 90 day retention in personal productivity, so the estate stays clean without repeated effort.

Handle the 544 apps and 441 flows that need action because they use unrecommended connectors, are shared with 20 or more users, or carry a business criticality of 3 or higher. Decommission or migrate each to the appropriate zone.

A process that reassigns or retires assets when a maker leaves. Between 25% and 30% of makers who own assets have already left the company.

Assess and remediate the 165 canvas apps shared with guests and the 120 shared tenant-wide.

Define and publish the request catalogue entries with their field definitions, covering environment requests, DLP changes, licence assignment and access.

The steps and required fields for each request type, written so first line can execute them without escalation.

Decide which items route to which OpCo and where L3 sits. This is a tier ownership decision, not a flow design task, and it blocks several downstream items.

Publish the SLA offering, with response and recovery targets that align to the RTO requirements of each business criticality level.

No solution enters BAU without an SoP handed to first and second line and a named third line individual. Define the gate and its acceptance criteria.

Run the handover sessions and publish the known-error and how-to content that first line needs.

A central place where business users and stakeholders trigger a structured process for environments, DLP changes, licences and access.

Bring the CoE Starter Kit current and fix the gaps found during the assessment, including limited flow run data and incomplete Purview coverage.

Make it possible to attribute every environment, app and flow to a specific OpCo. The assessment could not connect all assets to an OpCo, which undermines every regional view.

A uniform dashboard giving insight into inventory, usage, compliance to standards and cost, for global teams, regional teams and business owners.

Filtered views of the central dashboard scoped to each OpCo, so local teams can execute their responsibilities against their own estate.

Automated detection of drift from the blueprint: environments without policies, missing naming conventions, excess admins and unclassified solutions.

Replace the manual ADUSA criticality process with an automated route that covers flows as well as apps.

Standard solution structure, publisher prefixes and naming, so solutions are recognisable and portable across environments.

Native deployment pipelines as the standard promotion route for governed solutions, replacing manual export and import.

Define when and how solutions are held in source control, building on what BeCSEE already does with GitHub.

Tooling that identifies and retires orphaned and unused assets on a schedule, made available to every region.

Tooling for business application identification, classification and catalogue management, feeding the criticality and support model.

Review what BeCSEE and the Czech team have already built and decide what becomes the global standard rather than rebuilding it.

What a new maker sees, signs and learns before they build, including the welcome experience and the routing into their own development space.

Global frameworks, learning paths and reusable building blocks that regional and local teams implement, raising proficiency and reducing dependency on central support.

Identify and support the makers who already carry the community, so they can empower each other rather than working around the absence of guidance.

A route for makers to request guidance from an experienced developer before they build something that becomes business critical by accident.

A simple, repeatable communication plan for DLP changes, environment changes and cleanup activity, so remediation does not land on makers unannounced.

Continue the phased, managed rollout of Copilot Studio with clear guidance on agent authoring, publishing and authentication. 178 agents already exist, 100 of them in the default environment.