An Enterprise Data Governance Glossary Operators Can Use

The first enterprise glossary failed because it defined words and left decisions untouched.

The definitions were reasonable. Business Intelligence meant turning raw data into information for decisions. Data Steward meant the business role responsible for metadata and data quality. Metadata meant data about data. Data retention meant how long data was kept. Nobody argued much with the words.

Then the customer dashboard shipped.

Sales used one definition of active customer. Finance used another. Support wanted canceled customers included while service obligations were still open. Security wanted a sensitive field masked. Analytics wanted drill-through access to transaction-level detail. Legal asked whether the retention schedule allowed the historical table to exist in the first place.

The glossary had entries. It did not have operating force.

That is the standard I use now: a governance glossary is useful only if it changes how a data product is reviewed, approved, accessed, monitored, and retired. A definition should name the thing, but it should also tell the team who owns it, where it appears, how it is measured, and what decision it affects.

This post is a practical glossary for enterprise data governance. It is not a legal taxonomy, and it is not a replacement for frameworks like EDM Council DCAM, NIST CSF 2.0, NIST Privacy Framework, or NIST SP 800-53. It is the operating language I want in the room when business, analytics, platform, security, privacy, and governance teams have to make the same data product mean the same thing.

How to Use the Glossary#

A glossary entry should answer more than "what does this term mean?"

It should answer:

• Who owns the term?
• Which data products use it?
• Which source is authoritative?
• Which quality rules prove it is fit for use?
• Which privacy or security controls apply?
• Which downstream decisions break if the meaning changes?

The tradeoff is precision over speed. It is faster to let every team define terms locally. It is also how enterprises end up with five revenue numbers, three customer counts, and a privacy review that discovers sensitive data after the dashboard is already trusted.

The better path is slower at the definition boundary and faster everywhere downstream.

Business and Analytics Terms#

These terms describe how data becomes decision support.

Microsoft's Power BI drillthrough documentation is a useful reminder that navigation features carry governance implications. Drill-through often moves a user from summary to detail. That can change privacy risk, row-level access needs, and interpretation.

Governance Roles and Structures#

These terms describe who can define, approve, implement, and escalate.

I wrote a companion role model in Data Governance Roles Need Decision Rights. The short version here is simple: owners decide, stewards define, custodians implement, SMEs validate, and the committee escalates enterprise risk.

Governance Concepts#

These terms describe the rules of the operating model.

The failure mode is treating "source of truth" as a universal title. It is rarely universal. A billing system may be authoritative for invoice status. A CRM may be authoritative for account owner. A support platform may be authoritative for service obligations. A governed domain needs scoped authority, not slogans.

Data Management Concepts#

These terms describe how data is created, moved, described, and made reusable.

Microsoft Purview's data governance glossary and lineage documentation are useful examples of how catalog terms, classifications, assets, and lineage become a connected operating surface.

The most common mistake is separating glossary and catalog work. A glossary without asset links is vocabulary. A catalog without business terms is inventory. Governance needs both.

Security, Privacy, and Compliance Terms#

These terms describe how data is protected and constrained.

For security and privacy terms, current link-outs matter. NIST CSF 2.0 provides a general cyber risk management frame. NIST SP 800-53 organizes detailed control families such as access control, audit and accountability, incident response, PII processing and transparency, and system integrity. NIST's RBAC project gives historical and technical context for role-based access control.

For de-identification, Google Sensitive Data Protection documents transformations such as masking, and HHS explains HIPAA de-identification through Expert Determination and Safe Harbor. For GDPR-oriented teams, the European Commission's GDPR principles are a cleaner anchor than secondhand summaries.

Lifecycle Management Terms#

These terms describe how data quality and data lifespan are governed.

Lifecycle terms are where privacy, cost, and analytics collide. Analysts often want history. Legal may need retention. Privacy may require minimization and deletion. Platform teams want storage cost under control. The glossary should not pretend those tensions disappear. It should name the decision owner and the evidence required.

Term Entry Contract#

The glossary becomes operational when each governed term has a minimum contract.

term: "active customer"
domain: "customer"
status: "approved"
owner: "customer data owner"
steward: "customer data steward"
definition: "A customer with an active billable contract during the reporting period."
business_context: "Used for executive reporting, retention analysis, and revenue operations."
authoritative_source: "crm.account_contract_status"
related_terms:
  - "billable customer"
  - "service obligation"
  - "churned customer"
quality_rules:
  - name: "contract status is populated"
    threshold: ">= 99.5 percent"
  - name: "reporting period has one status per account"
    threshold: "100 percent for certified reporting"
security_and_privacy:
  classification: "confidential"
  pii_fields:
    - "account_contact_email"
  access_model: "RBAC with steward approval for detail-level drill-through"
lineage:
  source: "crm"
  certified_asset: "customer_profile_certified"
  consumers:
    - "executive_customer_scorecard"
    - "retention_model_features"
change_control:
  breaking_change_requires:
    - "steward review"
    - "owner approval"
    - "consumer migration note"
retention:
  rule: "retain certified monthly snapshots for 7 years unless legal hold applies"
evidence:
  - "definition approval record"
  - "quality dashboard"
  - "lineage registration"
  - "access review log"

This looks heavier than a plain definition because plain definitions are not enough for enterprise use. A term that drives reporting, access, AI features, compliance, or customer action needs ownership, source, rules, controls, lineage, and change behavior.

What I Would Add Before Calling It Complete#

The starter glossary above covers the core vocabulary from business analytics, roles, governance, data management, security, privacy, compliance, and lifecycle management. Before using it as an enterprise standard, I would add a few organization-specific columns:

The status field is underrated. Proposed terms should not be treated like approved terms. Deprecated terms should not vanish quietly. Retired terms should leave a pointer to their replacement or the reason they stopped being valid.

The Tradeoff#

Glossaries slow people down at the start.

Someone has to decide whether "customer" means buyer, account, household, patient, subscriber, merchant, tenant, or legal entity. Someone has to separate dashboard convenience from source-of-truth authority. Someone has to say that a field cannot be used for a new purpose until privacy and access have been reviewed.

That friction is the cost of enterprise meaning.

The alternative is local speed and global confusion. Every team moves quickly until a metric dispute reaches leadership, a model trains on an unstable feature, a regulatory request takes weeks, or a data quality incident reveals that nobody knows which definition was official.

I would rather pay the definition cost once and attach it to artifacts than keep paying the trust tax forever.

The Review Checklist#

Use this checklist when adding or approving a glossary term.

That is the difference between a glossary and a governance asset.

A glossary is not successful because it has many entries. It is successful when the next dashboard, data product, AI feature, access request, and incident review all use the same language without reopening the same argument.