Measuring What Matters: CDE Program Reporting, KPIs, KRIs, and Risk Integration

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

The Translation Problem

A note before the scene below. This article was drafted in March 2026 and published on September 1, and the US enforcement backdrop shifted in between while Europe’s did not; the section before Do Next records what moved, with sources, and why the discipline here matters more when examiners step back rather than less.

A CDO walks into a risk committee meeting and reports: “CDE coverage is 78% with an average Data Quality score of 94.2.” The CRO responds: “What does that mean for our risk exposure?”

If the CDO cannot answer that question, the program loses executive sponsorship. Not immediately. Not dramatically. It just stops getting budget, stops getting attention, and slowly atrophies into a compliance artifact that nobody references. I have watched this happen twice. At both organizations, the Data Governance team built genuinely good operational metrics: dashboards with real-time quality scores, trend lines, domain-level rollups. But they never translated those metrics into language the risk committee could act on. Both programs were effectively defunded within two years. Not because the work was bad, but because the audience could not connect the numbers to their own accountability.

This is the translation problem. CDE programs that report only Key Performance Indicators (operational health metrics) fail to sustain funding. CDE programs that translate KPIs into Key Risk Indicators (risk exposure metrics tied to the enterprise risk appetite) survive.

Part 4 of this series covered scaling and sustaining the CDE program. This article covers the final and arguably most consequential challenge: measuring CDE program health in a way that connects the CDO’s world to the CRO’s world. It must satisfy regulatory examiners and give every stakeholder, from steward to board member, the view they actually need.

CDE Program KPIs: Operational Health Metrics

KPIs measure whether the CDE program is functioning. They answer the question: “Is our governance machinery running?” These are necessary but not sufficient. Without them, you have no operational visibility. With only them, you have no executive relevance.

Coverage Metrics

Coverage tells you how much of your identified CDE inventory is actually under governance control. Three dimensions matter:

Coverage Dimension	What It Measures	Why It Matters
Monitoring	% of CDEs with active quality checks (EWSolutions identifies this as a primary maturity indicator)	Documented without monitoring = not governed
Ownership	% with assigned owner and steward	Monitoring without ownership = no accountability
Lineage	% with source-to-consumption documentation (the ECB RDARR Guide mandates lineage “at the data attribute level”)	Cannot satisfy BCBS 239 or examination without it

A mature program tracks all three coverage dimensions separately. Aggregating them into a single coverage number obscures gaps. A CDE with 100% monitoring coverage but 0% lineage coverage is still a regulatory exposure.

Quality Metrics

Quality KPIs measure whether CDEs meet their defined standards:

• DQ scores by CDE: accuracy, completeness, validity, timeliness, and consistency scores for each element, tracked against its tier-specific threshold (99.9% for Tier 1, 99.5% for Tier 2, 99% for Tier 3, as established in Part 3 of this series)
• SLA compliance rate: the percentage of CDEs meeting their quality SLA over a given period. Microsoft Purview’s Data Quality framework implements this as automated no-code quality rules that score data assets against defined standards.
• Trend analysis: raw scores at a point in time mean less than the direction. A CDE at 99.1% and improving is less concerning than a CDE at 99.5% and declining. Trend lines over 90 days, by quarter, and year-over-year provide the signal.

Incident Metrics

Incident KPIs measure the consequences of quality failures:

• CDE-related data incidents: total count of incidents involving CDEs, segmented by tier and severity
• Mean time to resolution (MTTR): how quickly CDE issues are remediated once detected. Tier 1 CDEs should carry a 4-hour remediation SLA; tracking actuals against that SLA reveals operational effectiveness
• Incident reduction rate: quarter-over-quarter trend in CDE-related incidents. A mature program should show declining incident volume as quality rules, lineage tracing, and proactive monitoring take effect

Stewardship Activity Metrics

Stewardship activity measures whether governance is active or passive. Umbrex’s governance playbook emphasizes that “governance programs that cannot demonstrate engagement metrics struggle to justify continued investment.” Track:

