Most definitions of Critical Data Elements, CDEs, start the same way. “A CDE is data that is critical to the company”. That statement is true and still not very useful. Because it avoids the only question that matters. Critical for what.

Data does not create value on its own. It never has. All value in a company is created through work being done. Decisions taken, actions executed, obligations fulfilled. In other words, through processes. If we want CDEs to mean something operationally, we must stop starting with data and start with processes.

A company is nothing but processes

Strip a company down to its essence and nothing remains but processes. Selling, buying, producing, delivering, servicing, reporting, vetting, complying. Even control and compliance are processes. People, systems, and data exist only to enable these flows of work. There is no such thing as important data in isolation. Data becomes important only when someone relies on it to do something.

Why important data quickly fails

When CDEs are defined without process context, the same pattern repeats itself. Everything becomes critical. Nothing is prioritised. Governance turns theoretical. Lists of important attributes grow long. Ownership becomes vague. Quality rules multiply. And yet, nothing really improves. The reason is simple. Importance was never grounded in dependency.

Data becomes critical only through dependency

A piece of data becomes critical at the moment a process depends on it to produce a correct outcome. Not because it exists. Not because it is widely used. Not because it sounds important. But because something breaks when it is wrong.

To identify CDEs, the only questions that matter are. Which process relies on this data and
what decision or outcome depends on it. What happens if it is wrong, late, missing, or ambiguous. Who feels the impact and when.

If you cannot answer these questions, the data is not critical. It may be interesting. It may be convenient. But it is not a CDE.

CDEs emerge from understanding processes

The work, therefore, is not tagging fields in a data model or populating a catalogue. The real work is understanding the process data network. Which processes produce data. Which processes consume it. Where are the handovers. Where does responsibility shift.

When this network becomes visible, CDEs reveal themselves naturally. Ownership becomes clearer. Usage becomes explicit. Impact becomes measurable. At that point, CDEs stop being a declaration and become a shared understanding.

Compliance does not break the model

A common objection is that some data is critical because of regulation or compliance. But compliance is still work. And work is still a process. Vetting is a process. Screening is a process. Regulatory reporting is a process.

The criticality of data in these contexts is no different. It is still defined by dependency and failure modes. What data drives the decision. What happens if it is wrong. What the consequence of failure is.

Calling it compliance does not exempt it from process thinking. It reinforces it.

Not all data in a process is critical

Discipline matters here. Just because a process touches data does not make that data a CDE. A data element is critical only if it is decisive for the process outcome.

Ask this question relentlessly. If this data is wrong, does the process still succeed. If the answer is yes, it is not a CDE. This single filter prevents governance inflation and keeps focus where it belongs.

Ownership follows creation, not consumption

Once a CDE is identified, governance becomes much simpler. Every CDE has a point of creation, a reason for existence, and one or more dependent processes. Ownership does not belong to everyone who uses the data. It belongs where the data is created or legitimately changed. Downstream controls can detect errors. Only upstream ownership can prevent them.

Governance is about securing the channel

Good CDE governance is not about control everywhere. It is about securing the few channels where correct and unambiguous creation must happen. That means clear authoritative sources, explicit creation rights, fewer entry points, and stronger rules at the source. Fix creation, and most quality problems disappear on their own.

Measure impact, not aesthetics

CDE quality should not be measured because a standard says so. It should be measured because a process depends on it, a failure has a real consequence, and someone is accountable for the outcome. If no process feels the pain, the data is not critical, no matter how elegant the definition.

In short

Critical Data Elements are not defined by importance. They are defined by process dependency.

Understand why data exists.
Understand who relies on it.
Understand what fails when it is wrong.

Only then decide what is truly critical, who owns it, and how it must be governed.

Everything else is just data talking about itself.