Data governance operating model
Definition
Data governance operating model
A data governance operating model is the organisation design that puts data rules into practice. It names the roles, councils, decision rights and funding that turn a written framework into daily behaviour. It answers who governs, rather than what the rules say.
The framework and the operating model are a pair. The framework says a customer record must be 98 percent accurate; the operating model says which domain owner is accountable when it is not, and who they escalate to.
Most models fail on decision rights rather than on effort. People attend, nobody owns the final word on a definition, and the same argument comes back every quarter.
Key takeaways
- An operating model names who governs: roles, councils, decision rights, funding and escalation routes.
- The framework holds the rules, while the operating model supplies the people and forums that apply them.
- Federated designs suit large groups; a central team suits a single market business.
- Outsourced delivery means the model has to reach across the contract boundary into supplier teams.
How it works
A data governance operating model works by assigning three things to named people: ownership of a data domain, authority to decide, and a route for escalation. A council then meets on a fixed cycle to clear what owners cannot settle alone.
| Model shape | Where decisions sit | Best fit | Common failure |
|---|---|---|---|
| Centralised | One corporate data office | Single market firms | Queues build, domains disengage |
| Federated | Domain owners, central standards | Large multi domain groups | Standards drift apart |
| Hybrid | Central policy, local execution | Groups after a merger | Veto rights left unclear |
| Provider run | Supplier operates, client decides | Lean internal teams | Accountability slides to the supplier |
Pick the shape before you pick the people. Moving from central to federated later means renegotiating every domain owner’s objectives, which is a year of work that nobody budgets for.
Escalation is the part that gets tested first. When two domain owners disagree on a definition, the model should already say who rules, by when, and what happens while the question stays open.
This is a slice of the wider business operating model, not a separate structure beside it. The reporting lines, funding cycle and committee calendar should be the ones your business already uses.
Decisions need a repeatable shape. Each recurring task, from onboarding a data source to retiring one, should end up as a standard operating procedure that a new joiner can follow without asking.
Shared service bodies make useful templates. An automation center of excellence already runs intake, prioritisation and a review board, and a data council can copy that mechanism instead of inventing one.
The model has to cross the contract boundary. Vendor management outsourcing teams hold the supplier reviews where quality breaches get raised, so give them a standing seat on the council.
Every vendor touching regulated data needs a named owner on your side — not a shared mailbox. Pin that name to the contract and to the council minutes.
Public bodies show how durable written authority can be. The US Office of Management and Budget issues standing circulars, among them Circular A-11 on preparing and executing the federal budget, a document running to about 940 pages.
Industry bodies sell the scaffolding. The EDM Council, a data management membership body, surrounds its DCAM framework with training, certification, assessments and benchmarks, which gives a new council a shared vocabulary to argue in.
Stand it up in this order:
- Name a domain owner for every major data set.
- Write down who decides and who is merely consulted.
- Set a monthly council with a published agenda.
- Agree an escalation route and a time limit on it.
- Fund the roles before you fund the tooling.
Minutes matter more than mandates. A council that records its decisions builds a precedent library, and the second year of governance then costs far less than the first.
Examples
Operating models differ by how many domains and markets you run. The shape follows the organisation chart far more closely than it follows the technology underneath it.
Federated banking group. A bank across several countries gives each domain an owner in the business, keeps standards central, and sends unresolved definitions to a named chief data officer each month.
Centralised retailer. A single market retailer with one data team keeps every decision inside that team, publishes a weekly change log, and reviews exceptions in the operations meeting it already holds.
Offshore shared services. A group with a services centre in Manila seats the provider’s data lead on the council as a non voting member — remediation then gets scoped where the decisions are actually made.
Insurer after a merger. A hybrid model keeps policy central while each legacy business runs its own execution, under a six month deadline to converge the definitions of customer and policy.
Related terms
- Strategic business unit: the division the model usually treats as a data domain with its own owner.
- Activity-based management: costs activities, which helps you fund governance work rather than hide it.
- Business operating model: the wider structure this sits inside, sharing its reporting lines and funding.
- Standard operating procedure: the written routine that each recurring governance decision turns into.
- Vendor management outsourcing: runs the supplier reviews where breaches of your data rules surface.
FAQ
What is the difference between a data governance framework and an operating model?
The framework is the rule set, covering policies, standards and thresholds. The operating model is the organisation design that applies those rules through roles, councils, decision rights and funding.
Who sits on a data governance council?
Domain data owners, a chair from the business, someone from risk or compliance, and a technical lead. Keep it small enough to reach decisions inside an hour. Rotate domain owners through it rather than inviting everyone to everything.
Should the model be centralised or federated?
Centralise when you run one market and one system estate. Federate when domains differ enough that a central team would simply become a queue.
How do you fund it?
Either through a central budget line or a charge against the domains that benefit. Naming the funding source early is what stops the model stalling after its first year. Treat year one as a project and everything after it as a running cost.
Can a provider run the operating model for you?
A partner can chair working groups, run profiling and prepare council papers. Final decision rights — the veto on a definition — should stay with your own domain owners.
Shortlist partners with data governance experience in the Outsource Accelerator directory before you redesign your council.
Independent
