The bottom line
A Fabric governance checklist should cover eight areas — tenant and capacity, workspace and domain topology, access and security, data management and endorsement, development lifecycle, quality and reliability, cost, and AI readiness — with every item naming a screen, a verification and a pass condition. The checks that separate estates that understand Fabric from those that bought it: workspace creation restricted to named groups, production workspaces Git-connected, row-level security tested and not defeated by Contributor roles, certified endorsement actually used, throttling alerting via Activator, and Fabric Data Agents grounded only on certified items. An item with no named owner is not governed — it is documented.
In This Article
Most governance checklists fail as aspiration
They are written as a compliance artefact — something to show an auditor — and every line reads like an aspiration. The second failure is subtler: the checklist is verifiable, but written for a generic data platform, so it asks about things Fabric does not have and misses the things it does.
This is the other kind of checklist. Each check names a screen and a pass condition. Two conventions run through it: an item with no named owner is not governed, it is documented; and every check is answerable by looking, not by asserting.
What a Fabric governance checklist should contain
Eight areas: tenant and capacity administration; workspace and domain topology; access and security; data management and endorsement; development lifecycle; quality and reliability; cost control; and AI readiness. The condensed high-value checks per area follow — enough to find your biggest gaps in an afternoon.
1. Tenant and capacity
| Check | Verify / pass condition |
|---|---|
| Workspace creation is restricted | Admin portal → Tenant settings → Create workspaces = specific security groups, not "entire organisation" |
| Every tenant setting has an owner | Each category has a named owner and a review date within 12 months |
| Capacity creation is controlled | Azure portal → Subscription → IAM; only a named group can create Fabric capacities |
| Capacity Metrics app installed & shared | Installed by a capacity admin, shared with the platform team, not one person |
| Throttling alerting exists | Real-Time hub → Activator alert on Microsoft.Fabric.Capacity.Summary, grouped by capacityId, to a named person |
| The team knows its throttling stage | Someone can state it without guessing (≤10 min absorbed, 10–60 adds a 20s delay, 60 min–24h rejects interactive) |
The last check separates estates that understand Fabric from estates that bought it. Smoothing spreads background operations across 24 hours, so a nightly load that would flatten a fixed cluster may show no user impact — until it does, suddenly, at month-end.
2. Workspace and domain topology
| Check | Verify / pass condition |
|---|---|
| Domains map to business areas | Admin portal → Domains; each is a real operating area (Supply Chain, Manufacturing), not a technology |
| Every domain has a named domain admin | A person, not a distribution list nobody reads |
| Naming convention enforced, not published | Workspaces list sorted alphabetically; fewer than 5% break it |
| Dev, test and production are separate workspaces | Production workspaces contain no items edited in place |
| Personal workspace policy is set | A stated policy on what may live in My Workspace and for how long |
| No production dependency in a personal workspace | Lineage/impact analysis on each certified item shows zero |
3. Access and security
| Check | Verify / pass condition |
|---|---|
| Workspace roles assigned to groups | Individual assignments are the exception and documented |
| Group nesting has been traced | Nobody gains Admin through a nested group by accident (highest permission wins) |
| Workspace Admin count is bounded | Two named admins per production workspace, no more |
| Service principals are inventoried | Developer settings scoped to a named group; every principal has an owner |
| RLS is tested by impersonation | Semantic model → Test as role; each role tested, result dated |
| RLS coverage gaps acknowledged | No Contributor or Member who should be seeing filtered data only |
The RLS gap is the one found during an audit rather than a design review: a plant manager added as a workspace Contributor so they could refresh a dataflow now sees every plant's cost data, because row-level security never applies to Contributor, Member or Admin roles — only to Viewer.
Row-level security protects data only from Viewer-role users. Anyone made a Contributor "to refresh a dataflow" reads everything — the gap an audit finds, not a design review.
4. Data management and endorsement
| Check | Verify / pass condition |
|---|---|
| A source of truth per domain | One named item per critical measure — one OEE model, not four |
| Certification enabled and scoped | Named certifiers per domain; only they can mark Certified |
| Certified badges used and earned | Every item on an executive report is Certified or Promoted |
| Lineage reviewable per workspace | An engineer can trace any certified model to its sources in under five minutes |
| Cross-workspace dependencies known | Downstream consumers listed before any breaking change |
| Sensitivity labels applied | Every item holding personal, commercial or price data carries a label |
Endorsement is a social control, not a technical one — a Certified badge means a named reviewer said yes — but that is exactly why it works: it gives a consumer a way to tell a finished model from a draft, which raw lakehouse tables never do.
5–6. Development lifecycle and quality
| Check | Verify / pass condition |
|---|---|
| Every production workspace Git-connected | 100% of production workspaces |
| A deployment pipeline per data product | Dev → Test → Production, item pairing intact |
| Direct production editing blocked in practice | No human holds Contributor on production; deployment runs as a service principal |
| Change approval recorded | Every production deployment traces to an approved pull request |
| Data quality rules for critical tables | Rules defined for the tables behind the top five operational measures |
| Failure alerts reach a person | A named individual, not a shared mailbox |
The failed check most estates share: alerts to a shared mailbox. A shared mailbox is not an owner — when the 06:00 refresh fails, someone must know within minutes who is called and what users are told.
7–8. Cost and AI readiness
| Check | Verify / pass condition |
|---|---|
| Capacity utilisation reviewed monthly | A dated review with a decision: hold, scale up, or scale down |
| Consumption attributed to a business owner | Each domain sees its own consumption; showback at minimum |
| Orphaned items reviewed | A quarterly deletion/archive list for items with no views in 90 days |
| Copilot tenant settings are a decision | Explicitly reviewed and scoped, not left on by default |
| Cross-geo AI processing settled | A documented decision, particularly for UAE and Saudi residency |
| Fabric Data Agents grounded on certified items only | Each agent grounds only on Certified items, never raw tables |
The single most useful AI check is the grounding one: an agent grounded on a raw lakehouse table will answer confidently from data that has never passed a business rule.
Where this breaks, and what it does not fix
A checklist does not create ownership — every item needs a name against it. Preview features move — workspace monitoring and several Git-supported item types are in preview, so re-check them. Endorsement is a social control, not a technical one — a Certified badge is a claim by a named reviewer, not an enforced state. RLS testing has real gaps — Test as role cannot simulate a B2B guest or a service principal, and does not cover DirectQuery models with single sign-on.
Cost attribution in Fabric is approximate — capacity is a shared pool, so showback is directional, not invoice-grade. And none of this fixes a bad source system: if Business Central and the MES disagree on what a completed work order is, no label, badge or pipeline resolves that.
What to do first
Do not attempt everything in one pass. Answer these five this week, because each changes what the rest looks like:
- Open Admin portal → Tenant settings → Create workspaces. Is it set to the entire organisation?
- Count your production workspaces that are not Git-connected — that number is your change-control exposure
- Open the Capacity Metrics app and find your worst throttling timepoint in the last 14 days; if nobody has looked, look now
- List every item with a Certified badge — if the list is empty, no consumer can tell a finished model from a draft
- For each Fabric Data Agent and Copilot-enabled workspace, write down its grounding sources; if any are raw tables, that is the first fix
We run Fabric governance reviews as a fixed-scope exercise: complete the checklist against your tenant, rank the gaps by operational risk rather than audit severity, and hand back the remediation sequence.
Five checks locate most of the risk: is workspace creation open to everyone, how many production workspaces are not in Git, what is your worst throttling timepoint, is anything actually Certified, and what do your AI agents ground on. Book a diagnostic with Amit — no slides, no pitch deck, no obligation to proceed. We run the checklist against your tenant and rank the gaps by operational risk, not audit severity.
Free Assessment
Where does your operation sit on the data maturity curve?
8 questions. 3 minutes. You get a scored breakdown across data infrastructure, analytics readiness, and automation potential — with a specific next step for your industry.