Data Stewardship: Roles, Responsibilities and a Working RACI

A data steward is the named person accountable for the meaning, quality and appropriate use of a defined set of data. The role is not a title and not a committee seat: it is two to four hours a week of specific, recurring work — approving definitions, resolving quality exceptions, and reviewing who has access to what.

Almost every governance programme nominates stewards. Most of those nominations never become a role, because nobody wrote down what the person does on a Tuesday.

What does a data steward actually do?

Strip away the framework language and the job is four recurring tasks.

Own the definition. When a term is contested — "active customer", "non-performing loan", "processed order" — the steward decides, records the decision in the business glossary, and the organisation uses that definition. The decisive part is not the writing; it is that somebody has the authority to end the argument.

Resolve quality exceptions. A rule fails: 340 rows have a null national ID. The steward decides whether that is a source system bug, a legitimate case the rule failed to allow for, or a backlog to be fixed. Somebody who does not know the business cannot make that call, which is why this task cannot live in IT.

Review access. Not grant it — review it. Who has access to this data, is that still appropriate, and what is the justification. In a supervised institution this review is also the evidence an examiner asks for.

Assess change. A source system is upgrading and a column type changes. The steward is the person notified, because they know which downstream reports carry regulatory weight and which do not.

Everything else attributed to the role — evangelism, training, "driving a data culture" — is real but secondary. If the four tasks above are not happening on a schedule, the rest is decoration.

Who owns what: owner, steward, custodian

The three-role split is standard and worth keeping, because collapsing it is the most common structural mistake.

The data owner is an accountable executive — the head of retail banking, the director of operations. They are accountable for the data their function produces, they approve policy exceptions, and they fund the work. They do not do the work. One owner per business domain, not per table.

The data steward is the working role described above. Domain expert, close to the process, empowered to decide on definitions and quality within the policy the owner approved.

The data custodian is technical — the DBA, the platform engineer, the team running the source system. They implement controls, maintain the pipelines, and execute access changes. They are accountable for the mechanism, never for the meaning.

The mistake is making the custodian the steward. It happens because the custodian is the person who answers when the data goes wrong, and it fails because the custodian cannot adjudicate whether a customer with two active products counts once or twice. That is a business decision wearing technical clothing.

The opposite mistake — a steward with no technical counterpart — is less common and equally fatal. The steward decides a rule should exist; without a custodian it never gets implemented.

What does a working RACI look like?

RACI matrices for governance are usually written at a level of abstraction that makes them useless. The fix is to build the RACI per activity, not per role, and to keep the activity list short.

For approving a business definition: the steward is responsible, the data owner is accountable, the custodian and affected report consumers are consulted, and everyone using the term is informed via the glossary.

For fixing a data quality issue: the custodian is responsible for the technical fix, the steward is accountable for deciding what correct looks like and for accepting the result, the source system owner is consulted, and the affected consumers are informed.

For granting access to sensitive data: the custodian is responsible for execution, the data owner is accountable for the decision, the steward and the privacy or compliance function are consulted, and the requester's manager is informed.

For classifying an asset — personal data, confidential, public: the steward is responsible, the owner accountable, the compliance function consulted, and the platform team informed so the classification can drive enforcement.

For assessing a source system change: the custodian is responsible for identifying the change, the steward is accountable for assessing business impact, the report owners are consulted, and the governance forum is informed.

Five activities. That is a RACI people will actually consult, and it fits on one screen. A twenty-row matrix is a document written to be approved, not used.

One rule saves most of the argument: exactly one accountable party per activity. If two names appear in the A column, the activity has no owner.

How many stewards do you need?

Fewer than the estate suggests, because stewardship scales with business domains rather than with tables.

The workable ratio in a mid-size bank or ministry is one steward per business domain — customer, product, risk, finance, HR, operations — with a second in the largest one or two domains. That is typically six to ten people for an organisation with thousands of tables, because the 100 to 200 critical data elements that matter cluster tightly into a handful of domains.

Scaling by table count is what produces programmes with forty nominal stewards and no actual stewardship. Coverage looks excellent on the slide, per-person time allocation is near zero, and nothing gets decided.

The honest constraint is that stewards are, by definition, the people who already know the business best — which means they are already busy. A programme that does not resolve this by taking something else off their plate is asking for volunteer effort and will get volunteer results.

