Data governance: common questions and clear answers

Two people bring numbers for the same metric to the same meeting and the numbers disagree. Everyone stops discussing the business and starts discussing the data. Half an hour later the meeting ends with an action item to "align on the definition," which nobody does, and the same thing happens next month.

Data governance is what stops that. Not the committee, not the policy document: the specific, unglamorous artifacts that make one number the number.

What to take away

• Access sprawl happens one reasonable exception at a time.
• Definition changes are where governance earns its keep, because a changed definition silently rewrites the past.

Governance is a set of answers, not a program

Strip away the vocabulary and governance answers six questions about every important piece of data:

1. Who owns it? One name, not a team.
2. What exactly does it mean? A definition precise enough that two people implement it identically.
3. Who can see it? And what happens when someone new needs access. This is ordinary access control applied to data rather than to systems.
4. How do we know it is correct? Automated checks, not vigilance.
5. What happens when it changes? Who approves, who gets told, what happens to history.
6. How long do we keep it, and where can it go? Especially anything about identifiable people.

If your governance effort is not producing concrete answers to those six, it is producing documents. The distinction matters, because the documents version can run for a year and change nothing.

Ownership: one name, or it is unowned

Shared ownership is unowned. Every metric, table, and pipeline that matters needs one person accountable for it, not necessarily the person who built it, but the person who decides what it means and approves changes.

An owner's actual job is small and specific:

• Approve or reject changes to the definition.
• Answer "is this number right?" when someone asks.
• Be the escalation point when a quality check fires.
• Decide when the thing should be retired.

Two rules make ownership stick. First, ownership must be recorded somewhere a stranger can find it: in the table's metadata, in the model's documentation, on the dashboard tile. Second, it must transfer explicitly when someone changes role or leaves. Orphaned ownership is how a company ends up with critical pipelines nobody understands.

Definitions: write them so two people build the same thing

"Active user" is not a definition. This is:

Element	What it must state	Example of what goes wrong without it
Entity	User, account, workspace, or device	Per-user and per-account counts differ, and both get called "users"
Qualifying action	Which specific events count	One team counts logins, another counts any API call
Window	The lookback, and whether it is rolling or calendar	A rolling 28-day and a calendar-month figure never match
Timezone	Which zone the day boundary uses	Regional teams get different daily numbers from the same data
Exclusions	Internal accounts, test data, bots, deleted records	Internal usage inflates every engagement metric
Source of truth	The exact table or model it must be computed from	Two implementations drift the moment either source changes
Owner and last review	Name and date	Nobody knows whether the definition is current

Store definitions where they are computed, not in a separate wiki. A definition in a document and a calculation in a dashboard will diverge, and the document will lose. If your stack has a modeling or metrics layer, the definition belongs there as code, with the prose explanation attached to it.

Keep a short list of metrics that get this treatment. Trying to govern every column produces a catalog nobody maintains. Governing the twenty numbers that appear in executive conversations produces peace.

Access: default closed, granted by role, reviewed on a schedule

Access sprawl happens one reasonable exception at a time. Some structure that holds up:

• Classify data into a small number of tiers: public internal, restricted, and sensitive personal data is usually enough. More tiers than that and nobody remembers which is which.
• Grant to roles, not individuals. Individual grants are invisible and never get removed.
• Make requesting access easy and logged. If the official path is slow, people will copy data into spreadsheets, and now you have uncontrolled duplicates you cannot see.

A catalog is only as good as the discipline of the people filing cards into it, which is the whole of governance in one image. The formal handling of a definition that changes over time is old and well described as a slowly changing dimension.

• Review periodically. Pick a cadence you will actually keep, and treat departures and role changes as automatic triggers.
• Separate reading from exporting. Many people need to see a number; far fewer need to extract the underlying rows.

For anything involving personal data, the constraints come from the privacy regimes your organization operates under, and those are a legal question rather than a data-team question. Get the applicable requirements from counsel in writing, translate them into concrete rules about what may be collected, stored, joined, and retained, and record which rule came from where. Do not infer obligations from what other companies appear to do.

Quality: automated checks, run where the data lands

Data quality is not a review meeting. It is assertions that run on a schedule and fail loudly.

Start with the checks that catch the most breakage for the least effort:

• Freshness. Did this table update when it should have? This catches more real incidents than anything else on the list.
• Row volume. Is today's count within a plausible band of recent history? Catches partial loads and duplicated loads.
• Uniqueness. Is the primary key actually unique? Catches the join fan-out that silently multiplies every sum.
• Not-null on key columns. Catches upstream schema and form changes.
• Accepted values. Catches new categories appearing in a status field that downstream logic does not handle.
• Referential integrity. Catches orphaned rows after a source deletion.

Route failures to the owner, not to a shared channel everyone mutes. And write down the response: does the pipeline halt, or does it publish with a warning banner? Deciding that in advance is the difference between a controlled incident and an argument at 8am.

Change control: history is the fragile part

Definition changes are where governance earns its keep, because a changed definition silently rewrites the past.

Before any change to a metric that people watch:

1. Quantify the impact. Compute both versions over recent history and show the difference. If the change moves the number materially, that is a business conversation, not a technical one.
2. Decide about history. Restate the past under the new definition, or apply it from a cutoff date forward. Both are defensible; pick deliberately and record which.
3. Announce before, not after. People who watch a number need to know why it moved. Discovering it themselves costs you trust.
4. Annotate the charts. A visible marker on the date of the change saves years of future confusion.
5. Keep the old definition retrievable. Someone will need to reproduce a number from an old deck.

Small changes benefit from the same discipline in a lighter form. The rule of thumb: if a person outside the data team would notice, tell them first.

Lineage: know what breaks when something changes

Lineage is simply the ability to answer two questions: where did this number come from, and what depends on this table?

You do not need a sophisticated system to start. A dependency graph generated from your transformation code covers most of it, and knowing which dashboards read which models covers the rest. The value shows up in two moments: when a source schema changes and you need to know the blast radius, and when a stakeholder challenges a number and you need to trace it back to the source row.

How governance efforts fail

It becomes a committee with no authority. A group that recommends but cannot approve or block will be routed around. Give the function the ability to say no to a change, or do not create it.

It tries to catalog everything. Enthusiasm produces a complete inventory that is stale within a quarter. Cover what matters and let the long tail be undocumented.

It is enforced only on the data team. If analysts follow the process and the teams building the source systems do not, you are governing the symptoms. Upstream event naming and schema changes are where most quality problems originate.

It is written for auditors instead of practitioners. A policy nobody on the team can recall is not operating. The test is whether a new hire can find the owner and definition of a metric on their first week without asking anyone.

It has no failure mode. If nothing happens when a rule is broken, it is a suggestion. Attach a consequence: a blocked deploy, a failed check, a required approval.

A realistic starting sequence

Do not launch a program. Start with the numbers that already cause arguments:

1. List the metrics that appear in leadership conversations. Keep the list short.
2. Assign each one an owner, by name, and get their agreement.
3. Write the full definition for each, using the elements in the table above.
4. Implement each definition once, in one place, and point every consumer at it.
5. Add freshness and volume checks on the tables underneath them.
6. Establish the change-announcement habit for exactly those metrics.
7. Expand only when the first set is genuinely stable.

That sequence produces a visible result, the meeting where two numbers disagree stops happening, which is what buys you the room to do the rest.

Related reading on this site

Governance shows up most visibly in the delivery layer; see dashboards for how definitions and freshness belong on the page itself, and analytics foundations metrics for writing the definition itself. For the function whose arguments governance is meant to settle, see business intelligence; for the analysis that inherits every definitional gap, see how to work through a question; and for the recurring artifacts where drift shows up first, see building a report worth keeping.

Common questions

Do we need a dedicated governance role?

Not at first. Ownership distributed to the people who already build and use the data works well while the surface is small. A dedicated role becomes worthwhile when coordination across teams is the bottleneck rather than the work itself.

How do we handle a metric two teams genuinely need to define differently?

Give them different names. Two definitions with one name is the source of the problem; two clearly named metrics with documented differences is fine and often correct.

What about spreadsheets?

They will exist. Aim to make the governed path more convenient rather than banning the alternative, and pay attention to what people do in the spreadsheet after exporting, that step is usually a missing feature in your modeled data.

How do we prove governance is working?

Watch for the absence of specific events: fewer disputes about which number is right, fewer incidents discovered by stakeholders instead of by checks, faster answers to "where did this come from." Those are observable without inventing a maturity score.