Data Governance

Data governance is the set of policies, named ownership, and processes an organization uses to manage its data as an asset: who's accountable for a dataset, how sensitive it is, how long it's kept, and who can get access to it. It's the framework; the accuracy and completeness of the data it governs is Data Quality, a related but separate concern.

Key components

• Named data owner or steward — a specific person or team accountable for a given dataset: its definition, its quality, who can access it, and what happens to it over time. Not a committee, and not "the data team" in the abstract.
• Classification — a scheme (e.g. public, internal, sensitive, restricted) applied to each dataset that drives who's allowed to access it and what controls apply, rather than access being decided ad hoc each time someone asks.
• Retention and deletion policy — how long a dataset is kept, and what happens to it after that period (archived, anonymized, deleted), set deliberately rather than "forever by default."
• Access-request and approval process — a defined path for someone who needs access to a dataset to request it, and for the owner or a designated approver to grant or deny it, rather than access spreading informally through shared credentials or copied exports.

Why ownership needs a name, not just a policy

A written policy that says "sensitive data must be access-controlled" accomplishes nothing on its own if no specific person is responsible for applying it to a given dataset. An unowned dataset's classification goes stale, its access list accumulates people who no longer need it, and its quality issues have no one whose job it is to notice or fix them — because when something goes wrong, there's no name to go to, accountability just diffuses across "the org" and nothing happens. Naming an owner per key dataset turns a governance policy from an aspiration into something that's actually enforced day to day.

Common pitfalls

• Policies written but never enforced or checked — a retention policy or classification scheme exists in a document, but nobody audits whether datasets actually comply with it, so it has no effect on real practice.
• No single named owner for a dataset — when a quality issue, an access dispute, or a retention question comes up, several people could plausibly answer for it and none of them actually do.
• Classification applied once and never revisited — a dataset classified "internal" at creation stays that way even after it starts including data that should be "restricted," because nothing triggers a re-review as its content or use changes.
• Access granted informally and never revoked — someone gets a one-time export or a standing credential for a project, the project ends, and the access just stays live indefinitely because there's no process that expires or reviews it.
• Governance treated as a one-time compliance project — a burst of policy-writing around an audit or a new regulation, followed by no ongoing process to keep ownership, classification, or retention current as the data and its uses evolve.
• Governance disconnected from the people actually building pipelines — policies are set by a governance team that never talks to the people running the Data Pipelines the policies are supposed to apply to, so the policies don't reflect how data actually moves.

Learn more

• Data Quality for the measurable accuracy and completeness properties that good governance is meant to protect but doesn't itself guarantee.
• Data Pipeline for the automated processes that move data between the systems governance policy has to reach.
• Freedom of Information Request for a formal external access-request process governance sometimes has to interoperate with.
• Machine Learning Model Card for documenting the provenance of training data, an area where governance and dataset lineage overlap.