Data Governance

Data governance is the system by which an organisation assigns authority, responsibility and accountability for data: who may define it, own it, change it, access it, share it, preserve it, correct it and decide what happens when rules or interests conflict.

Data management keeps the system running. Data governance decides who has the right and duty to make the important decisions.

Governance is therefore not simply a policy document and not simply a committee. It is a decision architecture. Its job is to prevent important questions from falling into the space between technology, operations, privacy, security, records, analytics and leadership.

ARTICLE ID: DATA.MANAGEMENT.004
Canonical function: authority and accountability
Series boundary: this article owns governance. For the root definition see What Is Data Management?. For the operating runtime see How Data Management Works. For stewardship through time see The Data Lifecycle.

The Simple Answer

If two departments disagree about what “active customer” means, who decides? If a dataset contains errors, who owns the repair? If an analyst wants access to sensitive information, who can approve it? If a system change breaks a downstream report, who is accountable? If a retention period ends, who may authorise disposal? If a new AI project wants to reuse old data for a new purpose, who decides whether that use is appropriate?

Data governance exists so those questions have deliberate answers before a crisis forces improvised ones.

Why Governance Exists

Data crosses boundaries. That creates conflict naturally.

The sales team wants speed. Finance wants consistency. Security wants tighter controls. Researchers want reuse. Operations want availability. Privacy teams want purpose limitation and minimisation. Archivists want evidence preserved. Engineers want stable interfaces. Leaders want useful metrics. Individual data subjects may have rights and legitimate expectations.

No technical tool can resolve all of those interests by itself. Governance provides a structure for legitimate trade-offs.

Governance Is About Decision Rights

The strongest way to understand governance is to ask: who has the authority to decide what?

Typical decision rights include:

who defines a critical business term;
who declares a source authoritative;
who approves a schema change;
who sets quality thresholds;
who accepts a quality exception;
who classifies sensitivity;
who approves access;
who approves external sharing;
who decides retention and archival treatment;
who authorises disposal;
who resolves cross-domain conflicts;
who is accountable when controls fail.

A governance framework that lists principles but does not assign decision rights is incomplete.

The Core Roles

Organisations use different titles, but several roles recur.

Data owner

The data owner is accountable for a data domain or important dataset. Ownership is not the same as personally maintaining every row. It means having authority and accountability for key decisions.

Data steward

The steward helps translate policy into daily practice: definitions, quality rules, metadata, issue resolution, standards and coordination with users.

Data custodian

The custodian operates technical controls such as storage, backups, permissions, encryption, platform configuration and recovery. Custody is not ownership of meaning.

Data producer

The producer creates or captures data and therefore carries important knowledge about source context and collection methods.

Data consumer

The consumer uses data for operations, analysis, research, learning, automation or decision-making. Consumers are often the first people to discover whether governance works in practice.

Role names matter less than clear boundaries. If everyone is “responsible”, nobody may actually be accountable.

Ownership Is Not Possession

A department that happens to store a copy does not necessarily own the meaning of the data. A cloud platform that stores records is not the business owner. An analytics team that transforms a field does not automatically own the source definition.

Governance separates four ideas:

authority: who may decide;
accountability: who must answer for outcomes;
custody: who operates the technical environment;
use: who is permitted to consume the data.

Confusing these concepts is a common source of governance failure.

The Governance Stack

A useful governance stack contains several layers.

Principles: the values the organisation wants to protect.
Policies: mandatory expectations.
Standards: agreed ways of representing or controlling data.
Roles: who owns, stewards, operates and uses.
Decision rights: who approves changes and exceptions.
Controls: technical and procedural mechanisms.
Evidence: records showing that controls operated.
Metrics: signals showing whether governance works.
Escalation: a route for unresolved conflict.
Learning: revision when outcomes reveal weaknesses.

The stack moves from intention to observable behaviour.

Governance Principle 1: Purpose Before Collection

Good governance asks why data should exist before asking where to store it. Purpose helps limit unnecessary collection, clarify quality needs and define legitimate receivers.

This is especially important for personal or sensitive information. If nobody can explain why a field is needed, the safest governance decision may be not to collect it.

Governance Principle 2: One Definition Needs an Owner

Critical terms such as “student”, “customer”, “revenue”, “incident”, “active”, “completed” or “risk” can influence many systems. Governance should identify which domain owns each definition and how changes are versioned.

This does not mean every department must use one word identically for every purpose. It means differences should be explicit and mapped rather than hidden.

Governance Principle 3: Canonical Authority Must Be Explicit

Copies are inevitable. Ambiguous authority is not.

For each important data domain, governance should establish which source has authority for which facts. A human-resources system may own employment status. A customer platform may own communication preferences. An assessment system may own final marks. A finance ledger may own booked transactions.

Other systems may copy those facts, but lineage should preserve the route back to the owner.

Governance Principle 4: Quality Is an Accountability Question

Quality tools can detect errors. Governance decides what happens next.

For each critical dataset, somebody should be accountable for:

defining fit-for-purpose quality;
approving thresholds;
reviewing recurring exceptions;
prioritising repair;
communicating limitations;
accepting or escalating residual risk.

A dashboard showing a red quality score is not governance. Governance begins when an accountable owner has a duty to respond.

Governance Principle 5: Access Should Follow Legitimate Need

Access should not be determined by convenience, seniority or technical possibility. It should follow role, purpose, sensitivity and least necessary privilege.

A strong access process answers:

who is requesting access;
which dataset and fields are needed;
for what purpose;
for how long;
which restrictions apply;
who can approve;
how access will be reviewed or revoked.

Access governance should be usable. If legitimate access is impossibly slow, people create uncontrolled workarounds. Security and usability must be designed together.

Governance Principle 6: Privacy Must Be Part of Design

Privacy governance asks whether personal data is collected, used, disclosed, transferred, retained and protected appropriately for the relevant context.

In Singapore, the Personal Data Protection Act establishes obligations concerning personal data. Organisations should use the current guidance of the Personal Data Protection Commission when designing specific controls. From a governance perspective, the central lesson is that personal data needs accountable purpose and stewardship across its lifecycle.

Privacy is not equivalent to secrecy. Data can be securely stored and still be collected or used inappropriately. Governance must address legitimacy as well as protection.

Governance Principle 7: Security Must Have Owners and Exceptions

Security standards define expected controls. Governance defines who can accept risk when the standard cannot be met, how long an exception may remain, and what compensating controls are required.

Unowned exceptions are one of the quiet ways governance decays. A temporary workaround becomes permanent because no expiry, owner or review date was attached.

Governance Principle 8: Retention and Disposal Need Authority

Keeping data and deleting data can both create risk. Retention may be necessary for operations, accountability, research or legal reasons. Disposal may be necessary when purpose and justification end.

Governance should define:

retention categories;
trigger events;
review periods;
archival criteria;
hold mechanisms;
disposal authority;
evidence of important disposition actions.

The time dimension is developed fully in The Data Lifecycle.

Governance Principle 9: Changes Need Contracts

One team’s improvement can become another team’s outage. Schema changes, classification changes and definition changes need controlled communication where downstream receivers depend on them.

Data contracts can establish fields, meanings, service expectations, quality thresholds, versioning rules and deprecation periods. Governance decides who is allowed to change the contract and how conflicts are resolved.

Governance Principle 10: Evidence Matters

A policy saying “access is reviewed annually” is weaker than a system that can show when access was reviewed, by whom and what changed.

Governance should leave evidence:

approvals;
ownership assignments;
definition changes;
quality exceptions;
access grants and revocations;
risk acceptances;
retention decisions;
disposal actions;
incident reviews;
policy and standard versions.

Evidence turns governance from aspiration into something auditable and learnable.

The Governance Council: Useful Only If It Can Decide

Many organisations create data councils or governance committees. These can be useful, but meetings alone do not create governance.

A useful council has:

a defined scope;
named decision rights;
representatives with authority;
clear escalation routes;
published standards or decisions;
time-bounded issue resolution;
evidence that decisions reach operational systems.

A council that can discuss but not decide becomes an advisory forum. Governance requires a path from question to binding decision.

Central Governance vs Federated Governance

A central model puts more decision authority in one enterprise body. A federated model distributes more authority to domain owners while preserving common principles and interfaces.

Central governance can improve consistency but may become distant from domain reality. Federated governance can improve local expertise but may create incompatible definitions. Hybrid models are common because they separate what must be shared from what can remain local.

A practical rule is:

Centralise the minimum rules needed for trust and interoperability; keep domain meaning close to the people who understand the domain.

Governance and Metadata

Metadata provides the control surface on which governance can operate. Ownership, sensitivity, quality state, retention class, source, lineage and usage restrictions can all be represented as metadata.

When governance metadata is machine-readable, systems can automate parts of policy: apply access controls, flag retention deadlines, warn about unowned datasets or block unsupported schema changes.

But metadata must itself be governed. A field saying “confidential” has little value if nobody defines the classification levels or keeps them current.

Governance and Data Catalogues

A data catalogue can make ownership, definitions, lineage and quality visible. This improves governance because users can discover both data and the rules around data.

However, a catalogue is not governance by itself. It can faithfully display that a dataset has no owner. Someone still needs authority to fix the problem.

Governance and AI

AI introduces new governance questions because data can influence model behaviour far beyond its original collection context.

Important decision rights may include:

who approves a dataset for model training;
who verifies provenance and usage rights;
who defines labels and exclusions;
who approves sensitive attributes;
who decides whether synthetic or generated data is acceptable;
who owns dataset versioning;
who reviews drift and retraining triggers;
who can retire a model-data combination.

AI governance that ignores data governance starts too late in the system.

Governance in Education

Schools and learning organisations handle data about attendance, assessment, learning progress, communication and support. Governance should ensure that the information serves legitimate educational purposes without turning every recorded behaviour into a permanent judgement about the learner.

For assessment data, governance can define:

which result is final;
who may correct a mark;
how remarking is recorded;
who can access individual results;
which aggregates may be shared;
how long historical records remain useful;
how old scores should be interpreted as the learner changes.

The principle is simple: data should support education, not replace educational judgement.

Governance in Science and Research

Research governance must balance openness, reproducibility, ethics, participant protection, intellectual contribution, contractual constraints and long-term stewardship.

The FAIR principles are useful because they encourage rich metadata, persistent identification, interoperability and provenance while recognising that accessibility can include authentication and authorisation rather than unrestricted public release.

Governance decides which restrictions are justified and how future reuse remains possible without losing accountability.

Governance in Records and Archives

Records and archives bring governance into long time horizons. Someone must decide what constitutes evidence, which records are retained, which metadata proves context, when records can be disposed and which material has continuing historical value.

ISO 15489-1 describes records-management concepts involving records, metadata, policies, responsibilities, controls and processes for creation, capture and management. The broader governance lesson is that durable evidence needs assigned responsibilities, not only durable storage.

Data Governance Metrics

Metrics should reveal whether governance changes behaviour. Useful measures can include:

percentage of critical datasets with named owners;
percentage with approved definitions;
age of unresolved quality issues;
number of repeated issues by root cause;
access-review completion;
policy exceptions past expiry;
datasets missing retention rules;
percentage of critical data with traceable lineage;
time required to resolve cross-domain disputes;
number of deprecated datasets still used by active reports.

The purpose of metrics is not to produce a prettier governance dashboard. It is to expose where accountability is not reaching reality.

Good Governance Is Proportionate

Not every dataset needs a committee, legal review and thirty-page standard. Governance should scale with importance, sensitivity, regulatory exposure, number of receivers, decision consequence and expected longevity.

A disposable classroom scratch dataset and a national health record require radically different control intensity. Proportionate governance protects scarce attention for the data that can cause the greatest harm or deliver the greatest enduring value.

Governance Anti-Patterns

Committee without authority: issues are discussed but nobody can decide.
Owner in name only: an executive is listed as owner but has no operational route for stewardship.
Tool-first governance: software is purchased before decision rights are defined.
Policy pile: documents exist but controls are not implemented.
Universal centralisation: local domain meaning is overwritten by generic enterprise definitions.
Universal federation: every team invents its own rules and interoperability collapses.
Quality theatre: metrics are reported without owners or repair obligations.
Permanent exceptions: temporary risk acceptances never expire.
Access accumulation: people gain permissions over time but old access is rarely removed.
Retention by inertia: data stays forever because no one owns the disposal decision.
Privacy after design: personal data concerns are reviewed only after collection and integration are complete.

A Governance Maturity Ladder

Implicit: decisions depend on whoever happens to know.
Documented: policies and standards exist.
Assigned: owners and stewards are named.
Operational: decisions are connected to workflows and systems.
Measured: failures, exceptions and outcomes are visible.
Federated: local domains operate within shared cross-domain rules.
Adaptive: governance learns from incidents, new uses and changing obligations.
Durable: authority and evidence survive personnel and system changes.

A Practical Governance Charter

A compact governance charter for a data domain can answer twelve questions:

What domain does this cover?
Who is the accountable owner?
Who performs stewardship?
Which systems are authoritative?
Which definitions are controlled?
What quality is required?
How is sensitivity classified?
Who can approve access and sharing?
What retention and disposal rules apply?
How are changes versioned and communicated?
How are exceptions escalated?
What evidence and metrics prove the governance is working?

If these questions have clear answers, most of the foundation is already present.

The Governance Loop

Governance should itself operate as a loop:

Principle → Policy → Standard → Control → Evidence → Observation → Exception → Decision → Repair → Revised Standard

If the loop stops at policy, governance becomes ceremonial. If it reaches evidence and repair, governance becomes operational.

Trust Is the Output

The final output of data governance is not compliance paperwork. It is justified trust.

A user can trust that a critical term has an owner. A system can trust an interface contract. An auditor can trace a decision. A researcher can identify provenance. A person can expect sensitive information to have controlled use. A leader can know which metric is authoritative. A future team can discover why a decision was made.

Trust does not mean assuming the data is perfect. It means the organisation can explain what the data is, who stands behind it, where its limitations are and what happens when something goes wrong.

The Deeper Rule: Authority Must Follow Consequence

The more consequential a data decision becomes, the clearer its authority should be.

A local formatting choice may belong to a technical team. A change to the definition of a company-wide financial metric may require enterprise ownership. A decision to reuse sensitive personal data may require privacy and legal review. A decision to destroy evidential records may require formal authorisation.

Governance is strongest when decision authority rises with consequence rather than with organisational habit.

Data Management Series

References and Further Reading

Final idea: data governance is the architecture that makes responsibility visible. It turns “somebody should decide” into “this role owns the decision, this rule applies, this evidence records it, and this route repairs the system when reality proves us wrong.”

Data Governance | Ownership, Standards, Quality, Security, Accountability and Trust