Data Governance

Data governance establishes who can decide how data is defined, used, changed, and maintained, and who is accountable for those decisions. Data management performs the associated work. In a small team, the same people may participate in both — which is why the useful test is not whether a governance team exists but whether a specific decision has a named decision-maker. The roles that separate those duties are set out in data owner, steward, and custodian.

A disagreement needs a decision path

Suppose marketing counts every created order while operations counts only paid orders. The numbers can differ without either query being broken. Someone must clarify the purposes, approve distinct definitions, and settle conflicts when reports claim to measure the same thing. The artifact that records the outcome is a written metric definition, and the reason it is worth writing is that the disagreement returns every quarter until someone can point at one.

Useful governance connects a rule to its scope, responsible person, implementation, and evidence — and each of those has a mechanism behind it. A data contract specifies the agreed scope and obligations; producer checks, operating procedures, and enforcement points implement them. Consumers need a way to detect violations. Evidence is what an audit log and the data quality checks produce. A document with no responsible decision-maker cannot resolve a new payment state or prioritize a missing-data repair.

What separates a control that works from one that merely reads well is where it sits: at a point every access path crosses. A rule authored in one interface — a filter in a SQL endpoint, a masking expression in one tool’s model — binds the people who arrive through that interface and nobody else. Analytical platforms usually offer several routes to the same bytes: a SQL endpoint, a direct read of the underlying files, an import into a reporting model, a copy shared with another account. If the rule lives in one of those routes, the others are not exceptions to the policy; they are the policy, and the written one describes what happens on one path. The practical test is to list the paths that reach the data and say, for each, which mechanism enforces the rule there — treating a path with no answer as unverified and possibly open, to be checked directly, rather than as an edge case.

Responsibility continues after approval

Changes need impact review, versioned decisions, and communication to affected users. Data lineage identifies recorded dependencies, and catalog coverage measures a defined part of the registered estate. Query logs can add observed consumers, but miss uses outside their retention, instrumentation, or access boundary, including downstream exports. Combine these signals with owner and consumer records, and state remaining uncertainty. Quality failures also need an agreed response, such as labeling an incomplete report or withholding it.

Ownership does not mean unrestricted control over data. Decisions remain subject to the organization's applicable restrictions. A practical starting point is one disputed measure, a named owner, a documented rule, and a way to report and resolve exceptions.

References

• UK Government: Data ownership model