What a Power Platform Governance Assessment Actually Produces

A governance assessment worth paying for produces six things: an estate inventory you keep as a working file, a risk register ranked by evidence, a DLP and connector matrix that says what to change and why, a gap check against a standard you could read before the engagement started, a roadmap sequenced so each step lowers risk on its own, and a short list of decisions only you can make. It ends in a working session where your team argues with the findings, not a document dropped into a shared drive.

If you only remember one test: the report should be useful to you whether or not you hire the people who wrote it. A report that ends in a proposal instead of decisions has not finished; it has changed subject.

Nobody sets out to build an ungoverned estate. It happens because Power Platform grows wherever it is useful, and the place it grows first is the default environment, which every licensed user can build in. Microsoft's own environment strategy guidance is now unambiguous that the default environment should carry personal-productivity work only, with production work moved into dedicated environments, but most tenants were set up years before that guidance was written, and the apps did not wait.

The count itself is no longer the hard part. The Power Platform admin center now carries a tenant-wide inventory of apps, flows, agents, and environments, with a download button, and it is generally available. If an assessment's headline deliverable is "we found out how many apps you have," it is selling you a page you could have opened yourself. The hard part is the three questions the export cannot answer: which of these does the business quietly depend on, who is accountable for each of those, and what data can leave through them. That is what the assessment is for, and it is why the inventory is the first artifact, not the last.

One more thing has changed. The Center of Excellence Starter Kit, which for years was the de facto inventory and governance tooling, is no longer actively maintained by Microsoft; its core capabilities have moved into the admin center as native inventory, usage, monitoring, and action features. If a proposal's centerpiece is installing the kit, ask what it adds that the admin center does not already do.

The inventory has to be a file you own, not a screenshot in a deck. Every environment with its stated purpose and who administers it. Every app and flow with its owner, its connections and connectors, whether it sits inside a solution, and a usage signal so you can tell a daily tool from an abandoned experiment. Every maker. In the sample readout, the workbook's summary page is a single table: environments down the side, apps, flows, makers, unowned items, and critical items on personal credentials across the top. That table is the whole estate in one glance, and it is the page executives read.

Two columns make the workbook an assessment rather than an export. The first is "in real use," which needs usage data read against the calendar, because an app opened once in a quarter and an app opened every morning look identical in a resource list. The second is "the business depends on this," which no export contains at all. It comes from the working sessions: an IT owner and a business stakeholder walking the list and saying which items would stop invoices, approvals, or a month-end close if they failed tomorrow. In the sample, nobody had a list of those items before the engagement, and that is the normal condition, not the exception.

The test for this artifact is simple: could your team keep it current after the consultants leave? If the answer is no, because the workbook depends on tooling you do not have or a format you cannot edit, it is a prop.

A list of forty findings is a to-do list nobody starts. The register should rank risks by likelihood and impact, keep the top ten in front, and give each one three things: the finding, the evidence, and the severity. The evidence column is the one to read carefully, because it is what your security team can check. "Twelve business-critical flows run on personal credentials" is a finding. "The connection owners include two people who have changed roles, and a password reset would stop invoice intake" is evidence, and it is the sentence that gets the fix approved.

The same three risks sit at the top of most inherited estates, and it is worth knowing them before anyone measures yours. Critical automation running on individual accounts, which Microsoft's own guidance on orphaned flows describes plainly: when the owner leaves, flows that use connections tied to that account can fail. Production work living in the default environment beside every maker's experiments, under whatever single policy was written when the tenant was young. And connectors nobody classified, which is the subject of the next artifact. A register that does not mention these has not looked, and one that lists only these has not looked past the obvious.

Severity has to be argued, not asserted. A flow with no owner that runs once a year for a report nobody reads is a hygiene item. A flow with no owner that posts vendor payments is not. The register has to tell those apart, and the only way it can is by joining the risk to the "business depends on this" column in the workbook.

