What a CDE Actually Is: The Meta Model That Nobody Published

CDE Practitioner’s Guide: Overview | Part 0 | Part 1 | Part 2 | Part 3 | Part 4 | Part 5 | Part 6

The Question Nobody Answers First

This is the chapter I wish someone had handed me before the first CDE program I worked on.

Organizations launch Critical Data Element programs without agreeing on what a CDE structurally is.

Some teams treat CDEs as physical columns tagged in a catalog. Others treat them as business concepts that span systems. The difference is not academic. It determines your governance model, your quality rule architecture, your lineage requirements, and whether your program scales past 100 elements.

Consider a composite example, representative of programs this size. A mid-size US bank identifies approximately 300 Critical Data Elements. When the team maps those 300 CDEs to their physical implementations across source systems, data warehouses, and reporting layers, they typically find several thousand physical columns, on the order of 6,000 in a 1:20 ratio. If the bank had treated each column as a separate CDE, it would have been governing 6,000 elements with inconsistent definitions, fragmented ownership, and duplicate quality rules. Instead, it governs 300 business concepts, each with a clear definition, a single owner, and quality rules that cascade to every physical instantiation.

That 1:20 ratio is not unusual. TDAN’s analysis of Metadata Management found that the same data element can exist “10 or even 70 times across the enterprise.” Multiply 250 CDEs by even the conservative end of that range and you get 2,500 physical columns. At the high end: 17,500.

The structural question has to be answered first. What a CDE is determines how you identify CDEs (Part 1), build an inventory (Part 2), operationalize quality monitoring (Part 3), and scale the program (Part 4). Yet no canonical, vendor-neutral meta model for CDEs exists in published literature. ISO 11179 provides the foundation. DCAM provides the governance overlay. Vendors like Collibra, Purview, and Alation have their own entity models. But nobody has assembled these into a single, coherent reference architecture.

This article does that.

The Definition

A Critical Data Element is a business-level data concept that is essential to the organization’s regulatory compliance, risk management, financial reporting, or operational decision-making.

A CDE is not a physical column, though every CDE maps to one or more physical columns. “Customer Social Security Number” is a CDE. The column core_banking.dbo.customers.ssn, the column data_warehouse.edw.dim_customer.social_security_number, and the column regulatory_reporting.ccar.y14m_mortgage.borrower_ssn are three physical instantiations of that single CDE.

This distinction has deep roots across standards, frameworks, and practitioner guidance. The convergence is striking: international standards, industry frameworks, independent practitioners, and commercial vendors all arrive at the same structural conclusion.

ISO 11179 separates the Data Element Concept (an Object Class combined with a Property) from the physical Data Element (a Concept combined with a Value Domain). The concept “Customer Social Security Number” exists independent of any particular system’s column name or data type. The standard explicitly accommodates multiple physical representations of the same concept (ISO/IEC 11179; ISO/IEC 11179-3:2023).

DCAM, the EDM Council’s Data Management Capability Assessment Model, anchors governance at the Business Term level and relates every physical occurrence of a CDE back to that term, so metadata is defined once and inherited by all instances (DCAM). The framework positions the Business Term as the governance anchor, with physical columns as the governed instances beneath it.

Dr. Irina Steenbeek of Data Crossroads advises that “the preferable approach is to first identify critical data elements at the level of logical models along a data chain and then… link the logical and physical models using horizontal and vertical data lineage” (Data Crossroads, 2024). She distinguishes between the semantic identity of a data element and its physical containers, arguing that governance decisions belong at the semantic level.

Kalypso’s analysis draws the same boundary between the business concept and its meaning and the physical column in a specific system (Kalypso). Governance attaches to the concept. Technical implementation manages the columns.

Microsoft Purview implements CDEs as first-class entities, defining a CDE as “a logical grouping of important columns across tables” (Microsoft Purview CDEs). The platform maps one CDE to many columns, and Purview’s broader Unified Catalog model rolls quality measurement up from the column to the CDE to the governance domain.

For practitioners: Every source converges on the same structural conclusion: a CDE is a business concept. Columns are its physical manifestations.

The Three-Layer Meta Model

With the definition established, the next question is: what attributes does a CDE carry, what attributes do its physical columns carry, and how do the two connect?

The answer is a three-layer architecture. The top layer holds business governance. The bottom layer holds technical implementation. And a middle layer, often overlooked, bridges the two.

Conceptual Layer: Business Governance

This is where the CDE lives. Every governance decision attaches here.

