Data governance: roles, bodies and how to organise around data

Data governance is, according to DAMA-DMBOK, the exercise of authority, control and shared decision-making over data assets. Put practically: every piece of data has a clear owner, everyone interprets concepts in the same way, the quality and origin of what is used are known, and data requests follow an orderly process. It is also the foundation of any trustworthy AI project: an AI system is only as good as the data it uses.

The problems it solves

Almost every organisation starts from a similar situation:

• Informal or non-existent responsibilities for data.
• The same data item with different values in two applications.
• Data requests with no logging, prioritisation or follow-up.
• Little documentation and traceability.
• Dependence on the knowledge of specific individuals.
• No bodies to make decisions and resolve conflicts.

Organise by domains, not by org chart

The organisational unit is the functional domain: a stable grouping of data that share a purpose, processes and an owner (for example, population, finance, people, or city and environment). Unlike departments, domains do not change with every reorganisation. A domain may contain subdomains (in city and environment: mobility, waste or energy consumption), which share a glossary and can define their own concepts.

The hierarchy has three levels:

• Domain: the strategic level of accountability.
• Data product: a set of datasets, models or dashboards with a purpose, an owner and its own lifecycle.
• Dataset: the specific unit that is catalogued and to which quality, security and traceability are applied.

The roles

Role	What it does
Data Owner	Ultimately accountable for the value, use and quality of the data in their domain. Defines its meaning, prioritises requests, appoints the stewards and approves access and master data. This accountability cannot be delegated
Data Steward	Day-to-day functional role: defines acceptance criteria, validates deliverables in pre-production, interprets quality metrics, maintains definitions and the glossary, and reports incidents
Head of Data Governance (Chief Data Officer)	Cross-cutting role: defines and evolves the model, coordinates domains and committees, manages the catalogue and the quality model, and prioritises the team's work
Data Custodian	Technically responsible for the platforms: access controls, security, availability, cataloguing, lineage and labelling
Data Architect	Defines the architecture and technical standards: modelling, integration, layers and design criteria
Data Developer	Builds load and transformation processes, datasets, models and dashboards, with quality controls and technical traceability

The key to the model is to separate decision-making (owner), functional management (steward) and technical implementation (custodian), with a cross-cutting coordination role above them.

The RACI matrix

For each activity you assign who carries it out (R), who is accountable for the result (A, only one), who is consulted (C) and who is informed (I). An extract:

Activity	Owner	Steward	Gov. lead	Custodian	Architect	Developer
Define the domain's data and concepts	A	R	C	C	C	I
Prioritise the domain's work	C	C	A/R	C	C	I
Define quality rules	I	C	A	R	C	C
Maintain catalogue descriptions	I	C	A	R	C	C
Validate in pre-production	I	A	C	C	I	R
Implement access controls and encryption	I	C	C	R	A	I
Publish a data product	I	A	C	R	C	C

When the product includes AI, case-specific roles are added: sponsor, business lead, technical lead, security officer, data protection officer and human overseer, who must never be the same person as the technical lead nor approve what they oversee.

The governance bodies

They are introduced progressively, so as not to add bureaucracy before there is an operational foundation:

Body	Purpose	Frequency
Decision Committee	Corporate criteria, priorities across domains, conflicts and sources of authority	Monthly
Operational Committee	Requests, quality, catalogue, lineage and incidents; prepares proposals	Weekly at first, fortnightly afterwards
Functional meeting	Harmonise definitions across stewards	On demand
Strategic Committee	Multi-year roadmap, maturity targets and investments	Every six months, once maturity justifies it

In the first phase, two standing bodies are enough: the Decision Committee and the Operational Committee. All of them take minutes and record their agreements in a decision log (identifier, body, context and alternatives, decision, owners, affected assets and status), which avoids reopening discussions that have already been settled.

If the organisation uses AI, it is advisable to have an AI governance board that decides on the uses of AI, while the data governance committee decides on the data those uses need. The AI officer attends the committee when data from AI systems is discussed, and vice versa.

A single process for requests

Every data need (a new product, an enhancement, a new source, a quality improvement, an incident or an access request) comes in through a single front door, the request tool, and is synchronised with the technical team's backlog (for example, Azure DevOps). This gives end-to-end traceability, and closing the task closes the request. Prioritisation takes place in a monthly cycle with the owners, based on value, urgency, dependencies, complexity and the risk of not doing it.

Where to start: the maturity assessment

Data governance does not start with buying a tool, but with knowing where you are starting from. The reference is UNE 0080, which assesses the 22 processes of the specifications UNE 0077 (governance), UNE 0078 (management) and UNE 0079 (quality) on two planes: the capability of each process (from 0 to 5) and the maturity of the organisation (from 1 to 5).

Level	What is needed
1. Performed	Identify the main systems and sources
2. Managed	Data policy and strategy, owner and steward in the priority domains, first quality rules
3. Established	Domain model in operation, head of data governance, active bodies and a catalogue with mandatory metadata
4. Predictable	Quality and usage metrics with targets and thresholds, and a dashboard
5. Innovating	Continuous improvement and new uses of data with risks under control

