Building Your CDE Inventory: From Tier 1 Uses to Source Elements

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

From Thesis to Methodology

Update, September 2026. The Federal Reserve rescinded SR 11-7 and replaced it with SR 26-2 on April 17, 2026, moving Tier 1 risk-model validation to a materiality-driven, principles-based standard that explicitly excludes generative and agentic AI models. Microsoft Purview’s CDE feature remains in preview, now with bulk CSV import. Solidatus 2026.3 adds AI-agent lineage queries with staged human review, on top of the manual tracing Step 3 still describes.

Part 1 of this series established that usage-first CDE identification is structurally superior to glossary-first approaches. Part 1 showed that major regulatory frameworks across banking, insurance, and healthcare converge on usage-first identification, with HIPAA’s enumerated PHI identifiers a partial exception: start from the outputs that carry the highest organizational stakes, then trace backward to the data elements feeding them.

That article covered the “why.” This one covers the “how.”

The distance between “we agree that usage-first is the right approach” and “we have a defensible CDE inventory” is where most programs stall. The concept is straightforward. The execution requires a repeatable methodology that moves from high-priority uses through lineage tracing to a scored, validated, and formally registered set of Critical Data Elements, with a semantic layer built around them rather than preceding them.

I have seen teams nod along during the strategy presentation, then spend four months in a conference room debating which data elements “feel critical.” That is not identification. That is brainstorming. And brainstorming produces political artifacts, not defensible inventories.

CDE identification is a tracing exercise. You follow the data. The methodology that follows codifies that tracing into seven repeatable steps, supplements it with a formal scoring model, and finishes with the register and glossary structures that make the inventory operational.

The Seven-Step Usage-First Methodology

Step 1: Identify Your Tier 1 Uses

Every organization has a finite set of high-stakes outputs. These are the reports, models, and submissions where a data error creates a regulatory finding, a material misstatement, or a significant financial loss. They are your Tier 1 uses, and they form the starting boundary for CDE identification.

For a regulated bank, the Tier 1 list typically includes:

• Regulatory submissions: CCAR/DFAST FR Y-14 templates, Call Reports, FFIEC filings
• Risk models: Credit risk, market risk, operational risk, and liquidity models subject to SR 26-2 validation (the Federal Reserve’s April 2026 replacement for SR 11-7)
• SOX-relevant reports: Financial close processes, material financial statements, IPE (Information Produced by the Entity) subject to PCAOB AS 2201 testing
• Compliance dashboards: AML/BSA surveillance, fair lending analysis, sanctions screening

For insurers, the list shifts to Solvency II QRTs, IFRS 17 actuarial calculations, ORSA submissions, and statutory filings under the NAIC Model Audit Rule. For healthcare organizations, it includes USCDI-mandated data exchanges, CMS quality reporting, HIPAA designated record sets, and HEDIS measures.

The point is not to capture every report in the organization. It is to capture the ones where the consequences of bad data are severe and well-defined. Alation’s CDE best practices guidance frames these as the data elements that, if inaccurate or mismanaged, would materially affect an organization’s operations, compliance, and strategic outcomes: vital, not merely useful.

What this looks like in practice. A practical heuristic: if a data error in this output could trigger a regulatory finding, a restatement, a model failure, or a loss exceeding your materiality threshold, it belongs in Tier 1. Most organizations arrive at 15 to 30 Tier 1 uses. That is your scope boundary.

Step 2: Map Each Use to Its Constituent Data Elements

With the Tier 1 uses identified, the next step is decomposition. For each use, enumerate the specific data elements that populate it.

This is more mechanical than it sounds. What decomposition looks like for each output type:

• CCAR FR Y-14Q schedule: The reporting template defines its fields directly. Each cell in the schedule maps to a specific data element.
• SOX-relevant financial report: Maps to specific general ledger accounts, sub-ledger entries, and supporting calculations.
• Risk model: Input variables are documented in the model specification or validation report.
• Solvency II QRT: Specifies the data points required in each cell of the template.

For each Tier 1 use, document:

• The specific fields, columns, or input variables that populate the output
• The business meaning of each field (even a rough working definition at this stage)
• The expected format, range, or domain of allowed values
• The source system or table from which each field is currently sourced

At the end of this step, you have a flat list of data elements organized by their downstream use. This list is typically 500 to 2,000 elements across all Tier 1 uses before deduplication. That number drops significantly in the next steps.

