Data governance vendors sell clarity: named owners, consistent standards, lineage and control. Yet a platform can display an impeccable ownership matrix while every important issue is still passed between departments. That is the uncomfortable reality raised in recent UK enterprise data roundtables. The obstacle is often not a missing technical capability. It is the absence of people with both the responsibility and the authority to change the process that creates the data.
Participants described different routes to making stewardship work. Some built global data-lead roles alongside process owners. Others embedded governance within the operational management of customer, supplier and product domains. In banking, one participant described obtaining senior sponsorship to establish owners and stewards across regions, while still struggling to assign responsibility in particularly complicated operational areas. These were not stories of installing a tool and declaring the job finished.
An owner on a slide is not necessarily an owner in practice
Many governance programmes begin with a RACI document. It can be useful, but the hard test comes later. When sales and finance disagree about a customer identifier, who makes the decision? When a source system creates inconsistent product information, who can authorise a change? When an AI application requires a definition that cuts across multiple regions, who accepts the risk of the chosen interpretation?
The roundtable repeatedly returned to the role of business process owners. A central data office may understand the tooling better than anyone, yet have little control over the operational behaviours that produce the information. One participant described shifting away from an over-centralised data team and giving process leaders greater responsibility for quality end to end. That shift is organisational, not merely technical.
Vendors should therefore ask a diagnostic question before the product demonstration: if we surface a high-priority issue tomorrow, who has the power to fix its cause? If the customer cannot answer, a catalogue and stewardship dashboard may become repositories of unresolved tasks. A credible deployment plan should establish decision rights before automation creates a larger queue.
Global consistency and local execution need both sides
For multinational businesses, governance is not simply a choice between central control and decentralised freedom. A global definition of customer, product or supplier may be essential for consistent reporting and AI. Local businesses still need to manage the processes, suppliers and legal constraints that produce those records.
UK participants described global stewards and domain leads working with regional or functional process owners. The advantage is that standards can remain consistent without requiring one central team to repair every exception. The difficulty is resourcing and accountability. Senior sponsorship can persuade a reluctant function to nominate a steward; it cannot by itself ensure that the steward has time, skills or influence to do the work.
For software providers, the design implication is practical. Can an enterprise define global standards while delegating issue resolution locally? Is escalation visible? Can ownership survive organisational change? Can users find the policy, lineage and accountable person without learning an entirely new workflow? Capabilities such as flexible roles, approvals, issue management and auditable exceptions matter more when they support an operating model already endorsed by the business.
A governance project ends; poor data keeps arriving
One participant described the importance of treating data governance as an ongoing structure rather than a sequence of projects. The distinction changes procurement. A one-off migration or cleansing exercise has a definable finish. Data quality, access control and business definitions change whenever systems, processes, products and regulations change.
Buyers should be sceptical of a supplier that measures success exclusively through the number of fields catalogued, policies drafted or stewards onboarded. Those are implementation measures. They do not show that the business has changed its behaviour. More relevant indicators might include time to resolve priority issues, repeat defects originating from a source process, ownership coverage for critical elements and the number of decisions made using an agreed definition.
The difference is particularly important for AI. Agents and analytics tools amplify reliance on consistent definitions and trustworthy access. A data governance platform cannot compensate for a sales team that changes customer classifications without agreement, or a business unit that bypasses the process when deadlines tighten. It can, however, make the consequences visible and the corrective action traceable.
Stop pitching compliance as the only reason to care
Regulatory pressure can unlock attention. Banking participants discussed formal governance obligations and senior sponsorship; other contributors framed governance as part of culture and business performance rather than a policing exercise. There is value in both. Compliance can set minimum controls, while the operating benefit determines whether people embrace them after the initial audit.
This suggests a more effective commercial conversation. Instead of leading with the breadth of a metadata catalogue, ask about the decision or service that failed because nobody owned its inputs. Instead of presenting a maturity-model score, show how responsibilities are reflected in real workflows. Instead of promising that the data office can govern everything, explain how it can equip the business to govern what the business actually controls.
A platform’s value should be expressed in terms the business recognises: fewer reconciliations, faster issue resolution, more reliable reporting and reduced rework when an AI programme enters production. That is not less sophisticated than technical governance. It is what turns governance from a control function into an operating capability.
The ownership problem starts where data is created
A typical ownership diagram looks complete. There is an executive sponsor, a central governance office, several domain owners and a handful of stewards. The problem appears when a product record is entered incorrectly or a customer definition changes. Who can alter the originating process? Who can require a business unit to follow the new standard? Who is accountable when a field is technically valid but commercially misleading? If the answer to each question is the central data office, the organisation may have assigned responsibility to people without the authority to act.
Participants in the UK collection described efforts to move from central data teams towards business process ownership. One discussed global data leads working alongside process owners. Another described domain stewardship across supplier, customer, consumer, material and product information. A banking example involved identifying owners and stewards across regions, with executive sponsorship helping adoption. These are operating-model decisions, not simply software configuration choices.
The important distinction for a vendor is between ownership of a dataset and accountability for a business process. A person may curate a dataset while lacking control over how the business captures new records. A steward may investigate anomalies but be unable to compel a regional team to correct its inputs. Effective technology should make those differences explicit. It should map an issue to the correct accountable role, show escalation paths and leave a readable audit of decisions. A platform that merely imports an organisation chart will reproduce its weaknesses.
When demonstrating governance workflow, vendors should deliberately choose a case that crosses departmental boundaries. A supplier code may be maintained in procurement, consumed in finance and referenced in reporting. Show how disagreements are resolved, who approves a change and how downstream systems discover that the definition has been updated. That is a stronger demonstration than showing that permissions can be assigned to a named user.
Global rules are easier to write than to operate
Multinational enterprises need consistency without pretending every jurisdiction or operating unit works identically. The UK discussions surfaced both sides of that challenge. Global leads and standards can support local process owners, while operational teams are often the hardest to persuade. In one example, leadership support across regions helped the governance initiative gain authority. Another participant framed governance as a cultural programme because technical controls alone were unlikely to change behaviour.
For a supplier, the temptation is to sell one universal data policy. Buyers should instead ask which rules genuinely need to be common and which are locally configurable. A universal definition of a financial metric may be essential; the workflow for handling an exception may need to reflect who approves transactions in a particular geography. The solution should preserve the governing principle while documenting valid regional variation. Neither uncontrolled local customisation nor inflexible centralisation is a healthy default.
The change-management burden should be visible in the proposal. How will existing roles be mapped? Does the product support delegated approvals? Can regional teams see issues in the language and business context they recognise? Will stewards receive an actionable queue rather than a new dashboard that no one owns? Who handles disputes when two departments claim different interpretations of a term? An honest implementation plan addresses these questions before the licences are signed.
Vendors also need to account for organisational drift. People move roles, teams merge and processes are redesigned. If ownership mappings become stale, a seemingly mature governance platform can silently lose its ability to close issues. A sensible operating measure is not only the percentage of datasets with assigned owners, but the proportion of material issues resolved by an owner with continuing authority and within an agreed decision timeframe.
The proof buyers should demand after the first ninety days
Consider a buyer that assigns named owners to three data domains. A conventional project report might celebrate that all required fields have been completed and training sessions delivered. A more useful review asks what happened when real exceptions arrived. Were source problems corrected? Did operational teams engage? Did the same faults recur? Could an executive sponsor see unresolved cross-functional disputes without reading dozens of technical reports?
A vendor can strengthen its case by providing a simple evidence trail for a small set of incidents. Show the source event, the business rule, the routing decision, the steward’s analysis, the process owner’s approval and the eventual correction. Where an exception is accepted, show the documented business rationale and expiry or review date. This makes governance a visible activity rather than an abstract maturity score.
The roundtable also included approaches to awareness and data literacy, from internal communications to training and self-service enablement. Those programmes have a role, but vendors should not substitute training attendance for behavioural proof. If a frontline team has no time or incentive to correct its records, more training slides are unlikely to solve the problem. Product workflow, management expectations and business consequence must align.
The commercial opportunity is therefore broader than a governance tool yet narrower than an all-purpose transformation claim. Suppliers that make accountability operational, reduce friction for business teams and demonstrate successful closure of recurring issues can tell a credible value story. Suppliers that promise ownership as a feature risk being judged on organisational problems their technology was never designed to solve.
Six questions every governance vendor should welcome
- Who is authorised to make a final decision when data definitions conflict?
- How are global standards implemented without ignoring regional processes?
- What happens when a named steward has neither time nor operational authority?
- How does the system connect a detected issue to its originating process?
- Can leaders distinguish an active ownership model from a completed documentation exercise?
- Which measurable business outcomes change after the first six months?
The buyer is not purchasing an organisational chart
UK enterprise leaders are wrestling with the gap between technical governance and business accountability. The vendor that acknowledges that gap earns credibility. Software can record ownership, automate evidence and make decisions visible. It cannot make an unwilling department accountable by itself. Winning the deal requires an implementation model that addresses both sides.
For vendors: The Data Leadership Board creates opportunities to engage senior data and technology decision-makers about their real operational priorities. If your governance proposition is grounded in ownership and measurable business value, speak with our team about connecting with relevant enterprise leaders.