Data Governance

Building a governance operating model that scales

How a federated governance model assigns ownership, decision rights and review cadence without slowing delivery.

• By CDI-Code
• Reviewed by DII Reviewer (synthetic), TEST fixture

• Published September 21, 2026
• 7 min read

Share

• Share by LinkedIn
• Share by X
• Share by Email

Data governance programmes fail less often because of bad policy than because of unclear ownership. When no one is accountable for a dataset, quality drifts, definitions diverge, and every downstream report becomes a small negotiation. This article sets out a federated operating model that assigns ownership without slowing delivery, drawing on patterns seen across regulated and unregulated organisations alike. It is synthetic TEST content for the DII GeneratePress TEST integration and describes no real organisation.

Why centralised governance stalls

A single central team can write a clean policy. What it cannot do is keep up with every team’s changing data as the organisation grows. Requests queue, definitions go stale, and teams start working around the process rather than through it. The result is governance that looks complete on paper and is ignored in practice.

Federated governance addresses this by moving day-to-day ownership to the teams that actually understand the data, while a smaller central function keeps the shared rules consistent across teams.

The three ownership roles

A federated model works when three roles are distinct and named, not implied.

Domain owner

Accountable for a dataset’s definition and quality. Usually a senior person on the team that produces the data, not a governance specialist.

Data steward

Does the day-to-day work: maintaining documentation, triaging quality issues, running the review cadence.

Central governance function

Owns the shared rules — naming conventions, the quality-threshold framework, the escalation path — and arbitrates disputes between domains.

Setting the shared rules

Before assigning ownership, agree the handful of rules every domain must follow. In practice this is a short list:

1. A common naming convention for datasets and fields.
2. A quality-threshold framework every domain applies to its own data.
3. A documented review cadence, published and visible to other domains.
4. One escalation path, used the same way regardless of which domain raised the issue.

Keep this list short. Every additional shared rule is one more thing every domain has to remember, and long central rulebooks are exactly what federated governance is trying to avoid.

Governance that only the governance team can operate is not governance — it is a bottleneck with a policy document attached.

Review cadence over review depth

Organisations often default to a single deep annual review. In a federated model, a shorter cadence run more often catches drift earlier and costs each domain less time overall.

Escalation and dispute resolution

Even with clear ownership, domains disagree — about a shared definition, about which domain owns an overlapping dataset, about whether a quality threshold is being met. A federated model needs one visible path for raising these disputes, owned by the central function, used consistently regardless of which domain raises it.

Comparing the two models

The table below summarises where centralised and federated governance tend to differ in practice.

A worked example

Consider a mid-sized organisation with five business domains, each producing its own operational data. Under a centralised model, a single governance team of four people cannot review changes from all five domains without becoming a queue. Moving to a federated model, each domain names a domain owner and a data steward from within its own team — no new headcount — and the central team of four shrinks its role to maintaining the shared rule set and running monthly cross-domain reviews.

Within two quarters, the domains that adopted the monthly review cadence reported fewer quality escalations than under the previous annual review, and the central team spent proportionally more time improving the shared rules rather than processing individual change requests.

Measuring whether the model is working

A federated model can look busy without actually improving anything, so it is worth tracking a small number of signals rather than assuming activity equals progress. Three tend to matter most in practice.

Time to resolve a quality issue

Measured from the moment an issue is first flagged — by any team, not just the owning domain — to the moment it is fixed. A federated model should shorten this compared with a central queue, because the people who understand the data are the ones fixing it. If resolution time is not improving, the shared rules or the escalation path likely need attention before adding more domains.

Proportion of issues caught before they reach a report

This is the clearest signal that domain-level review is actually happening, rather than being a line in a policy document nobody follows. A domain that never catches its own issues before they surface downstream is not really running its review cadence, whatever the documentation says.

Central team’s time split

In a healthy federated model, the central team spends most of its time improving the shared rule set and arbitrating genuine cross-domain disputes — not processing routine requests that a domain could have handled itself. If the central team is still doing domain-level work, ownership has not actually moved, regardless of what the org chart says.

Common pitfalls

A handful of failure patterns recur often enough to be worth naming directly.

• Ownership without authority. Naming a domain owner who cannot actually change how their team works — because budget, priority or tooling decisions sit elsewhere — produces a title without the accountability it implies.
• Shared rules that grow without limit. Every exception, every edge case, every disagreement tends to get resolved by adding a new central rule. Over time the “small shared rule set” becomes as heavy as the centralised model it replaced.
• Review cadence that exists on paper only. A monthly review that nobody actually attends is worse than an honest quarterly one, because it creates false confidence that issues are being caught.
• An escalation path only the governance team knows about. If a domain has to ask “how do I raise this?” every time a dispute comes up, the path is not actually published — it just exists somewhere.
• Treating the model as finished. A federated model needs the same review discipline it applies to data: revisit the shared rules, the cadence and the escalation path periodically, using the same evidence-first approach described above.

None of these pitfalls are unique to data governance — they are the same failure modes that show up whenever an organisation tries to distribute a decision that used to be centralised. What is specific to data is how quickly the cost of getting it wrong compounds: a governance gap does not just slow one team down, it quietly degrades every report and decision that touches the affected data downstream.

Getting started

Organisations moving toward this model typically follow a similar sequence:

• Name a domain owner and a data steward for each domain that does not already have one.
• Agree the shared rule set — keep it to the four items above until it proves insufficient.
• Publish one escalation path and socialise it with every domain, not just the governance team.
• Set a review cadence and start with a shorter, more frequent cycle rather than a long annual one.
• Revisit the shared rule set after two or three cycles, adding to it only where a real gap showed up.