Why this matters before an organisation feels big enough to need it
Data governance failures rarely announce themselves. They show up as a slow accumulation of symptoms: three dashboards reporting different revenue numbers, nobody sure who can see a customer table with personal data in it, and a growing pile of tables nobody remembers the purpose of. By the time these problems are visible, they are expensive to unwind, because years of reports and decisions have been built on the inconsistency.
The good news is that meaningful governance does not require a dedicated team or an expensive platform. It requires four disciplines, started early and kept cheap.
1. Named ownership, not a committee
Every important dataset and every business metric needs one named, accountable owner — a person, not a team or a process. When two departments disagree about how a metric is defined, the owner decides, the decision is documented, and the disagreement does not resurface every quarter. This single discipline prevents more governance failures than any policy document.
2. Access control that matches data sensitivity, not convenience
- Classify data by sensitivity (public, internal, confidential, regulated) as it is modelled, not as an afterthought.
- Grant access by role rather than by individual, so onboarding and offboarding do not require re-auditing every table.
- Mask or tokenise regulated fields (PII, payment data) at the point they enter the platform, not just at the point of final consumption.
- Review access quarterly, not just at the point it is originally granted — access that made sense a year ago frequently no longer does.
3. Automated quality checks and lineage, not manual spot checks
Data quality issues should be caught by automated tests before a report is built on bad data, not discovered by a customer or executive noticing a wrong number. A small, focused set of tests — uniqueness on keys, not-null on required fields, referential integrity between related tables, and freshness checks that a pipeline actually ran — catches the large majority of real-world data quality incidents at a fraction of the cost of comprehensive manual review.
Column-level lineage — the ability to trace a number on a dashboard back to the raw source it came from — turns a data quality investigation from hours of manual archaeology into a query that takes minutes, and it becomes disproportionately valuable as the number of pipelines and models grows.
4. One definition per metric, enforced in code
The single most common governance failure is a metric — revenue, active users, churn — defined differently in different dashboards because each was built independently. The fix is a metric layer: definitions written once, in version-controlled transformation code (a dbt model, a LookML view), that every downstream report consumes rather than redefining. This does not require an enterprise semantic layer product to start; it requires the discipline of refusing to let a second definition of an existing metric exist anywhere in the platform.
How this scales as the organisation grows
These four disciplines do not require new tooling to start, and they do not require a dedicated governance function until the organisation is large enough that informal ownership genuinely breaks down — commonly somewhere between fifty and a few hundred people actively using data, though this varies. At that point, a lightweight data governance council (not a heavyweight committee) formalises what was previously informal: reviewing new domain ownership, arbitrating genuinely contested metric definitions, and maintaining a data catalog that has grown too large for tribal knowledge alone.
Mistakes that make governance expensive instead of cheap
- Buying a governance platform before the underlying disciplines (ownership, tests, one metric definition) exist — the platform then just displays the existing mess more clearly.
- Treating governance as a compliance exercise owned entirely by legal or security, disconnected from the engineers who actually build pipelines.
- Writing an access policy document that is never enforced through actual role-based access control in the systems themselves.
- Waiting until a serious incident (a wrong number reaching a board deck, a data exposure) before starting, rather than building the habits early when they are cheap.
Frequently asked questions
No. The core disciplines — named ownership, role-based access control, automated quality tests, and one metric definition per concept — can be run by an existing data engineering team. A dedicated function becomes useful once the organisation is large enough that informal ownership stops working, not before.
Named, accountable ownership for each important dataset and metric. It is free to implement and prevents the most common and expensive governance failure: the same metric being defined differently in different places with nobody empowered to resolve it.
Useful once the number of tables and pipelines outgrows what the team can hold in memory or document informally, typically once a platform has grown past a few dozen actively used tables across multiple teams. Below that scale, clear naming conventions and a shared document can suffice.
Data classification, access control and audit trails built for good governance directly support regulatory compliance, but governance is broader than compliance — it also covers metric consistency and data quality, which have no direct regulatory requirement but real business cost when absent.
One named person, ideally someone with authority over the business process the metric measures, should make and document the decision. The disagreement should not remain permanently unresolved across multiple competing dashboard definitions.
Tests defined alongside transformation models (as dbt tests do, for example) run automatically whenever a pipeline runs or a change is deployed, failing the pipeline before bad data reaches a report rather than being discovered after the fact.
How we can help
Governance, access control and testing built into the platform from day one.
Data Warehouse vs Lakehouse: How to ChooseWhy the platform choice matters less than the modelling discipline built on top.