Best Practices for Data Management and Governance: Who Decides What

Best Practices for Data Management and Governance: Who Decides What

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.

Stay Ahead With 4Labs

Get expert insights, security briefings, and the latest innovations in your inbox.

Name

Email

Phone Number

Your Message

Our Services

Digital Marketing

Staff Augmentation

IT Infrastructure

Software Development

Web & App Development

Industries

Cryptocurrency and Blockchain

Banking, Financial Services, and Insurance (BFSI)

Lending and FinTech

Energy and Utilities

Automotive and Manufacturing

E-commerce and Retail

Case Studies

Financial Services Test Automation

AI-Driven Customer Risk Profiling

Elevating Mobile Performance

Jewelry Client Transformation

AI Underwriting Revolution

Advanced Cybersecurity Solutions

Eyewear Retailer Transformation

Revolutionizing Manufacturing Operations

Offshore Development Excellence

Company

About Us

Careers

Let's Connect

Business Referral

Engagement Model

Partnership Programs

Resources

Blogs

iso_icon2

Copyright © 2026 4Labs Technologies. All Rights Reserved.

Privacy Policy

Terms & Conditions

Accessibility

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.

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.