Data Governance Roles Need Decision Rights

The weakest data governance document is a role directory.

It names a Data Owner, Data Steward, Data Custodian, and a few business subject-matter experts. Everyone nods. The organization can now say the domain has governance coverage.

Then a real decision arrives.

A customer table has three possible sources of truth. A privacy classification changes because a field now carries sensitive attributes. A dashboard depends on a business definition that no longer matches the operational process. A data quality rule blocks a release two days before a launch. A retention exception is requested because audit wants history and privacy wants disposal.

The role directory does not decide.

That is where governance fails. Not because the organization forgot the titles, but because the titles were never connected to decision rights, artifacts, cadences, and escalation.

I have seen that gap create the same pattern over and over: the data engineering team implements whatever is least blocked, the business team assumes governance approved the meaning, security assumes policy was applied, analytics assumes the data is certified, and the Data Owner only hears about the issue after trust is already damaged.

The fix is not more governance theater. The fix is an operating model small enough to run and explicit enough to say no.

EDM Council's DCAM frames data management around operating model, collaboration, evidence, and measurable capability. NIST CSF 2.0 puts governance, roles, responsibilities, and risk strategy into the cybersecurity conversation. NIST's Privacy Framework gives organizations a shared language for privacy risk management. Those references point in the same direction: governance is not a committee name. It is how authority, evidence, and control show up in the work.

The Failure Pattern#

Here is the sanitized version of the pattern.

A company launches a governed customer domain. The domain is supposed to support executive reporting, segmentation, retention modeling, and regulatory response. The first milestone is a certified customer profile table.

The team has reasonable people:

• a senior business leader listed as Data Owner,
• a domain expert listed as Data Steward,
• a data engineering lead listed as Data Custodian,
• several SMEs from sales, support, finance, and compliance.

The first release still gets stuck.

Sales says an active customer is any customer with an open contract. Finance says active means billable in the current period. Support says active should include customers still receiving service after cancellation. Compliance asks whether the retention period changes for customers in a regulated segment. The model team wants a stable feature definition. The dashboard team wants the launch date protected.

Everybody has input. Nobody has the final decision.

The mistake is treating governance roles like coverage. "We have an owner" sounds like accountability, but accountability only becomes real when the owner can approve a source of truth, accept a quality threshold, grant an exception, and absorb the consequence of delay.

The Operating Model#

The smallest useful model has four domain roles plus one escalation body.

The simple version:

That table is intentionally blunt. Governance confusion often starts when each role is written as if it owns everything good. The useful operating model gives each role enough authority to act and enough boundary to avoid pretending.

Data Owner: Accountable for the Domain#

The Data Owner is the executive or senior business leader accountable for the domain end to end.

The word accountable matters. The Data Owner does not write every rule, approve every row-level fix, or inspect every pipeline. The Owner is accountable for whether the domain's data is trustworthy, protected, and useful enough to support business decisions.

The Data Owner's real job is to decide when local preferences collide.

Core responsibilities:

• set the domain data strategy and align it to business objectives, regulatory obligations, and risk appetite,
• designate authoritative sources and approve source-of-truth changes,
• approve data quality thresholds, exception waivers, retention rules, and risk acceptance,
• prioritize domain initiatives within budget and capacity constraints,
• sponsor remediation when quality problems cut across functions,
• report domain health, unresolved risks, and policy proposals to the governance committee.

Deliverables:

Decision rights:

• final approval on domain strategy and policy changes,
• final approval on authoritative source designation,
• approval of critical quality thresholds and waivers,
• approval of retention and disposition schedules,
• approval of domain roadmap priorities within agreed constraints.

Out of scope:

• owning the application platform,
• designing dashboards,
• making local operational process decisions for one function,
• acting as the report development manager,
• replacing the data steward's semantic work.

The Data Owner should have enough business authority to choose between competing definitions. If the owner cannot decide between sales, finance, and support definitions, the role is underpowered.

Data Steward: Owns Meaning and Rules#

The Data Steward is the business-facing authority for meaning, quality, and proper use.

The Steward translates policy into rules that can be implemented and tested. This is a hard role because it lives between language and systems. The Steward has to turn "active customer" into a definition, valid values, lineage narrative, classification, quality rule, access pattern, and remediation path.

Core responsibilities:

• maintain business glossary terms, definitions, valid values, usage constraints, and lineage narratives,
• define quality rules, thresholds, validation logic, and remediation procedures,
• review and approve access requests that are routine and policy-consistent,
• maintain classification levels and usage guidance for domain data,
• coordinate profiling, monitoring, issue triage, and defect closure,
• serve as liaison between business consumers and technical implementers.

Deliverables:

Decision rights:

• approve business definitions and glossary entries,
• approve routine classifications under policy,
• approve domain-level quality rules and thresholds,
• approve routine access requests consistent with policy,
• accept or reject quality fixes against success criteria.

Out of scope:

• changing production systems directly,
• designing pipelines,
• building dashboards as the role's default responsibility,
• changing the operational process owned by a business unit.

The Steward is not a note-taker for governance meetings. The Steward is the role that prevents business ambiguity from leaking into every downstream table.

Data Custodian: Implements and Operates Controls#

The Data Custodian is the technical role responsible for implementing stewardship policy and keeping data pipelines, stores, transformations, and controls reliable.

This role often sits in data engineering, platform engineering, database administration, or an analytics engineering function. The title matters less than the accountability: the Custodian turns approved rules into running systems.

Core responsibilities:

• implement transformations, quality checks, validation jobs, alerts, and monitoring,
• maintain schemas, integration patterns, pipeline schedules, and runbooks,
• capture technical metadata, code lineage, change history, and operational evidence,
• enforce access controls, encryption, masking, tokenization, and logging per policy,
• support root-cause analysis and remediation,
• communicate delivery risks, source-system constraints, and data quality defects.

NIST SP 800-53 is useful context here because it organizes security and privacy controls across areas such as access control, audit and accountability, configuration management, incident response, media protection, PII processing, and system integrity. A Custodian does not own every control objective, but the role often implements the evidence that proves controls are working.

Deliverables:

Decision rights:

• select implementation details that satisfy approved policy and platform patterns,
• propose operational standards and reliability improvements,
• reject infeasible implementation requests until design constraints are resolved.

Out of scope:

• unilaterally changing business definitions,
• approving domain policy exceptions,
• acting as the business owner of the data product,
• becoming the default analyst for every consumer request.

The Custodian's boundary protects both sides. Business roles should not dictate brittle implementation details. Technical roles should not silently decide business meaning because nobody else answered fast enough.

Business SME: Validates Fitness for Use#

Business SMEs represent functional needs, constraints, exceptions, and process reality.

They are consulted because they know how the data is created, interpreted, and used in a specific function. They are not the same thing as the Data Owner. They may validate that a definition works for sales operations or finance close, but they do not set enterprise policy by themselves.

Core responsibilities:

• provide subject-matter input on definitions, valid values, business rules, and usage contexts,
• explain process constraints that affect data quality and interpretation,
• contribute to impact analysis for changes affecting reports, workflows, and controls,
• participate in root-cause analysis and remediation validation,
• provide test scenarios and UAT sign-off where functional behavior matters.

Deliverables:

Decision rights:

• approve functional acceptability within their remit,
• validate that remediation restored fitness for use,
• escalate when a proposed domain rule would break a real process.

Out of scope:

• designing the data model,
• implementing pipelines,
• setting domain-wide policy,
• approving security controls alone.

SMEs keep governance from becoming abstract. They also need boundaries so every local preference does not become enterprise policy.

The RACI That Actually Helps#

A RACI matrix is useful only when the activities are decision-shaped.

Legend: R = Responsible, A = Accountable, C = Consulted, I = Informed.

The most important line is "remediate data quality issue." In many organizations, this is where governance dissolves. The Custodian fixes the pipeline. The Steward confirms the rule. The Owner accepts residual risk or blocks release. SMEs validate whether the corrected data works in the affected process.

Nobody gets to say "not my part" when the domain is still wrong.

Access Is a Governance Decision and a Technical Control#

Access control is a good example of why these roles need to work together.

The Steward understands why a consumer wants the data and whether the use matches policy. The Owner accepts risk for the domain. The Custodian enforces the grant, mask, token, role, group, or policy tag. Security audits the control.

NIST's RBAC project is a useful reference point because role-based access control separates users, roles, permissions, operations, and objects into a model that can be administered. In practice, many modern data platforms mix RBAC with attributes, policy tags, row filters, column masking, and purpose-based approvals.

