Data governance 101: rules people can actually use

Finance says active customers are 48,200. Marketing says 61,900. Both screenshots hit the same Slack thread at 9:14 a.m. Nobody is lying. They just never agreed what a row means, who can change it, or what “good enough” quality looks like before a board chart freezes.

That mess is a data governance problem. Not a new BI tool problem. Not a “we need more dashboards” problem. Governance is the boring, powerful set of agreements that keep definitions, owners, access, and quality from drifting every quarter.

This is a practical guide for people who sit near the data: analysts, analytics engineers, product ops, and managers who keep getting blamed for conflicting numbers. You will leave with a plain definition, a small operating loop, a starter RACI, quality dimensions you can actually measure, and a 30-day pilot plan. For related vocabulary, see our Key Terms page and the companion post on master data management.

What you’ll learn

What data governance is in everyday work language (no binder theater)
The difference between governance, management, and “we bought Collibra”
A weekly loop you can run on one domain without a 40-person council
How to pick owners, decisions, and quality checks that stick
Common failure modes and a 30-day pilot you can start Monday

What data governance actually is

Data governance is the set of decisions, owners, and rules that make shared data trustworthy enough for real work. It answers questions like:

What does this field mean, in one sentence a new hire can apply?
Who can change the definition, and who only gets notified?
Who may see raw customer emails versus aggregated counts?
What quality bar must pass before a metric is “official”?
What happens when two systems disagree?

If you cannot answer those for a table people depend on, you do not have governance. You have hope and Slack archaeology.

Notice what is missing from that list: a 90-page PDF nobody opened, a logo slide about “data as an asset,” and a quarterly meeting that only reviews tool licenses. Those things sometimes appear later. They are not the work.

Governance vs data management vs tools

Layer	Job	Example
Governance	Decide and own the rules	“Active customer = paid in last 90 days; owner = Finance Ops”
Data management	Build and run the pipes	dbt models, warehouse jobs, access grants
Tools	Store and enforce	Catalog, quality monitors, IAM, ticketing

Tools without decisions become expensive shelves. Decisions without tooling stay tribal knowledge in someone’s head until they leave for a different job title.

Why it shows up as workplace pain

You feel the absence of governance long before someone renames a program. Typical symptoms:

Two “official” revenue numbers that only match after a late-night reconcile
PII lingering in a shared sheet because “the campaign needed it yesterday”
A KPI that changed definition mid-quarter and nobody updated the deck footnote
Analysts spending half their week hunting the right join key
Auditors asking for lineage and getting a shrug plus a screenshot

Those are not soft culture problems only. They burn calendar time, trust, and sometimes real money when a wrong grain ships to a partner or a regulator.

A governance loop you can run

Treat governance as a loop on one domain, not a one-time transformation. Here is the shape:

Start small. One domain. One loop. Then expand.

1. Pick one domain

Customer, product, order, employee, or location. Not “all enterprise data.” If you start everywhere, you finish nowhere. Choose the domain that causes the loudest fight in meetings this month.

2. Name owners and decisions

Every shared definition needs a human owner who can say yes or no. “The data team” is not a person. “The steering committee” is not a person either. Prefer a named role with a backup.

Decision	Accountable owner (example)	Consulted
Business definition of active customer	Finance Ops lead	Marketing analytics, Product
Allowed systems of record	Data platform lead	App owners
Who may export raw emails	Privacy / security	Marketing ops
When a quality fail blocks a dashboard	Analytics eng manager	Domain owner

3. Write rules people can use

A useful rule is short, testable, and lives next to the work. Good place: a dbt doc block, a catalog entry, or a one-pager linked from the dashboard. Bad place: a shared drive called Governance_FINAL_v7.

Example definition card:

Name: active_customer
Grain: one row per customer_id
Rule: has a successful payment in the last 90 days (UTC)
Source of truth: warehouse.finance.payments
Owner: finance-ops@company
Last reviewed: 2026-07-01
Known quirks: gift cards count; failed retries do not

4. Measure quality and use

If you never check, the rules rot. Start with a few dimensions that map to pain:

