Data Governance Consulting: A Function, Not a Committee

Data governance has a reputation problem, and it earned it. In most enterprises the phrase means a monthly meeting, a glossary nobody reads, and a policy that makes work slower without making data better. So when someone proposes data governance consulting, the reasonable internal reaction is resistance.

The version that works looks nothing like that. It is a small set of decisions with named owners, enforced in the systems rather than in a document, and it is one of the few things that gets cheaper the earlier you do it.

What is data governance consulting?

Data governance consulting is outside help deciding who owns which data, what it means, who may see it, and how it changes, then making those decisions enforceable in the systems that hold it.

Four decisions make up almost all of it.

• Ownership. A named person accountable for each significant dataset.
• Definition. What each field means, recorded where the data lives.
• Access. Who may read and write it, enforced by the platform.
• Change. How a definition or schema changes without breaking consumers.

Everything else in the discipline, the catalogs, the councils, the maturity models, exists to support those four. When a program starts with the supporting machinery instead of the four decisions, it produces documentation and no behavior change.

Governance is a function, not a gate

The standards bodies moved on this before most enterprises did, and it is worth borrowing their framing because it is more useful than the committee model.

When NIST released Cybersecurity Framework 2.0 on February 26, 2024, the structural change was adding a sixth function, Govern, alongside Identify, Protect, Detect, Respond, and Recover. It covers how strategy, roles, policy, and oversight get established and monitored, and it threads through the other five rather than sitting in front of them as an approval step.

NIST’s AI Risk Management Framework 1.0, released January 26, 2023, uses the same shape: Govern, Map, Measure, and Manage, with Govern as the function that makes the other three accountable rather than a stage they pass through.

The practical translation for data work: governance is not a checkpoint the delivery team clears. It is a set of properties the delivered thing has. A dataset that ships with an owner, a definition, enforced access, and a versioned interface is governed. A dataset that shipped without those and later gets reviewed by a council is not governed, it is monitored.

Start with the arguments, not the inventory

The standard first move in this field is to catalog everything. It feels thorough, it takes six months, and it changes nothing, because a catalog of ungoverned data is a very good map of a problem you still have.

Start instead with the two or three numbers your leadership team argues about. Revenue by segment, customer count, loss ratio, active users, cost to serve. For each one, run the argument to ground:

1. Find every definition currently in use. There will be more than one. That is the finding.
2. Pick one, in writing, with a named owner. This is a decision, and it needs someone with the authority to make it.
3. Publish it where the data lives, not in a separate glossary that drifts.
4. Retire the others, or mark them explicitly as different measures with different names.

Doing this for three metrics teaches an organization more about its data than any assessment, and it produces something people notice: the meeting stops being about whose number is right.

What to enforce in the platform versus what to write down

The caveat, because tables like this get read as absolutes: in a young estate, documenting is a reasonable interim step for most rows, as long as there is a date on which it becomes enforcement. Permanent interim controls are how governance programs lose credibility.

The regulated-industry version

In financial services, insurance, and healthcare, the four decisions are not optional and the deadline is not yours. Insurance carriers now work against the NAIC model bulletin on the use of artificial intelligence systems, adopted December 4, 2023, which expects documented governance around models touching underwriting, pricing, and claims. Health IT works against a certification baseline with defined data classes. Banking has had model documentation expectations for well over a decade.

The pattern across all three is the same and it is worth stating plainly: the regulator does not ask whether you have a governance council. It asks who owned this data, what it meant, who could see it, and how this specific decision was reached. Those are the four decisions, asked in the past tense. Build them in as data ships and the answer exists. Retrofit them and you are reconstructing history under time pressure.

We treat that as part of the build rather than a separate workstream, which is the same argument we make about insurance digital transformation and about model work generally in machine learning consulting.

How this connects to the rest of the data work

Governance is not a program that runs beside data engineering. It is a property of what data engineering produces. If you are contracting for pipelines, governance has nowhere to attach. If you are contracting for data products with contracts, ownership and definitions are already in the deliverable, and the governance program becomes a review of exceptions rather than an attempt to catalog the world.

Same for integration: every point-to-point connection is an ungoverned copy of something, which is why data integration discipline and governance are the same conversation, and why we build the infrastructure to be readable rather than merely storable.

How to tell it is working

• Competing definitions for core metrics, going down. The single most honest measure in this field.
• Percent of significant datasets with a named, published owner. Named, not assigned to a team.
• Time to answer an access request. If governance made this slower, it is being implemented as a gate.
• Time to answer “who could see this and why.” The audit question, timed.
• Schema changes shipped without breaking a consumer. Proof that the interface exists.

Note the third one. A governance program that makes legitimate access harder has failed, whatever its compliance posture. Good governance makes the safe path the fast path.

Frequently asked questions

Do we need a data catalog?

Eventually, and not first. A catalog is valuable once there is something governed to catalog. Bought first, it becomes an inventory of unowned datasets that nobody maintains, and the tool takes the blame for a decision problem.

Who should own data governance?

Someone with authority over both the business definitions and the platform, or two named people who meet weekly and can each decide. The common failure is placing it entirely in technology, which produces enforcement with no mandate, or entirely in the business, which produces policy with no enforcement.

How long before it is worth anything?

Settling the definitions for two or three contested metrics and publishing them with owners takes weeks and is immediately visible in leadership meetings. Enforced access and versioned interfaces follow the platform work, so they land alongside the first data products rather than as a separate program.

Is this different for AI?

The decisions are the same, and the consequences of skipping them are larger, because a model turns a data quality problem into a decision you have to defend. NIST’s framing is useful here: Govern is what makes Map, Measure, and Manage accountable. Without ownership and definitions, there is nothing to map.

Where to start

Pick the number your leadership team argues about most. Find every definition of it in use, choose one in writing with a named owner, and publish it where the data lives. That is a two-week project, it costs almost nothing, and it will tell you more about whether you have a governance problem or a tooling problem than any assessment will.