Data Governance & Stewardship

Data governance is the set of policies, roles, and tooling that decide who owns each piece of data, what it means, and who is accountable for its accuracy.

At a glance

• What it is: Assigning data owners and stewards, maintaining a data catalog and business glossary, and defining access and change-approval policies for shared data.
• Why it matters: Governance is what prevents three different teams from each building their own definition of the same business term.
• For developers: check the data catalog or business glossary before defining a new metric or field — redefining an existing term locally is exactly how metric drift starts.
• When to use it: For any data shared or referenced across more than one team or system.
• When not to use it: For purely personal or local temporary data with no downstream consumers.
• Prerequisites: Master Data Management.

Mental model

graph LR
    Owner["Data owner\n(accountable)"] --> Steward["Data steward\n(day-to-day custodian)"]
    Steward --> Catalog["Data catalog &\nbusiness glossary"]
    Catalog --> Consumers["Consumers\n(analysts, engineers, dashboards)"]

The owner is accountable for a data domain at a business level; the steward does the day-to-day work of defining, documenting, and resolving disputes about it; the catalog and glossary make that agreed definition discoverable so consumers don’t have to guess or re-derive it.

Step-by-step walkthrough

1. Identify the critical data domains that matter most (customer, order, product, revenue).
2. Assign a data owner accountable for each domain and a steward who manages it day to day.
3. Build and maintain a data catalog (what data exists, where) and a business glossary (what each term means).
4. Define access policies and a change-approval process for shared definitions and schemas.
5. Review and audit the catalog/glossary periodically so it doesn’t go stale.

Worked example

At a board meeting, Northwind’s marketing, finance, and product teams each present a different number for “active customers” — three dashboards, three definitions, no agreement on which is right.

• Input: three independently built definitions of “active customer” (marketing: logged in within 30 days; finance: made a purchase within 90 days; product: opened the app at all, ever).
• Process: a data owner is assigned for the Customer domain; a steward facilitates a session with all three teams to agree on one definition, balancing each team’s actual need.
• Output: a single agreed definition of “active customer” is published in the business glossary, and all three dashboards are updated to reference that one definition going forward. On Azure, the catalog and glossary are typically hosted in Microsoft Purview, which also scans and classifies the underlying data sources so the glossary stays linked to where each term actually lives.

Common use cases

Use case	When to use	Notes
Business glossary rollout	Multiple teams use the same term differently	Start with the highest-conflict terms, not an exhaustive glossary on day one
Data catalog adoption	Nobody knows what data exists or where	Catalog existing data before mandating new documentation standards
Data quality council	Recurring disputes about data ownership or accuracy	A standing forum, not a one-time meeting
Access approval workflow	Sensitive or regulated data needs controlled access	Pairs with Data Privacy, Security & Compliance

Advanced details

• Federated vs. centralized governance: centralized governance is easier to keep consistent but can bottleneck; federated (domain-owned) governance scales better but needs strong shared standards to avoid re-fragmenting — this is the core idea behind data mesh, which names four specific principles: domain-oriented data ownership (each domain team owns its own data), data as a product (a domain’s data has a defined owner, quality bar, and discoverability, not just an export), a self-serve data platform (domains don’t each rebuild pipeline/storage tooling from scratch), and federated computational governance (global rules like access and classification are enforced automatically across domains, not manually per team).
• Stewardship workflows: define an explicit process for resolving ambiguous or disputed definitions, rather than letting the loudest team’s definition win by default.
• Policy as code: mature governance programs encode access and quality policies as automated, enforced rules rather than relying on manual review alone.
• This section maps onto DAMA-DMBOK’s knowledge areas: the Data Management Body of Knowledge (DAMA-DMBOK) is the standard reference defining data governance, data quality, metadata management, and master/reference data management as distinct knowledge areas — the topics in this folder (Master Data Management, Data Governance & Stewardship, Data Privacy Security & Compliance, Data Lifecycle Management) are this site’s practical walk through several of those same knowledge areas.

Quick reference

Term	Meaning
Data owner	The accountable party for a data domain’s accuracy and definition
Data steward	The person who manages a data domain day to day on the owner’s behalf
Data catalog	An inventory of what data exists and where it lives
Business glossary	The agreed, published definitions of business terms and metrics
Data domain	A logical grouping of related data (e.g. Customer, Order, Product)
DAMA-DMBOK	The Data Management Body of Knowledge — the standard reference defining data governance, quality, metadata, and MDM as distinct knowledge areas
Data mesh’s 4 principles	Domain-oriented ownership, data as a product, self-serve data platform, federated computational governance

Troubleshooting

Symptom	Likely cause	Fix
Same metric shows different values across teams	No agreed single definition exists	Assign an owner/steward and publish one definition in the business glossary
Nobody can approve a schema or definition change	No defined change-approval process	Establish a lightweight approval workflow with a named owner per domain
Catalog or glossary is outdated	No periodic review cadence	Schedule regular audits, not just an initial one-time population

Check your understanding

• Why does assigning an owner and a steward work better than assigning just one or the other?
• Pick a metric your team reports on — could you point to where its definition is documented, or does everyone just “know” it informally?

Related pages

Part of Introduction to Data Architecture. See also Master Data Management for the entities governance oversees, Data Privacy, Security & Compliance for access-control policy, Analytics & BI Architecture for where agreed definitions get consumed, and the Glossary for term definitions.