Data loss prevention policies in Power Platform work by sorting connectors into three groups, Business, Non-business, and Blocked, and refusing to let an app or flow use connectors from different groups together. That is the entire mechanism, and it is why a single tenant-wide policy written years ago is such a common finding. Microsoft's connector classification documentation explains the groups; what it cannot explain is what your policy's default group setting does to every connector nobody explicitly placed. If the default is Business, then HTTP, custom connectors, and consumer storage services sit in the same group as SharePoint and Dataverse, and company data can travel from one to the other without a policy ever objecting. That is the open door in the sample readout, and it is not an exotic configuration; it takes one setting, made once, years ago.

The matrix is the artifact that turns that into a plan: every connector in use, who uses it, how it is classified today, how it should be classified in each environment, and why. The "why" is not decoration. Blocking HTTP in the default environment protects the estate; blocking it in the production environment breaks the vendor integration finance relies on. The matrix has to say which is which, per environment, so the policy split you make is the one you meant.

It also has to be sequenced with the roadmap rather than applied on a Friday afternoon. Microsoft's data policy overview is clear that apps and flows which violate a policy are suspended so they cannot run, and that enforcement of a policy change reaches existing resources over a window that can stretch to a day. A matrix without a claim window and a communication plan is a matrix that will stop something the business needed on the day it is enforced.

An assessment scores your estate against something, and the something matters more than the score. If the standard is the consultant's private opinion, you cannot read it in advance, cannot argue with it, and cannot run it yourself next year. Ours is the Ø Standard: seven checks for production readiness that we publish in full, with a free checklist, no email required. Ø orphans, a named owner and a successor path. Ø personal credentials, service identities for anything critical. Ø mystery access, permissions auditable and least-privilege. Ø prod-only, a Dev/Test/Prod path and rollback. Ø undocumented handoffs, documentation a stranger could operate from. Ø silent failures, monitoring and exception handling. Ø dead ends, a support path after go-live.

None of the seven is exotic, which is the point. Each is cheap at build time and expensive at two in the morning, and each is something an inherited estate is usually missing. In the sample readout the fictional insurer passes one of the seven, partly, and that is a typical result for an estate that grew without a standard. The score is not the finding; the gap column is, because it names what closes each gap, and that column becomes the roadmap.

Whatever standard your assessor uses, ask to read it before the engagement. If they cannot show it to you, they do not have one.

The roadmap is where most assessments quietly become proposals. The tell is a plan whose first item is a program: stand up a Center of Excellence, adopt a governance framework, begin a platform initiative. A real roadmap starts with the fixes and sequences them so each wave lowers risk on its own and makes the next wave easier, and it states for every item the problem, the fix, and why it sits where it does in the order.

The sample readout's three waves are the shape we use. Stabilize first: move the critical flows off personal credentials, split the DLP policy so the open connectors are blocked where experiments live, open a claim window for unowned items and archive what nobody claims. Then structure: decide what each environment is for, following Microsoft's guidance to keep the default environment for personal productivity and move production work into dedicated environments with a development, test, and production path; put the business-critical apps into solutions, because solutions are the mechanism for moving work between environments and managed solutions are what belongs in production. Then operate: monitoring and exception handling on every critical flow with a named responder, which Power Automate's automation center now makes far easier to see, a recurring review that keeps the workbook true, and maker enablement so the next two hundred apps are built to the standard instead of retrofitted to it.

Two things belong in the roadmap that vendors often leave out. The first is licensing consequences: much of the tooling Microsoft now offers for governance at scale, sharing limits, usage insights, solution checker enforcement, pipelines, lives in Managed Environments, which are an entitlement of premium licenses, so a roadmap that says "make production a managed environment" has to say what that means for who needs which license. The second is the calendar cost to your own team, wave by wave, so the plan can be resourced rather than admired.

The test is the one we hold ourselves to: could you hand the roadmap to another vendor, or to your own team, and have it executed without calling the people who wrote it? Every item should state its problem, its fix, and its sequence rationale in plain language. If it needs the consultant to decode it, it is not yours yet.

