Data Governance Roles and Responsibilities That Work in Practice

Data governance fails when everyone is responsible for data in principle and nobody has authority over a specific decision. A workable model names one accountable business owner for each important data domain or product, gives stewards time to run the controls, and keeps technical operation distinct from business accountability.

You do not need a large data office to begin. You do need explicit decisions, named people and a cadence for resolving issues.

Start with decisions, not job titles

Before creating a council or appointing stewards, list the recurring decisions governance must make:

• Who approves the definition of revenue, customer or service performance?
• Who decides whether a dataset is fit for a particular use?
• Who can approve access and exceptions?
• Who fixes source defects, and by when?
• Who certifies a data product for wider use?
• Who responds when sensitive data is exposed?
• Who approves data access for an application or AI agent?
• Who can retire a report, pipeline or dataset?

Assign each decision to one accountable role. Several people can do the work or provide advice, but two equal owners usually means no owner when a difficult trade-off appears.

The core roles

Executive sponsor

The executive sponsor makes governance a business operating requirement rather than a data-team preference.

Accountable for:

• Governance mandate, scope and risk appetite.
• Funding and capacity for stewardship and remediation.
• Resolving conflicts that domain owners cannot settle.
• Reviewing material risk, adoption and value.

Not accountable for: every definition, access request or quality rule.

For a mid-market organisation, this may be a CFO, COO, CIO or another leader whose remit matches the first priority. The sponsor must be able to resolve cross-functional disputes, not simply chair meetings.

Data governance lead or data office

This role designs the common system and keeps it operating.

Accountable for:

• Governance policy, role design and minimum standards.
• Common glossary and data-product conventions.
• Issue and exception process.
• Governance reporting and council preparation.
• Coaching owners and stewards.
• Coordinating the catalogue and governance tooling.

Not accountable for: the meaning or quality of every business domain.

In a smaller organisation, this can be part of a Head of Data, analytics lead or information-management role. The danger is turning the governance lead into the owner, steward, catalogue administrator and issue resolver for the whole company. That creates a central queue and lets business leaders opt out.

Data owner

The data owner is the accountable business decision-maker for a domain or data product.

Accountable for:

• Approved meaning and permitted use.
• Quality thresholds for important use cases.
• Access and exception decisions at the business level.
• Priority of remediation work.
• Certification and retirement decisions.
• Accepting or escalating residual risk.

Not accountable for: personally editing metadata, running pipelines or administering access.

Choose a role with authority over the process that creates or uses the data. Ownership should sit close enough to the business to make trade-offs, but high enough to commit resources.

Data steward

The steward turns policy and owner decisions into repeatable practice.

Responsible for:

• Maintaining definitions, metadata and ownership records.
• Monitoring agreed quality rules.
• Triaging issues and coordinating resolution.
• Supporting access reviews and certification.
• Checking lineage and impact when sources change.
• Helping consumers find and use the right data.

Not accountable for: accepting business risk or funding remediation without the owner's authority.

Stewardship is work, not an honorary title. Allocate time, expected outputs and escalation rights. A steward with no capacity or authority becomes the person who updates a glossary after decisions have already been made elsewhere.

Data custodian or platform owner

The custodian operates the technical environment. This may include Fabric administrators, data engineers, security engineers and application owners.

Responsible for:

• Implementing identity, access and technical security controls.
• Platform configuration, monitoring, backup and recovery.
• Pipelines, storage, deployment and operational support.
• Technical lineage, logs and evidence.
• Applying approved retention, classification and access requirements.

Not accountable for: deciding what revenue means or whether a business use is appropriate.

The technology team can advise what is possible and safe. It should not be forced to invent business policy because an owner is unavailable.

Security, privacy, legal and risk advisers

These specialists interpret obligations and challenge higher-risk decisions.

Responsible for:

• Advice on privacy, security, retention, contractual and regulatory requirements.
• Control review for sensitive or novel uses.
• Incident support and independent challenge where warranted.

They should be consulted according to risk, not asked to approve every low-risk dataset. They also should not inherit business ownership by default.

A practical decision-rights matrix

RACI tables become noisy when applied to every task. Use them for consequential decisions.

Adapt the matrix to consequence. Routine access can follow a pre-approved policy. Sensitive access or a new AI use requires explicit review.

Microsoft Purview has its own platform roles and permissions for Data Map and Unified Catalog. Microsoft's Purview roles documentation is necessary when configuring the tool, but those permissions should implement your operating model rather than define it. Microsoft also notes that governance permissions do not grant access to the underlying data.

Similarly, Fabric workspace roles control powerful platform capabilities. Do not equate a Fabric Admin or workspace Admin with the business owner of the data.

Use a federated model without creating ambiguity

For most mid-market organisations, a federated model is practical:

• A small central governance function sets minimum standards, common controls and escalation.
• Business-domain owners decide meaning, use and priority.
• Stewards maintain the day-to-day practice.
• Platform and security teams implement technical controls.

Microsoft describes a similar division in its Purview data-governance overview: central oversight sets rules while domain roles govern data with business context.

Federation is not decentralisation without standards. The centre must define what every domain must provide, such as an owner, description, sensitivity, quality measure, access route and review date. Domains then decide the additional controls their risk and use cases require.

Set a cadence that resolves issues

A practical starting cadence is:

• Always on: quality alerts, access logging, incident channels and issue capture.
• Weekly or fortnightly: stewards triage defects, ownership gaps and access exceptions.
• Monthly: domain owners review unresolved issues, quality trends, new products and access changes.
• Quarterly: the executive sponsor and governance lead review material risk, cross-domain disputes, adoption and investment.
• On material change: reassess when a new source, sensitive use, external sharing path or AI agent is introduced.

This is an operating recommendation, not a universal standard. Reduce meetings when controls work. Increase review when consequence or change warrants it.

Track measures that reveal behaviour, not activity theatre:

• Priority data products with an active owner and steward.
• Material quality issues past their agreed resolution date.
• Access exceptions open beyond expiry.
• Certified products that passed their scheduled review.
• Data incidents and repeated root causes.

Avoid celebrating glossary term counts or scanned assets without evidence that people use and maintain them.

Common role-design failures

Naming the IT team as owner of all data

IT operates systems. Business leaders decide meaning, acceptable quality and appropriate use. Mixing these accountabilities delays decisions and hides business risk.

Giving stewards responsibility without time

If stewardship is absent from workload and performance expectations, operational work will win every week.

Creating a council that owns everything

A council should set direction and resolve material disputes. It should not become the approval queue for ordinary access and quality work.

Letting consultants become permanent owners

External specialists can design the model, configure tools and coach roles. They cannot accept ongoing accountability for your business data. That must remain inside the organisation.

Start with one domain

Choose one domain tied to a real reporting, operational or AI outcome. Name the owner and steward. Define five to ten consequential decisions. Implement the access, quality, metadata and issue process. Run it for long enough to expose gaps before copying the structure elsewhere.

If the first domain will be built in Microsoft Fabric, read how Purview and Fabric work together for governance. If role conflict, platform design and data priorities are still unresolved, a Data & AI Readiness Assessment can turn them into an implementable sequence.

Book a free 30-minute Data & AI consultation if you need an independent view on whether your governance problem needs focused design, a Fabric implementation sprint, or stronger internal ownership rather than consulting.