Governance and operating models

Data governance answers two questions about a data asset: who decides, and who answers for the outcome. Everything else, the policies, the standards, the forum that meets monthly, exists to record and enforce those two answers. Where they are unwritten, an organisation has documentation rather than governance, and the difference shows the first time two teams disagree.

The decisions themselves are concrete, and it is worth writing them out because abstraction is where governance programmes go to hide. Which definition is authoritative when two systems disagree. Who approves access when someone wants to use an existing dataset for a new purpose. What quality level is acceptable before a figure reaches a board pack or a regulatory return. Whether a producer may make a change that breaks a downstream consumer, and on whose authority. An organisation that cannot name the person holding each of those for a given asset does not govern that asset, whatever its policy library says.

This gives a usable test, and it is deliberately unglamorous. Take one named asset, not the estate. Ask, from records rather than from memory, who approved its current definition, who signs off access to it, and who owns the quality rule it is measured against. Three names, three records. Where the answer is a committee, ask which individual is accountable when the committee is wrong, because a body cannot be held to account and a person can.

The corollary is that a policy naming no decision-maker for a named asset is advice. It may be good advice. It will not settle the customer count argument, because both directors can comply with it and still disagree.

The data owner is accountable. One named business role, senior enough to be listened to, decides the purpose the asset serves, who may access it and what quality is acceptable, and answers when the asset causes harm. Ownership here means accountability rather than property: the owner does not own the records, the organisation does.

The data steward is responsible for meaning day to day. Stewards curate definitions, hold the business glossary entries, watch the quality measures, chase issues to closure and speak for the asset when a system around it is redesigned. A steward carries out governance decisions; the owner makes them.

The data custodian runs the platform. Storage, backup, access enforcement, encryption and the pipelines that move the data are custodial work. It is a technical responsibility rather than an ownership claim, and confusing the two is how a platform team ends up setting policy nobody asked it to set and nobody reviews.

The figures above set this out twice, once as a map of roles around a single accountable owner and once as RACI applied to one data action rather than to a department. The second view is the more useful of the two in practice, because the unit of assignment is the action. Approving a definition, granting access for a new purpose and changing a retention period are different decisions and will not always sit with the same person, whereas a role-based matrix drawn at department level tends to produce a grid in which everybody is consulted and nobody is accountable.

Titles vary by organisation and arguing about them wastes the meeting. What must survive translation is the split: one accountable decider, a named party responsible for meaning, and a technical party that implements rather than decides. Where a single team holds all three, note it and be honest about what has been lost, which is the independent check that the platform is doing what the business asked rather than what was convenient to build.

An operating model is the arrangement that decides how much data work sits with a central team and how much sits with the business domains, and what each side is accountable for. Three shapes are worth knowing, and only one of them is usually chosen deliberately.

A centralised model puts pipelines, definitions and quality with one team. It buys consistency and gives every question a single place to go, which is exactly what a young data function needs. It fails by becoming the queue that every domain waits in. Zhamak Dehghani named that failure precisely in May 2019, describing disconnected source teams, consumers competing for a place on the platform team's backlog, and an over-stretched central team in the middle. Organisations abandon the centralised model at a certain size not because it was the wrong choice but because it stopped scaling.

Data mesh, set out in the follow-up article of December 2020, pushes ownership outward on four principles: domain-oriented decentralised data ownership and architecture, data as a product, self-serve data infrastructure as a platform, and federated computational governance. The fourth is the one most often dropped, and dropping it is why mesh programmes produce inconsistency rather than autonomy. Dehghani's argument is that some concerns have to be standardised globally, such as how a customer is identified across domains, precisely so that data can be correlated across boundaries, while modelling decisions inside a domain stay with the team that knows the business. The standards are then encoded in the platform and applied automatically rather than requested in a meeting.

The hybrid is where most organisations land, and the figure above treats it as a design rather than as a failure to choose. The centre supplies standards and vocabularies, the platform and pipelines, lineage and catalogue, and identity and access, so that owning a data product is affordable for a domain that has other work to do. The domains own their products, their definitions, their quality and their roadmap. The two quiet cards on either side of that figure name the extremes it is drawn against: everything central becomes a request queue, everything devolved loses interoperability.

Choose on evidence rather than on the popularity of a pattern. How many domains can genuinely staff and own a data product today, as opposed to how many would like to. Where does the queue actually form, at ingestion, at modelling or at access approval, because moving ownership past the bottleneck does nothing. And can the centre supply a platform rather than a service desk, since a mesh without self-serve infrastructure simply relabels the backlog as somebody else's problem. Where the honest answer is that two domains are ready and eleven are not, the honest model is a hybrid that starts with two.

Governance becomes operational when a decision is recorded somewhere a machine can read it. Two artefacts do most of that work, and both are taught in full elsewhere in this course, so what matters here is the governance role each one plays rather than how it is built.

A data catalogue is the register of who decides. An entry that lists a schema and a row count is a search result. An entry that names the accountable owner, the steward, the meaning of each field, the lawful-use constraint, the retention class and the quality rule is the written form of an allocation of decision rights, and it is what lets a new joiner find the decider without knowing who to ask. The catalogue mechanics, active metadata and the lineage that supports impact analysis are the subject of the Catalogues, lineage and active metadata module in the data and AI stage.