• Validations performed: how many CDE quality validations stewards have conducted, reviewed, or signed off on
• Corrections made: data issues identified and remediated through stewardship workflows
• Annotations and enrichment: metadata additions, definition refinements, lineage updates contributed by stewards
• Catalog adoption: the percentage of total data assets (not just CDEs) documented in the catalog, a broader indicator of governance program reach

What this looks like in practice. Active stewardship, where stewards regularly validate, correct, and annotate, indicates effective governance. Passive stewardship, where stewards are assigned but never engaged, is a warning sign. If your stewardship activity metrics are flat, the governance model is decorative.

Council Effectiveness Metrics

The governance council itself needs measurement. Two baseline thresholds:

• Meeting attendance: set a baseline of 75% of designated members present at each council meeting. Below that baseline, decisions lack legitimacy and implementation stalls. Umbrex’s governance operating model identifies consistent participation as a prerequisite for effective Data Governance councils.
• Training completion: set a baseline of 8 hours per member per year. Stewards and council members who fall short of it, and do not understand evolving regulatory requirements, new tools, or updated methodologies, cannot govern effectively.

CDE-Related KRIs: Risk Exposure Metrics

KRIs measure whether CDE quality creates, increases, or mitigates organizational risk. They answer a different question than KPIs: not “Is the program running?” but “Is the organization exposed?”

The distinction is consequential. A KPI tells you that 12 CDEs are below their quality threshold. A KRI tells you that those 12 CDEs feed three regulatory reports. If the quality issues are not resolved within the remediation SLA, the institution’s regulatory report accuracy will fall below the risk appetite statement threshold, triggering a mandatory escalation to the risk committee.

Risk Signal KRIs

Percentage of Tier 1 CDEs below quality threshold. This is the single most important KRI in a CDE program. Tier 1 CDEs feed regulatory reports and Tier 1 risk models. Any Tier 1 CDE below its quality threshold is a direct risk signal. The OCC Heightened Standards (12 CFR 30, Appendix D) require covered institutions to establish a risk governance framework that includes “processes and systems for identifying and reporting risks and risk management deficiencies.” Tier 1 CDE quality breaches are exactly those deficiencies.

Regulatory report accuracy trending. Track the accuracy of data in regulatory submissions over time. A declining trend is a leading indicator of examination findings. By the time a regulator identifies the problem, the reputational and financial damage is already in motion. McKinsey’s BCBS 239 2.0 analysis notes that full compliance remains elusive for many banks even after they build formal frameworks, with regulators applying increasingly forceful scrutiny. Forward-looking risk measurement of the kind described here is what closes that gap.

Unresolved CDE exceptions aging past SLA. An exception is a known quality issue with a documented remediation plan. When exceptions age past their SLA, they represent accumulating risk. Track exception aging in buckets:

Aging Bucket	Action
Within SLA	Normal monitoring
1-30 days past SLA	Steward escalation
31-90 days past SLA	Domain owner review
90+ days	Automatic risk committee escalation

Control Effectiveness KRIs

KRI	What to Track	Red Flag
Control effectiveness	Second-line ratings on CDE controls. The BIS progress report on BCBS 239 found that six of eleven principles regressed or stalled, partly because control frameworks existed on paper but were not operating effectively.	”Partially effective” or “Ineffective” rating
Data-related MRAs	Count and aging of regulatory findings. The Citigroup enforcement trajectory illustrates this: the 2020 consent order identified gaps, and the 2024 additional penalty came because MRA remediation was insufficient.	Growing or aging MRA backlog
Model validation findings	Validations under SR 11-7 citing CDE quality as a root cause or contributing factor	Rising count across validation cycles

The KPI-to-KRI Bridge

The most valuable capability in CDE program reporting is the translation layer: taking an operational metric and articulating its risk implication. This is not cosmetic reframing. It requires understanding the downstream dependencies of each CDE and the consequences of quality failure at each consumption point.

