Four things happen in enterprises that have no data governance, and they all look like different problems.
Two reports show different revenue for the same quarter, and the meeting stops while two teams defend their numbers. An auditor asks who can see salary data and nobody can answer inside a week. A migration surfaces four spellings of the same supplier, and no one will say which spelling is correct. An AI pilot that worked in the demo stalls on real records, because the model is confident and the master data is not.
Those are one problem wearing four costumes, and in each case a decision needed an owner and did not have one. That is what data management and governance best practices exist to fix, and it is why this page spends more time on who decides than on what the words mean.
Most pages on this topic define the terms, list the pillars, and give you ten practices of equal weight. The definitions are here too, because you may need them. But the weight of this page sits on the part that is missing everywhere else: which decision belongs to which role, what you do in the first ninety days, why you start on one data domain instead of the whole enterprise, and how you tell whether any of it is working.
We run this work for enterprises as part of our data practice, and the pattern is consistent. Programmes do not fail on tooling; they fail because a decision had two owners, which is the same as having none.
Data management and governance are not the same job
Every article on this subject says governance is the what and management is the how. That sentence is true and it helps nobody, because it does not tell you which team to call when something goes wrong.
Here is the version that works in a room. Data governance decides, and data management does. Governance sets what a field means, who may see it, how long it is kept, and who signs when the rule needs to bend. Management builds the pipelines, runs the platforms, loads the records, and keeps the whole thing available on a Tuesday morning.
One decision, run through both
Take a real question: what counts as an active customer?
Governance answers it. Somebody with authority over the customer domain decides that active means a purchase in the last eighteen months, that a cancelled account drops out immediately, and that trial accounts never counted. The decision is written down, dated, and attached to a name.
Management implements it. A flag gets added, the pipeline calculates it nightly, the definition goes into the business glossary, the two dashboards that disagreed are rebuilt against the same rule, and the change is announced to the people whose numbers will move.
Notice what happens when you skip the first half: management still has to ship something, so an engineer picks a definition, because a pipeline cannot run on an open question. The definition is now a technical accident that nobody agreed to, and it will be discovered in a board meeting eighteen months later.
Why the confusion costs you real time
When the split is unclear, three things follow, and you will recognise all three.
Decisions get made by whoever is closest to the keyboard, which is rarely the person accountable for the outcome. Governance meetings fill with implementation detail, because implementation detail is concrete and decisions are uncomfortable. And every dispute escalates, because there is no written rule to point at, so each disagreement has to be argued from first principles by someone senior.
A data governance framework is worth building for exactly this reason. Not because frameworks are good, but because a written rule ends an argument in thirty seconds that would otherwise take a fortnight.
What a data governance framework actually contains
A framework is four things, and it is not a diagram, not a platform, and not a slide with five pillars on it.
Policy: the rules, and where they live
Policy is the short statement of what is allowed: who may access personal data, how long records are kept, what has to happen before a new source system is connected, and which fields cannot be changed without approval.
The test of a policy is not how well it is written, but whether somebody who needs it at four o'clock on a Friday can find it in under a minute. A policy in a slide deck in somebody's drive does not exist, so keep it where people already work, keep it short enough to read in one sitting, and put a review date on it.
Standards: what "correct" means for each field
Standards are where governance becomes specific enough to be useful. A country code uses the two-letter ISO form, a customer record has one tax identifier validated at entry, a product description is under 120 characters, and dates are stored in one format across every system.
This is the layer nearly everybody skips, and skipping it is why data quality initiatives fail. You cannot measure quality without a standard, because quality is nothing more than distance from a standard. "The data is bad" is a feeling, while "nineteen per cent of supplier records have no valid tax identifier" is a standard being applied.
Processes: how a rule changes, and how an exception is granted
Two processes, and both need to be boringly clear.
Changing a rule: who proposes, who is consulted, who decides, how the change is announced, and where the old version is kept. Granting an exception: who asks, what evidence is needed, who may say yes, how long the exception lasts, and who is told.
The exception path is the more important of the two, and it is almost always missing. A governance programme with no exception path does not stop exceptions happening; it only stops them being recorded, which means the rules quietly stop reflecting how the business runs and everybody learns to route around the policy.
Controls: what is checked, how often, and by whom
A control is a check that runs whether or not anybody remembers it. The tax identifier validation that rejects a bad record at entry. The nightly job that counts records failing a standard. The quarterly access review. The audit trail that records who changed a definition and when.
Controls are where governance stops being a document and starts being real. A framework with policy, standards, and process but no controls is a statement of intent, and it will pass exactly one audit — the one where nobody looks closely.
Data governance roles and responsibilities
Four roles. The names vary between organisations and the vocabulary here follows the common data management body of knowledge, so you can map it onto whatever your own documents call them.
The data owner
A senior person in the business who is accountable for one data domain: customer, supplier, product, or employee. They decide what a field means, who may see it, and whether an exception is granted. They are not in IT, and they do not need to understand the pipeline.
The test of whether you have a real data owner is simple: ask who decides what "active customer" means. If the answer is a team, a committee, or "it depends," the role is vacant no matter what the organisation chart says.
The data steward
The person who does the daily work of data stewardship inside a domain. They find the duplicates, chase the missing tax codes, answer "which of these two records is right," maintain the business glossary, and bring genuine decisions to the owner rather than making them quietly.
This is usually a part of somebody's existing job, and that is fine as long as it is a written part with time attached. Data stewardship that exists only as goodwill lasts until the first busy quarter.
The data custodian
The technical role. Custodians run the platforms, implement access controls, apply retention rules, build the pipelines, and keep the audit trail. They execute the owner's decisions and they do not make them.
The common failure here is an inversion: the custodian gets asked to decide a business rule because they are responsive and available, and the owner is in meetings. It feels efficient, and it is how organisations end up with definitions nobody agreed to.
The governance council, and how to stop it becoming a status meeting
A council is where owners settle the questions that cross domains — when marketing's definition of a customer and finance's definition have to be reconciled, or when a new regulation touches four domains at once.
Most councils decay into status reporting within three meetings, and three habits prevent it. Every agenda item is a question with named options, not an update. Every meeting ends with decisions written down, each with one owner and a date. And anything that does not need a decision is not on the agenda.
A council that meets monthly and decides two things is working, while a council that meets monthly and reviews a dashboard is theatre.
The decision-rights test: one name per decision
Here is the test that settles most arguments about roles. Take any real decision — which supplier spelling survives, who may see salary data, whether an exception is granted — and ask for one name.One name means the decision has an owner. Two names means it has none, because when the two disagree the decision escalates or stalls, and no name means the decision is being made by whoever touches the system first.Run that test across ten real decisions before you write a single policy. The gaps it finds are your actual governance backlog, and they are more useful than any maturity assessment.
Start on one domain, not on the enterprise
The advice everywhere is to build an enterprise data governance programme. That is the destination, and it is the wrong place to start. Programmes launched across every domain at once produce a policy library, a steering committee, and no change to anybody's Tuesday.
Start on one data domain, get it genuinely working, and then use it as the pattern for the second.
How to pick the first domain
Three criteria, and you want all three in the same domain.
It hurts now. Something visible is going wrong — reports that disagree, an audit finding, a migration that keeps stalling on master data management problems. Pain buys you attention, and attention is the scarce resource.
One person can own it. If the domain spans four executives with equal claim, the decisions will escalate and you will learn nothing about whether the model works. Pick the domain with an obvious owner.
It is bounded enough to finish. Customer is often too big to start with, and supplier is usually a better first domain: fewer records, clearer rules, a genuine owner in procurement, and quick visible wins when duplicates collapse.
If you have a data migration or an ERP implementation already in flight, pick the domain that project is about to move. The migration will surface every disagreement about that data anyway, so let it fund the governance work rather than being ambushed by it.
What "done" looks like for that domain
Five things, and you should be able to demonstrate each one:
- A named owner, and people who know the name without looking it up.
- A written standard for the fields that matter, with a dated definition for each.
- At least one control running — a validation at entry, or a nightly count of records failing the standard.
- An exception path that has been used at least once, on purpose.
- A measurable move on one quality number, reported to somebody outside the data team.
That is a domain under governance: achievable in a quarter, visible, and enough to earn you the right to do the second one. An enterprise-wide programme with none of those five is a document.
Your first ninety days
One domain, three months, and an order that matters more than the contents.
Days 1–30: find out what is true
Do not write policy yet. Find out what is actually happening, because the gap between the documented process and the real one is where every problem lives.
Profile the data in the chosen domain, counting the records, the duplicates, the nulls in fields that are supposedly mandatory, and the distinct values in fields that should have five. Then talk to the people who key the data in and ask what they do when the system will not accept what they have. Their workarounds are your requirements.
Run the decision-rights test on ten real decisions and write down which have one name, which have two, and which have none. That list is the honest state of your governance, and it takes a fortnight rather than a quarter.
Days 31–60: name owners and write the first standard
Now get the owner appointed, in writing, with their consent and their manager's, because anything less lasts until the first disagreement.
Then write one standard — not a library. Pick the five to ten fields that the business genuinely argues about and define each one: what it means, what is valid, what happens to a record that fails, who decides when it is unclear. One page, dated, somewhere everybody can reach.
Appoint the steward at the same time, with time allocated. And agree the exception path now, before the first exception, because an exception path written under pressure is written to justify a decision already taken.
Days 61–90: put one control in, and hold the first exception
One control: the highest-value check in the domain, usually a validation at the point of entry for the field that causes the most downstream pain. Put it in, watch what it rejects for a fortnight, and fix the rule if it turns out to be wrong. It often is, and finding that out early is the point.
Then hold a real exception request end to end — requested, evidenced, decided, time-limited, recorded, announced. The first exception is a rehearsal of the whole governance machine, and you want it rehearsed on something small.
Close the ninety days by reporting one quality number, before and after, to somebody outside the data team. That single comparison does more for the programme's future funding than any maturity model.
What to deliberately leave until later
The things that feel like progress and are not, at this stage: buying a governance platform; writing policies for domains you are not yet governing; a maturity assessment; a full business glossary; cataloguing the whole estate; a training programme.
Each of these is defensible later. All of them consume the attention you need for the first domain, and none of them changes anything on a Tuesday. Tooling in particular deserves its own warning: a platform bought before the process is written will encode whatever confusion you already had, and it will encode it expensively.
Data quality: the practices that survive contact with a real business
Data quality is the part of data management best practices that everybody agrees on and few organisations sustain. Two things make the difference.
Measure at the point of entry, not in the warehouse
Most quality programmes measure at the end, because that is where the data is convenient to inspect. By then the bad record has been copied into four systems, a person has made a decision on it, and the fix has to be applied in several places.
Measure and, where you can, enforce at entry instead. Validate the tax identifier in the form rather than in a nightly report. Reject the impossible date when it is typed. Offer the existing supplier when somebody starts creating a duplicate.
The objection is always that this slows people down, and sometimes it does, by seconds. Compare that with the cost of a duplicate supplier record discovered during a migration, when nobody can say which of the four spellings is real and the payment run is on Friday.
The exception path matters more than the rule
Every rule meets a legitimate record that breaks it: the overseas supplier with no tax identifier in your format, the customer who genuinely has no surname, the historic record created before the rule existed.
If there is no path, people find one: they type a placeholder, and your quality report shows a pass while your data holds a lie. Placeholders are the single most common quality failure we find, and they are always a symptom of a missing exception path rather than of careless staff.
Build the path: a way to flag a record as a known exception, with a reason, a date, and an owner. Then report exceptions separately from failures, because both numbers are useful and they mean entirely different things.
The golden record question
When the same entity exists in several systems, somebody has to decide which version wins. That is a governance decision, not a matching algorithm, and it is the decision most master data management projects skip.
Write the survivorship rule down in plain language: the finance system wins on legal name and tax identifier, the CRM wins on contact details, the most recently verified address wins over the most recently entered one. Then the matching tool has something to implement. Without the written rule, the tool's defaults become your policy, and nobody in the business ever agreed to them.
Metadata management, cataloguing, and data lineage
A catalogue answers what data exists and what it means. Lineage answers where a number came from. Both are useful and both are commonly bought far too early.
What to catalogue first
Not everything: catalogue the things people already argue about.
Start with the business glossary for your first domain — the twenty terms that appear in board reports, each with a definition, an owner, and a date. Then the handful of tables those reports are built from. That is a week of work and it settles more disputes than a full estate scan.
A catalogue built before anybody asked a question becomes a second system to maintain. A catalogue built in response to a real argument gets used, because somebody was already looking for the answer it holds.
Why data lineage earns its cost only when somebody asks a question
Lineage is genuinely valuable in three situations: an auditor asks where a reported figure came from; a number changes and nobody knows which upstream change caused it; and a system is being retired and you need to know what depends on it. Outside those, lineage diagrams get admired and not used.
So build it where those questions land — the regulatory reports, the board metrics, the systems on the retirement list. Full-estate lineage is a programme in its own right, and it is almost never the right thing to do in your first year. If your estate spans several platforms, the cloud versus on-premises decision shapes how hard lineage will be to collect, which is worth knowing before you promise it.
Security, privacy, and access
Governance and security meet at one question: who may see what, and how do you prove it?
Classification before control
You cannot protect data sensibly without knowing which data is sensitive. Classification comes first, and it should be crude enough to actually get done. Three or four levels — public, internal, confidential, regulated — applied at the table or dataset level rather than the field level, at least to begin with.
A four-level scheme applied to everything beats a twelve-level scheme applied to nothing. Refine later, once people are using the coarse version.
Access reviews that people will actually do
Access accumulates: people change roles, projects end, contractors leave, and permissions stay. The standard answer is a quarterly access review, and the standard outcome is a manager approving forty lines at once because the deadline is today.
Make the review small enough to be real, and review one system a month rather than everything a quarter. Show the manager what each person actually used rather than what they are entitled to — unused access is easy to revoke and hard to argue for. And remove access by default when somebody changes role, so the review handles exceptions instead of the whole population.
This is also where regulation lands, so read this alongside our note on data privacy and security. Where the obligations are complex, our cybersecurity consulting team works alongside the data owners rather than behind them.
Governance before AI, not after it
Every article on this subject has grown an AI section. Most of it is decoration, but there is one point inside it that holds up, and it is worth stating plainly.
An AI project fails on exactly the problems a governance programme exists to fix. A model trained on records where the same supplier appears four times learns four suppliers. A retrieval system pointed at a document store with no access classification will quote a salary band to somebody who should not see it. An agent that acts on your data needs a rule about which source is authoritative, and that rule is governance, not engineering.
So the sequence is the other way round from how it is usually sold: ownership of master data first, then a written definition of the fields the model will use, then classification so the system knows what it may surface, and only then the model.
The cheerful version says AI will fix your data quality. It will not. It will find every place where nobody decided, and it will find them at speed and in front of an audience. Our note on AI and machine learning in data management covers where these tools genuinely help — on clean data with a named owner.
How you know data governance is working
This is the section that decides whether your programme gets a second year of funding.
Signals worth reporting
Time to answer. How long it takes to answer "where did this number come from" or "who can see this data." Measure it once at the start, then again each quarter. It is the single most persuasive metric available, because everybody senior has personally waited for one of those answers.
Disputes that did not escalate. Count the arguments settled by pointing at a written rule. Every one is a meeting that did not happen.
Exceptions granted and closed. A healthy number, trending down as the standards improve. Zero exceptions means the path is not being used, not that there are none.
One quality measure per governed domain, reported before and after. Duplicate supplier records. Records failing validation at entry. Whatever the domain's owner actually cares about.
Rework avoided. The migration that did not stall. The report that was not rebuilt twice. Anecdotal, and still the thing executives remember.
Numbers that look like progress and are not
Assets catalogued. Policies published. Council meetings held. Training courses completed. Percentage of the estate scanned.
Each of these can rise every quarter while nothing changes for the person keying in a supplier record. They measure activity, not effect. Report them if somebody insists, but never lead with them, because a sceptical CFO can tell the difference and will stop listening to the rest.
What to stop doing
Four habits consume governance effort and return nothing.
Writing policy for domains nobody governs. A policy with no owner and no control behind it is a document that creates an obligation you cannot meet. Write policy one domain at a time, as you take that domain on.
Running a council that reviews rather than decides. If the last three meetings produced no decisions with names and dates, the council is not governing. Shorten the agenda to questions only.
Measuring quality where the data lands rather than where it enters. It finds problems too late to be cheap to fix, and it puts the cost of the fix on the wrong team.
Buying the platform first. A governance tool encodes the process you have. If the process is unwritten, the tool encodes the confusion, and you now pay a licence to keep it.
Building your data management and governance practice
If you are starting, the order is the whole thing. Run the decision-rights test on ten real decisions. Pick one domain where it hurts, where one person can own it, and where you can finish. Appoint the owner and the steward in writing. Write one standard for the fields people argue about. Put one control in at the point of entry. Hold one exception end to end. Report one quality number to somebody outside the data team. Then do the second domain.
Everything else — the platform, the full catalogue, the maturity model, the enterprise policy library — comes after you have one domain that genuinely works.
The data work around it matters too. Governance decisions get tested hardest during a data migration, because a move surfaces every disagreement about master data in the same fortnight. The reporting layer built on top is where big data changes business operations or quietly fails to, depending on whether anybody owns the definitions. And governance is usually one workstream inside a wider programme, which our note on digital transformation strategies sets in context. The platforms underneath it all are covered in our IT infrastructure management notes.
Work with 4Labs Technologies
Our data analytics services team does this work with enterprise clients: the profiling that tells you what is actually true, the decision-rights map, the first domain's standards and controls, and the reporting that keeps the programme funded. We work alongside your owners rather than in place of them, because governance that depends on an outside team stops when the outside team leaves.
If you are weighing this up, bring three things to a first conversation: the domain you would start with, the two reports that disagree, and the name of whoever signs off on those numbers today. If the third one is hard to answer, that is the finding, and it is a useful place to begin.
Let's Connect — talk to our team about data management and governance
Frequently asked questions about data management and governance
What is the difference between data management and data governance?
Governance decides; management does. Governance sets what a field means, who may see it, how long it is kept, and who may grant an exception. Management builds the pipelines, runs the platforms, and implements those decisions. When the split is unclear, definitions get set by whoever writes the pipeline, because a pipeline cannot run on an open question.
Who is responsible for data governance?
Four roles. A data owner, senior and in the business, is accountable for one domain and decides. A data steward does the daily work inside that domain and brings real decisions to the owner. A data custodian is the technical role that implements and protects. A governance council settles questions that cross domains. The test of whether the roles are real is to name one person per decision.
What does a data steward do?
A data steward finds the duplicates, chases the missing values, answers "which of these two records is correct," maintains the business glossary for the domain, and escalates genuine decisions rather than making them quietly. It is usually part of an existing job, and it only works when that part is written down with time attached to it.
How do you start a data governance programme?
On one domain, not on the enterprise. Pick a domain that hurts now, that one person can own, and that is small enough to finish. Profile the data, run a decision-rights test on ten real decisions, appoint an owner and a steward in writing, write one standard, put one control in at the point of entry, and hold one exception end to end. Report a quality number before and after. That is a quarter's work, and it earns you the second domain.
What should a data governance framework contain?
Four things. Policy: the rules, kept where people can find them in a minute. Standards: what correct means for each field that matters. Processes: how a rule is changed, and how an exception is granted. Controls: what is checked, how often, and by whom. A framework with the first three and no controls is a statement of intent.
How do you measure whether data governance is working?
By effect, not activity: time to answer "where did this number come from", disputes settled by pointing at a written rule, exceptions granted and closed, and one quality measure per governed domain, reported before and after. Counts of assets catalogued and policies published rise every quarter while nothing changes for the person keying in a record, so never lead with them.
Do small and mid-sized companies need data governance?
They need the decisions, not the apparatus. A twenty-person company still has to answer what an active customer is and who may see salary data. What it does not need is a council, a platform, or a policy library; one owner per domain, a one-page standard, and a validation at entry cover most of it, and that scales up cleanly when the company does.