Step 3: Trace Lineage Backward from Output to Source

This is the step that separates a CDE exercise from a wish list. For each data element identified in Step 2, trace the full path from the output back through transformation layers to the authoritative source system.

The ECB’s 2024 RDARR Guide is explicit on this requirement, calling for “complete and up-to-date data lineages on data attribute level.” That makes column-level lineage a supervisory expectation, not a best-practice aspiration.

In practice, lineage tracing reveals three things:

Transformation complexity. An element that appears as a single field in a regulatory report may be derived from joins across five source tables, three aggregation steps, and a business rule applied in a middle-tier application. Every transformation point is a potential failure point, and every failure point on the path of a Tier 1 output makes that element a stronger CDE candidate.

Shared dependencies. You will discover that certain source-level fields feed multiple Tier 1 outputs. A customer identifier, for example, may appear in the credit risk model, the AML surveillance system, the CCAR submission, and the financial close process. These shared dependencies are concentration points, and they surface in Step 4.

Broken or undocumented paths. Some lineage paths will be incomplete. A field in the regulatory report cannot be traced to a definitive source because the ETL pipeline was built years ago by a team that no longer exists, or because an intermediate system performs undocumented transformations. These gaps are findings in themselves. They tell you where your Data Governance infrastructure is weakest and where remediation effort should be concentrated.

If your organization has a lineage tool (Collibra, Solidatus, Manta, DataHub), this step is partially automated. If it does not, this step is manual, labor-intensive, and still non-negotiable. Manual lineage tracing typically involves three activities: (1) reading the SQL or ETL code that populates each target field, (2) interviewing engineers who built the pipeline when code is undocumented, and (3) running test queries to verify that source values propagate as expected.

You cannot govern what you cannot trace. Data Crossroads’ practitioner perspective recommends documenting lineage at the physical data model level to reveal how elements relate across applications. For a comprehensive treatment of why lineage without business context is insufficient, see Metadata Management in 2026: Why Lineage Without Context Is Just Expensive Decoration.

Step 4: Identify Concentration Points

With lineage traced, you can now see which source-level elements appear on the paths of multiple Tier 1 uses. These are your concentration points: the data elements with the widest blast radius if something goes wrong.

Consider a simple example. If “customer_credit_score” feeds:

• The CCAR stress testing model (FR Y-14Q)
• The credit risk internal ratings model (SR 26-2 scope)
• The fair lending compliance dashboard
• The SOX-relevant allowance for credit losses calculation

Then an error in that single element propagates to four Tier 1 uses simultaneously. That concentration makes it a high-priority CDE candidate regardless of any other scoring factor.

The same data element commonly exists as dozens of separate physical columns across an enterprise, each in a different system with its own name and format. The concentration point analysis collapses those instances to reveal which underlying data concepts carry the most downstream weight. This is where the flat list from Step 2 begins to consolidate into a manageable inventory.

Step 5: Score Candidates Using the Criticality Formula

Not every element that touches a Tier 1 use is equally critical. A static reference field that rarely changes and has limited downstream impact is different from a daily-updated transaction field that feeds five regulatory reports. Scoring distinguishes the two.

A simple scoring formula does most of the early work:

C = N x I

Where:

• C = Criticality score
• N = Number of Tier 1 uses that depend on this element
• I = Impact rating (a 1-to-5 or 1-to-10 scale reflecting the severity of consequences if the element is wrong)

Monte Carlo’s CDE guidance makes a related point: poor quality in a CDE cascades through the applications and processes downstream of it, multiplying errors and bad decisions. C = N x I turns that intuition into a number.

The impact rating (I) should reflect the worst-case consequence of an error in that element:

Impact Rating	Consequence
1-2	Operational inconvenience, manual workaround available
3-4	Financial impact below materiality threshold, internal audit finding
5-6	Regulatory reporting error, material financial misstatement risk
7-8	Regulatory finding, enforcement action risk, significant financial loss
9-10	Systemic risk, major regulatory penalty, existential business impact

An element that feeds three Tier 1 uses (N=3) with a high impact rating (I=8) scores C=24. An element that feeds one Tier 1 use (N=1) with moderate impact (I=4) scores C=4. Set a threshold (typically C >= 5 or C >= 6 for the initial inventory) and every element above the line is a CDE candidate.