A data contract is where one specific decision right is enforced: whether a producer may make a change that breaks a consumer. Written as an interface rather than as a policy document, it states the schema, the meaning, the quality expectations, the freshness commitment, the accountable owner and the change policy, and the checks run when data is published. That converts an approval right into something that either passes or blocks, rather than something that is discovered three days later in a broken board pack. Contracts as a product specification are covered in the data as a product module in the engineering and platforms stage.

The governance and stewardship loop in the figures above is the cycle these artefacts sit inside. Policy sets direction, standards make the direction specific, stewardship applies it to real assets, and the evidence that comes back changes the policy. The loop is what stops governance being a launch event. An organisation that never reads the evidence step has a policy that ages without anyone noticing.

The DAMA Data Management Body of Knowledge maps the knowledge areas of the discipline: what the functions, roles and methods of data management are and what vocabulary to use for them. DAMA describes it as a reference and a framework rather than a prescriptive standard, and states plainly that it defines principles and practices without prescribing tools, technologies or methodologies. Use it for scope and vocabulary. Do not use it as something to certify against, and do not present a DMBOK chapter as a control your auditor can test.

Cite the edition actually read, because this is where the common error sits. The current text is the 2024 revision of DAMA-DMBOK 2.0. DAMA describes that revision as a maintenance release and says no material changes were made to the overarching framework, the knowledge areas or their definitions.

DMBOK 3.0 is a separate matter and is a project rather than a book. DAMA held its kick-off on 25 June 2025 and describes the aim as modernising the framework for current challenges, adding emerging topics such as artificial intelligence, cloud and modern data platforms while keeping the foundational principles. There is no published edition and no publication date on the project page. A citation to a third edition of DMBOK therefore points at something that does not yet exist, and a strategy document that leans on it is leaning on work in progress.

ISO/IEC 38505-1:2017 does what DMBOK does not. It gives guiding principles for members of governing bodies on the effective, efficient and acceptable use of data, by transposing the governance principles and model of ISO/IEC 38500 to the governance of data, and it establishes a vocabulary for the field. That makes data an accountability of the governing body rather than a task delegated to a team, and it is the instrument to reach for when the argument is about who should be answering rather than about what should be built.

ISO/IEC 42001:2023, Information technology, Artificial intelligence, Management system, published in December 2023 as a first edition, specifies requirements for establishing, implementing, maintaining and continually improving an artificial intelligence management system. It is aimed at organisations that provide or use products and services based on artificial intelligence, of any size and in any sector, and it is a management system standard, which means it governs how the organisation runs the work rather than listing the technical controls a given model needs.

Note what none of the three supplies. None of them tells you which definition of active customer is authoritative in your organisation, which is the decision the opening example turned on. Frameworks describe how to decide and what to record. The deciding is local work, and no amount of framework adoption performs it on your behalf.

Artificial intelligence has changed the urgency of data governance rather than its substance. A model inherits every ambiguous definition, quality defect and unclear lawful basis in the data it learned from, and it applies them at a rate and a scale that no quarterly management report ever exposed. The customer count argument that ran for two years in a boardroom becomes a training set property in an afternoon.

Two instruments make that concrete. ISO/IEC 42001:2023 supplies the management system, so the organisation has a stated way of establishing and improving how it develops, provides or uses artificial intelligence, in the same shape as other management system standards.

Article 10 of the EU AI Act does something narrower and sharper. It places data governance duties directly on the data sets behind high-risk systems, and it is careful about which sets. Where a high-risk system is built with techniques that train a model on data, the duties attach to its training, validation and testing sets. Where a high-risk system is not trained on data at all, they attach to the testing sets alone. The practices it names read as a data governance checklist with legal force: the relevant design choices; the data collection process and the origin of the data, including the original purpose of collection where personal data is involved; the preparation operations such as annotation, labelling, cleaning, updating, enrichment and aggregation; the assumptions about what the data measures and represents; an assessment of the availability, quantity and suitability of the data sets needed; examination for biases likely to affect health, safety or fundamental rights or to produce discrimination; measures to detect, prevent and mitigate those biases; and identification of gaps or shortcomings that prevent compliance, together with how they are to be addressed.

The Article also sets a quality bar in careful language. Data sets must be relevant, sufficiently representative and, to the best extent possible, free of errors and complete in view of the intended purpose, with statistical properties appropriate to the persons or groups the system will be used on, and they must take account of the geographical, contextual, behavioural or functional setting in which the system is to operate. That last requirement is where organisations are caught out, because a model trained on one market and deployed in another fails it without any single record being wrong.

Read the two together and the practical position is clear. Every item on that list is an artefact this course has already asked for: a stated purpose, a recorded provenance, a written definition, an owned quality rule, an assessment somebody signed. AI-ready data is not a new category of data. It is ordinary governed data, with the evidence attached, produced by an organisation that allocated its decision rights before a regulator asked who had.