There is a moment many data governance programmes eventually reach, usually a year or two in. You will recognise it. The framework has been completed. Roles have been defined and assigned. Data owners have been nominated, stewards identified, policies approved, committees established. On paper, governance exists. You have surely experienced it.
Then somebody asks a seemingly very simple question: who can actually make this decision? Things become considerably less clear. The data owner points to IT. IT points to the business process owner. The business process owner was not aware they had any responsibility for the data in question. The steward understands the problem but has no authority to resolve it. Eventually, another meeting is scheduled.
This is one of the most common patterns in data governance, and one of the most instructive. The problem is rarely that organisations have never heard of governance, or that they have not tried. Many have been working on it for years. The harder question is why, despite sustained effort, governance so often struggles to deliver the value expected of it.
In my experience, the answer is rarely a missing component in the governance framework. More often, there is a gap between how governance has been designed and how the organisation actually makes decisions, allocates authority and gets work done. Most likely the implementation of the designed governance has come to a hurdle. Or two.
Governance fails when it is designed as a structure rather than as a way for an organisation to make and execute decisions.
That distinction runs through many of the problems that appear later as ownership issues, persistent data quality problems, ineffective stewardship or lack of engagement. They may look like separate governance failures. Often, they are different symptoms of the same underlying disconnect between the governance model and the organisation it is supposed to serve. 
Governance designed in isolation
Most governance frameworks make sense on paper (and if they don’t, organisations hopefully do not even try to implement them). Someone should be accountable for important data. Definitions should be agreed and documented somewhere. Quality should be measured and improved. Issues should have owners. Access should be controlled. Decisions should be traceable.
On paper, none of that is particularly controversial. The difficulty begins when those principles meet an actual organisation.
Organisations already have their own structures, incentives, systems, processes, reporting lines and ways of getting things done. Governance arrives in the middle of all of that. If it is designed without a serious understanding of that existing reality, including how decisions actually get made, where authority genuinely sits and what competing priorities look like in practice, the organisation may adopt the terminology of governance without changing much else.
People acquire new titles. Meetings acquire new names. Templates acquire new fields. Teams are changing members. But the underlying decisions continue to happen exactly as they did before.
That is not governance embedded in how the organisation works. It is governance layered on top of it. Layered governance creates compliance theatre: the appearance of accountability without the substance of it. A governance structure can be perfectly logical and still have remarkably little influence over how the organisation actually behaves.
The difference between a role and accountability
Data ownership is perhaps the clearest example of this problem. Organisations typically invest considerable effort in identifying data owners, working through domains and sub-domains, negotiating with business areas and eventually producing a list of names attached to datasets or subject areas. The names appear in a catalogue or a sharepoint. The exercise is declared complete. Celebration is in order.
But giving somebody the title of data owner does not automatically give them the ability to own anything.
The questions that matter are more operational. Can this person approve a definition? Can they decide whether a quality issue is serious enough to prioritise? Can they resolve a disagreement between two business areas about how a term should be interpreted? Can they ensure that a decision is translated into action, even when implementation sits elsewhere? Is there a budget allocated for the changes the person will approve? And, perhaps most fundamentally, do they even know they have been named as the owner? (No smiling here, this is happening more often than you might guess).
If the answers to those questions are unclear, the organisation has assigned a role without establishing accountability.
This distinction matters because governance depends on decisions being made. When nobody knows who can make them, governance does not disappear. It transforms into escalation. Issues travel upwards through the organisation, consuming time and goodwill, often returning without resolution. The committee discusses. The meeting is rescheduled. The problem persists.
A role description can tell someone that they are accountable. A functioning governance model has to make that accountability possible.
Starting in the wrong place
Another reason governance struggles is that organisations frequently begin by designing the governance structure itself. What committees are needed? What roles should be created? Which domains should be defined? Which tool should support the programme?
These are real legitimate questions, but they are rarely the most useful first questions.
A more productive starting point is often much closer to an actual business problem. Suppose two senior executives consistently receive different revenue figures and cannot agree on which to use. Rather than responding with a generic enterprise governance model, it is worth following that specific problem. Where do the two figures originate? What definitions are being applied? Where do the interpretations diverge, and at what point in the process? Who currently has the authority to determine which definition should be used going forward? Who would need to implement the decision? What would prevent the same problem from recurring?
Suddenly governance is no longer theoretical. Ownership, definitions, data quality, lineage and escalation paths become connected to something the organisation genuinely needs to resolve. That is considerably easier for people to understand, engage with and sustain than an abstract framework, and much harder to dismiss as bureaucracy.
The governance model can then be designed around the decisions and accountabilities the organisation actually needs, rather than asking the organisation to adapt itself to a model designed in isolation. This does not mean abandoning enterprise governance or solving every problem individually. It means using real decisions and real friction to understand what the governance model actually needs to enable.
What workarounds are telling you
When governance is not working as intended, the instinct is often to add more of it. Another approval step, another mandatory field, another policy, another committee. Sometimes that is exactly what is needed. But governance accumulates surprisingly easily, and the cumulative effect can be an environment where following the formal process becomes harder than working around it.
The spreadsheet reappears. The offline approval happens. The local definition survives alongside the official one. The unofficial dataset becomes the one that people actually trust.
This does not necessarily mean people oppose governance. More often, they are simply trying to get their work done within the time and authority available to them.
A workaround is frequently a signal worth taking seriously. It suggests that the formal process and the operational reality have drifted apart in ways the governance design did not anticipate. Before asking how to stop people from working around the process, it is usually more valuable to ask why the workaround is easier than the process that was designed. The answer can reveal something a maturity assessment may not: whether governance actually works when people need to use it.
This is also why I am cautious about treating every workaround simply as non-compliance. Some absolutely need to be removed, particularly where they introduce material risk. But others are telling us something useful about the design of the formal process. Governance should be capable of distinguishing between the two.
Knowledge without authority
There is one further pattern that appears with striking consistency. The person who understands a data problem most clearly is often not the person who can do anything about it.
A data steward may know exactly why a particular field is consistently wrong. An analyst may have identified that two reports rely on incompatible definitions. An engineer may know precisely where the lineage breaks. But knowing where a problem lies is not the same as being able to address it.
Governance must create a functioning connection between the people who can identify problems and the people who have the authority and resources to resolve them. In practical terms, this means an organisation needs a clear route from recognising that a problem exists, to someone being able to decide what should happen, to that decision actually being implemented. When any part of that chain is missing, issues circulate. They are discussed, documented, escalated, reopened and occasionally renamed, but they do not disappear.
Because over time, something more damaging can happen. The people who originally raised the problems stop raising them, as experience has taught them that identifying an issue does not reliably lead to resolution. At that point, a governance dashboard may even appear to improve because fewer issues are being reported. That does not necessarily mean there are fewer issues.
A governance model therefore needs more than mechanisms for identifying problems. It needs credible mechanisms for resolving them.
What working governance looks like
Successful governance is not defined by the organisation with the most policies, the largest data office or the highest maturity score. It tends to look rather more ordinary from the outside: the right conversations happening at the right level; people understanding which data matters for which decisions; ownership that includes genuine authority; issues that have somewhere to go and someone able to resolve them; escalation that is the exception rather than the default operating model.
It also has to acknowledge a simple and very practical constraint: the people whom governance depends on have other jobs. The executive nominated as a data owner is already managing operational targets and competing priorities. The subject matter expert asked to serve as a steward already has a full workload. Technology teams have delivery commitments. Business teams have customers. Governance enters that environment asking for time, judgement and engagement. If the value of that contribution is not clear, and if the tasks are not proportionate to the problems being solved, governance will consistently lose the competition for attention.
This is why asking people to “take accountability for data” is rarely sufficient on its own. They need to understand what decisions they are expected to make, what authority or mandate they have to take those decisions, how frequently, what information and support they will have, and what happens when issues are not resolved. Governance needs an operating rhythm that is regular, purposeful and proportionate, not simply an organisational chart with names attached.
Proportionality matters more broadly as well. Not every dataset requires the same level of oversight. Not every issue needs to reach a governance forum. Not every decision requires a committee. Part of what makes governance usable is that people can understand why a particular requirement exists and see a reasonable connection between the effort it asks of them and the problem it is trying to solve.
If your governance programme is not delivering the value expected of it, another layer of framework may not be what is needed. (Hint: it probably is not). Look instead for the friction. Where are decisions consistently slow? Where do people repeatedly question the same numbers? Where do ownership disputes surface? Where are teams maintaining local workarounds because the official process does not serve them? Where does everyone know there is a problem, but nobody seems able to resolve it?
Those are governance problems already pointing to where the work needs to happen. Governance does not succeed because an organisation has documented everything on how it should work. It succeeds when people can use it to resolve uncertainty, make decisions and move forward.
That is the difference between having governance and having the confidence to act.
Which brings us to a question most governance programmes think they have already answered: who actually owns the data?
Because naming an owner is one thing. Understanding what ownership means, and what it allows someone to decide, is quite another…
About the author
Karima Makrof is the Founder and Chief Adviser at AKLYON Consulting and Senior Manager, Data Governance at PwC Sweden, within the Chief Data Office. With more than 20 years of international experience across industries and countries, she works at the intersection of data governance, organisational accountability and decision-making, helping organisations move from having data to being able to act on it with confidence.
Her experience spans financial services, technology, manufacturing, automotive and professional services, including leadership roles with global organisations such as Volvo Group, Oracle, SKF, ESAB, Volvo Cars and Swedbank. This breadth gives her a perspective on how data challenges evolve as organisations, technologies and expectations change.
Today, her work focuses on the gap between governance as it is designed and how it functions in practice, taking a pragmatic approach to accountability, ownership, decision authority and how governance becomes part of the way an organisation operates.
Karima is a regular stage moderator at the Data Innovation Summit and Data 2030 Summit and speaks internationally on data governance, data leadership and responsible AI, bringing a practitioner’s perspective to questions often treated as primarily technical or procedural.
She is the author of The Confidence to Act: 30 Reflections on Data Governance – What Breaks and What Holds?, drawing on over two decades of experience to explore why governance falls short in practice and what enables organisations to act with confidence.
*The views and opinions expressed by the author do not necessarily state or reflect the views or positions of Hyperight.com or any entities they represent.