The operating question is not "do we have RBAC." The question is:

• Who approves this use?
• Which role or attribute grants it?
• Which columns are masked?
• Which rows are filtered?
• Which logs prove use?
• When does access expire?
• Who reviews recertification?

If those answers live in separate ticket comments and memory, the access model is not governed. It is improvised.

Cadence Beats Heroics#

Governance needs rhythm.

The escalation path should be boring:

Custodian -> Steward -> Data Owner -> Enterprise Data Governance Committee

Custodians raise operational facts. Stewards triage and translate facts into governance impact. Owners decide priorities, risk acceptance, and domain conflicts. The EDGC handles enterprise policy, cross-domain exceptions, and unresolved risk.

If every issue jumps straight to the governance committee, the operating model is too weak. If no issue can reach the committee, the operating model is performative.

KPIs That Prove the Model Is Working#

Governance metrics should show whether the operating model changed behavior.

Metrics can become theater too. A glossary completion rate is useful only if the glossary is used in release gates, catalog certification, access review, and incident response. Metadata coverage matters because it makes impact analysis faster, not because the catalog looks full.

The metric should connect to a decision.

A Data Product Readiness Contract#

This is the artifact I would want before certifying a new governed data product.

data_product: "certified_customer_profile"
domain: "customer"
 
owner:
  name: "customer domain owner"
  decisions:
    - source_of_truth
    - quality_threshold_waivers
    - retention_exceptions
    - release_go_no_go
 
steward:
  name: "customer data steward"
  required_artifacts:
    - business_glossary_entries
    - quality_rule_catalog
    - classification_review
    - usage_guidelines
 
custodian:
  name: "customer data custodian"
  required_artifacts:
    - pipeline_runbook
    - technical_lineage
    - dq_monitoring_jobs
    - access_control_configuration
 
smes:
  required_signoff:
    - sales_operations
    - finance
    - customer_support
 
release_gate:
  source_of_truth_registered: true
  critical_rules_pass_rate: ">= 99.5 percent"
  pii_classification_complete: true
  access_model_documented: true
  retention_schedule_approved: true
  lineage_registered: true
  rollback_plan_ready: true
 
incident_closure:
  root_cause_required: true
  automated_test_required: true
  steward_acceptance_required: true
  owner_signoff_required_for_critical_rules: true

This contract is not meant to be bureaucratic. It is meant to stop a launch from relying on vibes. A data product is ready only when the owner, steward, custodian, and SMEs have each done the part only they can do.

The Tradeoff#

Clear governance slows some decisions down.

It should.

Source-of-truth designation, privacy classification, retention exceptions, and quality waivers should not move at the speed of whoever is loudest in Slack. The tradeoff is slower local autonomy in exchange for faster recovery, fewer definition disputes, cleaner audit evidence, and more trustworthy data products.

The rejected alternative is pure local speed. It feels efficient until every domain invents its own definition of customer, revenue, policy, product, account, or employee. Then enterprise reporting, AI features, risk controls, and regulatory response all pay the tax.

The other rejected alternative is committee-first governance. That protects the organization by making ordinary work painful. People route around it. Shadow definitions appear. Data marts multiply. The governance function becomes famous for delay and irrelevant to delivery.

The better pattern is role-first, artifact-backed, cadence-driven governance.

Owners decide. Stewards define. Custodians implement. SMEs validate. The committee escalates policy and unresolved risk.

That sentence is simple enough to remember and strict enough to operate.

What to Do First#

Pick one important domain and one data product.

Do not start with the whole enterprise glossary.

For that domain, answer five questions:

1. Who can designate the authoritative source?
2. Who can approve the business definition?
3. Who can implement and monitor the control?
4. Who can validate that the output is fit for the functional process?
5. Who can accept residual risk when the data is imperfect?

Then require four artifacts before certification:

• a source-of-truth register entry,
• a quality rule catalog,
• an access and classification record,
• a lineage and runbook package.

That is enough to make governance real.

The point of roles and responsibilities is not to prove that a governance program exists. It is to make the next data decision cheaper, clearer, safer, and easier to audit.

If the next incident still ends with everyone agreeing the data is important while nobody can approve the fix, the role model has failed.