Kindly fill up the following to try out our sandbox experience. We will get back to you at the earliest.
Metadata governance in practice: who owns it, what a metadata standard specifies, the review workflow that keeps entries true as schemas change, and what fails.
Updated on
Metadata governance is the set of policies, roles and review steps that decide what your metadata must contain, who may change it, and what has to be true before a change goes live. It is a discipline inside data governance, aimed at one specific asset: the description of your data rather than the data itself.
The distinction that matters in practice is what each one produces. Data governance produces policies about the data: who may read a table, how long a record is kept, what quality level a report depends on. Metadata governance produces a different set of artifacts: a metadata standard, a list of required fields, an ownership register, and a review workflow. Metadata management is neither of those. It is the machinery that collects, stores and serves metadata, and it will happily run with no governance at all, which is exactly how organizations end up with a catalog full of accurate schemas and no idea what anything means.
Each row below is written to stand on its own, so it still answers something if you read only that line.
| Question | Data governance | Metadata governance | Metadata management |
|---|---|---|---|
| What it governs | The data: access, quality, retention, privacy, classification | The metadata about that data: which fields exist, what they mean, who sets them | Nothing. It is the machinery, not a rule set |
| What it produces | Policies, a decision forum, an approved risk position | A metadata standard, required fields, an ownership register, a review workflow | A metadata store, a model, an API, and usually a catalog interface |
| Who is accountable | The chief data officer or the head of data | A governance lead inside that same program, with one named owner per asset | Platform engineering |
| What it decides | Whether a use of data is permitted | Whether a description of data is complete and current enough to publish | How metadata gets from the source system into the store |
| How you know it works | Fewer incidents, and audits that pass without a scramble | Required fields are filled on the assets people actually query, and stay filled after the next schema change | Metadata arrives without anyone typing it |
| How it fails | Policy exists on paper and nobody enforces it | Fields are filled once at launch and drift silently from then on | Metadata is collected accurately and nothing consumes it |
If you want the wider picture of the parent discipline first, our explainer on data governance concepts and pillars covers the layer this sits inside, and the separate question of how a data catalog differs from metadata management is answered in its own article rather than repeated here.
Metadata governance sets the rules for creating, keeping and using metadata at every stage of the data lifecycle. Inside a working data governance framework, those rules are what let an organization organize, understand and reach its data without asking a person every time. Good metadata governance gives data the structure and context it needs so that people can make better decisions, and it makes data stewards accountable for work that would otherwise belong to nobody.
Data stewards matter here more than any tool. As data privacy rules tighten, the ability to say who decided that a column is personal data, and when, is what separates an audit that passes from one that does not. Stewardship is the human half of metadata governance and it does not scale by being asked nicely; it scales by being written into a workflow, which is the subject of a later section.
Metadata governance is owned by the head of data, run day to day by a governance lead, and executed by one named owner per asset. That is the whole model, and the third part is the one organizations skip. A governance council can approve a standard, but it cannot write a description of a table it has never queried, and it cannot be paged when that description goes stale.
The rule to hold to is that every governed asset carries exactly one accountable person in its owner field, identified by name, not a team, not a distribution list and not a shared inbox. A team can be responsible for the work. Only a person can be accountable for the answer. When an owner leaves, the asset does not quietly inherit a new one; the governance lead reassigns it explicitly or it is flagged as unowned.
| Role | What this role decides | What this role may not decide |
|---|---|---|
| Head of data, accountable | Whether the program exists, what is in scope, who is appointed to it, and what it is funded to do | What a business term means inside a domain, or whether a specific table is accurate |
| Governance lead, runs it | The metadata standard, which fields are required, the classification scheme, the review windows, and how disputes are settled | The content of any individual asset entry |
| Domain data steward | Business definitions, glossary terms and classification for the assets inside their domain | Standards that apply to other domains, or the required field list |
| Asset owner, one named person per asset | The description, the contact, whether the asset is published, deprecated or hidden | The standard itself, or the classification scheme |
| Producing engineer | Technical metadata: schema, contracts, column types, lineage emission, freshness signals | Business definitions, glossary links or classification |
| Data consumer | Nothing. Raises a dispute against an entry, which the steward answers within the review window | Anything. The dispute route is the point; silent edits are not |
The technical half of that table is the part most teams already have without calling it governance. Schema, types and lineage are emitted by the platform rather than typed by a person, and our guide to technical metadata covers what a producing system can supply on its own.
A metadata governance framework has four working parts. They are not stages and they do not happen in order; each one keeps failing in a different way if the others are absent.
Metadata management is the practices and tools that create, keep and watch over metadata about your data. It is the layer governance acts on, and without it a governance standard has nowhere to be enforced. If you want the category explained on its own terms, including what each type of metadata records, our article on metadata types and what each one records covers it, and this page assumes it.
A metadata standard makes different systems and formats describe the same thing the same way. Without one, two teams document the same customer table with different field names and neither entry can be queried against the other. The next section says what a standard has to specify to earn the name, because "adopt metadata standards" is the single most common piece of empty advice on this subject.
Policies set the rules for managing metadata: who may create an entry, who may change a classification, what happens when two domains disagree about a definition. A policy that does not name a person and a window is a preference. The review workflow further down is the procedural half of this component, written out in full.
Cataloging puts metadata in order so it can be found and managed. Its value is entirely downstream of the other three parts. A catalog populated by automated harvesting fills with schemas in a week and then stops improving, because harvesting can supply what a column is called and never what it means.
| Component | Description | Benefits |
|---|---|---|
| Metadata Management | Technologies and practices for managing metadata | Enhanced data accessibility and accuracy |
| Metadata Standards | Guidelines for consistency across data systems | Improved interoperability and compliance |
| Metadata Policies | Defining processes for metadata governance | Structured guidance for data accuracy and security |
| Metadata Cataloging | Organizing metadata for easy retrieval | Better data quality and governance |
A list of field names is not yet a standard. A standard specifies six things per field, and where any of the six is missing, two people who have never met will apply it differently. The table below gives the six, and next to each one shows how a real public standard handles it, so the shape can be copied rather than invented.
| What the standard must specify | How a public standard does it |
|---|---|
| A name and a stable identifier for the field | DCMI Metadata Terms gives every term a name, a human readable label and a URI that does not change, so two systems can agree they mean the same field |
| A written definition of what the field holds | Every DCMI term carries a definition, and many add a comment plus a domain and a range that say what kind of thing the field may describe and what kind of value it may take |
| Which fields are required and which are optional | W3C DCAT 3 marks title, description and distribution as recommended properties for a dcat:Dataset, so a catalog entry missing them is incomplete by the standard rather than by opinion |
| The class of asset each field attaches to | DCAT 3 defines dcat:Catalog, dcat:Dataset, dcat:Distribution, dcat:DataService and dcat:CatalogRecord, and properties are declared against those classes rather than floating free |
| The allowed values, where values are constrained | DCMI publishes nine vocabulary encoding schemes and twelve syntax encoding schemes alongside its properties, which is what stops a free text field from becoming twelve spellings of the same answer |
| How conformance is checked | This is where most internal standards stop. A named validation mechanism is what makes the other five enforceable, and the next section covers the one that works at build time |
DCMI Metadata Terms is a DCMI Recommendation dated 2020-01-20, and the Data Catalog Vocabulary (DCAT) Version 3 is a W3C Recommendation of 22 August 2024. Both were read on 6 September 2026. Neither has to be adopted wholesale. The reason to read them is that they have already solved the argument you are about to have about what a description field is for, and the DCMI Metadata Terms specification is short enough to read in an afternoon.
The practical version for an internal standard is a table with one row per required field and six columns matching the six above. Fifteen rows is usually enough to cover an entire warehouse. A standard nobody can hold in their head is a standard nobody applies.
Metadata does not decay on a schedule, so it cannot be reviewed on one. It decays the moment the thing it describes changes, which means the review has to be triggered by the change itself. A quarterly metadata audit is a way of discovering in October that a column stopped meaning what it said in July, by which point several reports have been wrong for a quarter and no list exists of which ones.
The workflow below is trigger based. Every row names what fires it, who acts, a recommended window, and the condition that must hold before the change is allowed to publish. The windows are Decube guidance and a starting point to argue with, not measured benchmarks.
| Trigger | Who acts | Recommended window | What must be true before it publishes |
|---|---|---|---|
| A column is added to a governed table | The producing engineer | Same change set as the code | Name, data type and a one sentence definition are set, and nullability is declared |
| A column is removed or its data type changes | The producing engineer, with the asset owner notified | Before the change merges | Downstream consumers are identified from lineage and told, and the contract version is raised |
| A new table is registered in the catalog | The asset owner | 5 working days | Owner, domain, classification and a description are set, or the table stays unpublished in the catalog rather than appearing empty |
| A classification changes, for example internal to restricted | The governance lead | 2 working days | The access policy is updated in the same change, and the previous classification is kept in history rather than overwritten |
| A business term definition changes | The domain steward, approved by the governance lead | 10 working days | Every asset carrying that term is either relinked or explicitly approved again against the new wording |
| An asset owner leaves the organization | The governance lead | Before the leaving date | A named replacement is recorded, or the asset is flagged unowned. It is never silently reassigned to a manager |
Two of those rows only work if something can refuse the change, which is why the workflow needs an enforcement point rather than a reminder. The clearest one available today is a contract on the model that produces the data. dbt model contracts work exactly this way: once a contract is set to enforced, the model must declare every column's name and data type. At build time the tool runs a preflight check that the query returns exactly that set of columns, includes those names, types and constraints in the DDL it submits to the warehouse, and fails the build if the query produces anything else. Removing a column, changing a data type, changing a constraint or deleting a contracted model are all treated as breaking changes and raise a contract error.
That is the difference between a metadata policy and a metadata rule. A policy says the definition should be updated when the column changes. A contract makes the column change fail until it is. Read the dbt documentation for what your own warehouse enforces, because constraint support varies: on Postgres all four constraint types are enforced, while on Snowflake and Redshift only not null is actually enforced even though the others can be declared.
For the measure, count required field completeness on the assets people actually query, not across the whole catalog. A useful starting target is 95 percent completeness on the hundred most queried assets and no target at all on the rest. Catalog wide completeness rewards documenting dead tables, which is how a metadata program spends a quarter looking busy and changes nothing anybody notices. This target is our recommendation, not a published benchmark.
Almost every stalled metadata governance program has the same underlying mistake: it treats metadata as documentation, something written once to describe a system, rather than as a product with an owner, a consumer and a definition of done. The two look identical in a project plan and behave completely differently six months in.
| Where it shows | Metadata governed as documentation | Metadata governed as a product |
|---|---|---|
| What triggers an update | Someone remembers, or an annual audit asks | A change to the underlying asset fails the build until the metadata matches |
| Definition of done | The field is not empty | A named consumer can answer their question without asking a person |
| Ownership | A team name, a distribution list or a shared inbox | One named person, recorded on the asset, reassigned explicitly when they leave |
| What happens on drift | Nothing visible, until a number in a report turns out to be wrong | The pipeline fails and names the contract that broke |
| What gets measured | Assets cataloged, which rises fastest when you harvest dead tables | Required field completeness on the assets people actually query |
| Where it lives | A wiki page or a spreadsheet, edited by whoever opened it last | Version controlled next to the code that produces the data, reviewed like code |
| What it costs when it fails | Quiet, distributed and hard to attribute | Loud, immediate and attributed to one change |
The test is simple enough to run this week. Pick the three tables your analysts query most and ask, for each one, who would be paged if its description were wrong. If the answer is a team name for any of the three, the program is documentation, whatever the strategy deck calls it.
Setting up metadata governance needs a plan that fits the wider data governance program, so that data quality improves and risk is managed rather than described. It starts with talking to the people involved so they know what they are being asked to do, and it ends with those obligations written into a workflow that fires without anyone chasing it.
Governance committees help make decisions and keep people accountable, and they are the right place to set and revise metadata policies. Automation is what makes those policies survive contact with a real backlog: technical metadata that arrives on its own leaves human effort for the definitions only a person can write. Continued training keeps the data culture in place, because a standard that nobody has been taught is a standard nobody follows.
Sequenced, and without dates attached, the order that works is this. Appoint the governance lead first, because a program with no runner is a document. Write the standard second, limited to the fields you will actually require. Assign one named owner per asset third, starting with the hundred most queried assets and ignoring the rest. Wire the review triggers fourth, and only then buy or configure tooling, because a tool bought before the standard exists will impose its own and you will inherit somebody else's field list.
Tooling belongs at that fifth step rather than the first. Decube's data governance software handles the classification and access side of that program, and its metadata management software supplies the automated collection, column level lineage and catalog surface the workflow above depends on.
One part of metadata governance is not optional and has a legal shape already defined for it. Under Article 30 of the GDPR, each controller must maintain a record of processing activities under its responsibility, and the article lists exactly what that record has to contain: the name and contact details of the controller and, where applicable, the joint controller, the representative and the data protection officer; the purposes of the processing; a description of the categories of data subjects and of personal data; the categories of recipients, including recipients in third countries or international organisations; where applicable, transfers to a third country or international organisation with the documentation of suitable safeguards; where possible, the envisaged time limits for erasure of the different categories of data; and, where possible, a general description of the technical and organisational security measures.
That is a metadata standard written by a regulator, with seven required fields and a named accountable party. Article 30(3) requires the record to be in writing, including in electronic form, and Article 30(4) requires it to be made available to the supervisory authority on request. Article 30(5) exempts organizations employing fewer than 250 persons, but only if the processing is occasional, poses no likely risk to the rights and freedoms of data subjects, and involves no special category data or criminal conviction data. Most companies with a data warehouse fail at least one of those three conditions, so the exemption reads wider than it is. The wording above is quoted from the consolidated text of Regulation (EU) 2016/679 on EUR-Lex, read on 6 September 2026.
The operational point is that the record of processing and your internal metadata are the same information kept twice. If categories of personal data and retention periods are already required fields on every governed asset, the Article 30 record is a query. If they are not, it is a spreadsheet somebody rebuilds by hand every time a regulator asks, and it is wrong by the time it is finished.
Organizations run into the same four problems, and each one has a specific answer rather than a general one. Changing privacy rules make it hard to keep up, and the answer is to hold the classification scheme in one place so a rule change edits one definition instead of a thousand entries. Volume makes accuracy hard, and the answer is to scope required fields to queried assets rather than to everything harvested.
Getting people to adopt good practice is the third, and it is not solved by training alone. Adoption follows enforcement: teams document what the build will otherwise refuse, and treat as optional whatever only appears in a policy document. The fourth is security and privacy of the metadata itself, which is more sensitive than teams expect, since a column named ssn_hash tells an attacker where to look without any data being exposed. Classification, access control on the catalog and an audit trail of who changed a classification are the three controls that matter, and the third is the one most often missing.
Tools reduce the effort but they do not remove the decisions. Decube's data governance software covers classification, access and column level lineage, which is enough to make the workflow in this article enforceable rather than aspirational.
Metadata governance works when it stops being a description of good intentions and starts being a set of rules with owners and triggers attached. Name the accountable person for each asset. Write a standard that specifies six things per field rather than listing field names. Trigger review on schema change and enforce it at build time. Measure completeness on the assets people query. Those four moves are the whole program, and each one is a decision a team can make in a meeting rather than a project it has to fund.
A tailored strategy still matters, because the required field list for a bank and for a games studio are not the same list. What does not change is the shape: a standard, an owner, a trigger, a measure.
Data management is difficult and working with people who have set up these programs before shortens it considerably. If you want to see what the workflow above looks like inside a working platform, with classification, ownership and column level lineage already wired together, book a demo with Decube and bring the three tables you most want to trust.
Metadata governance is the set of policies, roles and review steps that decide what your metadata must contain, who may change it, and what has to be true before a change is published. It is a discipline inside data governance aimed specifically at the description of your data rather than at the data itself. In practice it produces four artifacts: a metadata standard, a list of required fields, an ownership register with one named person per asset, and a review workflow triggered by schema change.
Because metadata management will run perfectly well without it and produce a catalog nobody trusts. Automated collection fills a catalog with accurate schemas in a week, and then nothing improves, because harvesting can tell you what a column is called and never what it means. Metadata governance is what assigns the person who answers that second question and the deadline by which they answer it.
Four: metadata management, which is the machinery that collects and stores metadata; metadata standards, which make different systems describe the same thing the same way; metadata policies and procedures, which say who may change what and within what window; and metadata cataloging, which puts the result in order so it can be found. They are not sequential stages. Each one fails in a different way when the others are missing.
In this order. Appoint a governance lead, because a program with no runner is a document. Write a standard limited to the fields you will actually require, specifying for each one a name and identifier, a definition, whether it is required, the class it attaches to, allowed values, and how conformance is checked. Assign one named owner per asset, starting with the hundred most queried assets. Wire review triggers to schema change. Only then buy or configure tooling, because a tool bought before the standard exists will impose its own field list.
Four recur. Changing privacy rules, answered by holding the classification scheme in one place so a rule change edits one definition rather than a thousand entries. Data volume, answered by scoping required fields to queried assets rather than everything harvested. Adoption, which follows enforcement rather than training, since teams document what the build will otherwise refuse. And the security of the metadata itself, since a column name can reveal where sensitive data sits without any data being exposed.
Three controls carry most of the weight: a classification scheme held in one place and applied to every governed asset, access control on the catalog itself rather than only on the data, and an audit trail recording who changed a classification and when. The third is the one most often missing and the one a regulator asks for. Treat metadata as sensitive in its own right, because a column named ssn_hash tells an attacker where to look.
Name one accountable person per asset rather than a team. Specify six things per field in your standard instead of listing field names. Trigger review on schema change rather than on the calendar, and enforce it at build time with a contract on the producing model. Measure required field completeness on the assets people actually query rather than across the whole catalog. Reassign ownership explicitly when someone leaves rather than letting an asset inherit a new owner silently.
The head of data is accountable for the program, a governance lead runs it day to day, and one named person owns each individual asset. The third part is the one organizations skip, and it is the reason most programs stall. A team name in an owner field cannot answer a question, cannot approve a change and cannot be paged when a definition goes stale, so shared ownership behaves exactly like no ownership.
Five. A metadata store that can hold custom fields beyond what the vendor shipped. Automated collection of technical metadata, including column level lineage, so people write definitions rather than schemas. A classification scheme with access control and an audit trail on the catalog itself. An approval and review workflow that can hold a change until a named person signs it. And an API, so metadata can be read back out and enforced in the build rather than only browsed in a user interface.
Data governance is a rule set and metadata management is machinery. Data governance decides what may happen to the data: who may read a table, how long a record is kept, what quality level a report depends on. Metadata management is the collection, storage and serving of metadata, and it runs with or without those rules. Metadata governance sits between them, applying governance discipline to the metadata layer specifically.
A metadata management framework is the combination of a metadata model, the collection mechanisms that populate it, the interfaces that serve it, and the standards and policies that keep it consistent. The difference from a metadata governance framework is that the management framework describes the machinery and the governance framework describes the rules the machinery is held to. Buying the first does not give you the second.
Not on a fixed cycle. Review should fire on change, because metadata decays at the moment the thing it describes changes rather than at the end of a quarter. Recommended windows to start from: a new column is documented in the same change set as the code, a new table is completed within five working days or stays unpublished, a classification change is settled within two working days, and a business term redefinition is propagated within ten. Those are targets to argue with, not measured benchmarks.
First step to AI Readiness
Table of Contents
Sneak peek from the data world.
Bring lineage, quality, governance, and AI together in one platform—so your teams and AI agents can act with confidence.
_For%20light%20backgrounds.svg)
.svg){kind=small}
.webp)