Rules
Part of The honest guide to data governance as of 2027
Data governance mistakes compared: documents versus real agreement
Data governance failures that yield documents instead of agreement: policy before definitions, cataloging everything, and councils that decide nothing.
Governance work fails in public and slowly. A program is announced, a committee meets, documents accumulate, and two years later the same two numbers still disagree in the same meeting.
The nine data governance mistakes below run in two directions. One kind produces a document: a policy, a catalog entry, an issue log. The other produces an agreement somebody has to defend in a meeting.
What to take away
- Governance that starts with policy produces policy. Governance that starts with one contested number produces agreement.
- Most of these mistakes substitute an artifact for a decision, because artifacts can be delivered and decisions have to be made by someone.
- The scope question settles almost everything: govern a short list properly, or govern everything nominally.
- The document version has names you will meet again: a DAMA-DMBOK chapter, a DCAM score, a Collibra catalog entry. The agreement version does too: a dbt metric, a Snowflake role, a Kimball Type 2 row.
1. Writing the policy before settling a single number
A policy document is the natural first deliverable, and it commits nobody to anything. DAMA International's DAMA-DMBOK is the reference book for data management practice, and an EDM Council DCAM assessment scores capability without settling which revenue figure is correct. Neither resolves a dispute, and the disputes continue.
Take the number that causes the most arguments, name an owner, write the definition, and switch everything to it. Put it where queries read it: a dbt metric, a Looker LookML measure, or a Cube model. Then write the policy afterwards, describing what you did. It will be shorter and it will be true.
2. Cataloging every table instead of the contested concepts
Inventorying the whole estate feels like the responsible start. Collibra, Alation, Atlan and Informatica will ingest tens of thousands of tables, and the open-source options Apache Atlas, LinkedIn DataHub and Lyft's Amundsen cost only engineering time. Most entries describe tables nobody queries, owned by nobody, going stale from the day they publish.
Catalog the short list of concepts the business argues about, and leave the rest undocumented until somebody needs it. Twenty or thirty entries with named owners beat ten thousand without.
A catalog nobody trusts is worse than no catalog, because it invites people to rely on stale entries.
3. A council that reviews but cannot decide
A cross-functional group meets monthly, reviews issues, and escalates. Nothing is decided, because deciding would mean one department losing its version of a number. ISO/IEC 38500, the governance-of-IT standard, expects a governing body to evaluate, direct and monitor, and to hold the authority for all three.
The fix is to give the group the power to name an owner and to ratify a definition, and to make the outcome of every meeting a decision rather than an action item. If it cannot decide, it is a forum, and it should be called one.
4. Automated checks on easy fields instead of business meaning
Automated checks appear where checks are simple: not null, in range, unique key. dbt ships four built-in generic tests, unique, not_null, accepted_values and relationships, and plenty of teams never move past them. Great Expectations, Soda Core and Elementary add more of the same structural checks. Business meaning still needs somebody to say what correct means.
This is the streetlight effect in operational form. The checks are where the light is, and the failures are elsewhere. Monte Carlo, Bigeye and Anomalo instead watch Snowflake, BigQuery and Databricks tables for anomalies, which finds breaks but not wrong definitions.
Write one meaningful test per governed concept, even if it is crude, before adding a tenth structural test.
5. Approving access tickets instead of owning roles
Approving access requests is visible, constant, and satisfying, and it consumes the entire capacity of a small governance function. Access matters, but the rule is simple enough to automate: default closed, granted by role, reviewed on a schedule.
That is the principle of least privilege applied to data, and once the roles exist it should require almost no meetings. NIST SP 800-53 carries it as control AC-6, and the NIST RBAC standard, INCITS 359-2004, defines the role model underneath.
Turn access into a role model and a review calendar, then spend the freed time on definitions. Snowflake, BigQuery and AWS IAM all grant by role, and Okta and SailPoint run the review cycle.
6. Assigning ownership to the system instead of the concept
Ownership gets assigned to whoever runs the database. That person can tell you what the field contains and cannot tell you what it means or whether it should change. DAMA-DMBOK separates the data owner, the system owner and the data steward for this reason.
Assign ownership to the concept, in the part of the business that would have to change its behavior if the definition changed. A revenue definition belongs to finance, not to the warehouse team. The system owner is a separate and also necessary role.
7. Correcting a definition without deciding what happens to history
A definition is corrected. Somebody has to decide whether prior periods are restated or the change applies forward only, and that decision is usually made by whoever writes the query.
The pattern of handling this well is old and well described. Ralph Kimball's The Data Warehouse Toolkit sets out slowly changing dimensions as Type 1, which overwrites the old value, and Type 2, which adds a dated row. dbt snapshots and similar features in other tools implement the same idea.
A written definition and a change log are the same discipline that analytics foundations metrics describes for rates, averages and cohorts.
Decide explicitly, announce before the change lands, annotate the charts on the date, and keep the prior figure recoverable.
8. Reference data living in somebody's spreadsheet
Customer hierarchies, product groupings, region mappings: the small tables everything joins to. They live in a file, maintained by one person, with no history and no review. Handling them properly is what master data management means, and most organizations need a very small amount of it rather than a program.
Informatica MDM, Reltio, Stibo Systems and SAP Master Data Governance sell the full version, with matching rules, survivorship and a change history.
Move the two or three that matter into a versioned, owned place with a change log, and leave the rest alone.
9. Measuring the governance function by output
Policies written, entries cataloged, issues logged. All countable, all easy to increase, none connected to whether anything got better. A DCAM score or a catalog coverage percentage climbs whether or not the revenue number stops disagreeing.
Measure the disputes that stopped: concepts with a single agreed definition in use everywhere, and the count of numbers still calculated two ways. DataHub, Alation and the dbt lineage graph will show whether old dashboards still read the retired field. Those numbers are hard to move and hard to fake.
Which to fix first
If the function is new, do the first one and nothing else for a quarter. One contested number, settled properly, with an owner and a written definition and every downstream use switched over, buys more credibility than any document.
If the function already exists and is stalled, look at the third mistake. A group that cannot decide is the usual reason a governance effort produces artifacts instead of agreements.
Related reading on this site
The full account of what governance consists of is in data governance. The sponsor-level errors that damage a whole intelligence function are in nine business intelligence mistakes.
The setup-phase errors are in the mistakes made while a data function is being built. Definition work is covered in writing a metric definition. The publication tiers that decide how much governance a given artifact needs are in the three publication tiers.
Common questions
Leadership has asked for a governance policy. Can we refuse?
Write a short one, then spend the quarter settling a number and use it as the worked example. You get the document and something real, and the document is better for having a case behind it.
How small can a governance function be?
One person part time can run a short list of concepts, a role-based access model, and a review calendar. Snowflake roles and an Okta review cycle cover the access half without meetings. What one person cannot do is catalog an estate, which is a good reason not to try.
Our council has met for a year and decided nothing. What now?
Change the agenda to one contested number per meeting, with the requirement that the meeting ends with an owner named. If that still produces nothing, the group lacks authority and the fix is above it.
Who decides when two departments both insist their definition is correct?
Someone senior to both, once, in a documented decision. Governance cannot resolve a disagreement about whose calculation wins; it can only make sure the question reaches a person who can.