This scoring is deliberately simple. More sophisticated models exist, and the DAMA-NL approach (covered in the next section) provides a richer framework. But C = N x I has a practical advantage: it can be computed for hundreds of candidate elements in a single working session. It also produces a defensible rank ordering that business stakeholders can challenge on specific grounds (“I think the impact of getting this wrong is a 7, not a 5”) rather than abstract ones (“I feel like this should be critical”).

For practitioners: Use C = N x I for your first pass. It is fast and sufficient for most organizations. Upgrade to DAMA-NL when you need to defend designations to external auditors, have more than 300 candidates needing finer discrimination, or must integrate with competing prioritization frameworks.

When C = N x I falls short. The formula works well for initial scoring because it is simple and defensible. It does not account for three factors that matter at scale: (1) Recoverability: can the error be corrected before it reaches the consumer? A wrong value in a T+0 real-time feed carries more risk than the same error in a monthly batch with a 3-day review window. (2) Detectability: how quickly will you know it is wrong? A credit score of 950 is obviously invalid. A credit score of 712 when it should be 718 requires reconciliation to catch. (3) Regulatory proximity: is this CDE directly reported on a regulatory submission, or is it four transformations away? Distance from the regulatory output affects both impact speed and detection likelihood.

These gaps are why the DAMA-NL weighted scoring model (below) exists. Use C = N x I for your first pass. Upgrade to DAMA-NL when you have 300+ candidates, need to defend scoring to external auditors, or find that the simple formula produces ties that it cannot break.

Step 6: Validate with Business Stakeholders

Scoring produces a ranked candidate list. Validation turns candidates into confirmed CDEs.

This step is where the technical tracing work meets business judgment. The lineage analysis and scoring formula produce a physically grounded candidate list. Business stakeholders, the data owners, risk officers, compliance leads, and line-of-business executives, ratify or challenge that list based on contextual knowledge that no algorithm captures.

Validation typically surfaces three types of adjustments:

Additions. Business stakeholders may identify elements that do not appear in Tier 1 outputs but carry high criticality for reasons the tracing exercise missed. A data element used exclusively in board-level decision-making, for example, might not flow through any formal regulatory report but still warrants CDE designation. These cases are rare when the Tier 1 use list is well-constructed, but they exist.

Reclassifications. An element that scored below the threshold may be elevated because the business owner knows that the impact rating should be higher than the initial assessment. Conversely, an element that scored above the threshold may be deprioritized because the business context makes it less critical than the formula suggests (perhaps it is a derived field with a simple, well-tested calculation from a source element already on the CDE list).

Ownership assignment. Validation is the natural point to assign data ownership. Each confirmed CDE needs a business owner (the executive accountable for its quality and usage policy) and a data steward (the subject matter expert responsible for day-to-day quality management). Ownership assigned during identification tends to be more durable than ownership assigned retroactively, because the owner participates in the decision rather than inheriting it.

The output of this step is a confirmed CDE list with each element scored, owned, and documented with its lineage path and downstream uses.

Step 7: Formalize in the CDE Register

The CDE register is the authoritative record of your Critical Data Elements. It is not a spreadsheet that lives on someone’s desktop. It is a governed artifact, maintained in your Data Catalog or governance platform, with defined update procedures and review cycles.

Each entry in the register should capture, at minimum:

Field	Purpose
CDE Name	Canonical business name for the element
Business Definition	Plain-language definition agreed upon by business stakeholders
Data Type	Technical data type (string, integer, decimal, date, etc.)
Allowed Values / Format	Valid value ranges, enumerated lists, or format masks
Data Owner	Business executive accountable for this element
Data Steward	SME responsible for day-to-day quality management
Source of Record	Authoritative source system for this element
Quality Rules	Specific DQ checks applied (completeness, accuracy, timeliness, validity)
Quality Threshold	Minimum acceptable quality score (e.g., 99.5% completeness)
Sensitivity Classification	PII, PHI, confidential, internal, public
Downstream Uses	List of Tier 1 and Tier 2 uses that consume this element
Regulatory Relevance	Specific regulations that require or imply governance of this element
Lineage Documentation	Link to column-level lineage from source to consumption points
Domain Assignment	Business domain (Risk, Finance, Compliance, Operations, etc.)
Criticality Score	The C = N x I score from Step 5, with component values