Here is a concrete example.

“Customer ID” completeness in the core banking system drops from 99.8% to 97.3%. The KPI dashboard shows the element has fallen below its 99.5% Tier 1 SLA. The steward is notified. The incident is logged. That is the operational response.

The KRI translation goes further: “Customer ID” feeds 12 downstream regulatory reports including CCAR stress testing submissions and fair lending analysis. At 97.3% completeness, approximately 2.5% of customer records cannot be reliably attributed across those reports.

The fair lending analysis depends on complete customer identification to evaluate lending patterns by demographic segment. Incomplete Customer IDs may produce inaccurate demographic attribution, increasing fair lending compliance risk. If the quality breach persists past the 4-hour remediation SLA, the exception must escalate to the compliance risk assessment for the Consumer Compliance Risk Assessment Unit.

For practitioners: Same data point. The KPI says “below SLA.” The KRI says “fair lending compliance exposure increasing, escalation required if not remediated within 4 hours.” The risk committee can act on the second version. The first one never makes it past the governance council agenda.

Here is a second example in a different risk domain.

The “Account Balance” CDE in the general ledger shows a 2.1% reconciliation variance against the sub-ledger. KPI view: reconciliation accuracy is 97.9%, below the 99.5% Tier 2 threshold. KRI view: the Q4 financial close process has an unresolved data variance that, if uncorrected, could result in a SOX internal control deficiency finding. Under PCAOB AS 2201, auditors testing this reconciliation control will classify a 2.1% variance as a deviation. If the deviation is not remediated before external audit fieldwork, the institution faces a material weakness or significant deficiency disclosure in its SOX 404 report, with direct consequences for investor confidence and board-level accountability.

Building this bridge requires two inputs that most CDE programs lack:

1. Downstream dependency mapping: for each CDE, which regulatory reports, risk models, and business-critical processes consume it? This is the lineage work covered in Parts 2 and 3 of this series.
2. Impact analysis by consumption point: for each downstream consumer, what is the consequence of quality failure in this CDE? Not in abstract terms (“bad data causes risk”), but in specific terms (“incomplete Customer ID in the HMDA LAR submission can trigger a CFPB examination finding, as Freedom Mortgage discovered when errors across 35 data fields, alongside a violation of a prior enforcement order, drew a $3.95 million penalty”).

Reporting Hierarchy: Every Audience Gets a Different View

A single CDE reporting view cannot serve all audiences. The steward needs element-level detail. The board needs a one-page summary. Building the right view for each audience is a design problem, not a data problem. The underlying metrics are the same; the aggregation, framing, and emphasis differ.

Audience	Content Focus	Cadence	Design Principle
Stewards	Element-level DQ scores, open issues	Daily/real-time	Operational
Governance Council	Domain rollups, coverage, exceptions	Monthly	Decision-oriented
Risk Committee	KRIs, risk appetite alignment	Quarterly	Risk language
Board	Compliance status, exposure summary	Quarterly	No jargon, 3 questions
Regulators	Full evidence package	Continuous	Traceability

Steward Dashboards

Element-level quality scores, open issues, remediation status, SLA compliance, trend lines (7-day, 30-day, 90-day), and recent stewardship activity. Refreshed daily or in real time. The design principle: operational, not evaluative. The dashboard exists to enable remediation, not to grade performance. If stewards feel it is a surveillance tool, engagement drops.

Governance Council Scorecards

Domain-level quality rollups, CDE coverage metrics (monitoring, ownership, lineage) by domain, quarterly trend lines, exception reports with aging and escalation status, stewardship activity summaries, and program roadmap progress. Delivered monthly or at each council meeting. LightsOnData’s governance scorecard template recommends structuring council reporting around decisions: which domains need resources, which exceptions need escalation, which coverage gaps need prioritization.

Risk Committee KRI Reports