The realistic recommendation: start with one or two priority domains, consolidate level 2 in the first year and then move towards level 3, without skipping levels. UNE 0085 helps move from diagnosis to implementation with a gap analysis and a roadmap. In the public sector, the Model Data Governance Ordinance of the Spanish Federation of Municipalities and Provinces (FEMP) and the materials on datos.gob.es are the starting reference.

How to classify domains

Each domain has a type that indicates its nature and the governance criteria that apply to it. Tools such as Microsoft Purview use this classification:

Type	What it groups	Example
Functional unit	Data from a function tied to a stable unit	Accounting
Line of business	An activity or service with cross-cutting use cases	Customer or citizen services
Data domain	Homogeneous information regardless of who generates it	People, territory
Regulatory	Data with specific legal requirements and reinforced controls	Health data, census data
Project	Data from a temporary initiative, such as an AI pilot	Integrated, archived or retired when it ends

An example of a domain with subdomains: City and environment, with Mobility (traffic counts, car parks, bus routes), Waste (containers, routes, tonnes per fraction) and Energy consumption (electricity, gas and water in buildings and street lighting). They share terms such as “district” or “public road”, and each defines its own, such as “waste fraction” or “traffic count”.

Each role, day to day

• Head of data governance: entry point for the owners' requests; meets them every month to prioritise; maintains the team's backlog; is accountable for deliverables even without developing them; looks after the data platform and the catalogue; escalates cross-domain blockers and promotes training.
• Data architect: validates the architecture of each new product, provides guidance on modelling and source integration, sets security and access requirements, and ensures that deliverables come with the technical metadata needed for lineage.
• Data custodian: registers assets in the catalogue, maintains technical metadata and lineage, applies classification and labelling, configures quality rules and checks before publication that each deliverable meets the minimum requirements.
• Data developer: documents requirements and design with the steward and the architect, builds loads, transformations, models and dashboards, runs the technical tests and hands the custodian the information on sources and dependencies.
• Data owner: turns the needs of their domain into traceable requests, prioritises them, provides stewards for requirements and validation, and escalates conflicts.
• Data steward: acts as the bridge between the source system and what is published; approves the specification, validates calculations and interpretation in pre-production and does not approve go-live if the metadata is not in the catalogue.

How decisions are made

Level	Who decides	What they decide
Organisational	Decision committee	Priorities across projects, corporate criteria, cross-domain conflicts, sources of authority
Coordination	Operational committee	Technical coordination, validation of solutions, preparation of proposals
Domain	Data owner	Definitions, domain priorities, access to its data
Data product	Data steward	Functional validation, quality criteria, harmonisation of definitions

By default, decisions are made by consensus. Anything not resolved at its level is escalated through a defined path, with indicative deadlines so that nothing gets stuck:

Type of issue	Path	Indicative deadline
Functional definition	Steward → owner → decision committee	5 working days per level
Technical conflict	Developer → architect → head of governance → operational committee	3 working days per level
Priorities across domains	Owner → head of governance → decision committee	10 working days per level
Security or data protection exceptions	Custodian → head of governance → committee, with security and data protection	Immediate

A monthly meeting that makes decisions

The decision committee works if it is short and well prepared. A typical 60 to 75-minute agenda:

1. Work in progress: progress, deviations and blockers (10–15 min).
2. Pending requests by domain (10 min).
3. What each owner needs prioritised and why (10–15 min).
4. Prioritisation decisions based on available capacity (10 min).
5. Escalated incidents and conflicts (10 min).
6. Governance decisions: criteria, sources of authority, new integrations.
7. Close: agreements, owners and decision log (5 min).

Requests, with type and status

For the process to work, each request has a type, which determines how it is handled:

Type	Example
New data product	A dashboard that does not exist yet
Enhancement	A new field or indicator in an existing product
New source or integration	Bringing in the data from an application
Quality improvement	Fixing recurring duplicates
Incident	An indicator showing incorrect data
Access request	Access to a data product
Definition change	Modifying a glossary term
Governance request	Declaring a source of authority

And a set of minimum fields: title, type, requester, domain, affected product, functional description, impact and urgency, acceptance criteria and sensitivity. The statuses (new, under analysis, approved, in progress, under review, resolved or rejected) are synchronised between the request tool and the technical backlog, so the requester always knows where their request stands.

Process indicators: requests logged, approved and closed per period and domain, average time to approval and to closure, and percentage of requests with full traceability (request, task, code and deployment).

Common mistakes

• Organising data by application or by org chart, with no owner or source of authority.
• Appointing roles without giving people time to perform them: a data steward without recognised time allocation stewards nothing.
• Setting up every committee from day one and seeing them become empty shells within three months.
• Leaving documentation until the end of the project.
• Skipping maturity levels by wanting an advanced tool before having the basic processes in place.

At Bidatia we design and implement data governance models: maturity assessment, roles, committees, catalogue and quality. To go further, read about metadata management and which regulations apply to AI and data.