Microsoft Purview’s CDE capabilities model CDEs as governance-domain objects with owners, data types, mapped columns, access policies, and linked glossary terms, reflecting this register structure in a platform-native way. Keep the register a living document, not a point-in-time snapshot, with regular review cycles tied to business changes, regulatory updates, and system migrations.

The worked example at the end of this article traces a mid-size bank through all seven steps, from 18 Tier 1 uses to a final inventory of 214 CDEs.

The DAMA-NL Weighted Scoring Model

The C = N x I formula works well for initial identification. For organizations that need a more granular scoring approach, particularly those with complex regulatory environments or multiple competing prioritization demands, the DAMA-NL weighted scoring model provides a richer framework.

This guide’s weighted scoring model builds on general DAMA data-management principles, as described by Data Crossroads, and extends them into a three-stage weighted approach.

Stage 1: Define and weight your criteria. Select the dimensions along which criticality should be evaluated. Common criteria include:

• Regulatory impact (does an error trigger a regulatory finding?)
• Financial impact (does an error cause material financial loss?)
• Operational impact (does an error disrupt critical business processes?)
• Downstream dependency count (how many systems or reports consume this element?)
• Data quality history (has this element been a recurring source of quality issues?)
• Customer impact (does an error affect customer experience or trust?)

This guide’s recommended weighting scale: 1 / 4 / 7 / 10 (not a linear 1-10 range). The non-linear spacing forces deliberate priority choices. A criterion weighted at 4 is not “slightly less important” than one weighted at 7; it is categorically lower priority. This prevents the common failure mode where every criterion receives a 6, 7, or 8 and the weights fail to discriminate.

For a bank under active BCBS 239 scrutiny, regulatory impact might carry a weight of 10 while customer impact carries a weight of 4. For a direct-to-consumer insurer, those weights might reverse.

Stage 2: Score each candidate. For every CDE candidate, score it against each weighted criterion. The sum-product of weights and scores produces a composite criticality score.

For example, if an element scores:

Criterion	Weight	Score	Weighted Score
Regulatory impact	10	8	80
Financial impact	7	6	42
Operational impact	4	5	20
Downstream dependencies	7	9	63
DQ history	4	7	28
Customer impact	4	3	12
Total			245

Stage 3: Plot and select. Plot all candidates on a two-dimensional coordinate system (this guide’s refinement uses a coordinate plane where one axis represents business criticality and the other represents Data Quality risk). Candidates above a defined quarter-arc boundary qualify as CDEs. Those below the boundary are non-CDE data elements that receive standard governance controls. Imagine a quarter-circle drawn from the top of the y-axis to the right end of the x-axis. Candidates above the arc qualify. The curve means an element can compensate for moderate business criticality with high Data Quality risk, or vice versa, but it must score strongly on at least one dimension to clear the threshold.

The DAMA-NL approach is more resource-intensive than C = N x I, but it produces a more nuanced output. It is particularly valuable when an organization needs to defend its CDE designations to regulators, auditors, or internal stakeholders who will challenge any binary “critical or not” classification. The weighted scoring provides a documented, auditable rationale for every inclusion and exclusion.

Rajesh Jugulum’s Competing with High Quality Data (Wiley, 2014) extends this further with a formal funnel methodology, applying sampling-based statistical process control to Data Quality at each stage of the identification process. For organizations with mature analytics capabilities, this provides the most rigorous scoring framework available.

How Many CDEs Is Right?

This is the question every CDE program sponsor asks, and the answer matters more than most teams realize.

Practitioner literature describes several CDE identification approaches, from simple usage-based selection to matrix scoring and hybrid combinations, without prescribing a target count, and converges on a maturity progression:

Stage	Count	Governance Approach
Inception (0-3 months)	10-15	Spreadsheet register, informal ownership, manual quality checks
Developing (3-9 months)	50-100	Catalog-based register, first lineage documentation, automated DQ rules
Mature (9-18 months)	150-500	Column-level lineage, tiered SLAs, data contracts, formal stewardship
Optimized (18+ months)	500+	AI-assisted discovery, proactive impact analysis, continuous monitoring

The critical insight is in the starting number. Organizations that begin with 10 to 15 CDEs tied to their single most important regulatory submission or risk model tend to get further than organizations that try to identify 500 CDEs in their first pass. Demonstrating measurable quality improvement on a small set before expanding is what earns the next round of investment.