Risk appetite alignment, regulatory report accuracy trends, Tier 1 CDE breach summary with risk impact, control effectiveness ratings, MRA status and aging, model validation findings tied to Data Quality, and exception escalation summaries. Delivered quarterly, aligned with enterprise risk reporting cycles. The design principle: risk language, not governance language. Every metric must connect to a risk category (credit, operational, compliance, model) and to a risk appetite statement.

Board Summary

A one-page view answering three questions: Are we compliant? Where are we exposed? What are we doing about it? Delivered quarterly or as triggered by material events. No jargon. Board members are not Data Management professionals. The summary should be readable by someone with zero Data Governance vocabulary. “Three data elements feeding our stress test submissions fell below quality standards this quarter. Remediation is on track for Q2 completion. No regulatory impact has materialized, but examination risk increased from low to moderate.”

Regulator Examination Package

Audience: OCC examiners, Federal Reserve supervisory teams, state insurance commissioners, CMS reviewers.

Content: this is not a dashboard. It is a pre-assembled documentation package that should exist before the examiner requests it. Contents include: CDE inventory with classification rationale; quality history (at least 12 months of trend data); control documentation (design, implementation, testing evidence); lineage maps from regulatory reports to source systems; exception history with resolution documentation; governance council minutes showing oversight; risk committee minutes showing escalation and action.

Cadence: maintained continuously, refreshed quarterly.

Key design principle: traceability. Examiners follow the thread. They pick a regulatory report, ask what data feeds it, ask what controls exist on that data, ask for evidence that the controls operate effectively, and ask what happens when something goes wrong. The examination package must support that thread end to end.

Mapping CDEs to Risk Assessment Units and RCSAs

RAU: A Risk Assessment Unit is an organizational segment assessed for specific risk types. RCSA: A Risk and Control Self-Assessment is the structured process by which RAUs evaluate their own risk exposure and control effectiveness.

One of the most operationally complex aspects of CDE program reporting is the intersection with enterprise risk assessment. Most large institutions organize risk assessment by Risk Assessment Unit (RAU), typically aligned to business lines, risk types, or regulatory domains. The CDE program, however, is organized by data domain. These two organizational structures do not map cleanly onto each other, and the misalignment creates real problems.

The Cross-Cutting Problem

Consider “Customer ID,” a single CDE that lives in the Customer data domain. The CDE register shows one Data Owner, one Principal Steward, one Domain Steward, one set of quality rules, one lineage path from source to the Customer master.

But “Customer ID” gets assessed in multiple RAUs simultaneously:

• Credit Risk RAU: Customer ID links borrowers to exposures across the loan portfolio. Quality failures affect credit risk aggregation.
• Operational Risk RAU: Customer ID is a key field in transaction processing. Quality failures cause operational losses (failed settlements, misdirected payments).
• AML/BSA RAU: Customer ID is foundational to Know Your Customer (KYC) and transaction monitoring. Quality failures impair surveillance coverage, increasing the risk of missed or delayed suspicious activity reporting.
• Consumer Compliance RAU: Customer ID links to demographic data for fair lending analysis. Quality failures can cause HMDA reporting errors.

Surveillance data gaps carry direct enforcement risk elsewhere in the risk taxonomy too. In March 2024 the OCC fined JPMorgan Chase $250 million for trade-surveillance deficiencies rooted in inadequate data controls, a separate action from AML/BSA surveillance but the same underlying pattern: a data quality gap that impairs a monitoring control becomes an enforcement finding.

Each RAU conducts its own Risk and Control Self-Assessment (RCSA). The RCSA for the Credit Risk RAU evaluates whether controls are adequate for credit risk purposes. The RCSA for the AML/BSA RAU evaluates the same Customer ID from a surveillance perspective. Different risk owners, different control expectations, different assessments.

Avoiding Double-Counting

