The organisational roles that make data governance work in practice — what a Chief Data Officer actually does, the difference between data owner and data steward, how governance committees function, and the role design that enables accountability without creating bottlenecks.
Data governance initiatives fail most often not because of technology but because of role ambiguity. Who is accountable for data quality in the finance domain? Who approves a new data source before it connects to the warehouse? Who enforces the naming convention when a new analyst publishes an uncertified workbook? Without clear answers to these questions — enforced by real accountability, not just a framework document — governance exists on paper but not in practice.
This guide covers the roles that make data governance work: what each role does, where responsibility lies, and how the roles fit together.
Chief Data Officer (CDO)
The CDO is the executive-level role responsible for the overall data strategy, data governance programme, and the organisation's analytical capabilities. In organisations with a CDO, they typically report to the CEO or CTO and are accountable for:
- Data strategy and vision: how the organisation uses data as a competitive asset
- Data governance programme: the policies, standards, and accountability structures that ensure data is reliable and compliant
- Data and analytics team leadership: managing the data engineering, analytics engineering, data science, and BI functions
- Regulatory data obligations: GDPR, CCPA, HIPAA, financial data regulations
What a CDO does not do: make day-to-day data quality decisions, approve every data source, or personally review workbooks. The CDO establishes the framework and holds domain leaders accountable for execution within it.
**When organisations need a CDO:** Mid-market and enterprise organisations with significant data regulatory obligations (financial services, healthcare, any organisation handling personal data at scale), organisations where data quality failures have reached executive visibility, and organisations where data is a core product or competitive differentiator. Smaller organisations may have this function performed by the CTO or VP of Engineering with a narrower scope.
**What the CDO cannot do alone:** Data governance requires distributed accountability. A CDO who owns all data decisions becomes a bottleneck and a single point of failure. The CDO's effectiveness is measured by whether governance is happening without the CDO's direct involvement on every decision.
Data Owner
The data owner is a business role — typically a department head, VP, or director — who is accountable for the accuracy, completeness, and proper use of data in their domain. Data ownership is not a technical role; it is an accountability role.
The finance data owner is accountable that:
- Financial data in the warehouse correctly represents the source system
- Access to financial data is granted only to appropriate roles
- Metric definitions for financial KPIs (revenue, EBITDA, cost categories) are agreed and documented
- Data quality issues in the finance domain are investigated and resolved
Data owners are not responsible for building pipelines or writing SQL. They are responsible for the business decisions that affect data quality: approving schema changes, setting access standards, validating metric definitions, and escalating data quality failures that affect reporting accuracy.
A common mistake: making data owners accountable for technical work. An SVP of Sales should not be debugging a pipeline. They should be accountable for whether the sales pipeline data is accurate, and should be escalating to data engineering when it is not.
**Data owner assignment:** Assign a data owner to every critical domain — finance, sales, marketing, product, operations, HR. The assignment should be to a named individual who understands the domain's data and has authority to make decisions about its use.
Data Steward
The data steward is the operational role that executes the data owner's governance decisions day to day. In larger organisations, the data owner is too senior to handle the detailed governance work — the data steward does this on their behalf.
Data steward responsibilities:
**Data quality monitoring:** Reviewing data quality reports, investigating anomalies, and working with data engineering to resolve issues.
**Metadata management:** Maintaining the business definitions, owners, and classifications for data assets in the data catalogue.
**Access management:** Processing access requests for their domain's data, ensuring access is granted to appropriate users, and conducting periodic access reviews.
**Onboarding new data consumers:** Working with new analysts and business users to understand what data is available, what the definitions mean, and what the caveats are.
**Certification support:** Reviewing content submitted for certification in the BI environment and providing the business validation that the data team requires.
A data steward is typically a senior analyst or analytics manager — someone with both business domain knowledge and enough data literacy to understand what the data means and where quality problems originate. It is not a full-time role in most organisations at the start of a governance programme; it is typically 20–30% of a senior domain analyst's responsibilities.
Data Governance Committee
The governance committee is the cross-functional body that makes shared data governance decisions that no single domain owner can make alone. Typical membership: CDO or VP of Data (chair), data owners from each major domain (finance, sales, product, operations), a representative from Legal/Compliance, the lead data architect or analytics engineering manager.
The committee meets monthly or quarterly to:
- Approve changes to the master data model (changes to how customers, products, or accounts are defined across the organisation)
- Resolve metric definition conflicts between domains (when finance and sales define "revenue" differently, the committee arbitrates)
- Approve new data sources and their classification (is this source PII? what access tier does it warrant?)
- Review the data governance programme's health (quality metrics, access review completion rates, certification rates)
What the committee should not do: approve routine access requests (too slow), review every workbook (too broad), or operate as a compliance checkpoint that blocks analytical work. The committee makes architectural and policy decisions, not operational ones.
Data Architect
The data architect's role in governance is design authority — ensuring that new data models, pipelines, and integrations meet the organisation's data architecture standards. In a governance context:
- Reviewing new data source onboarding requests for architectural fit (can this source be integrated cleanly, or does it require custom handling that creates maintenance risk?)
- Establishing and maintaining the canonical data model (the agreed definition of customer, product, account, and other core business entities)
- Setting data modelling standards (naming conventions, grain definitions, SCD type decisions)
- Providing technical input to the governance committee on the implications of architectural decisions
The data architect is the bridge between business governance decisions (the committee) and technical implementation (the data engineering team).
Making Governance Work in Practice
Role definition is necessary but not sufficient. Governance frameworks fail when the roles exist on paper but the accountability does not:
**Escalation paths must be clear.** When a data quality issue is detected, who does the data steward escalate to? What is the expected resolution time? What happens if the data owner does not prioritise the fix? Governance without escalation paths produces unresolved issues.
**Incentives must align with governance.** If a sales data owner is measured only on pipeline delivery and data governance is additional work with no recognition, governance will be deprioritised. Governance accountabilities must appear in performance expectations, not just in a framework document.
**Governance must make data access easier, not harder.** A governance programme that adds two weeks to every data access request will be bypassed. The access review process must be fast enough that the business does not create shadow data sources to avoid it. Automation helps — automated access provisioning through groups, regular reviews that batch requests rather than one-at-a-time approvals.
**Start with the domains that matter most.** Do not attempt to govern all data simultaneously. Start with the data domains that cause the most frequent governance failures — usually financial data (accuracy requirements, compliance) and customer data (PII obligations, accuracy for customer-facing processes). Prove the model works before expanding.
Our data architecture consulting practice designs governance operating models as part of broader data platform engagements — contact us to discuss your data governance requirements.
A former Microsoft data architect audits your data foundation, identifies your top priorities, and sends you a written plan. Free. No pitch.
Book a Call →