Data Steward: A Clear Guide to the 4 Governance Roles

A data steward is the role that makes data governance operational rather than aspirational. Owners decide, stewards do — and programmes that appoint one without the other either produce decisions nobody implements or work nobody has authorised.

This guide separates the four roles that get confused, covers what a steward actually does week to week, how many you need, and why the job title is less important than the decision rights behind it.

Four roles, and what separates them

The distinction that matters most is owner against steward. The owner has authority and rarely has time; the data steward has knowledge and needs the owner’s authority to make it count. Merge them and you get a senior person who cannot answer questions about the data, or a specialist making decisions they cannot defend.

What a data steward actually does

1. Defines the terms. What “active customer” means, where the boundary sits, and which system is authoritative. Most data disputes are definition disputes wearing a technical costume.
2. Owns the business rules. Valid values, formats, mandatory fields, and the rules that decide whether a record is acceptable.
3. Monitors quality. Profiling against the agreed dimensions, tracking the results, and raising issues that cross a threshold rather than reporting a dashboard nobody reads. Our guide to the six data quality dimensions covers what to measure.
4. Triages issues. Deciding whether a defect is a data entry problem, a process problem or a system problem — and routing it to whoever can fix the cause.
5. Represents the domain. Sitting in the working group where cross-domain conflicts get resolved, with a mandate to agree something.
6. Reviews access requests. Advising the owner on whether a proposed use fits the data’s purpose, sensitivity and any consent behind it.

Where the role fails

Appointing a data steward with no time allocation is the most reliable way to kill a governance programme. The work is real — a domain of any size is a day a week at minimum — and stewards appointed on top of a full job will do the urgent thing instead, every time. The second failure is appointing someone without domain credibility: the role runs on persuasion, and a steward whose definitions are ignored has no other lever.

How many data steward roles, and where they sit

Steward by data domain — customer, product, employee, finance, asset — rather than by system or by department. Systems change; domains do not. One steward per domain, with named deputies, is enough for most organizations; large domains split by sub-domain rather than by geography.

Two models work in practice. Federated: stewards stay in the business, report to their line manager, and are coordinated by a central function. Centralised: stewards sit in a data office and partner with the business. Federated keeps domain knowledge and struggles with consistency; centralised is consistent and drifts away from how the business actually works. Federated with a strong central standard is the common middle, and it is the one that survives reorganisations.

Making the role stick

• Write the decision rights down. What the data steward decides alone, what they recommend to the owner, and what escalates. Ambiguity here is why stewardship stalls.
• Give it a percentage. Put the time in the job description and in the objectives the person is actually measured on.
• Start with one domain. A working stewardship model in customer data beats a complete role definition across twelve domains that nobody performs.
• Measure something the business cares about. Duplicate rate, failed reconciliations, rework — not “number of terms defined”.
• Connect it to compliance work. The steward’s definitions and lineage feed the record of processing, retention decisions and access reviews, which is where the role starts paying for itself. See our guide to records of processing.

Frequently asked questions

What does a data steward do?
Defines and maintains the meaning, business rules and quality of data within a domain, monitors it, triages issues and advises the owner on use — the operational half of data governance.

How is a data steward different from a data owner?
The owner holds accountability and decision rights; the steward holds the knowledge and does the work. The owner approves; the steward proposes and maintains.

Is it a full-time job?
Sometimes, in large domains. More often it is a defined portion of an existing role — but it has to be defined, or it will not happen.

Do we need stewards to comply with privacy law?
No regime requires the title. Several require the outcomes stewards produce — knowing what data you hold, what it means, where it came from and who may use it — which is why privacy programmes end up building stewardship whether they call it that or not.

Where does the DMBOK fit?
It is the standard reference for the knowledge areas and roles, and a useful vocabulary. Our guide to data governance and the DMBOK covers what it is and is not.

Where this leaves you

Appoint a data steward per domain, pair each with a named owner who holds the decision rights, and write down which decisions belong to which. Allocate real time, pick people whose domain judgement the business already trusts, and measure the role on something operational rather than on documents produced. Start with the domain causing the most rework — one working stewardship model teaches you more than a complete framework nobody is staffed to run.

References

• DAMA — Data Management Body of Knowledge — the reference framework for data governance roles and knowledge areas.
• ISO/IEC 38505-1:2017 — governance of data, and the accountability model behind these roles.

More on data governance

• The data steward — you are here
• Data governance and the DMBOK
• The six data quality dimensions
• Data classification

Role descriptions, decision-rights matrices and the stewardship charter are in the Data Governance Toolkit, or start with the free ISO templates.