The Prerequisites for Enterprise-Grade Data Governance

The most common governance mistake is to start by buying a catalog or a governance platform, switch it on, and expect governance to happen. It does not. A governance tool enforces a model; it does not create one. Install it over an organisation with no owners, no agreed definitions and no policy, and you get a well-featured record of the chaos.

Enterprise-grade data governance is an operating model: who owns what, what the terms mean, who can access what, how quality is assured, and how it is all traced. The tool comes last, and it enforces decisions that people with authority have already made. Get the prerequisites in place and any competent platform will serve; skip them and no platform rescues you.

So the useful question is not "which governance tool?" but "are the prerequisites in place for a tool to enforce?" Below are the prerequisites, roughly in the order they matter.

The first prerequisite is a named business owner for each data domain — an operations or finance leader accountable for what the data means and which priorities matter, not just an IT custodian. This is the role most often missing, and it is where governance quietly fails: without an owner, the technical team defines metrics in a vacuum and priorities go to whoever shouts loudest.

The second, closely related, is agreed definitions of each key measure. Finance, operations and supply chain typically define OEE, OTIF, margin or revenue differently — which is exactly why the numbers disagree today. Governance forces one definition of each, and that is a business negotiation requiring authority, not a technical task. Someone has to decide, and the owner is who decides.

Get these two right and much of governance follows. Skip them and every downstream control — the catalog, the access model, the quality checks — is built on sand, because nobody can say authoritatively what the data is or what it should mean.

Governance needs something coherent to govern. If the enterprise’s data lives in fragmented silos — ERP here, MES there, spreadsheets everywhere — there is no single place to apply policy, trace lineage or enforce access consistently. A unified, governed foundation is the prerequisite that makes governance enforceable at all.

In practice that is a governed lakehouse or platform: OneLake on Microsoft Fabric, or a Unity Catalog-governed Databricks lakehouse, with sources brought together and organised (for example in a medallion Bronze/Silver/Gold structure). The point is not the specific platform; it is that the data meets in one governed place with a coherent structure.

Without this, governance becomes a per-system patchwork — each source governed differently, no cross-system lineage, no single answer to "who can see this?" The unified foundation is what turns governance from a collection of local rules into one enforceable plane.

With owners, definitions and a foundation in place, you need a deliberate access model rather than a pile of ad-hoc grants. That means role-based access through groups (synced from your identity provider), least privilege as the default, and attribute-based policies where access must be conditional — by country, entity or clearance.

And it needs enforcement close to the data: row-level security for which rows a user sees, column-level security and masking for sensitive fields, so every consumer inherits the same controls. PII — identifiers, financial and health data — is classified and protected here, once, rather than each report inventing its own masking.

The discipline is to design the access model with the business owners (who know who should see what) and enforce it at the platform. This is where role-based and attribute-based control, and the row/column mechanisms that apply them, come together into a coherent, auditable model.

A catalog makes governed data discoverable and trustworthy: search, tags, ownership, and endorsements (certified vs promoted) so people and tools find the right, trusted dataset rather than a stale copy. Sensitivity classification — via Microsoft Purview on the Microsoft stack, or Unity Catalog with the OneLake catalog — surfaces what is confidential. A catalog nobody curates is just a list; the curation is the governance.

Data quality checks belong at each layer of the pipeline — schema, nulls, ranges, referential integrity, freshness — so bad data is caught where it enters rather than surfacing as a confidently wrong number in a report. Quality is a first-class governed metric with an owner, not a one-off clean-up.

Lineage and audit close the loop: lineage shows how data flows source to report so you can trace and impact-assess a change; audit records who accessed what for compliance. Together, catalog, quality and lineage turn governance from a policy document into something visible and verifiable.

Sequence a governance programme by the prerequisites, not the tool: name owners and agree definitions; unify the data on a governed foundation; design the access model and enforce it at the data; curate the catalog, apply quality checks and turn on lineage and audit. Choose the platform — Unity Catalog, Microsoft Purview, the OneLake catalog — to enforce that model, once it exists.

What makes this urgent now is AI. Governance used to be a back-office compliance exercise that produced reports nobody read. The moment Copilot and AI agents started grounding on your data, governance became the thing that decides whether their answers can be trusted — a direct input to AI quality, not a cost centre. Agents reason from whatever you govern; ungoverned data produces confident nonsense.

So the honest message to a leadership team: do not buy a governance tool and expect governance. Put the prerequisites in place — ownership, definitions, foundation, access, catalog, quality, lineage — and the tool enforces a model that works, for analytics and for AI alike. That is the work we do before, not instead of, the platform.