What does the week actually look like?

A concrete allocation, because "two to four hours" means nothing until it is scheduled.

A weekly slot of 60 to 90 minutes, in the calendar, recurring. The steward works the queue: pending definition approvals, quality exceptions raised since last week, access reviews due, change notifications received.

A monthly governance forum, 60 minutes, where stewards bring what they could not settle alone — a definition two domains disagree on, a quality issue whose fix requires a source system change nobody has funded, a policy exception. This forum needs the data owners in the room, because its purpose is to convert disagreements into decisions.

A quarterly review against coverage metrics: which critical elements still lack definitions, which quality rules have been failing all quarter, where access reviews are overdue.

That is roughly five hours a month per steward and one hour a month per owner. Programmes fail at a fraction of this cost — not from the size of the commitment but from its irregularity.

How do you stop stewardship from decaying?

Stewardship decays predictably, and the decay has a signature: the queue grows, the forum starts being rescheduled, and within two quarters the role is a title again.

Three things prevent it.

Put it in objectives. Not a mention in a job description — a measurable objective the person's manager sees. Stewardship competes with delivery work, and delivery work has deadlines. Without a formal objective the steward is being asked to choose governance over their day job, and they will not.

Make the queue visible and small. A steward facing 200 pending items does nothing. A steward facing six items does six. This is a tooling responsibility: the catalog should route only what genuinely needs a human decision. In OvalEdge, the crawlers build the technical metadata — schemas, column-level lineage, usage patterns — automatically, so what reaches the steward is the subset that requires business judgement. That distinction between what a machine can infer and what only a person can decide is the whole argument for an automated data catalog.

Report on it upward. Coverage and queue-age metrics going to the data owners monthly. Not to punish stewards, but because a steward whose queue is growing usually has a workload problem their manager can solve.

What breaks in a trilingual organisation?

Stewardship in Azerbaijani institutions carries a complication the standard frameworks do not address: definitions exist in Azerbaijani, English and Russian, and they drift.

The failure is subtle. The Azerbaijani definition of a term is approved by the steward. The English version was written during a vendor project. The Russian version came from a legacy system's documentation. All three are plausible, none is flagged as authoritative, and reports built from different language sources quietly diverge.

The rule that works: one authoritative language per definition, with the others explicitly marked as translations of it. Which language is authoritative depends on the domain — regulatory terms are usually authoritative in Azerbaijani because that is the language of the requirement; technical platform terms are usually authoritative in English because that is where the source documentation lives. The steward owns the authoritative version and approves the translations as translations. The broader problem is treated in governing AZ/EN/RU metadata in one catalog.

Where stewardship meets AI

One change worth planning for. When enterprise AI systems retrieve internal documents and data as context, the steward's classification decision becomes a runtime control: what an assistant is allowed to retrieve for a given user depends on how the underlying asset was classified.

This raises the stakes on a task that was previously a compliance exercise. A misclassified table used to be a finding in an audit report. Now it is a table an assistant may surface to someone who should not see it, which is why ungoverned data is the constraint on enterprise AI far more often than model quality is.

Practically: before an AI project reaches production, the assets in its retrieval scope need a named steward and a current classification. That is a small piece of work if stewardship exists and a project-blocking one if it does not.

Key points

• A steward's job is four recurring tasks: own the definition, resolve quality exceptions, review access, assess change. Everything else is secondary.
• Keep owner, steward and custodian distinct. Making the custodian the steward is the most common structural failure.
• Build the RACI per activity, keep it to about five activities, and allow exactly one accountable party each.
• Scale stewardship by business domain, not by table count. Six to ten stewards covers most mid-size institutions.
• Schedule it: 60 to 90 minutes weekly, a monthly forum with owners present, a quarterly coverage review.
• Put stewardship in objectives, keep the queue small, and report coverage upward — otherwise the role decays to a title within two quarters.
• In a trilingual estate, mark one authoritative language per definition and treat the others as approved translations.

Yukon Labs sets up stewardship operating models alongside OvalEdge implementations, and starts most engagements with a data and AI readiness assessment that establishes where ownership actually sits today. For the wider regional picture, see data governance in Azerbaijan.