Data Governance Isn't a Policy Pack: Here's What Broken Ownership Looks Like

Ask most mid-market companies whether they have data governance and you'll get one of two answers: "no, we should probably do that at some point," or "yes, we have a policy document." Both answers miss the point, because data governance is not primarily a document. It is a set of working ownership relationships, and when those relationships are missing, the symptoms show up everywhere except in a compliance audit, which is usually the only place anyone goes looking.

This article is about data ownership problems: what they actually look like day to day, why a policy pack does not fix them, and what real ownership looks like instead.

What broken ownership actually looks like

Not a missing document. These, instead:

"Whose number is right?"

Sales says pipeline value is £2.4m. Finance's forecast model says £1.9m. Nobody can definitively say which is correct, because nobody owns the authoritative definition of "open pipeline" across both systems. The meeting spends twenty minutes debating whose spreadsheet to trust instead of discussing the business implications.

The person everyone asks, informally, who has no actual authority

There's always someone, often a long-tenured analyst or an IT contact, who people quietly go to when data looks wrong. That person did not agree to be the data owner. They have no formal standing to make decisions, no time allocated to the role, and no backup if they're on leave. Ownership exists, but only informally, which means it is fragile and untracked.

Definitions that drift silently between teams

"Active customer" means something different to sales (opened an opportunity in the last quarter), to finance (has an invoice in the last twelve months), and to support (has a ticket in the last six months). Nobody decided this was fine. It happened because no one owns the definition across the business, so each team built their own to solve their own immediate problem.

Changes made without anyone being told

A field gets renamed in the CRM. A status value gets added in the ERP. Someone downstream builds a report referencing the old structure and it silently breaks or misreports, because there was no owner whose job it was to be consulted before the change, or to communicate it after.

Nobody can answer "who is allowed to change this"

When a new integration needs to write to a customer record, or a new report needs a new field added to a core table, there is no clear person to ask. Requests either go unanswered for weeks, or get approved by whoever happened to have access, without real accountability for the downstream consequences.

Data quality issues nobody owns fixing

A duplicate customer problem has existed for eighteen months. Everyone agrees it's annoying. Nobody has fixed it, because it does not clearly belong to any one team's job description, and without an owner, "annoying but not urgent enough for anyone specifically" tends to last indefinitely.

Why a policy document doesn't fix any of this

A governance policy document typically states principles: "data should be accurate," "access should be appropriate," "changes should be documented." These statements are true and useless in the same breath, because they describe outcomes without assigning anyone the job of producing them.

Policy without ownership is a wish list. The ownership relationship is what actually makes any of it happen, because ownership means:

• A specific person or role is accountable when the outcome fails
• That person has actual standing to make decisions, not just an opinion
• Other teams know who to go to, rather than guessing or asking around
• There is someone to consult before changes, and someone to escalate to when something breaks

What real ownership looks like instead

Ownership, done properly, is simple to describe even if it takes discipline to maintain:

This is the foundation of any workable data governance framework, not the classification scheme, not the catalogue, not the council. Ownership comes first, because everything else assumes someone is actually accountable to act on it.

A quick diagnostic: do you actually have ownership?

Ask these about your three or four most important data domains (customer, product, financial, whatever matters most in your business):

• Can you name, right now, without checking anything, who owns this domain?
• Does that person have actual authority to approve or block structural changes?
• Is there a backup if they're unavailable?
• When two departments disagree about a definition in this domain, is there a clear person who decides?
• Would that person be consulted before a system change affecting this domain, not just informed after?

If you answered no to more than one of these for a domain that matters to the business, you have a data ownership problem, regardless of whether you have a governance policy document sitting somewhere.

Why this matters more as companies grow

In a 15-person company, informal ownership works fine, everyone roughly knows who understands what, and questions get answered in a hallway conversation. Somewhere past 50-100 people, informal ownership starts failing quietly: too many people, too many systems, too much distance between the person who understands a data domain and the people who need answers about it. This is often around the same point companies start noticing every department has its own version of the truth, which is the direct downstream symptom of exactly the ownership gap described here.

Where quality problems actually come from

It's tempting to treat data quality issues as purely technical, a bad integration, a missing validation rule. Often, the real root cause is a governance gap, not a technical one: the duplicate records exist because nobody owns deduplication, the invalid status codes persist because nobody owns the reference data, the stale customer records survive because nobody owns retention decisions. Fix ownership, and a surprising number of "technical" quality problems become someone's clear job to solve.

Ownership before anything else

Data ownership problems are the practical, everyday face of failed data governance, not a missing policy document, but the absence of a specific, authoritative, resourced person whose job it is to make decisions about a given piece of the business's data. You can write the most thorough governance policy in the world and it will not fix a single one of the symptoms above, because policy describes intent and ownership is what actually executes it.

If you're planning a governance initiative, start here, not with the document, with the names.

Next step: Talk to us about implementing a right-sized governance model, or read our practical framework for companies under 200 people for the full operating model this ownership layer sits inside.