How to build the check. The danger is that a single CDE quality issue gets counted as a separate risk in every RAU it touches, inflating the enterprise risk profile. The solution is to separate the underlying Data Quality measurement (one score, one owner, one set of controls) from the risk impact assessment (different for each RAU).

In practice, this means:

• The CDE program maintains a single quality score and control assessment for each CDE
• Each RAU references the same quality score but assesses the risk impact in the context of its own risk profile
• The enterprise risk function reconciles across RAUs to ensure that the same root cause (a Customer ID quality issue, for example) is not double-counted when aggregating to the enterprise level

Connecting RCSAs to CDE Quality

The RCSA process should incorporate CDE quality as an input. When a risk assessor evaluates the control environment for a process, the quality of CDEs feeding that process is a relevant factor. If “Customer ID” completeness is at 99.8%, the control assessment for KYC processes can reflect strong underlying Data Quality. If completeness drops to 97.3%, the RCSA should reflect increased residual risk. This requires a formal handoff: CDE quality scores flow into RCSA working papers as evidence for control environment assessment. The EDMC DCAM framework supports this integration by defining Data Management capabilities that map to enterprise risk management processes.

Maintaining a cross-reference between CDE data domains and RAUs closes the remaining gap. A simple matrix showing which CDEs are relevant to which RAUs, with the nature of the dependency (direct input, derived input, reference data), gives both the Data Governance team and the risk assessment teams the visibility they need to avoid gaps and overlaps.

Regulatory Examination Readiness

Regulatory examinations test the CDE program’s connection to risk management. Examiners do not ask to see your governance framework in the abstract. They ask specific questions that trace from regulatory requirements to data, controls, and evidence.

What Examiners Actually Ask

BCBS 239 examinations (ECB, PRA, national supervisors): “Show me the lineage from this risk indicator to its source data.” The ECB RDARR Guide requires “data attribute level” lineage, not system-level diagrams. Examiners will pick a specific KRI on a risk report, ask which CDEs feed it, ask to see quality rules on those CDEs, ask for quality history, and ask what happens when a CDE falls below threshold. They are testing whether lineage is operational, not whether it is documented.

SOX/PCAOB examinations: “Show me IPE testing results for this financial report.” Under PCAOB AS 2201, auditors must test Information Produced by the Entity for every report used as audit evidence. They will ask for the specific data elements in the report, the quality validation applied to each, and the results of that validation. CDE quality monitoring provides the evidence. Without it, auditors must perform expanded substantive testing, which is more expensive and often surfaces findings.

OCC Heightened Standards examinations (for banks with $50 billion or more in assets): “Show me how CDE quality connects to your risk appetite.” 12 CFR 30, Appendix D requires covered institutions to establish “a risk governance framework that provides for the identification, measurement, assessment, and control of risk.” The OCC expects the Data Governance program to be integrated with this framework, not parallel to it.

Examiners will ask whether CDE quality thresholds are reflected in risk appetite statements, whether breaches trigger escalation through the risk governance structure, and whether the board receives reporting on data-related risk exposure. The Citigroup enforcement actions (2020, 2024) demonstrate the consequences of failing this test: the bank had governance artifacts but could not demonstrate operational integration with risk management.

Building the Examination Package Before the Examiner Arrives

The best examination preparation is continuous. Organizations that scramble to assemble documentation when an examination is announced have already signaled weakness. The examination package should be a living artifact, refreshed quarterly and always ready. Essential components:

• CDE inventory with classification rationale tied to regulatory requirements
• At least 12 months of quality scores with trend analysis
• Control documentation: quality rules, monitoring frequency, remediation SLAs, responsible parties
• Attribute-level lineage maps from regulatory reports to source systems
• Exception history with root cause analysis and closure evidence
• Governance evidence: council minutes, stewardship activity, escalation records
• Risk integration evidence showing how CDE quality connects to RCSAs, risk appetite, and board reporting

Connecting CDE Quality to Risk Appetite Statements

