When two dashboards disagree, every number becomes negotiable. Governance is how data stays worth arguing from.
Data governance has a reputation problem: it sounds like committees and compliance binders. In practice, for a growing company, it’s four working agreements — who owns each dataset, what “correct” means and how it’s checked, who can access what, and where definitions live. Skip them and you get the familiar symptoms: dashboards that disagree, metrics that mean different things in different teams, personal data scattered across tools nobody remembers, and analysts spending most of their week reconciling instead of analyzing.
Every dataset that matters needs a named owner — a person, not a team — accountable for its definition, freshness, and fixes when it breaks. Ownership is the single highest-leverage governance move: unowned data rots silently, and “whose number is right” arguments are really ownership disputes in disguise.
Quality then becomes testable instead of aspirational: freshness checks (did last night’s load land?), volume checks (row counts within expected range?), and validity checks (no nulls in keys, values in allowed sets) running automatically in the pipeline — dbt tests or equivalents — with alerts to the owner, not a shared channel everyone mutes. A dozen well-placed tests on your core models beats a quality initiative every time.
Access control should follow least privilege by role, with personal data classified and masked in analytics environments — analysts rarely need raw emails or phone numbers, and with India’s DPDP Act joining GDPR-class regimes, knowing where personal data lives and who touched it is now table stakes, not maturity. Log access to sensitive datasets; make offboarding revoke everything by group membership, not by memory.
Definitions are the quiet killer: “active user”, “revenue”, and “churn” must each have exactly one written definition, owned like code — ideally as metrics defined once in the semantic layer rather than re-derived in every dashboard. A lightweight catalog (even a well-kept wiki page per core dataset: what it is, who owns it, how fresh, what the fields mean) removes the tribal-knowledge tax every new hire pays. Start with your ten most-used tables, not all thousand.
Name owners for the ten datasets your company actually runs on.
Write the canonical definitions of your five core metrics — one source of truth each.
Classify personal data and mask it in analytics environments.
Add automated freshness, volume, and validity tests to core pipelines, alerting owners.
Move access to role-based groups with least privilege and logged access to sensitive data.
Stand up the lightweight catalog page per core dataset and make it part of onboarding.
No — ownership, definitions, and tests need agreement more than software. dbt tests, warehouse-native access controls, and a disciplined wiki cover the first year for most teams; buy a catalog when scale makes the wiki unmaintainable.
Compliance (GDPR, DPDP) is one output of governance, not the goal. The same ownership, classification, and access work that makes regulators happy is what makes your dashboards agree — do it for the trust, collect the compliance for free.
Early on, whoever runs data — with each dataset owned by the person closest to its source. A dedicated governance function only makes sense once there are enough data producers that coordination itself is a full-time job.
One clear owner per dataset, a handful of automated quality checks, and role-based access — that alone prevents most of the trust problems that show up later.
Keep it automated and invisible where possible — checks that run in the pipeline, not approval meetings people have to attend before touching data.
A practical comparison of data warehouses, data lakes, and lakehouses — where each one fits, what they cost, and how to pick the right one.
Read the guideRelational vs document, key-value, and wide-column stores — what each model is actually good at, and why “both” is often the real answer.
Read the guide