Ask what a data governance taxonomy is, and most answers point at the wrong noun: they classify the data, when the taxonomy that matters here classifies the work governance does with it. According to McKinsey (2020), teams without a clear data inventory spend 30-40% of their time just searching for what they need, and most of those same teams already own a framework, a pillars deck, or a taxonomy sitting in a wiki somewhere. The taxonomy is the classification system underneath both: five domains of governance work, policy, data quality, lineage and access, stewardship, and compliance, that decide what a framework operationalizes and what a pillars list communicates. Whether that classification survives contact with a live data estate, or decays into a glossary nobody opens after quarter one, is the harder question.
Most content ranking for this exact phrase classifies the wrong thing. Sensitivity tiers, business domains, and ownership tags sort data assets, useful and necessary, but answering “what is this data” rather than “what does governance do with it.” The five domains below classify the governance work itself: the rules that define what is allowed, the standards that define what is trustworthy, where data flows and who can reach it, who owns which category, and how it all maps to regulation. A taxonomy that only tags data still leaves open who enforces the tag, how long it stays accurate, and what happens once an AI agent, not a person, is the one requesting access.
| Term | What it is | Where to go on Atlan |
|---|---|---|
| Taxonomy | A classification system: the categories governance work sorts into | You’re reading it |
| Framework | An implementation structure: how you operationalize governance day to day | Data Governance Framework → |
| Pillars | A stakeholder-facing building-blocks list used to communicate governance | Data Governance Pillars → |
A fourth artifact worth naming here: Data Governance Key Components breaks the same discipline into ten operational building blocks, closer to a framework’s granularity than a taxonomy’s. All three exist on the same foundation the domains below define; none of them replace it.
What is a data governance taxonomy?
Gartner defines data governance as “the specification of decision rights and an accountability framework to ensure appropriate behavior in the valuation, creation, consumption, and control of data.” A taxonomy is what makes that definition operational: it names the categories decision rights get assigned across, rather than leaving “appropriate behavior” as an abstraction. Most published data governance taxonomies, including the ones vendors and analytics platforms publish under that exact phrase, actually classify the data itself: sensitivity (public, internal, confidential), business domain (Sales, Finance, HR), and ownership. That reading is real and useful, but it is a data-asset taxonomy, not a governance-discipline taxonomy.
Policy, data quality, lineage and access, stewardship, and compliance are the five domains governance work sorts into, regardless of which data domain or sensitivity tier a given asset carries. A Data Governance Framework operationalizes those five domains day to day, with named owners, workflows, and KPIs. Data Governance Pillars and Data Governance Key Components communicate the same domains to stakeholders and break them into buildable steps. The taxonomy is the classification system underneath all three.
That classification rarely survives contact with a real data estate untouched: thousands of tables, dozens of pipelines, and AI agents now reading from it directly all put pressure on it that a filed-away document never faced. Scope matters too: data governance vs AI governance covers where this discipline ends and a newer one, controlling how models and agents act on data rather than how the data itself gets classified, begins; Atlan’s own AI Governance Framework is the parallel structure for that adjacent question.
What are the five domains of a data governance taxonomy?
Policy, data quality, lineage and access, stewardship, and compliance are the five domains, and each one is organized around a piece of governance work rather than an attribute of the data itself. Together they cover what most frameworks assign to people, process, and technology, but sorted by the kind of decision being governed rather than by who executes it.
Policy
Policy is the domain of rules: what data is allowed to exist, who can access it, how long it can be retained, and under what classification. A documented data governance policy is the artifact; the domain is whether that artifact is a PDF someone consults occasionally or a machine-readable rule a system enforces before a query runs, an idea often called policy as code. Data governance policy enforcement mechanisms covers what enforcement looks like once policy leaves the document stage.
Data quality
Data quality is the domain of trustworthiness: accuracy, completeness, freshness, and the standards used to measure all three. According to McKinsey (2020), teams without enforced data controls spend 20-30% of their time cleansing data whose quality was never governed in the first place. A quality domain with no enforced standard produces the same pattern why data governance implementations fail documents: a catalog complete on day one, untrusted by month six, the same gap that shows up as data quality problems inherited whole by an LLM instead of caught before it answers.
Lineage and access
Lineage and access is the domain of where data flows and who, or what, can reach it. Increasingly “who” includes AI agents, which is why RBAC and access in data governance and how to give AI agents access to enterprise data are the same governance question asked twice. Training data lineage for LLMs and data lineage impact analysis both depend on this domain staying current, not documented once and left alone. Zero-trust data governance, where access gets verified at the point of the request rather than assumed from a prior approval, is this domain built for an estate an AI agent can query directly, the same posture securing multi-agent systems in the enterprise requires once several agents act across the same data. How that posture gets modeled technically, not just written as policy, is what role-based access control inside an AI context platform actually implements.
Stewardship
Stewardship is the domain of ownership: who is accountable for which category, and who gets asked when two teams disagree about what a field means. Federated stewardship, where domain teams own their own segment of the taxonomy while a central team holds the five-domain standard constant, is the model most enterprises land on once one central team can no longer keep pace with the estate. Who owns AI governance: CAIO vs CDO vs CTO and who owns the context layer ask this same ownership question at the executive and infrastructure level. How to build an AI Center of Excellence is the operating-model version of assigning it formally.
Compliance
Compliance is the domain that maps the other four onto regulation: what GDPR, HIPAA, and the EU AI Act require of policy, quality, lineage, and stewardship in a given jurisdiction. Sherri Adame, Data Governance Lead at General Motors, put the stakes directly: “Atlan has been a really good partner in helping us figure out how to register AI models and applications, and what metadata to put in place to meet the transparency requirements that [AI Governance] legislation asks for.” Compliance work is downstream of the other four domains being classified correctly, not a checklist bolted on afterward.
| Domain | What it governs | Example artifact |
|---|---|---|
| Policy | What’s allowed: retention, classification, access rules | A written or machine-readable access policy |
| Data quality | What’s trustworthy: accuracy, completeness, freshness | A quality scorecard or SLA |
| Lineage and access | Where data flows and who or what can reach it | A lineage graph, an access-control list |
| Stewardship | Who owns which category | A RACI chart or a domain-ownership registry |
| Compliance | How the other four map to regulation | A GDPR or EU AI Act mapping document |
A taxonomy that names these five domains but leaves each one’s enforcement to a person remembering to check it is a glossary with good intentions, not a governance system. A small but useful practitioner signal that formalizing this kind of schema is worth the effort: the open-source cadmiumkitty/data-governance taxonomy schema on GitHub structures concepts, containers, elements, ownership, and transformations into the same kind of explicit, enforceable hierarchy.
The AI Context Stack
See where governance classification fits in the stack AI agents actually query, and what breaks when it's missing.
Get the BriefHow is a governance taxonomy different from classifying your data?
Most content that ranks for “data governance taxonomy” is actually a guide to classifying data assets: sensitivity tiers (public, internal, confidential, PII), business domain (Sales, Finance, HR), and ownership tags. That classification is real and worth doing well. A rigorous, multi-dimensional version of it, spanning business domain, entity, identifiability, sensitivity, regulatory obligation, and lifecycle stage, is documented in the Privacy-Aware Data Taxonomy for Data Governance framework, an academic model built specifically for that asset-level question.
The five governance domains classify something different: not what the data is, but what governance does with it. The two are complementary rather than competing. An asset classified “PII, Sales domain, Confidential” is the input the compliance and access domains act on; it tells the lineage-and-access domain what to restrict and the compliance domain what regulation applies. Atlan’s own guides to what data classification is and data classification and tagging cover that asset-level reading in depth, and the five governance domains take it as an input rather than re-explaining it.
| Dimension | Classifying the data | Classifying the discipline |
|---|---|---|
| What it sorts | Individual data assets (tables, columns, fields) | Governance work itself |
| Typical categories | Sensitivity, business domain, ownership | Policy, quality, lineage/access, stewardship, compliance |
| Answers the question | “What is this data?” | “What does governance do with it?” |
| Who uses it directly | Data stewards tagging assets | Governance leads structuring a program |
Neither classification means much without the other. A perfectly tagged asset with no lineage-and-access domain enforcing who can query it is still exposed; a well-run compliance domain with no underlying asset classification has nothing concrete to check against. The five governance domains are the discipline layer both those asset-level tags and every downstream policy ultimately answer to.
How does this compare to the DAMA Wheel and Microsoft’s governance domains?
Two adjacent frameworks organize similar territory without using the word “taxonomy” for it. DAMA International’s DMBOK places data governance at the center of a wheel surrounded by knowledge areas covering the wider discipline of data management. DAMA’s own current DMBOK materials confirm ten knowledge areas surrounding that hub: architecture, modeling, storage, security, integration, content management, reference and master data, warehousing and business intelligence, metadata, and quality, for eleven disciplines total once governance itself is counted. The wheel answers a broader question: it maps all of data management with governance as the hub, where this taxonomy maps only the governance discipline itself into five domains.
Microsoft Purview defines a “governance domain” as a boundary that enables common governance, ownership, and discovery of data products and business concepts, scoped to whatever business area a Purview administrator configures, HR, Sales, Finance. It is the clearest example of how a major platform vendor thinks about domain-based classification, and it is worth studying for that reason. It is also a product-configuration construct: the boundary exists inside one platform’s catalog, not across a heterogeneous estate spanning a warehouse, a lakehouse, and a dozen SaaS tools. A classification that only holds inside one platform’s configuration does not travel with the data once that data leaves the platform, which is the same limitation platform-native context layers hit at enterprise scale.
| Framework | Organizing unit | Scope |
|---|---|---|
| DAMA Wheel | 10 knowledge areas around a governance hub | All of data management |
| Microsoft Purview | Governance domain (a configured boundary) | One platform’s catalog |
| This taxonomy | Five domains of governance work | The governance discipline, across the whole data estate |
None of the three is wrong. They answer different questions at different altitudes, and an organization typically needs elements of all three: DAMA’s breadth for a data management program, Purview’s domain concept for whatever sits inside that one platform, and this taxonomy for the governance work that has to hold true regardless of which platform a given asset happens to live in this quarter.
Why does a governance taxonomy fail when it only lives in a document?
Every taxonomy that gets classified once and then filed away produces the same failure mode: it is accurate on the day it ships and progressively wrong after that. New tables get created without anyone re-running the classification. Pipelines change and lineage goes stale. An AI agent starts querying a dataset the taxonomy never accounted for, because the taxonomy assumed a human would notice and re-document it. Gartner’s Saul Judah frames the underlying pattern bluntly: a governance program “that does not enable prioritized business outcomes fails,” and a taxonomy nobody maintains is a symptom of exactly that, not a separate failure from it.
A taxonomy that lives only in a document is a glossary. It tells a reader what the five domains mean, but nothing in a glossary checks whether a new column got classified, whether a policy actually blocked a bad query, or whether an agent’s access request matched what stewardship intended. The distinction that separates governance programs that scale from ones that quietly decay is not which domains they name; it is whether classification propagates automatically the moment the data estate changes, or waits for someone to remember, the same static catalog versus living context layer distinction that decides whether a catalog stays trusted past its launch month, and the same distinction a context catalog is built around: context expected to change constantly, not filed away once. What is active ontology covers the same living-versus-static idea applied to the structure underneath a taxonomy, not just its categories.
That is a mechanical fix, not an aspirational one, and it is the version these five domains have to survive to be worth naming at all.
Context Maturity Assessment
Score where your governance taxonomy actually enforces itself against where it still depends on someone remembering.
Take the AssessmentHow Atlan makes a governance taxonomy operational
A taxonomy applied once through manual tags or a wiki page degrades the moment the data estate changes: a new table appears without inheriting a classification, a rebuilt pipeline breaks the lineage a policy relied on, an AI agent reads from a dataset nobody re-documented.
Atlan’s classification, PII tags, security labels, compliance flags, and quality scores propagate along data lineage automatically to every downstream asset and every AI agent that touches it. A column tagged PII once is inherited everywhere it flows, rather than re-tagged manually at each new table it feeds. Policy gets expressed as machine-readable rules enforced at the point an agent or person tries to reach the data, not a PDF consulted after the fact, which is the policy-as-code version of the policy domain described above. Federated stewardship lets domain teams own their own segment of the taxonomy while a central team holds the five-domain standard constant. That’s the model context layer work for data governance teams is built around. The enterprise context layer is the mechanism that makes this hold across a heterogeneous data estate rather than one platform’s boundary. Whether a team builds that layer, buys it, or extends what it already has is its own decision; implementing an enterprise context layer for AI and self-service analytics governance: build or buy for AI agents both walk through it. Whichever route a team takes, that governed context still has to reach an agent somehow; the MCP pattern that delivers business context is how Atlan does it regardless of which underlying system holds the data.
In Atlan’s AI Labs benchmark, adding this kind of governed context to a model improved text-to-SQL accuracy by 38%, and Atlan’s analysis of Gartner’s active-metadata research found that keeping metadata current this way can cut the time to deliver a new data asset by up to 70%. A taxonomy that enforces itself is not a bigger version of the same document; it is a different kind of artifact, one a context graph represents rather than a spreadsheet, and one whose return on investment is measured in avoided rework, not in whether the document got read.
Context Layer ROI Calculator
Estimate what a self-enforcing taxonomy is worth against the hours your team currently spends re-verifying data.
Calculate Your ROIA taxonomy earns its place by enforcing itself, not by being named
A data governance taxonomy names five domains: policy, data quality, lineage and access, stewardship, and compliance. A framework operationalizes them with named owners and enforcement. A pillars list communicates them to stakeholders. None of the three replaces the other two, and the domains matter because they are what stays constant while everything else churns: sensitivity tiers change with regulation, business domains shift when a company reorganizes, policy documents get rewritten every year. Classifying governance work once, carefully, only pays off if that classification travels with the data automatically instead of sitting in whichever document was last updated. That is the difference between a taxonomy and a glossary, and it is the standard worth holding any framework, pillars list, or platform’s own domain concept to.
FAQs about data governance taxonomy
1. What is the difference between data governance and data management?
Data governance sets the decision rights, policies, and accountability for how data gets used; data management is the day-to-day execution of moving, storing, and processing it. Governance decides who can approve a schema change and under what policy; data management is the pipeline that makes the change happen. One defines the rules, the other runs the operation the rules apply to.
2. What are the three roles of data governance?
Most governance operating models name three core roles: data owner (accountable for a domain’s decisions), data steward (responsible for day-to-day quality and documentation), and data user (consumes data under the policies the first two set). Some frameworks add a fourth, a governance council that arbitrates conflicts between owners, but owner, steward, and user is the baseline triad.
3. Can we define our own classification levels, or must we use a preset taxonomy?
You can define your own classification levels. Sensitivity tiers, business domains, and ownership categories are specific to each organization’s data estate and regulatory exposure, and no regulator mandates a single preset scheme. What matters more than the exact levels you choose is that classification gets applied consistently and enforced automatically, not that it matches an external template.
4. How are classification conflicts handled?
Classification conflicts, where two domains disagree on how an asset should be tagged or who owns it, get escalated to the governance council or the named executive sponsor rather than resolved by whichever team touched the data last. The stricter classification typically wins by default (a field with any PII exposure gets treated as PII estate-wide) until the council rules otherwise.
5. What are the components of a data governance framework?
A data governance framework’s components typically include people and ownership structures, standardized processes, technology and automation, and machine-readable policy, built on top of the same domains this taxonomy defines. The full breakdown, with a template and KPI scorecard, lives on Atlan’s Data Governance Framework page.
6. What are the 4 pillars of data governance?
There is no single agreed-on “4 pillars” list; published counts range from three to nine depending on the source, and Atlan’s own Data Governance Pillars page documents nine, not four. Treat any specific pillar count as one vendor’s or analyst’s framing rather than a fixed standard, and check the source’s full list before repeating a number.
7. What is a data domain in data governance?
A data domain is a business area, such as Sales, Finance, or HR, used to classify data assets by where they originate and who uses them. That is a different sense of “domain” than the five governance domains this taxonomy describes: a data domain classifies the data itself, while a governance domain classifies the governance work (policy, quality, lineage, stewardship, compliance) applied across every data domain.
8. How does Atlan make a data governance taxonomy operational instead of a static document?
Atlan propagates classification, PII tags, security labels, compliance flags, quality scores, along data lineage automatically to every downstream asset and every AI agent that touches it. A column tagged once inherits its classification everywhere it flows, and access is enforced at the point an agent or person tries to reach it, not applied after the fact from a document.
Sources
- Data Governance, Gartner. https://www.gartner.com/en/data-analytics/topics/data-governance
- Reducing Data Costs Without Jeopardizing Growth, McKinsey, 2020. https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/reducing-data-costs-without-jeopardizing-growth
- Gartner Predicts 80% of D&A Governance Initiatives Will Fail by 2027 (Saul Judah, VP Analyst), Gartner, 2024. https://www.gartner.com/en/newsroom/press-releases/2024-02-28-gartner-predicts-80-percent-of-data-and-analytics-governance-initiatives-will-fail-by-2027-due-to-a-lack-of-a-real-or-manufactured-crisis-
- DAMA-DMBOK: Data Management Body of Knowledge, DAMA International. https://dama.org/learning-resources/dama-data-management-body-of-knowledge-dmbok/
- Governance Domains in Unified Catalog, Microsoft Learn. https://learn.microsoft.com/en-us/purview/unified-catalog-governance-domains
- A Privacy-Aware Data Taxonomy for Data Governance, sapub.org, 2025. http://article.sapub.org/10.5923.j.computer.20251506.05.html
- cadmiumkitty/data-governance: An Open-Source Data Governance Taxonomy Schema, GitHub. https://github.com/cadmiumkitty/data-governance