Attribute	Description	Example
CDE Name	Canonical business name	Customer Social Security Number
Business Definition	Plain-language definition agreed across domains	The nine-digit identifier assigned by the Social Security Administration to an individual customer
Data Domain	Business domain that owns this concept	Customer
Data Owner	Business executive accountable for the element	VP, Retail Banking
Data Steward	Subject matter expert managing day-to-day quality	Customer Data Steward
Criticality Tier	Tier 1 (regulatory), Tier 2 (financial), Tier 3 (operational)	Tier 1
Regulatory Relevance	Which regulations require this element	CCAR (FR Y-14M), HMDA, BSA/AML
Privacy Classification	PII, PHI, confidential, public	PII
Retention Policy	Business retention requirement	7 years after account closure
Quality Rules	Business-level thresholds	Completeness > 99.9%, Format: 9 digits, no dashes
Valid Value Sets	Permitted values or format constraints	9-digit numeric, no leading zeros eliminated

Semantic Layer: The Logical Bridge

This is the layer most organizations skip, and the layer that makes everything else work.

Attribute	Description	Example
Logical Name	Standardized attribute name	customer_ssn
Parent Data Entity	The logical entity this attribute belongs to	Customer
Data Type / Format	Logical data type	CHAR(9)
Authoritative Source Flag	Whether this system is the golden source	Yes (Core Banking), No (Data Warehouse)
Upward Link	Maps to CDE	Customer Social Security Number
Downward Link	Maps to specific columns	core_banking.dbo.customers.ssn; edw.dim_customer.social_security_number

The semantic layer matters because it translates between two vocabularies. Business stakeholders talk about “Customer Social Security Number.” Engineers talk about core_banking.dbo.customers.ssn. Without a bridge entity that connects the two, governance and technology speak different languages. The data steward defines a quality rule on a concept they understand. The data engineer implements that rule on a column they can query. The semantic layer is the Rosetta Stone.

It also solves the authoritative source problem. When a single CDE maps to twenty columns across seven systems, you need to know which column is the golden source and which are downstream copies. The authoritative source flag lives at the semantic layer because the question “which system owns this data?” is a logical question, not purely a business question or a purely physical one.

Physical Layer: Technical Implementation

This is where measurement happens.

Attribute	Description	Example
Fully Qualified Column Name	database.schema.table.column	core_banking.dbo.customers.ssn
Physical Data Type	Actual storage type	VARCHAR(11)
System / Application	Source system name	Core Banking (FIS)
Quality Measurements	Actual scores from profiling	Completeness: 99.94%, Format compliance: 99.87%
Profiling Results	Distribution, null counts, pattern analysis	0.06% null, 0.13% contain non-numeric characters
Technical Lineage	ETL/pipeline lineage	core_banking.customers.ssn > ETL_job_142 > edw.dim_customer.social_security_number

Where Everything Attaches

The three-layer structure is not just an organizational convenience. It determines where every governance artifact binds.

Quality Rules

Quality rules are defined at the CDE level. They are measured at the column level. Scores aggregate upward.

The CDE “Customer Social Security Number” carries a rule: completeness must exceed 99.9%. That single rule applies to every physical column mapped to this CDE. The core banking column measures 99.94%. The data warehouse column measures 99.91%. The regulatory reporting column measures 99.97%. Each column has its own score. The CDE’s aggregate score is a weighted average or a worst-case rollup, depending on your methodology.

Thresholds can also vary by position in the data chain. The source system might tolerate 99.5% completeness because records are still being enriched. The regulatory report requires 99.9% because incomplete records trigger examination findings. The rule is the same (“completeness for Customer SSN”), but the threshold varies by where in the pipeline you measure. This nuance belongs at the semantic layer, where the authoritative source flag and the position in the lineage chain are both visible.

Lineage

Two types of lineage serve different audiences, and both are necessary.

Technical lineage traces at the column level: source_system.table.column flows through ETL_job_123 into warehouse.table.column, which feeds report.table.column. Tools like Collibra Data Lineage, Solidatus, and Manta operate here.

Business lineage connects the CDE to its physical instantiations through the semantic layer. The Data Owner does not need to know that ETL_job_123 transforms VARCHAR(11) to CHAR(9). They need to know that “Customer Social Security Number” flows from Core Banking (authoritative source) through the enterprise data warehouse into CCAR reporting. Business lineage operates at the CDE and semantic layers.

The ECB’s 2024 RDARR Guide requires banks to maintain data lineage “on data attribute level” (starting from data capture and including extraction, transformation, and loading), not merely system to system (ECB, 2024). That requirement sits squarely in the semantic layer. System-to-system lineage is too coarse. Column-to-column lineage alone is too granular for governance consumers. Attribute-level lineage connects business meaning to physical reality.

Ownership

