Data governance defines who can make decisions about an organization’s data, which rules apply and how their application is checked. It establishes responsibilities for the meaning, quality, access and use of information so that people can rely on it for an agreed purpose.
Its practical work includes approving the definition of an active customer, resolving a discrepancy between reports, deciding who can use a dataset and managing a change that affects several teams. Policies become useful when those decisions can be made, implemented and reviewed.
This guide explains data governance frameworks, operating models, ownership, stewardship, catalogs, lineage and master data management. It also sets out how a program can begin with a business problem and demonstrate progress without making every request unnecessarily slow.
What does data governance need to achieve?
Information problems often cross organizational boundaries. Sales may count customers by active contract, while finance counts invoiced legal entities. Both measures can be valid in their own context. A shared discussion needs to preserve those meanings and establish which measure answers which question.
Governance provides the authority and process for making that agreement. It also determines who maintains the definition, how exceptions are handled and what happens when a business change makes the old rule unsuitable.
IBM’s overview of data governance connects policies, responsibilities and procedures with the handling of data assets. Applied to a business process, the framework should answer four questions: who decides, what is expected, how the decision is implemented and what evidence shows it works.
The pizzeria analogy for data governance provides an accessible introduction to how shared rules and responsibilities work together. The operating framework then turns those ideas into specific decisions.
Data governance and data management
Data management covers the practices and capabilities used to administer information throughout its lifecycle. Governance establishes decision rights and expectations that must be reflected in that operational work.
For example, a governance decision may require approval before access is granted. A management process handles the request, and a technical mechanism applies the permission. All three need to agree. The introduction to enterprise data management develops the wider management scope.
Data governance and data quality
Governance assigns responsibility for agreeing the required quality, deciding priorities and resolving exceptions. Quality controls test conditions such as completeness, validity or freshness for a particular use.
A dataset may be sufficient for observing a broad trend while being unsuitable for an individual payment decision. Quality expectations therefore need a context and an owner. The comparison of data governance and data quality explains their relationship.
Choosing a data governance operating model
An operating model defines where authority and work sit. Its suitability depends on the organization’s domains, shared information, risks and available capacity. A label alone does not explain how disagreements will be resolved.
- Centralized governance concentrates important decisions and standards in a common team. It can provide consistency and support for domains that lack capacity, but needs a workable route for local requirements.
- Decentralized governance places more responsibility close to the teams producing and using information. Shared data still requires coordination across those boundaries.
- Federated governance combines common standards with local accountability. It needs explicit limits on what domains can decide and what must be agreed centrally.
A useful test is a disagreement about a shared measure. The model should identify the decision-maker, the people consulted, the implementation owner and the way the outcome reaches affected users. A committee without that path can add meetings without resolving the issue.
The enterprise data strategy identifies the priorities that governance must support. The data architecture must reflect the agreed conditions for access, exchange and operation.
An initial assessment should examine observable practices: recent incidents, access requests, definition changes and evidence of ownership. The data maturity model guide for companies provides a companion for discussing the starting point. An average score should not conceal a blocking issue in a critical process.
Data governance roles and responsibilities
A role needs a defined scope, authority and capacity. Naming someone in a spreadsheet does not establish that they can resolve a cross-functional conflict or fund a correction.
- Executive sponsor: supports priorities and resolves conflicts beyond the participating teams’ authority.
- Data owner: is accountable for defined decisions about a domain or asset, including meaning, approved uses and correction priorities.
- Data steward: coordinates documentation, issue follow-up and the practical maintenance of agreed standards.
- Technical custodian or delivery team: implements and operates storage, integration, access and other assigned controls.
- Data consumer: uses information within the agreed conditions and reports limitations or errors.
- Specialist control functions: security, privacy and other relevant teams contribute decisions within their responsibilities.
Smaller organizations can combine roles. The condition is clarity about decision-making and execution, including a route to challenge or escalate a decision. Internal ownership terminology should also be distinguished from legal responsibilities for personal data.
The article on the role of the data owner develops this accountability. Effective ownership contributes to a data-driven culture alongside reliable information, usable tools, skills and leadership support.
Documenting a responsibility that can be used
For a priority asset, a practical record names the accountable owner, the decisions within that remit, the steward or operational contact and the escalation route. It also identifies who approves a material change and when the assignment was last reviewed.
Adoption depends on people knowing how to use that arrangement. Role-based learning can cover interpreting a measure, reporting an incident or requesting access. The guide to building a data-driven culture supports the organizational side of those changes.
What should a data governance policy include?
A data governance policy records the criteria used to make decisions about information. It identifies the assets and uses within scope, the authority responsible for approval and the route for handling cases that do not fit the general rule.
Policies, standards and procedures serve different purposes. A policy establishes an expectation. A standard makes it testable, for example by requiring a shared metric to have a definition and an accountable owner. A procedure explains how publication is requested, reviewed and recorded. Keeping these levels distinct makes the framework easier to maintain when platforms or workflows change.
- Scope: the domains, assets, teams and uses covered.
- Decision rights: the authority assigned to each role and the escalation route.
- Business meaning: agreed terms, definitions and reference sources.
- Conditions of use: access, sharing, retention and relevant restrictions.
- Quality and change: acceptance criteria, incident handling and communication with consumers.
- Exceptions and review: justification, approval, expiry and evidence of follow-up.
An example of a testable governance rule
“Reports must use reliable data” expresses an intention but leaves acceptance unclear. An operational rule could require a shared revenue measure to identify its source, update period, treatment of returns, accountable owner and known limitations before publication.
The check examines a sample measure and confirms that the required information exists and is applied. If a definition is missing or an exception is approved, the record needs to show who resolves it and which uses remain permitted in the meantime.
Data catalogs, metadata and a business glossary
A data catalog organizes information about available assets and their conditions of use. Metadata describes their structure, meaning, origin, ownership or processing. A business glossary agrees the terms used across teams.
For a priority dataset, useful documentation includes:
- Purpose and intended consumers.
- Definitions, units, keys and interpretation rules.
- Accountable owner and support contact.
- Sources and expected update frequency.
- Access conditions and limitations on use.
- Quality checks, known issues and review status.
The overview of metadata types and management explains the foundations. Technical scans can collect column names and types, while the meaning of a business measure still needs validation by people who understand the process.
Keeping documentation useful
A catalog entry should help a consumer decide whether information is suitable and how to request access. An entry with no maintained owner or obsolete definitions can create misplaced confidence.
Resolved questions should feed back into shared documentation. The relationship between data management and knowledge management matters when useful decisions would otherwise remain in private conversations. Priority assets deserve the depth needed for their use; not every file requires the same documentation effort.