Sogeti Labs’ CDE guidance makes the same point: concentrating governance on a focused set of Critical Data Elements produces better Data Quality outcomes than trying to govern everything at once. The mechanism is straightforward: when everything is labeled “critical,” nothing receives the concentrated governance attention that actually improves quality. Stewards are spread across too many elements. Monitoring alerts fire so frequently that they become noise. Remediation queues grow faster than teams can work them.

Sizing by Organizational Complexity

The mature-state CDE count depends on organizational complexity, not a universal target. Four factors drive the number: (1) the count of Tier 1 regulatory submissions, (2) the number of distinct business lines, (3) the number of jurisdictions with separate reporting requirements, and (4) the number of source systems feeding those reports.

Organization Type	Likely Mature CDE Count	Primary Drivers
Regional bank (< $50B assets)	80-150	Fewer regulatory submissions, simpler product mix
Mid-size bank ($50-250B)	150-300	CCAR, SOX, AML/BSA, commercial + retail
G-SIB / large universal bank	500-800	CCAR, BCBS 239, Basel III, SOX, AML/BSA, Fair Lending, CECL, FRTB, resolution planning
Mid-size insurer	150-300	Solvency II or RBC, IFRS 17/LDTI, ORSA
Large multi-line insurer	300-500	Multiple regulatory regimes, reinsurance, cross-entity reporting
Large health system	100-200	CMS reporting, HEDIS, HIPAA designated record sets
Academic medical center	150-300	Clinical trials (NIH CDE Repository), CMS, research data sharing

These per-organization-type ranges are field estimates from program experience, not survey data; treat them as sizing intuition, not benchmarks. The range at maturity (150-500 in the progression table) reflects this organizational variation. A regional bank that lands at 120 CDEs may be right-sized. A G-SIB that lands at 600 may also be right-sized. The question is not “how close are we to 250?” but “does our count align with the regulatory and operational complexity we actually face?”

How to build the check. If your count at maturity significantly exceeds the range for your organization type in the table above, check whether your Tier 1 boundary has expanded too far or your scoring threshold is too low. If it produces fewer than 50, check that your lineage tracing is sufficiently deep. Surface-level mapping that stops at the first intermediate system will miss source elements that carry the actual quality risk.

The Semantic Overlay: Building the Glossary Around Your CDEs

Part 1 argued that the glossary layer is essential but sequenced wrong when it comes first. With a confirmed CDE inventory in hand, it is time to build that glossary layer, on the right foundation.

Why the Glossary Comes Second

The glossary-first approach asks an organization to define every business term, then decide which are critical. That produces a scope problem: 50,000 to 500,000 candidate terms with no natural prioritization mechanism.

The usage-first approach inverts this. You have identified your Critical Data Elements through lineage tracing and criticality scoring. The glossary needs to define those terms with precision, plus a modest penumbra of related terms needed for context. Whether your inventory lands at 120 or 500 elements, that is still a bounded, achievable scope compared to defining every term that exists.

Business Term to CDE Mapping

Each CDE in your register maps to one or more business terms. These mappings serve two purposes.

First, they provide semantic consistency. The CDE “customer_credit_score” may be called “FICO Score” in the risk domain, “Credit Rating” in the lending domain, and “Borrower Score” in the securitization domain. The glossary reconciles these into a single canonical term with documented aliases, ensuring that all Tier 1 uses referencing this concept mean the same thing.

Second, they enable cross-domain discovery. Reporting Data Quality at the business term level, rather than at each individual physical instantiation, is the only scalable approach: a single business term and its CDE designation may correspond to dozens of physical columns across different systems. The glossary provides the abstraction that makes quality management tractable at enterprise scale.

Cross-Domain Reconciliation

Building the glossary around CDEs forces cross-domain conversations that glossary-first approaches defer indefinitely. When the Risk domain and the Finance domain both claim “net revenue” as a CDE, the glossary construction process requires them to reconcile: is this the same concept with one definition, or two different concepts that share a name?

These reconciliation conversations are among the highest-value activities in any Data Governance program. They surface definitional conflicts that propagate silently through reporting pipelines, causing discrepancies between the risk report and the financial statement that auditors and regulators will eventually find.

