Steward vs owner vs custodian

Someone pings you on a Tuesday: “Who owns weekly revenue?” You open the dashboard, stare at a metric that three teams argue about, and realize the real question is not “what is the formula.” It is “who is allowed to change the formula, who has to keep the data usable, and who is only keeping the lights on under the table.”

That is the mess this series is for. Not a 40-page governance program. Not a new committee name. Weekly habits for people who already “own” a domain’s data without a fancy title on LinkedIn.

This is Part 1 of Data stewardship at work. We start with three roles that get mashed together in hallway talk: steward, owner, and custodian. Then we translate RACI into language you can use in a stand-up without sounding like a consulting deck.

If your company already has a formal data governance program or master data management workstream, treat those as the program layer. This series is the practice layer: what you do on Monday when the number is wrong and nobody wants the ticket.

What you’ll learn

How steward, owner, and custodian differ when a weekly metric breaks
RACI in human words (Responsible, Accountable, Consulted, Informed) without the theater
A filled RACI card for weekly revenue tasks you can copy
How stewardship habits connect to quality checks, pipelines, and metric definitions without rewriting those series
Common role collisions and a 30-minute exercise to unstick them

Why titles collapse under real work

In real companies, “data owner” gets used three ways before lunch. Sometimes it means “budget for the warehouse.” Sometimes it means “signed the privacy review.” Sometimes it means “the person who gets yelled at when Finance and Sales disagree.” All three can be true for different people. Pretending one label covers them is how you get hero culture and silent risk.

Stewardship language exists so you can split decisions from operations. Owners decide what “good” means and accept residual risk. Stewards keep definitions, quality habits, and access requests coherent for a domain. Custodians run systems: backups, jobs, permissions at the platform layer. When those roles blur, you get classic failures:

An engineer changes a join “to make the dashboard faster,” and the business definition shifts without a decision log.
An analyst becomes the permanent human API for a metric nobody documented.
Security locks prod, and product still demands ad-hoc extracts with customer emails because “we need it for the board.”

You do not need a new org chart to fix the first 80%. 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, not job grades.

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 GM, or a product lead who lives and dies by the number. Owners do not have to write SQL. They do have to answer: What counts? What is excluded? Who may redefine the metric? What risk is acceptable when quality is imperfect?

If two owners claim the same metric and disagree, you do not have a steward problem yet. You have a decision problem. Stewardship cannot invent consensus. 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 maintains the day-to-day trustworthiness of a domain: customer, orders, inventory, content, support, whatever your map looks like. They curate definitions, chase quality issues, route access requests, and know which tables are “certified” versus “here be dragons.” Often this is an analyst, analytics engineer, or ops lead who already does the work without the title.

Stewards are not the only people who touch data. They are the ones expected to notice when a pipeline change will break a board metric, or when a new field arrives with nulls that poison a join. That sits next to the habits in our data quality series: dimensions, profiles, and checks are tools stewards actually use.

Custodian: runs the systems safely

Custodians implement technical controls and operations: warehouse grants, ETL runners, backups, encryption at rest, job monitoring. They may never define “net revenue.” They should know who is allowed to change a production view, and how to restore a table after a bad load. If your team is small, one human may wear steward and custodian hats on different days. Name the hat when you speak, or you will mix “change the definition” with “restart the job.”

Steward vs owner vs custodian roles with RACI-style responsibilities

Notice what the diagram does not claim: permanent job titles. Roles attach to assets and processes. The same person can be owner of a metric, steward of a domain, and never touch production grants. That is fine. Confusion starts when the same Slack handle is treated as all three forever.

RACI in human words

RACI is an old project management idea: for each task, name who is Responsible (does the work), Accountable (one throat to choke, one final yes), Consulted (two-way input before the decision), and Informed (told after). Standards bodies and process frameworks reuse the same pattern for a reason: multi-person work fails when everyone is “kind of” accountable.

Human translation for data work:

Responsible: fingers on the keyboard or in the ticket. Writes the SQL, runs the check, updates the catalog card.
Accountable: signs off. One name. If the wrong number ships to the board, this person owns the outcome.
Consulted: must be heard before the change. Legal on PII fields. Finance on revenue exclusions. Eng on job risk.
Informed: needs the memo after. Downstream dashboard owners. Support. Sales ops. Not a committee of fifty in every meeting.

Rule of thumb: If two people think they are Accountable, neither is. If nobody is Responsible, the work is a wish.

Map roles to RACI without forcing a perfect 1:1. Often the owner is Accountable for definition changes. The steward is Responsible for documenting and quality triage. The custodian is Responsible for applying grants or deploying a model. Sometimes the steward is only Consulted on a platform upgrade. Write the task first, then the letters.

A role comparison you can paste into a wiki (one page max)

Here is a compact comparison for hallway debates. Keep it short enough that people 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, publish vs hold	Approvals, escalation, trade-offs with other owners	Endless re-litigation of numbers
Steward	Is this domain still trustworthy for how we use it?	Certification status, triage priority, catalog honesty	Definitions, quality checks, intake for access and issues	Tribal knowledge and silent drift
Custodian	Are systems running safely and as authorized?	How to implement access and recovery	Jobs, grants, backups, monitoring	Fragile ops and shadow access