Ownership is assigned at the CDE level through a three-tier accountability model. Each tier serves a distinct function, and collapsing them into a single “steward” role is one of the most common reasons CDE programs stall.

Data Owner (VP/Director or above): Ultimate accountability for a CDE or CDE domain. The Data Owner sets quality policy, approves tier classification, and signs off on certification. This is a governance role, not an operational one. The Data Owner does not investigate individual quality failures; they set the standards and hold the organization accountable for meeting them.

Principal Steward (Director/Senior Manager): Portfolio-level accountability for a set of CDEs. The Principal Steward resolves cross-domain conflicts, reviews quality trends, and certifies register entries quarterly. In the three-tier model this guide recommends, this is the tier most programs skip. Without it, Data Owners are pulled into operational detail they cannot sustain, and Domain Stewards lack an escalation path with actual authority.

Domain Steward (SME/Analyst): Day-to-day quality ownership. The Domain Steward investigates failures, coordinates remediation, maintains definitions, and responds to SLA breaches. This is the hands-on-keyboard role that most organizations think of when they say “data steward.”

“Customer Social Security Number” has a single Data Owner (VP, Retail Banking) regardless of how many columns contain that data across however many systems. The Data Owner is accountable for the definition, the quality thresholds, and the retention policy. The Principal Steward certifies that the CDE register entry is accurate and that quality trends remain within tolerance. The Domain Steward investigates when completeness drops below 99.9% in a downstream system and coordinates the fix.

For a detailed treatment of the three-tier model, including capacity guidelines and sustainability practices, see Part 3: Operationalizing CDEs.

What this looks like in practice. Assigning ownership per column creates a governance nightmare: who owns edw.dim_customer.social_security_number versus regulatory_reporting.ccar.y14m_mortgage.borrower_ssn? They are the same data concept. The answer is the same person at each tier.

Nicola Askham emphasizes this in her Data Governance coaching practice: accountability must sit with the business, at the level of the business concept, not distributed across technical instances where it becomes diffuse and unenforceable.

Privacy and Sensitivity Classification

Privacy classification attaches at the CDE level. “Customer Social Security Number” is PII regardless of which column it lives in, regardless of whether the column is in a source system, a data warehouse, or a reporting layer.

What this looks like in practice. This matters operationally. When a privacy impact assessment asks “where does PII reside?”, the answer starts from the CDE inventory: here are our PII-classified CDEs, and here are all the physical columns they map to. That gives you a complete, auditable inventory of PII locations across the enterprise, derived from one classification decision per CDE rather than thousands of classification decisions per column.

Retention Policy

The retention decision is a business decision about the concept, not about the column name. “Customer Social Security Number” must be retained for seven years after account closure. That policy applies to every physical column mapped to this CDE. Different systems may implement the retention differently (soft delete in the source, hard delete in the warehouse after the retention window), but the policy itself attaches at the CDE level because the business rationale is about the concept.

Data Contracts

Data contracts reference CDEs as their governance anchor. A contract between a data producer (Core Banking) and a data consumer (CCAR Reporting) specifies which CDEs the producer commits to delivering, at what quality level, with what freshness, and under what change management procedures.

The contract does not say “deliver core_banking.dbo.customers.ssn with 99.9% completeness.” It says “deliver Customer Social Security Number with 99.9% completeness.” The CDE is the unit of agreement. The physical column is the implementation detail. If the producer restructures their schema, renames the column, or migrates to a new platform, the contract remains valid because it references the concept, not the container.

The ISO 11179 Foundation

The three-layer meta model is not invented from scratch. Its conceptual roots trace directly to ISO/IEC 11179, the international standard for metadata registries, first published in 1994 and most recently updated in 2023 (ISO/IEC 11179-3:2023).

ISO 11179 defines a two-level architecture for data elements:

Level 1: Data Element Concept. A Data Element Concept combines an Object Class (the thing you are describing) with a Property (the characteristic being measured). “Customer” is the Object Class. “Social Security Number” is the Property. Together they form the Data Element Concept “Customer Social Security Number.” This is a semantic entity. It has meaning independent of any physical representation.

Level 2: Data Element. A Data Element combines a Data Element Concept with a Value Domain (the permissible representation). The same Concept can be represented through different Value Domains: one system stores SSN as CHAR(9) with no formatting, another stores it as VARCHAR(11) with dashes. Each combination of Concept plus Value Domain is a distinct Data Element in the ISO 11179 sense.

Multiple Data Elements can represent the same Data Element Concept through different Value Domains. This is exactly the one-to-many pattern that CDE programs encounter: one business concept, many physical representations.