Risk appetite statements define how much risk an institution is willing to accept in pursuit of its strategic objectives. They are typically expressed as qualitative principles (“The institution maintains conservative credit risk exposure”) and quantitative thresholds (“Credit losses shall not exceed X% of the loan portfolio under stress scenarios”).

Data quality is increasingly appearing in risk appetite frameworks, either as a standalone risk category or as a qualifier on other categories. The OCC Heightened Standards require covered institutions to adopt and adhere to a written risk governance framework including “concentration and front-line unit risk limits, and a set of risk metrics, and a set of risk appetite indicators.”

Making the Connection Measurable

A typical data-related risk appetite statement reads: “The institution maintains data accuracy and completeness sufficient to support reliable risk measurement, regulatory reporting, and strategic decision-making.”

That is aspirational. To make it operational, you need to define what “sufficient” means in CDE terms:

• Tier 1 CDE quality scores must remain above 99.9% (monthly average)
• No more than 2 Tier 1 CDE exceptions may be open simultaneously
• No Tier 1 CDE exception may age past its 4-hour remediation SLA by more than 24 hours
• Regulatory report accuracy (as measured by post-submission validation) must exceed 99.5%

These thresholds become the measurable risk appetite metrics for Data Quality. When any threshold is breached, the breach protocol activates.

Breach Protocols

When CDE quality threatens risk appetite, the escalation path should mirror the institution’s standard risk appetite breach process. Automated monitoring detects the threshold breach. The responsible steward has the tier-defined remediation SLA to resolve it. If not resolved within SLA, the exception escalates to the governance council with an impact assessment. If the council cannot resolve within its authority (typically 30 days), it escalates to the risk committee. Material or persistent breaches require summary reporting to the board.

This path ensures that CDE quality issues do not remain trapped in governance silos. They flow through the same channels as any other risk event, which is precisely what regulators expect.

Program Maturity Scoring

Stakeholders invariably ask: “Where are we?” Maturity assessment provides the answer, but it carries a hazard. Maturity models can become performative, organizations chasing a higher maturity “score” by formalizing processes without improving outcomes. The EDMC DCAM framework offers a structured assessment organized around 8 components covering 34 data management capabilities and 101 sub-capabilities, each scored against defined criteria.

The EDM Council’s 2023 benchmark report found that 80% of organizations have Data Governance programs in progress or already established. Program existence is not operational effectiveness, and that gap is exactly where maturity theater thrives: organizations score well on process documentation while scoring poorly on outcome delivery.

Outcome-Based Maturity

The antidote is to anchor maturity assessment to outcomes, not process formalization. Dataversity’s maturity framework aligns maturity stages with observable outcomes rather than process documentation alone.

A practical approach:

Maturity Indicator	What It Measures	Why Process Alone Is Insufficient
CDE coverage (monitoring)	% of CDEs with active quality checks	Having a monitoring policy is not the same as having monitoring running
Incident reduction trend	QoQ decline in CDE incidents	Having an incident management process does not mean incidents are declining
MTTR improvement	Remediation speed trend	Having SLAs documented does not mean SLAs are met
Regulatory finding rate	Data-related findings per examination	Having an examination package does not mean examiners find no issues
Risk appetite compliance	% of time CDE metrics are within appetite	Having risk appetite statements does not mean quality stays within them
Stewardship engagement	Active steward participation rate	Having stewards assigned does not mean stewards are engaged

When communicating maturity to senior stakeholders, frame it in terms of these outcomes, not in terms of which capability quadrant achieved which rating. “Our Tier 1 CDE incident rate has declined 40% year-over-year and our regulatory examination produced zero data-related findings” is more meaningful than “We achieved Level 3 maturity across 6 of 8 DCAM components.”

Gartner’s 80% failure prediction exists precisely because too many programs measure maturity by process formalization rather than by the outcomes that justify the program’s existence. For why outcome-based maturity assessment outperforms documentation-focused models like CMMI DMM and DCAM, see The Data Governance Maturity Model Most Organizations Get Wrong.