This table is not law. Your company may use “data product owner,” “domain owner,” or “platform team” labels. Translate, do not argue taxonomy for three weeks.

Worked example: weekly revenue RACI card

Scenario: you publish a weekly revenue metric used by Finance, Growth, and the executive pack. Data lands from the orders system, transforms in the warehouse, and serves a certified table that BI tools read. (If that path is fuzzy, walk it with the data pipelines series first: sources, land, transform, serve.)

List the recurring tasks, not the org chart.

Define net vs gross and exclusion rules
Implement the transform model and tests
Run weekly quality checks and triage failures
Approve a definition change mid-quarter
Grant 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

Filled RACI (letters only; one Accountable per row):

Task	Owner (Finance analytics lead)	Steward (Orders domain analyst)	Custodian (Platform eng)	Growth lead	Legal
Define net vs gross	A	R	I	C	I
Implement model and tests	C	R	C	I	n/a
Weekly quality triage	I	R / A*	C	I	n/a
Approve mid-quarter definition change	A	R	C	C	C if PII
Grant certified-table read	C	R (request + business need)	R (apply grant)	I	C if sensitive
Restore after bad load	I	C	R / A	I	n/a
Communicate known issue	A	R	I	I	I

*For triage, many teams make the steward Accountable for “issue handled or escalated,” while the owner stays Accountable for “publish or hold the number.” Split those two accountability lines explicitly or you will fight about who should have paused the dashboard.

Filled RACI card for weekly revenue metric tasks

You can keep the same idea in a tiny YAML or markdown file next to the metric definition. The point is not pretty process art. The point is that next quarter’s intern can see who to ping for each verb.

# 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 a real metric spec habit from the metrics series. RACI without a written definition is theater. A definition without RACI is a PDF 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 covers golden records for customers, products, and other shared entities. Clean rooms cover multi-party measurement without free-for-all PII sharing. Those are architecture and policy choices.

Stewardship habits are what make those programs real on a Tuesday:

Someone answers access questions without inventing shadow extracts.
Someone updates the catalog when a certified table changes grain.
Someone escalates quality fails before the board pack freezes.

If your company has no council, you still need owner and steward names on the assets you touch. If your company has a council that never meets domain operators, you have policy without practice. This series lives in the practice gap on purpose.

Small company vs large company patterns

In a ten-person startup, one person may be owner, steward, and part-time custodian. Still write the roles on the metric card. When you hire the second analyst, you will thank yourself for not inventing history from Slack archaeology.

In a large enterprise, you may have domain stewards, platform custodians, and federated owners. The risk flips: too many R’s and no single A. Enforce “one Accountable per task,” even if twelve teams are Consulted. Informed lists can be channels, not individuals.

Matrix orgs love to put three Accountables on one row to “share ownership.” That is how you get status meetings instead of decisions. Prefer explicit co-ownership only for rare dual-control cases (for example, two signatures for irreversible deletion). For weekly revenue definitions, one A is enough pain already.

Common mistakes

Title cosplay: naming everyone a “data owner” so nobody feels left out. Titles without verbs do not route work.
Steward as unpaid product manager forever: if the steward has no escalation path to an owner, they become a human shock absorber.
Custodian as silent veto: platform teams that block every change without a consult path create shadow pipelines. Write Consulted, not surprise No.
RACI for everything: do not RACI lunch orders. Start with certified metrics, PII tables, and production write paths.
Confusing informed with approved: a dashboard consumer being Informed does not mean they approved a definition change.
Skipping quality and pipeline reality: roles without checks and path knowledge are name tags. Connect them to quality habits and the pipeline path you already teach on this site.

Practice: 30 minutes this week

Pick one metric or dataset people fight about. Open a doc with four headings: Owner, Steward, Custodian, Tasks. Fill names (or “unknown”). List five recurring tasks. Assign RACI letters with exactly one A per task. Share the draft in the channel that usually argues. Ask only one question: “What is wrong?”

Next, Part 2 of this series will tackle catalogs and “where is the truth?” without a 200-page wiki. You will need the steward and owner names from this exercise, because a catalog card with no human is just a nice empty form. For broader learning paths, browse Learn.

Quick recap

Owner decides and accepts risk. Steward keeps the domain usable and honest. Custodian runs systems safely.
RACI: one Accountable, clear Responsible, Consulted before change, Informed after.
Write RACI on tasks (define, implement, triage, grant, restore, communicate), not on vague “owns data.”
Program-layer governance and MDM set policies and golden records. Stewardship is the weekly habit layer.
Small teams: one person, many hats, still name the hats. Large teams: many people, still one A per task.

Sources

DAMA International, DAMA-DMBOK (data governance, stewardship, and roles overview): https://www.dama.org/cpages/body-of-knowledge
ISO, responsibility assignment concepts and related management system practices (RACI-style accountability in projects): ISO 21500 project management guidance and general RACI practice notes via PMI materials: PMI on responsibility assignment matrices
NIST Privacy Framework (risk, roles, and organizational accountability language): https://www.nist.gov/privacy-framework
NIST SP 800-53 security and privacy control families (access and accountability context for custodians): https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final
Data Management Association glossary and role discussions commonly referenced in stewardship programs: start from DAMA resources above; pair with your internal policy, not vendor lock-in.