The standard also prescribes a naming convention: [Object Class] [Property] [Representation Term]. “Customer Credit Score Value” follows this pattern. “Customer” is the Object Class, “Credit Score” is the Property, and “Value” is the Representation Term indicating a numeric measurement. This naming convention, while not universally adopted, provides a consistent taxonomy that reduces ambiguity when CDEs span organizational boundaries.

CDE programs overlay criticality on top of this structure. ISO 11179 provides the entity model for any data element. A CDE program selects the subset of data elements that are critical to the organization and applies additional governance: ownership, tiered SLAs, quality thresholds, regulatory mapping, and privacy classification. The three-layer meta model presented earlier maps directly onto ISO 11179:

• Conceptual Layer corresponds to the Data Element Concept (Object Class + Property) plus the criticality and governance overlay
• Semantic Layer corresponds to the bridge between Concept and physical representation, including the Value Domain and authoritative source designation
• Physical Layer corresponds to the registered Data Element in its specific representational form within a specific system

How Vendors Implement This

No two vendors model CDEs the same way, but every major Data Catalog or governance platform implements some version of the three-layer pattern. Understanding the vendor landscape helps you map the meta model to your actual tooling.

Vendor	CDE Entity Type	CDE-to-Column Path
Collibra	Business Term + criticality attribute	Business Term > Data Attribute > Column (three-layer)
Alation CDE Manager	First-class CDE entity	AI semantic mapping: CDE > Columns
Microsoft Purview	First-class CDE entity	CDE > Columns directly
Informatica CDGC	Business Term + Data Element Classification	Business Term > Column
Ataccama	Business Glossary Term	Term > Attributes (DQ rules cascade from Term)
IBM Knowledge Catalog	Business Term + Data Class	Business Term <> Data Class > Column (auto-profiling)

Two architectural camps emerge from this landscape.

CDE as first-class entity. Microsoft Purview and Alation’s CDE Manager (introduced November 2025, initially in private beta) treat CDEs as dedicated entity types in their data models. In Purview, a CDE is an object within a Governance Domain that maps directly to columns, and the platform’s broader quality model rolls scores up from column to CDE to domain (Microsoft Purview CDEs). Alation uses AI-driven semantic mapping to connect CDE entities to physical columns across the catalog (Alation CDE Manager). The advantage of this approach: CDEs are visible as their own objects in the catalog, which simplifies reporting and governance workflows.

CDE as decorated Business Term. Collibra, Informatica, Ataccama, and IBM Knowledge Catalog model CDEs as Business Terms with additional attributes (a criticality flag, a classification tag, or a custom property). In Collibra’s Guided Stewardship model, the three-layer pattern is explicit: Business Term connects to Data Attribute connects to Column (Collibra). Ataccama is notable because DQ rules attach directly to the Glossary Term and cascade automatically to every tagged attribute, which operationalizes the “define once, measure everywhere” pattern without manual rule duplication.

Both approaches work. The choice depends on your tooling and your organization’s catalog maturity. The meta model is the same regardless of whether your vendor gives CDEs their own entity type or represents them as enriched Business Terms. What matters is that the one-to-many relationship between concept and columns exists, that governance attributes attach at the concept level, and that measurements aggregate upward from the physical layer.

Industry-Specific Variations

The core meta model holds across industries, but the reference ontologies and regulatory drivers differ.

Banking: FIBO and the ECB’s Attribute-Level Lineage Requirement

The Financial Industry Business Ontology (FIBO) provides the semantic reference framework for banking CDEs. When a bank identifies “Legal Entity Identifier” or “Counterparty Exposure” as CDEs, the business definitions should align to FIBO’s OWL class definitions. FIBO provides standardized, machine-readable definitions for financial concepts that reduce ambiguity when CDEs cross organizational boundaries or when regulators ask for documentation.

The ECB’s 2024 RDARR Guide goes further. It mandates attribute-level lineage for Critical Data Elements, requiring banks to trace data from the point of origin to the final report at a granularity that supports validation and reconciliation (ECB, 2024). In meta model terms, the ECB requires full traversal of all three layers: from CDE (conceptual) through Data Attribute (semantic) to Column (physical), with documented lineage at each transition.

Healthcare: USCDI, NIH CDEs, and the FHIR Evolution

Healthcare has the most formally structured CDE ecosystem of any industry.

The United States Core Data for Interoperability (USCDI) is, functionally, a regulator-curated CDE list. USCDI v5 (July 2024) defines standardized data elements organized by clinical context: patient demographics, medications, lab results, clinical notes, social determinants of health, and more. Each USCDI data element is a CDE in everything but name.