What Has Changed Since March 2026

• Heightened Standards may shrink to five banks. On December 23, 2025, the OCC proposed raising the Heightened Standards asset threshold from $50 billion to $700 billion. Mayer Brown’s analysis counts the covered institutions falling from 31 to 5; the comment period closed on March 2, 2026.
• Two long-running orders eased. On December 19, 2025, the OCC withdrew its 2024 amendment to Citi’s 2020 consent order, leaving the 2020 order in force. On March 30, 2026, it terminated JPMorgan Chase’s trade-surveillance consent order, stating that its continued existence was no longer required for safety and soundness.
• The CFPB changed its posture. On June 22, 2026, the bureau adopted four enforcement principles: address actual rather than speculative harm, give due process, favor collaboration over litigation, and avoid enforcement pursued for good press coverage or that duplicates other regulators’ work.
• Europe did not ease. The ECB’s supervisory priorities for 2026 to 2028, published in November 2025, keep risk data aggregation and reporting a Priority 2 vulnerability, report no improvement in the average sub-score, and say progress “remains slow.”

When fewer US institutions face mandatory examination, the internal case for CDE metrics has to stand on risk exposure rather than examiner pressure. That is the translation this article argues for.

Do Next

Priority	Action	Why It Matters
Start here	Define KPIs for CDE program operational health: monitoring coverage, ownership coverage, lineage coverage, DQ scores by tier, SLA compliance rate, and incident reduction trend	Without operational KPIs, you have no baseline against which to measure improvement.
Start here	Define KRIs that translate CDE quality into risk language: percentage of Tier 1 CDEs below threshold, regulatory report accuracy trending, and unresolved exception aging past SLA	The CRO and board cannot act on governance KPIs; they need risk exposure metrics tied to consequences.
Then	Map each CDE to the Risk Assessment Units it impacts, documenting the nature of the dependency (direct input, derived input, reference data) for each RAU	Without CDE-to-RAU mapping, quality issues get double-counted in some units and missed in others.
Then	Build tiered dashboards for each audience: element-level detail for stewards, domain rollups for the governance council, KRI reports for the risk committee, and a one-page summary for the board	A single reporting view cannot serve all audiences, from steward detail to board-level exposure summaries.
Next	Prepare a regulatory examination package before the next exam cycle, containing CDE inventory with classification rationale, 12 months of quality history, control documentation, lineage maps, exception history, and governance evidence	Scrambling to assemble documentation when an examination is announced signals weakness to regulators.
Advanced	Connect CDE quality thresholds to your risk appetite statement with measurable limits (maximum Tier 1 exceptions, maximum SLA overages) and breach protocols that escalate through the same channels as any other risk event	Without this connection, Data Quality breaches stay trapped in governance silos and never reach the risk committee.

CDE Program Quick-Start Checklist

This checklist consolidates the action items from all six parts of the series into a phased plan. It answers the question practitioners ask after reading the full guide: “What do I do Monday morning?”

Week 1-2: Anchor the Program

• Identify your 15 to 30 Tier 1 uses (regulatory submissions, risk models, SOX-relevant reports, compliance dashboards) that define the scope boundary for CDE identification
• Audit your current approach: if your program starts from glossaries, resequence to usage-first using the regulatory cross-reference from Part 1 as the business case
• Secure an executive sponsor (CRO, CDO, or head of compliance) with authority over both Data Governance and the regulatory reporting processes that anchor the program

Month 1: Build the First Inventory

• Trace lineage from 3 Tier 1 reports to their source systems, documenting constituent data elements, transformation points, and broken or undocumented paths
• Score all CDE candidates using C = N x I (criticality equals usage count multiplied by impact rating) with a threshold of C >= 6
• Validate the scored candidate list with business stakeholders, assigning a named data owner and data steward for each confirmed CDE
• Build the initial CDE register with all 15 required metadata fields, in a spreadsheet if necessary, but plan the catalog migration

