Data owners, stewards, and custodians are three different jobs, and most companies blur them together. Say a coworker in finance messages you on a Tuesday, asking who owns weekly revenue. You open the dashboard and stare at a metric that three teams argue about. Then you realize the real question is not what the formula is. It is who is allowed to change the formula, who has to keep the data usable, and who is only keeping the systems running behind the scenes.
That is the mess this series is for. It does not offer a 40-page governance program or a new committee name. It offers weekly habits for people who already look after a team’s data without having a fancy title.
This post opens the Data stewardship at work series. We start with the three roles that get mashed together in hallway talk: steward, owner, and custodian. Then we translate a common planning tool called RACI into language you can use in a team meeting without sounding like a consulting deck.
If your company already has a formal data governance program or master data management (MDM) workstream, treat those as the program layer. This series is the practice layer, which covers what you do on Monday when the number is wrong and nobody wants the ticket.
Why titles collapse under real work
In real companies, “data owner” gets used three different ways before lunch. Sometimes it means the person with the budget for the data warehouse. Sometimes it means the person who signed the privacy review. Sometimes it means whoever gets yelled at when finance and sales disagree. All three can be true of different people. Pretending one label covers them all is how you end up leaning on a few heroes while risk builds up. It works until one of them leaves.
Stewardship language exists so you can keep decisions apart from daily operations. Owners decide what “good” means and accept the risk that remains. Stewards keep the definitions, quality habits, and access requests consistent for one area of the business. Custodians run the systems, which means backups, scheduled jobs, and permissions at the platform level. When those roles blur, you get classic failures.
- An engineer changes how two tables are joined “to make the dashboard faster,” and the business definition shifts without anyone recording the decision.
- An analyst becomes the permanent go-between for a metric nobody documented.
- Security locks down the live systems, and the product team still demands one-off exports with customer emails because “we need it for the board.”
You do not need a new org chart to fix the first 80% of this. You can start today. You need shared words and a small RACI for the work that actually happens every week.
Steward, owner, custodian in plain English
Think in verbs and not in job grades. Ask what each person does, not what their title says.
Owner: decides and is on the hook
The owner is accountable for a data product or domain outcome. For weekly revenue, that might be the head of finance analytics, a general manager (GM), or a product lead who lives and dies by the number. Owners do not have to write SQL, but they do have to decide what counts, what is excluded, and who may redefine the metric. They also decide how much risk is acceptable when the data quality is imperfect.
If two owners claim the same metric and disagree, you do not have a steward problem yet, because you have a decision problem. Stewardship cannot invent agreement, but it can force the conflict into the open with a written definition.
Steward: keeps the domain usable and honest
The steward is the person who keeps one area of data trustworthy day to day. That area might be customer records, orders, inventory, content, support, or whatever your business map looks like. They keep definitions current, chase quality problems, and route access requests. They also know which tables are “certified” and which ones are risky. Often this is an analyst, an analytics engineer, or an operations lead who already does the work without the title.
Stewards are not the only people who touch data, but they are the ones expected to notice when a pipeline change will break a board metric. They also notice when a new field arrives with blank values that poison a join. That sits next to the habits in our data quality series: the dimensions, profiles, and checks in that series are tools stewards actually use.
Custodian: runs the systems safely
Custodians handle the technical controls, such as warehouse permissions, backups, and job monitoring. They also run the extract-transform-load (ETL) jobs that move data around. They may never define “net revenue.” They should know who is allowed to change a live view, and how to restore a table after a bad load. If your team is small, one person may wear the steward hat and the custodian hat on different days. Name the hat when you speak, or you will mix up “change the definition” with “restart the job.”
Notice what the diagram does not claim, which is permanent job titles. Roles attach to data and to processes, so the same person can own a metric, steward an area, and never touch a live permission. That is fine. The confusion starts when one person is treated as all three forever.
RACI in human words
RACI stands for Responsible, Accountable, Consulted, and Informed, and it is an old project management idea. For each task, you name who is Responsible (does the work), Accountable (the one person who gives the final yes), Consulted (asked for input before the decision), and Informed (told afterward). The name comes from those four words. Standards bodies reuse the same pattern for a reason. Work shared among many people fails when everyone is only “kind of” accountable.
Here is a plain translation for data work.
- Responsible: the person with their hands on the keyboard or in the ticket, who writes the SQL, runs the check, and updates the catalog entry.
- Accountable: the person who signs off, and there is only one name. If the wrong number ships to the board, this person owns the outcome.
- Consulted: the people who must be heard before the change, such as legal for fields with personally identifiable information (PII), finance for revenue exclusions, and engineering for job risk.
- Informed: the people who need the memo afterward, such as owners of downstream dashboards, support, and sales operations. This is not a committee of fifty in every meeting.
Rule of thumb: If two people think they are Accountable, then neither really is. If nobody is Responsible, the work is only a wish.
Map roles to RACI without forcing a perfect one-to-one match. Often the owner is Accountable for definition changes. The steward is Responsible for documenting and sorting out quality problems. The custodian is Responsible for applying permissions or deploying a model. Sometimes the steward is only Consulted on a platform upgrade. Write the task first and the letters second.
A role comparison you can paste into a wiki, one page at most
Here is a compact comparison for hallway debates. Keep it short enough that people will actually read it.
| Role | Primary question they answer | Typical decisions | Typical hands-on work | Failure mode if missing |
|---|---|---|---|---|
| Owner | What is “correct enough,” and who accepts the risk? | Metric definition, inclusion rules, and whether to publish or hold | Approvals, escalation, and trade-offs with other owners | Endless re-litigation of numbers |
| Steward | Is this domain still trustworthy for how we use it? | Certification status, priority of problems, and an honest catalog | Definitions, quality checks, and taking in requests for access and reports of issues | Knowledge that lives only in people’s heads, and quiet drift |
| Custodian | Are systems running safely and as authorized? | How to implement access and recovery | Jobs, permissions, backups, and monitoring | Fragile operations and unofficial access |
This table is not law. Your company may use labels like “data product owner,” “domain owner,” or “platform team.” Translate them into these three roles. Do not spend weeks arguing over names.
Worked example: weekly revenue RACI card
Say you publish a weekly revenue metric used by finance, growth, and the executive report. Data lands from the orders system and gets cleaned up in the warehouse. It is then served as a certified table that business intelligence (BI) tools read. If that path is fuzzy, walk it with the data pipelines series first, which follows the four steps of sources, land, transform, and serve.
Start by listing the recurring tasks and skip the org chart.
- Define net versus gross and the exclusion rules
- Implement the transform model and tests
- Run weekly quality checks and sort out failures
- Approve a definition change mid-quarter
- Give a new analyst read access to the certified table
- Restore last week’s table after a bad load
- Communicate a known issue to dashboard consumers
Here is the filled RACI. To keep it readable, the four roles are written as plain phrases: “Signs off” means Accountable, “Does the work” means Responsible, “Asked first” means Consulted, and “Told after” means Informed. Every row has exactly one person who signs off.
| Task | Owner (Finance analytics lead) | Steward (Orders domain analyst) | Custodian (Platform engineer) | Growth lead | Legal |
|---|---|---|---|---|---|
| Define net vs gross | Signs off | Does the work | Told after | Asked first | Told after |
| Implement model and tests | Asked first | Does the work | Asked first | Told after | Not involved |
| Weekly quality triage | Told after | Does the work and signs off* | Asked first | Told after | Not involved |
| Approve mid-quarter definition change | Signs off | Does the work | Asked first | Asked first | Asked first if the data has personal details |
| Grant certified-table read | Asked first | Does the work (writes up the request and business need) | Does the work and signs off (applies the permission) | Told after | Asked first if sensitive |
| Restore after bad load | Told after | Asked first | Does the work and signs off | Told after | Not involved |
| Communicate known issue | Signs off | Does the work | Told after | Told after | Told after |
*For triage, many teams make the steward Accountable for “issue handled or escalated.” The owner stays Accountable for “publish or hold the number.” Split those two on purpose. Otherwise you will fight about who should have paused the dashboard.
You can keep the same idea in a tiny text file (YAML, a plain-text format) next to the metric definition. The goal is not a pretty process diagram. It is that next quarter’s intern can see who to ask about each task.
# weekly_revenue.raci.yaml (example, not a standard)
metric: weekly_net_revenue
domain: orders
owner: finance_analytics_lead
steward: orders_domain_analyst
custodian: platform_data_eng
tasks:
define_net_vs_gross:
accountable: owner
responsible: steward
consulted: [growth_lead]
informed: [custodian]
weekly_quality_triage:
accountable: steward
responsible: steward
consulted: [custodian]
informed: [owner, growth_lead]
apply_certified_read_grant:
accountable: custodian
responsible: [steward, custodian]
consulted: [owner]
informed: [requestor]
pause_publish_on_quality_fail:
accountable: owner
responsible: steward
consulted: [custodian]
informed: [dashboard_consumers]Tie the definition itself to the habit of writing a real metric specification, which the metrics series covers. A RACI without a written definition is for show, and a definition without a RACI is a PDF that nobody owns when it drifts.
How this sits next to governance programs without rewriting them
Data governance at the program layer covers policies, councils, and enterprise standards. MDM keeps a single trusted record for customers, products, and other shared things. Clean rooms let several companies measure something together without handing over personal data. Those are design and policy choices.
Stewardship habits are what make those programs real on an ordinary Tuesday.
- Someone answers access questions, so nobody has to invent a side export.
- Someone updates the catalog when a certified table changes what one row means.
- Someone raises quality failures before the board report is locked.
If your company has no governance council, you still need owner and steward names on the data you touch. If it has a council that never meets the people who run each area, you have policy without practice. This series lives in that gap on purpose.
How small and large companies differ
In a ten-person startup, one person may be owner, steward, and part-time custodian. Write the roles on the metric card anyway. When you hire the second analyst, you will be glad you did not have to dig the history out of old chat messages.
In a large enterprise, you may have stewards for each area, platform custodians, and owners spread across teams. The risk flips, and you get too many Responsible people and no single Accountable one. Enforce “one Accountable per task” even if twelve teams are Consulted, and let the Informed list be a channel instead of a list of individuals.
Companies with crossing reporting lines love to put three Accountable people on one row to “share ownership.” That is how you get status meetings instead of decisions. Use shared ownership only for rare cases that need two people to agree, such as two signatures before an irreversible deletion. For weekly revenue definitions, one Accountable person is plenty.
Common mistakes
- Handing out titles for show: naming everyone a “data owner” so nobody feels left out. A title without a verb does not route any work.
- The steward as an unpaid product manager forever: if the steward has no way to escalate to an owner, they become a human shock absorber.
- The custodian as a silent veto: platform teams that block every change without being consulted push people to build unofficial pipelines. Write them in as Consulted so the answer is not a surprise No.
- A RACI for everything: do not make a RACI for lunch orders. Start with certified metrics, tables with personal data, and anything that writes to live systems.
- Confusing informed with approved: a dashboard user who is Informed has not approved a definition change.
- Skipping quality and pipeline reality: roles without checks and knowledge of the data path are just name tags. Connect them to the quality habits and the pipeline path taught elsewhere on this site.
Practice: 30 minutes this week
Pick one metric or dataset that people fight about. Open a document with four headings: Owner, Steward, Custodian, and Tasks. Fill in the names, or write “unknown” where you do not have one. List five recurring tasks and give each a RACI assignment with exactly one Accountable person. Then share the draft in the channel where the arguing usually happens, and ask only one question: “What is wrong?”
Series notes: This is Part 1 of Data stewardship at work. The next post tackles data catalogs and the question of where the truth lives, without a 200-page wiki. You will need the steward and owner names from this exercise, because a catalog entry with no person attached is just a nice empty form. For broader learning paths, browse Learn.
Quick recap
- The owner decides and accepts risk. The steward keeps the data usable and honest. The custodian runs the systems safely.
- In a RACI, name one Accountable person and a clear Responsible person, consult people before a change, and inform people after it.
- Write the RACI on tasks such as define, implement, triage, grant, restore, and communicate, and not on a vague “owns data.”
- Governance and MDM at the program level set policies and trusted records, and stewardship is the weekly habit layer.
- Small teams have one person in many roles, so name the roles anyway. Large teams have many people, so keep one Accountable person per task.
Sources
- Data Management Association (DAMA), DAMA-DMBOK, on governance and roles: https://www.dama.org/cpages/body-of-knowledge
- International Organization for Standardization (ISO), on who is responsible in projects: ISO 21500 project management guidance and Project Management Institute (PMI) notes: PMI on responsibility assignment matrices
- National Institute of Standards and Technology (NIST) Privacy Framework (roles and accountability): https://www.nist.gov/privacy-framework
- NIST 800-53 security and privacy controls, for custodians: https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final
- Data Management Association glossary and role discussions used in stewardship programs. Start from the DAMA resources above, and pair them with your own company policy.
Keep going
Same lessons in your feed
Short diagrams, hooks, and weekly tutorials on Substack, Instagram, X, and Facebook.
