Data Governance: Making Responsibility Explicit

Data crosses products, teams, vendors, and years.

Without explicit responsibility, nobody knows which definition is authoritative, who may grant access, how long copies should remain, or how an error should be corrected.

Data governance connects important data to accountable decisions across its lifecycle.

It combines policy, ownership, process, and tooling rather than producing documents alone.

A concrete example: a governed customer dataset

A customer dataset has:

business owner,
technical steward,
agreed definition,
authoritative source,
sensitivity classification,
access rules,
quality objectives,
retention period,
lineage,
correction process.

Consumers can understand both meaning and responsibility.

Governance questions

Governance answers:

What does this data mean?
Who owns it?
Who can access it?
For which purpose?
How trustworthy is it?
How long is it retained?
Where is it shared?
How is it corrected or deleted?

Data owner

The data owner is accountable for business decisions:

definition,
acceptable use,
access approval,
quality expectation,
and retention.

Ownership should attach to a role or team that can act, not one ceremonial name.

Data steward

A steward maintains practical quality and metadata:

glossary,
catalog,
issue triage,
lineage,
and standards.

The exact title varies. Responsibilities should remain clear.

Technical custodian

Platform and engineering teams operate:

storage,
backup,
encryption,
pipelines,
and access mechanisms.

They implement controls but may not decide business purpose independently.

Business glossary

A glossary defines terms such as:

active customer,
revenue,
churn,
completed order.

Definitions include scope, formula, owner, and exceptions.

One label with several hidden meanings creates conflicting dashboards.

Data classification

Classify by sensitivity:

public,
internal,
confidential,
restricted,
or domain-specific categories.

Classification drives access, encryption, logging, sharing, and retention.

Automated discovery helps but needs owner validation.

Access governance

Access should be:

purpose based,
least privilege,
approved,
time bound where possible,
audited,
and reviewed.

Broad analyst access to raw personal data is not necessary for every report.

Data minimization

Collect and retain only what a legitimate purpose needs.

Minimization reduces:

breach impact,
compliance scope,
storage,
and misuse.

Future hypothetical usefulness is not always sufficient justification.

Retention

Retention defines how long each class remains.

Policy must reach:

primary stores,
lakes,
logs,
exports,
backups,
and vendor copies.

Deletion from one table does not complete lifecycle deletion.

Data quality

Governance assigns:

quality dimensions,
thresholds,
monitoring,
issue owner,
and correction.

Quality should be tied to use. A field safe for broad trend analysis may be unsuitable for an individual decision.

Master and reference data

Shared entities such as:

customer,
product,
location,
currency,
and category

need authoritative identifiers and change processes.

Competing masters create duplicate or conflicting records.

Data contracts

Contracts define source schema, meaning, freshness, quality, and change expectations.

They let producers evolve systems without silently breaking consumers.

Enforcement can occur through schema registries and pipeline checks.

Catalog

A catalog makes governed data discoverable.

Useful entries show:

description,
owner,
classification,
lineage,
quality,
freshness,
access path,
and approved use.

A catalog with stale metadata loses trust.

Acceptable use

Technically available data may not be appropriate for every purpose.

Examples:

support notes used for employee ranking,
location used for unrelated advertising,
health data used without consent.

Governance reviews purpose, fairness, legal basis, and user expectation.

Before internal or external sharing, define:

recipient,
purpose,
minimum fields,
transfer method,
retention,
onward sharing,
and deletion.

Contracts and technical controls should agree.

Third parties

Vendors processing data need:

due diligence,
approved scope,
security requirements,
subprocessor visibility,
incident obligations,
and exit or deletion evidence.

Provider convenience does not transfer organizational accountability.

Correction and dispute

People and teams need a path to report incorrect data.

Correction may need to propagate through:

source,
derived tables,
reports,
models,
and exports.

Lineage identifies affected copies.

Governance council

Cross-functional governance may include:

product,
engineering,
security,
privacy,
legal,
analytics,
and affected business teams.

The group should resolve decisions and exceptions, not become an approval bottleneck for ordinary low-risk work.

Exceptions

Policies need a controlled exception path for urgent, unusual, or legacy situations.

An exception records scope, owner, rationale, compensating controls, expiry, and review. Permanent undocumented exceptions create a second shadow policy that is impossible to audit.

Federated governance

Central teams can define common classifications, identity, retention mechanisms, and interoperability standards while domain teams own local meaning and quality.

This federated model avoids one central bottleneck without allowing every team to redefine customer, currency, or privacy independently.

Policy enforcement

Turn policy into practical controls:

role templates,
automated retention,
classification labels,
masked views,
quality checks,
and audit.

Manual documents alone do not scale.

Metrics

Measure:

ownership coverage,
access-review completion,
quality incidents,
stale catalog entries,
overdue deletion,
and exception age.

Avoid rewarding number of policies instead of reduced risk and improved trust.

Governance user experience

Make the compliant path easy:

searchable catalog,
standard access request,
approved masked views,
automated expiry,
clear denial reason,
and visible data owner.

When legitimate access takes weeks, users create spreadsheets and unmanaged exports that weaken governance.

Knowledge check

How do data owner, steward, and technical custodian differ?
Why does a business glossary matter?
Which copies must retention policy address?
What does acceptable-use governance add beyond access control?
How can policy become operational rather than documentary?

The one idea to remember

Data governance gives important information a clear meaning, owner, access purpose, quality expectation, retention rule, lineage, and correction path. It succeeds when policy becomes usable tooling and accountable decisions throughout the data lifecycle.