Month 2-3: Operationalize

• Classify confirmed CDEs into Tier 1, 2, and 3 with corresponding quality thresholds and remediation SLAs
• Deploy automated quality monitoring for your top 20 CDEs, covering completeness, consistency, conformity, accuracy, freshness, and uniqueness
• Build a closed-loop remediation workflow: detection routes to steward, SLA tracking in a system of record, automatic escalation on SLA breach
• Define business terms for your top 50 CDEs as the glossary overlay, reconciling cross-domain definitions

Month 3-6: Scale and Integrate

• Implement column-level lineage for all Tier 1 CDEs using lineage tooling (Collibra, Solidatus, Manta, or equivalent)
• Extend CDE identification domain by domain using the same usage-first methodology, prioritized by regulatory exposure
• Map each CDE to the Risk Assessment Units it impacts and integrate CDE quality scores into RCSA working papers
• Build tiered dashboards: steward detail, governance council scorecards, risk committee KRI reports, and board summary

Ongoing: Sustain and Improve

• Conduct quarterly recertification for Tier 1 CDEs, semi-annual for Tier 2 and Tier 3, confirming definitions, ownership, tier assignments, and thresholds
• Audit the CDE inventory for sprawl at each recertification cycle, pruning elements below the criticality threshold
• Maintain the regulatory examination package as a living artifact, refreshed quarterly
• Track the single most important metric: percentage of CDEs with active, automated quality monitoring (target: 100%)

The Complete Arc: What the CDE Practitioner’s Guide Covers

This article concludes a six-part series designed as a complete practitioner guide for building, operating, and sustaining a CDE program in a regulated environment.

Part 0: What a CDE Actually Is established the structural foundation: a three-layer meta model (Business Concept, Logical Mapping, Physical Instance) that separates what a CDE means from where it lives, preventing the conflation of concept and column that leads to governance sprawl.

Part 1: Start With Uses, Not Words established the strategic principle. A cross-reference of nine major regulations across financial services, insurance, and healthcare demonstrated that usage-first CDE identification is structurally superior to glossary-first approaches. Start from regulatory reports, risk models, and business-critical processes; trace backward to source data elements. The glossary layer is essential, but it belongs as the second step.

Part 2: Building Your CDE Inventory covered the methodology for usage-first identification: lineage-based tracing from Tier 1 uses, scoring formulas (criticality equals usage count multiplied by impact rating), the DAMA-NL weighted scoring model, building the CDE register, and layering the semantic glossary around identified elements.

Part 3: Operationalizing CDEs addressed the controls that turn a CDE list into an operating capability: tiered quality SLAs, column-level lineage, monitoring and remediation workflows, the three-layer accountability model (owner, steward, domain lead), and technology enablement.

Part 4: Scaling and Sustaining covered the progression from 10 CDEs to enterprise scale, the 12-to-18-month program roadmap, anti-patterns with real-world examples, and connecting CDE quality to business outcomes.

Part 5 (this article) covered the measurement and risk integration layer: KPIs for operational health, KRIs for risk exposure, the translation bridge between the two, reporting hierarchies for every audience, integration with enterprise risk assessment (RAUs and RCSAs), regulatory examination readiness, and risk appetite alignment.

Together, the six parts form a single argument: the CDE program’s purpose is not to document data. It is not to populate a catalog, achieve a maturity score, or satisfy a governance checkbox. The purpose is to ensure that the data feeding your highest-stakes decisions, the regulatory reports that trigger enforcement actions, the risk models that drive capital allocation, the financial statements that officers certify under penalty of law, is accurate, traceable, and controlled.

Every metric, every KPI, every KRI, every dashboard, every board summary exists to answer one question: Can you trust the data that runs your institution? If the answer is yes, the CDE program has done its job. If the answer is “we think so but cannot prove it,” the program has documentation. Documentation is not governance.