The usage-first approach makes reconciliation tractable because the scope is bounded. You are reconciling definitions for your CDE inventory (typically a few hundred elements, depending on organizational complexity), not for every business term in the enterprise. Each reconciliation conversation has a concrete anchor: “This element feeds these three Tier 1 uses. What does it mean in each context, and should the definition be the same?”

Golden Source Designation

For each CDE, the glossary must designate a golden source: the authoritative system of record from which the canonical value of that element originates. Every downstream system that consumes this CDE should be traceable back to this golden source through documented lineage.

Golden source designation is where the lineage work from Step 3 pays dividends. If you have traced each CDE from its Tier 1 outputs back to source, you already know which system holds the authoritative value. The glossary formalizes that designation and makes it visible to every team that produces or consumes the element.

This matters because it prevents drift from unauthorized duplicate copies: when a downstream team copies a CDE value into a local database and applies its own transformations, that copy is not subject to the same quality controls as the golden source and drifts from the authoritative value over time. Enforced through the glossary and lineage documentation, golden source designation makes these copies visible and governable.

Data Contracts as the Formalization Mechanism

The glossary provides the semantic foundation. Data contracts formalize the operational expectations.

A data contract, as Monte Carlo describes, is an agreement between a data producer and its consumers. It specifies the schema and format of the data, the quality standards it must meet, the freshness or timeliness guarantees, the change management procedures when the schema evolves, and the escalation paths when the contract is violated.

For CDEs specifically, contracts should specify:

• Schema expectations: exact field names, data types, nullable status, allowed value ranges
• Quality thresholds: minimum completeness, accuracy, and validity percentages (tied to the CDE register’s quality threshold field)
• Freshness SLA: how recent the data must be at each consumption point
• Lineage requirements: the producer must maintain documented lineage from source to delivery point
• Change notification: how far in advance consumers must be notified of schema changes, and what constitutes a breaking versus non-breaking change

Data contracts transform the CDE register from a documentation artifact into an operational governance mechanism. The contract is the executable form of the CDE’s governance requirements. When a contract is violated, monitoring systems detect the breach, stewards are notified, and remediation follows the SLA defined in the CDE’s tier classification.

Part 3 of this series will cover the tiered SLA structure, monitoring approaches, and remediation workflows in detail. The point here is structural: data contracts are the bridge between the CDE inventory (what matters) and operational governance (what happens when something goes wrong).

Derived and Calculated CDEs

Many CDEs are not raw data from a source system. They are calculated from other data elements. LTV Ratio = Loan Balance / Property Value. Net Interest Margin = (Interest Income - Interest Expense) / Average Earning Assets. Risk-Weighted Assets aggregate exposure values multiplied by risk weights across the entire portfolio.

The practitioner question: if LTV Ratio is a CDE, are Loan Balance and Property Value also CDEs? The answer is almost always yes, but the governance model differs.

Three rules for derived CDEs:

1. Both inputs and outputs can be CDEs independently. Loan Balance may be a CDE in its own right because it feeds multiple Tier 1 uses beyond LTV calculation. Score each element on its own merits using C = N x I. Do not automatically promote or demote inputs based on the output’s CDE status.

2. Quality rules must cover the formula, not just the inputs. Input data can be perfect while the calculation is wrong. Versioning matters: if the LTV calculation methodology changes (e.g., from original appraised value to automated valuation model), the quality rules must reflect the current formula. Track formula versions in the CDE register alongside the data definition.

3. Assign ownership for the derivation logic separately from the input data. The team that owns Loan Balance (servicing) is not the same team that owns the LTV calculation (risk analytics). The LTV CDE register entry should document: the formula, the formula owner (who can authorize methodology changes), the input CDEs and their owners, and where the calculation executes (which system, which pipeline step).

Practical guidance for the register:

For derived CDEs, add two fields to the standard 15-field register:

• Derivation Logic: The formula or business rule, including version and effective date
• Input CDEs: List of CDE names that feed this derivation, with their CDE IDs

This creates a dependency graph within the CDE inventory itself. When an input CDE changes its definition, source, or quality threshold, the derived CDEs are flagged for review automatically.

Putting It Together: A Worked Example

The identification funnel: 18 Tier 1 uses > 1,400 output-level elements > 600 source-level concepts > 210 scored above threshold > 214 CDEs (after validation)