The NIH Common Data Element Repository follows ISO 11179 structure explicitly. Each CDE in the repository is a standardized question paired with allowable responses (the ISO 11179 Data Element Concept combined with a Value Domain). The NIH’s “gold ribbon” designation marks CDEs that have achieved the highest level of standardization and validation. This is the closest any public repository comes to operationalizing ISO 11179 for real-world Data Governance.

FHIR’s evolution illustrates the architectural challenge. FHIR STU3 included a dedicated DataElement resource for representing metadata about data elements independent of their use in questionnaires or observations. In FHIR R4, the DataElement resource was absorbed into the broader StructureDefinition resource. The meta model did not disappear; it was folded into a more general-purpose framework. Healthcare organizations implementing CDE programs on FHIR need to understand that the structural concept persists even though the dedicated resource type does not.

Insurance: EIOPA’s Data Point Model

EIOPA’s Data Point Model for Solvency II is arguably the most formally defined regulatory meta model in any industry (EIOPA). Every cell in every Quantitative Reporting Template maps to a unique Data Point. Each Data Point is defined as a Metric combined with a set of Dimension Members.

In CDE meta model terms: the Metric is the Data Element Concept (what is being measured), the Dimension Members are the Value Domain constraints (which slices of that metric apply), and the Data Point is the registered Data Element. An insurer’s CDE program for Solvency II compliance is, in effect, a mapping exercise from the EIOPA Data Point Model to the insurer’s internal data landscape. The meta model provides the structural bridge.

The Practical Implication: What This Changes

The meta model is not an academic exercise. It has direct consequences for every part of this series.

When Part 1 says “start from uses, trace backward to CDEs,” the destination of that trace is a business concept, not a column. You trace from a CCAR report field back through transformation layers and arrive at “Customer Social Security Number,” not at core_banking.dbo.customers.ssn. The column is one implementation of the CDE. There may be nineteen others.

When Part 2 says “identify 200 to 250 CDEs,” that means 200 to 250 business concepts, not columns. The column count underneath those 250 CDEs might be 2,500 or 5,000 or more. But you govern 250 concepts. The scaling properties of the program depend on this distinction.

When Part 3 says “implement quality monitoring for Tier 1 CDEs,” you define the rule once at the CDE level (“completeness > 99.9%”) and deploy it across every physical column mapped to that CDE. You do not write 20 separate rules for 20 columns. Ataccama’s glossary-term-to-attribute cascade is the cleanest implementation of this pattern, but every major platform supports some version of it.

When Part 4 says “scale from 50 to 5,000 CDEs,” the column count may be 10x to 20x that number. But the governance overhead, the stewardship assignments, the quality rule definitions, the ownership accountability, all scale with CDEs, not columns. That is why the program remains manageable at scale.

When Part 5 says “report KPIs to the risk committee,” scores aggregate from column to CDE to domain. The risk committee does not see 6,000 column-level scores. It sees 300 CDE-level scores, grouped by domain, with drill-down available when a score drops below threshold. The meta model defines the aggregation path.

Do Next

Priority	Action	Why It Matters
Start here	Determine whether your organization treats CDEs as business concepts or as physical columns. Ask the team: “If we rename a database column, does the CDE definition change?” If the answer is yes, you are governing columns, not concepts.	The most common structural mistake in CDE programs is conflating the concept with its physical container. This single test surfaces the problem.
Start here	Inventory the physical columns mapped to your top 10 CDEs. Count the ratio.	If the ratio is below 1:5, you may be under-mapping (missing physical instances). If it is above 1:50, your CDE definitions may be too broad.
Then	Map your catalog’s entity model to the three-layer meta model. Identify where your tool places CDEs (first-class entity or decorated Business Term) and whether a semantic bridge layer exists.	Your tooling constrains your implementation. Understanding the mapping prevents building workarounds that fight the platform.
Then	Define one CDE end-to-end through all three layers: business definition, semantic attributes, and every physical column. Use it as the template for your register.	One fully documented CDE reveals every gap in your metadata, lineage, and ownership documentation before you scale.
Next	Establish the rule: quality thresholds attach at CDE level, measurements happen at column level, aggregation flows upward. Document this in your governance policy.	Without this rule codified, teams will define rules at the column level, creating duplicates that diverge over time.
Advanced	Align your CDE naming convention to ISO 11179: [Object Class] [Property] [Representation Term]. Retrofit your existing inventory.	Consistent naming across 200+ CDEs prevents the synonyms and homonyms that erode trust in the catalog.

What Comes Next

With the meta model established, Part 1 addresses the next question: how do you identify which business concepts qualify as critical? The answer, as nine regulatory frameworks and three enforcement actions demonstrate, is to start with uses, not words.