Dimension	Plain meaning	Toy check
Completeness	Required fields are filled	% of orders missing ship_country
Validity	Values look legal	status in allowed set
Uniqueness	No duplicate business keys	duplicate customer_id count
Timeliness	Data is fresh enough	max(event_ts) lag vs SLA
Consistency	Systems agree within tolerance	CRM vs warehouse headcount delta

Publish one quality score next to the metric people already open. Quiet monitors nobody sees do not change behavior.

Minimum viable framework (people, process, data)

People

You do not need a 12-seat council on day one. You need:

A sponsor who can unblock access and time (often a director or VP)
A domain owner who owns meaning
A technical steward who can implement checks and docs
A privacy/security voice when PII or regulated data is in play

Meet for 30 minutes every two weeks on the pilot domain. Longer meetings fill with status theater.

Process

Keep process thin:

Request: someone needs a new official metric or a change to an existing one
Decide: owner accepts, rejects, or asks for more detail within a fixed SLA (for example three business days)
Publish: definition + owner + quality checks land in the same place the data lives
Review: monthly, retire unused fields and fix the top three quality fails

Data and systems

You will eventually want a catalog, lineage, and automated tests. Start by documenting the two tables that cause 80% of arguments. Then wire tests where the warehouse already runs (many teams use dbt tests or simple SQL monitors). The catalog can wait until the definitions exist.

Worked example: “active customer” peace treaty

Scene: Growth wants “active users” for a launch deck. Finance wants “active customers” for cash planning. Both words sound similar. They are not the same grain.

Field	Growth version	Finance version
Who counts	Any logged-in user	Paying account
Window	Last 28 days	Last 90 days
Events	session_start	successful payment
Timezone	America/Los_Angeles	UTC
Owner	Growth analytics	Finance Ops

A governance fix is not forcing one team to abandon their need. It is naming both metrics clearly, forbidding the bare word “active” in decks without a qualifier, and putting both definition cards next to the charts. If a slide says “active,” the reviewer rejects the slide. That single social rule prevents weeks of rework.

Best practices that survive contact with Monday

Start with a use case, not a universe. “Clean customer for churn analysis” beats “enterprise data excellence.”
Write for the person who was not in the room. If the definition needs a meeting to interpret, rewrite it.
Pair every official metric with an owner and a test. Orphans drift.
Separate access rules from vanity sharing. Wide read access to aggregates can be fine; raw PII exports should be rare and logged.
Publicize one win. “Duplicate customer rate fell from 6% to 1.2% after the merge rule” does more for adoption than a vision statement.
Revisit on a calendar. Quarterly review is enough for many domains; weekly for the pilot until it stabilizes.

Common mistakes

Mistake	What it looks like	Fix
Binder first	80-page policy, zero tests	One domain, one definition card, one monitor
Tool first	Catalog with empty descriptions	Fill meaning before buying another UI
Committee ownership	Everyone nods, nobody decides	Named accountable human per domain
Hidden changes	Definition shifts mid-quarter	Change log + dashboard footnote + notify consumers
Quality theater	Green dashboards, angry users	Measure the fails users actually feel
Boiling the ocean	All systems in scope on day one	Pilot, then expand by pain rank

30-day pilot plan

Days 1-3: Pick the domain and list the three loudest metrics. Pull last month’s Slack fights if you have them.
Days 4-10: Draft definition cards. Interview Finance, Product, and Support for 20 minutes each. Write disagreements in the open.
Days 11-15: Agree owners. Socialize a “no bare labels” rule for decks.
Days 16-22: Add two automated quality checks and surface them next to the main dashboard.
Days 23-30: Run one biweekly review. Fix the top fail. Write a short note on what improved and what is still messy.

Still messy is allowed. Pretending the pilot is finished when people still use three definitions is not.

How this ties to analytics work

Governance is not separate from analysis. It is what makes analysis reusable. A one-page analytics brief (see how to write a one-page analytics brief) still needs a stable grain. Reading a number like an adult still needs a definition that survived review. If your team is building the analytics loop, governance is the layer that stops the loop from spinning on fiction.

Quick recap

Governance is decisions, owners, and rules, not a tool purchase
Run a loop on one domain: define, own, check, improve
Put definitions next to the data people already use
Measure a few quality dimensions that map to real pain
Pilot for 30 days, publicize one concrete win, then expand