A Gauge report ends with a short list of decisions, because the things an assessment cannot do for you are the things that need your authority. In the sample, there are three. Which identity critical automation should run under, since service accounts are fast and familiar while application identities are more secure and more work, and the honest answer is often both, split by what the flow touches. What the default environment is for, because locking it down protects finance and stalls the makers who make the platform worth having, and the DLP split plus an environment strategy is how you get both. And who runs governance after the project: an internal owner, a managed arrangement, or a Center of Excellence shaped for your size. The report should lay out those options without steering you to the one the assessor happens to sell.

The readout itself is part of the deliverable. Findings get pressure-tested with your team in a working session before they are final, because a finding your people can correct in week two is worth more than one they dispute after the report is printed. If a proposal describes the readout as "delivery of the report," ask who is in the room.

A proposal for a governance program dressed as a finding. If the assessment concludes that you need a Center of Excellence, it should say what the CoE would govern, why the fixes alone are not enough, and what the internal alternative looks like. If it cannot, the conclusion came before the evidence.

Findings scoped to the entry topic. Governance work touches SharePoint permissions, ALM, and identity. If the assessment uncovers a SharePoint sharing problem or a deployment path that does not exist, you should hear about it, whether or not it flatters the engagement that was sold.

A recommendation to shut down citizen development. In an inherited estate, including the fictional one on the sample page, the productive part of the platform is real: the business is running invoice intake and approvals on it because those things needed running. The roadmap's job is to make that safe, not to make it stop.

Numbers without evidence. An estate has the apps it has. A maturity score is a summary of findings you can inspect, not a substitute for them, and a benchmark against "organizations like yours" is worth exactly as much as the data behind it, which you should ask to see.

And construction work hiding inside the diagnosis. A diagnosis you can trust has no buildout in it. Ours is separated on purpose: the Gauge measures and plans; follow-on engagements fix, and the fee credit is how we keep that honest rather than a reason to blur the line.

Eight questions sort most proposals. Will the inventory come to us as a file we keep and can maintain? Is the risk register ranked, and does each risk carry evidence we can verify? Is the standard the estate is scored against published somewhere we can read today? Is the roadmap sequenced, with a rationale for the order, and does it state the calendar cost to our team? Does the report end in decisions for us rather than a proposal for you? What access does the collection need, and is it read-only? What is the total time our people spend, in hours? And is remediation priced separately from the diagnosis?

A good assessor answers all eight without flinching. For ours, the answers are on the Gauge page: read-only tenant access, two working sessions, two weeks, a fixed price, and a readout workshop at the end.

If you are weighing an assessment, read the sample readout first and judge the deliverable before the price. If you want a quick read on your own estate before talking to anyone, the free governance scorecard takes about two minutes and asks the same questions the Gauge starts with. And if the honest answer after either is "we can fix this ourselves," that is a fine outcome; the checklist is free, and the admin center inventory is already yours.

Microsoft's own documentation for the platform facts above. Product names, capabilities, and licensing change; check them at decision time.

1. Power Platform inventory: the admin center's tenant-wide inventory of apps, flows, agents, and environments, and its export options.
2. Center of Excellence Starter Kit transition to Power Platform admin center: the kit's maintenance status and where its capabilities moved.
3. Develop a tenant environment strategy: what the default environment is for, and the development, test, and production topology.
4. Data policies: what a policy violation does to apps and flows, and how enforcement propagates.
5. Connector classification: the Business, Non-business, and Blocked groups and why connectors in different groups cannot share data.
6. Manage orphaned flows when the owner leaves the organization: what happens to flows on departed accounts and how admins reassign them.
7. ALM basics with Microsoft Power Platform: environment separation, solutions, and managed solutions in production.
8. Managed environments overview: the governance capabilities and their licensing entitlement.
9. Explore Power Automate's automation center: monitoring flow runs, failures, and errors in one place.