Data governance: the minimum viable version that actually works in a mid-sized company

Data governance has a branding problem. When someone raises it in a management meeting, half the room hears "committees", "policies" and "a year of work before anything shows". They're not wrong: most governance initiatives launched in mid-sized companies die of their own weight, leaving behind a half-filled catalogue and a 60-page document nobody has opened since the kickoff.

But the problem it tries to solve is very real. You feel it the day two reports give different figures for the same sales number. Or when nobody knows whether the field `active_customer` means they bought this year or that they have a live contract. Or when a deletion request arrives from a customer and it takes three weeks to work out how many systems hold their data. This guide is about that: how to build the minimum data governance that solves those cases, without constructing a bureaucracy that collapses under itself.

What is data governance, and why does it get mistaken for bureaucracy?

Data governance is the set of decisions about who is accountable for which data, what each piece of data means, and who is allowed to do what with it. That's it. Not a tool, not a department, not a certification.

The confusion with bureaucracy comes from how it's usually sold. The textbook version starts with a complete reference framework — domains, policies, three tiers of committees, RACI matrices — and leaves the value for the end. In a company of 50 to 500 people that doesn't survive contact with reality: nobody has a spare day a week to chair a data quality committee.

The version that works runs the other way. You start with the three or four pieces of data already causing pain, answer the questions above for those only, and expand once the mechanism has proved it's worth something. Governance as a practice, not a project with an end date.

If your data governance document has more pages than you have governed data, you started in the wrong place.

A concrete example. A distributor had three definitions of "order fulfilled": logistics' (it left the warehouse), finance's (it was invoiced) and sales' (the customer confirmed receipt). None of them was wrong. The problem was that all three reports had the same name and got compared in the same meeting. Governing that piece of data meant picking one canonical definition, renaming the other two and writing it down somewhere people would actually find. Two weeks, not a year.

Why do most data governance projects fail?

The patterns repeat with almost boring regularity:

• Starting with the full catalogue. Inventorying 4,000 fields before deciding anything useful. By the time you finish, half of them have changed.
• Buying the tool first. A cataloguing platform is a container. If nobody is accountable for the data, the container fills up with automatic metadata that nobody has validated.
• Naming owners without taking work off their plate. "You're now also a data owner" isn't a role, it's another line in an email signature.
• Keeping it separate from real work. If governance lives in its own wiki space while the work happens in the ERP and the warehouse, governance goes stale within a quarter.
• Not defining what success looks like. Without a metric — time to answer an access request, number of reports with conflicting figures — there's no way to tell whether it's going well.

There's a sixth, quieter one: setting up data governance because "we need it for AI", with no concrete application on the horizon. That's the short road to a zombie project. In why AI pilots fail we cover the flip side of the same problem: pilots that crash into data nobody had looked at beforehand.

What is the minimum viable data governance setup?

Four pieces. None of them needs a dedicated tool to get going; a spreadsheet and a repository are enough for the first quarter.

1. An inventory of domains, not of fields. Between six and ten domains: customers, products, orders, billing, employees, suppliers, plus whatever is specific to your business. For each one: which system is the source of truth, who is accountable, how sensitive it is. Half a page per domain.

2. A glossary of the metrics people argue about. Not every metric: the ones that show up in management meetings and feed decisions. Each entry carries a one-sentence definition, the exact formula, the source system and who approves it. Twenty or thirty entries cover 90% of the arguments.

3. An access matrix by role. Who sees what, on what grounds, and who approves an exception. This is where data governance meets the GDPR, and where it pays to have settled how personal data is handled before moving anything into analytics environments or into a model — the detail is in data anonymization.

4. A review cycle with a date on it. One hour a month, four people, three items: quality issues detected, changes to definitions, pending access requests. If it doesn't fit into an hour, the scope is still too big.

That's already enough to answer the questions that currently hang in the air. Everything else — automated lineage, monitored quality, a federated catalogue — comes later and only if the volume justifies it.

Which roles do you actually need?

Fewer than the textbook says. In a mid-sized company these four cover the ground, and two of them are part-time:

| Role | Who it usually is | Time | What they're accountable for | |---|---|---|---| | Sponsor | CEO or CFO | 2 h/month | That budget exists and decisions get honoured | | Domain owner | Whoever already uses that data daily (head of logistics, of billing) | 2-4 h/month | Definitions, quality and access for their domain | | Technical lead | Data or IT profile | 20-30% | Source of truth, integrations, lineage, controls | | Privacy lead | DPO or legal | On demand | Legal basis, retention, data subject rights |

The usual trap is putting domain owners in IT. The owner has to be whoever suffers the consequences of the data being wrong, not whoever administers the database. If the head of billing can't close the month because the customer master is dirty, they're the one who should be able to decide how it gets cleaned.

How do you roll it out in 90 days without stopping the business?

A realistic calendar for a first pass, assuming nobody drops their day job for this:

| Weeks | What happens | What you end up with | |---|---|---| | 1-2 | Short interviews with 6-8 people: which data wastes their time | A prioritised list of real pain points | | 3-4 | Domain map and sources of truth | Half a page per domain, with a named owner | | 5-7 | Glossary of the 20-30 board-level metrics | Approved, published definitions | | 8-9 | Access matrix and personal data review | Who sees what, and what needs anonymizing | | 10-11 | First quality cycle on one domain | Validation rules and corrected errors | | 12-13 | Review committee and next quarter's plan | A monthly routine that runs |

Two conditions keep this calendar from being fiction. First: pick a single domain for the quality pass — usually customers or products, where it hurts most — and leave the others alone until next quarter. Second: publish the glossary where people already work. A permanent link inside the reporting tool makes the glossary a living thing; a PDF in a shared folder kills it.

How do you know data governance is working?

Through observable signals, not project completion percentages:

• Conflicting figures in meetings. How many times a quarter two reports contradict each other on the same number. It should fall.
• Time to answer an access or deletion request. From weeks to days.
• Time to start a new analysis. How long it takes someone to find the right data without asking three people.
• Reopened quality issues. If the same master data error comes back every month, the fix was cosmetic.
• Access exception requests. Lots of exceptions mean the role matrix is badly designed, not that people are undisciplined.

None of these metrics needs sophisticated instrumentation. You count them by hand in the monthly review, and that friction is healthy: it forces you to look at them.

How does data governance relate to AI?

Directly, and unromantically. A model inherits the quality, the biases and the legal problems of the data it's built on. If it isn't clear what a field means, the model will learn that ambiguity. If nobody knows where the historical data came from, there's no way to justify an automated decision to a customer or a regulator.

In practice, three parts of the minimum viable setup become critical the moment AI enters: knowing what personal data sits in each dataset, knowing who authorised its use for that purpose, and being able to reconstruct which version of the data trained or fed the system. Without that, any serious deployment stalls in legal review. It's the same idea we develop in data before AI: the ordering isn't methodological fussiness, it's what stops you redoing the work.

What you should not do is use AI as an excuse to inflate the scope. Governing the five datasets the first use case will touch is enough to start. Governing the forty that might get touched some day is how you lose the year.

Frequently asked questions

What does it cost to implement data governance in a mid-sized company?

The real cost isn't licences, it's hours from the people who already understand the business. A first pass like the one described consumes between 150 and 250 hours spread over a quarter, mostly in 2-4 hour monthly commitments. The tool, if it turns out to be needed at all, comes later and with a clear requirement attached.

Do you need a data catalogue tool?

Not to start. A glossary and a domain map work fine in a spreadsheet or the internal wiki while you're dealing with dozens of metrics and fewer than ten domains. The tool earns its place when you need to automate lineage, run recurring quality controls, or manage access across many sources.

Are data governance and data management the same thing?

No. Data management is the operational work — pipelines, storage, integration, quality controls. Data governance is the decision layer above it: who is accountable, what things mean, who is allowed to do what. You can have plenty of management with no governance at all, and that's exactly what most companies have.

Where do I start if my data lives in five systems that don't talk to each other?

By deciding which one is the source of truth for each domain, before integrating anything. Integrating five systems without deciding which one wins just produces five synchronised versions of the same disagreement. That decision is a business call, not a technical one.

Data governance is a hard sell because its result is the absence of problems: meetings where nobody argues about which number is right, analyses that start in hours, legal requests handled without drama. If you recognise any of the pain points in this guide and want to know where to start with your actual data, the audit is a good first step — it produces a map of domains, sources of truth and priorities. And if you'd rather talk it through first, let's talk.