Strip away the frameworks and committees, and Power BI governance is the ability to answer four questions about your BI estate at any moment: What exists? Who uses it? Can it be trusted? What does it cost? Everything else — policies, review boards, naming conventions — is machinery in service of those four answers. This page maps the territory pillar by pillar, with the practical starting point for each.
Pillar 1 — Inventory: you cannot govern what you cannot list
Every governance effort starts with a complete, current catalog of workspaces, reports, semantic models, apps and capacities — including admin-only and personal workspaces the portal never shows you together. Point-in-time exports go stale in days, so the real requirement is a catalog that refreshes itself. The tenant inventory & audit guide covers the methods and their limits.
Pillar 2 — Access: who can see what
Workspace roles, app audiences, direct shares and external access accumulate silently for years. Governance here means being able to enumerate access — per workspace and per app — and reviewing it on a cadence, because permissions granted for a 2023 project do not expire by themselves. App access lists are the most commonly forgotten surface: they are where content actually reaches its audience.
Pillar 3 — Usage and lifecycle: the sprawl problem
Self-service BI creates content faster than anyone retires it, and the result is the zombie estate: reports nobody has opened in months, still refreshing, still shareable, still confusing search results. Usage history — kept longer than Microsoft’s ~30-day windows — is what separates defensible cleanup from guessing. The unused-reports guide shows three ways to find them.
Pillar 4 — Reliability: refresh health
A report that silently shows last week’s numbers is worse than a broken one. Failure notifications go to individual model owners, so tenant-wide refresh health is invisible by default — governance means tracking success rates, repeat offenders and failure causes in one place. The refresh-failures guide catalogs the causes and fixes.
Pillar 5 — Lineage and trust
"Where does this number come from?" and "what breaks if we change this source?" are the same map read in opposite directions: source → model → report → audience. Standard reports inherit sources from their semantic model, paginated reports connect directly — get that mapping wrong and impact analysis quietly lies. The data lineage guide covers both directions.
Pillar 6 — Cost: capacity FinOps
In Fabric, cost control is capacity control: every refresh, query and notebook drains one shared CU pool, and the difference between a right-sized SKU and a panic upgrade is per-item consumption history. The Fabric FinOps guide covers the economics; the throttling guide explains what happens when it goes wrong, and the metrics-history guide why 14 days of data is not enough.
A 30-day starting plan
- Week 1: stand up the tenant inventory (admin scope, personal workspaces labeled).
- Week 2: start collecting usage events daily — the history clock only starts when you do.
- Week 3: baseline refresh health; fix the top three repeat offenders.
- Week 4: review capacity consumption; spread the refresh pile-up you will almost certainly find.
Governance as a process, not a project
Every pillar above decays without a refresh cycle: inventories go stale, access drifts, zombies accumulate, capacity fills. PGR Sonar automates the collection side — continuous tenant inventory, usage and refresh history, capacity consumption, lineage — so the governance conversation starts from current facts. The deciding stays human; the bookkeeping should not be.