A Microsoft Data Governance Framework You Can Actually Implement

Four parts, implemented rather than documented: named ownership per data domain, one governed definition of core entities, quality rules enforced automatically in the pipeline, and monitoring with lineage so trust becomes checkable. On the Microsoft stack that means Fabric's medallion layers doing the enforcement and Purview providing classification and lineage. What it does not mean is starting with a committee.

The failure pattern is consistent enough to be predictable.

A programme starts with a steering group. It produces a policy document, a glossary and a tool evaluation. Six months in there is a framework nobody has felt, because none of it changed what happens when a record is created or a report is built. Attention moves elsewhere and the documents go stale.

The diagnosis is straightforward: governance that is not enforced by the platform is a suggestion. Anything relying on people remembering to comply will decay at exactly the rate you would expect.

The programmes that work invert the order. They pick one painful domain, ship enforceable rules for it in weeks, and expand from a win people can point at.

Before any tooling, somebody has to own each domain of data - customer, product, supplier, employee - and that somebody sits in the business, not in IT.

This matters because the questions governance exists to settle are business questions. IT cannot decide whether a lapsed account still counts as a customer. IT can enforce whatever answer the business gives, which is a different job.

What ownership means practically: a named individual who arbitrates definitional disputes, approves changes to the domain's structure, and is accountable for its quality. Not a committee. Most data chaos is simply the absence of anyone being responsible, and committees preserve that absence while appearing to address it.

You also need a lightweight forum - monthly, brief - where cross-domain disputes get settled. Lightweight is the operative word.

Master data management sounds like an enterprise programme and does not have to be one. At its useful minimum it is: one governed definition of each core entity, with controlled creation and a clear rule for which source wins.

This is the highest-leverage fix available, because every report and process downstream inherits it. It is also the one that surfaces the uncomfortable conversations - the same real-world customer existing three times, or two departments meaning different things by the same word.

Those conversations are the work. Have them before the tooling, because no platform resolves a disagreement about meaning.

This is where a Microsoft estate does real work for you. In a Fabric medallion architecture, raw data lands in Bronze, and the Silver layer is where quality rules live: required fields, valid ranges, format checks, duplicate detection, referential integrity. Applied automatically, to every record, on every refresh.

The critical discipline is fixing data at the source or in the pipeline, never in the report. Analysts patching known errors downstream is how organisations end up with corrections that exist as folklore, work only in one report, and leave when their author does.

Practical rules of thumb:

• If a rule can be enforced at data entry, enforce it there.
• If it cannot, enforce it in Silver.
• If it is being applied in a report, it is not governance - it is a workaround with a shelf life.

Governance you cannot observe is governance you cannot trust.

Three things make it checkable: quality dashboards tracking error rates and completeness over time, alerts when a feed breaks or a metric drifts outside expected bounds, and lineage showing where any figure originated.

Purview's lineage across Fabric matters more than it first appears. When a board member asks whether a number can be trusted, the difference between a governed estate and an ungoverned one is whether that question has an answer or an argument.

Classification belongs here too. Sensitivity labels applied where data lives travel with it into exports, carrying protection past the platform boundary - which is the gap most organisations actually leak through. Our guide to governed access covers that in depth.

Weeks 1-2: pick the domain that hurts most. Usually customer or product master data feeding financial and executive reporting. Assign an owner. Profile the data honestly - the first quality dashboard is always sobering, and that is useful.

Weeks 3-6: enforce the highest-impact rules. Not every rule. The handful causing most of the pain, applied in the pipeline so they hold automatically.

Weeks 6-10: make it observable. Quality dashboard, alerting on the feeds that matter, lineage on the critical path.

Then expand, domain by domain. Each one is faster than the last because the pattern exists.

Note what is absent: a policy document as a first deliverable, a tool selection exercise, an enterprise glossary project. Those can follow demonstrated wins. They cannot substitute for them.

For organisations under GDPR, POPIA or sector regulation, governance is an obligation rather than hygiene - but the framework does not change. What changes is that classification and lineage move from useful to mandatory, and audit evidence needs to be producible on demand rather than assembled on request.

The practical test: if a regulator asked today who can see personal data and how you know, could you answer with a report rather than an archaeology project? If not, that is where to start.

Governance and data quality frameworks are a core part of what we build, and we build them in the order above deliberately - most governance work we are asked to rescue failed because it started with documents.

We work with your most business-critical data first, ship enforceable rules early, and grow the framework around wins people can see. Because it runs on the Microsoft platform you already own, governance becomes a property of the architecture rather than a parallel bureaucracy someone has to maintain.

The outcome clients notice is not a policy. It is the day a surprising number appears in a dashboard and the room's first question is "what should we do about it?" rather than "is that right?"

• Row-level security in Power BI
• Fabric security overview
• Microsoft Entra ID