To make this concrete, consider a mid-size bank that needs to build its initial CDE inventory.

Step 1: Tier 1 uses. The governance committee identifies 18 Tier 1 uses: 4 CCAR submission schedules, 3 SOX-relevant financial reports, 5 risk models (credit, market, operational, liquidity, counterparty), 2 AML surveillance processes, and 4 regulatory filings (Call Report, FFIEC 031, HMDA, CRA).

Step 2: Constituent elements. Decomposing those 18 uses produces 1,400 data elements before deduplication.

Step 3: Lineage tracing. Working backward from each element through the transformation stack reveals that the 1,400 output-level elements trace to approximately 600 distinct source-level data concepts, sourced from 14 authoritative systems.

Step 4: Concentration points. Of the 600 source-level concepts, 180 appear in the lineage paths of two or more Tier 1 uses. Forty-three appear in four or more.

Step 5: Scoring. Applying C = N x I with a threshold of C >= 6 produces 210 candidates. The top-scoring elements include customer identifiers, account balances, transaction dates, credit scores, and interest rates, the elements that feed the widest range of critical outputs with the highest impact if wrong.

Step 6: Validation. Business stakeholders review the 210 candidates. They add 12 elements missed by the tracing exercise (primarily board reporting fields not captured in formal Tier 1 use list). They remove 8 elements that are derived calculations from other CDEs already on the list (governing the source element is sufficient). Final count: 214 CDEs.

Step 7: Register. Each of the 214 CDEs is entered in the catalog with all 15+ register fields populated. Ownership is assigned. Initial quality rules are documented. The register becomes the authoritative inventory.

Glossary overlay. The 214 CDEs map to 214 canonical business terms. Cross-domain reconciliation surfaces 23 definitional conflicts (terms used differently across Risk, Finance, and Compliance). Resolving those conflicts produces 214 clean definitions, 14 of which required creating new composite definitions that bridge domain-specific usage. Golden sources are designated for each CDE based on the lineage work already completed.

The entire process, from Tier 1 identification through glossary overlay, takes 8 to 12 weeks for a team of 4 to 6 people (a governance lead, two lineage analysts, a business analyst, and rotating business stakeholder participation). That is a fraction of the time organizations spend on glossary-first approaches that never reach the identification stage.

Do Next

Priority	Action	Why It Matters
Start here	Select your first 3 Tier 1 uses for lineage tracing: pick the regulatory submissions or risk models with the highest examination exposure	Three uses keeps scope manageable while producing enough CDE candidates to demonstrate the methodology.
Start here	Trace lineage from one regulatory report to source systems, documenting every transformation point and system handoff	The first trace exposes broken paths and undocumented transformations no glossary exercise would surface.
Then	Score initial CDE candidates using the C = N x I formula (criticality equals usage count multiplied by impact rating) with a threshold of C >= 6	Objective scoring replaces political debate about what counts as “critical.”
Then	Build your CDE register with the 15 required fields: CDE name, business definition, data type, allowed values, owner, steward, source of record, quality rules, quality threshold, sensitivity classification, downstream uses, regulatory relevance, lineage documentation, domain assignment, and criticality score	The register is the authoritative artifact regulators and auditors reference; start with a spreadsheet, migrate before 50 CDEs.
Next	Define business terms for your top 50 CDEs as the glossary overlay, reconciling cross-domain definitions where the same concept carries different names	Reconciliation surfaces definitional conflicts that silently propagate through reporting pipelines.
Advanced	Establish data contracts for your highest-traffic CDE pipelines, formalizing schema expectations, quality thresholds, freshness SLAs, and change notification procedures between producers and consumers	Without contracts, quality expectations remain informal and unenforceable.

What Comes Next

With CDEs identified and the semantic layer in place, the question becomes: how do you operationalize them? A CDE inventory that sits in a catalog without active monitoring, tiered quality SLAs, and defined remediation workflows is a documentation exercise, not a governance capability.

Part 3 of this series covers the operational layer: tiered SLA structures (from 99.9% with 4-hour remediation for Tier 1 regulatory CDEs down to best-effort for non-CDEs), column-level lineage as a monitoring requirement, the three-layer accountability model (owner, steward, domain lead), and the technology stack that makes continuous CDE governance feasible at scale.

The inventory is the foundation. Operations make it real.