What Is a Data Governance Operating Model?

A data governance operating model is the arrangement of people, bodies, and decision rights that makes data governance run: who sets policy, who decides inside each domain, who does the hands-on work, how disagreements are escalated, and how often each group meets. If a data governance framework is the list of components a program needs, the operating model is the wiring diagram that says where authority actually sits.

Most governance programs that stall do not fail on policy content. They fail on the operating model. Nobody is sure whether a domain can define its own metrics, the council meets but cannot force a decision, and every cross-team dispute escalates to an executive who has no time for it. Getting the operating model right is what turns a set of good intentions into decisions that get made, recorded, and followed.

Operating Model Defined

An operating model answers four questions about governance, and a program is only as clear as its weakest answer:

• Where does authority sit? Which decisions are made centrally, which are delegated to domains, and which need both.
• Which bodies exist? The sponsor, council, domain groups, and working teams, with their membership and mandate.
• Who does what? Role-level accountability for each recurring governance decision, usually written as a RACI matrix.
• How does it run? Meeting cadence, escalation paths, how decisions are recorded, and which metrics show the model is working.

DAMA-DMBOK treats this as part of the data governance function itself: the organization's structure for exercising authority over how data is managed. The operating model is also the part of governance that changes most over time. Programs often start centralized to build consistency, then federate as domains mature and the central team becomes a bottleneck.

The Three Models

There are many variants in practice, but almost all of them sit somewhere on one spectrum, from fully centralized to fully decentralized.

Centralized

A single central team, usually under a chief data officer, owns governance decisions for the whole organization: definitions, standards, quality thresholds, and access rules. Domains follow.

• Strengths: consistency, one place to ask, fast to stand up, easy for regulators to understand.
• Weaknesses: the central team becomes a bottleneck, sits far from the business meaning of the data, and struggles to scale beyond a few domains.
• Fits: smaller organizations, early-stage programs, and highly regulated environments where uniformity matters more than speed.

Decentralized

Each business unit or domain governs its own data with little central coordination. Domains define their own terms, standards, and access rules.

• Strengths: decisions are close to the people who understand the data, and domains move at their own pace.
• Weaknesses: definitions drift apart, cross-domain reporting becomes a reconciliation exercise, and nobody owns the enterprise view.
• Fits: holding structures with largely independent businesses that rarely share data.

Federated

A central governance function sets the shared rules, common vocabulary, and platform, while domains own and govern their data within those guardrails. It is the most common choice for larger organizations, and the governance model behind data mesh.

• Strengths: local ownership with enterprise consistency on the things that must be shared, such as core definitions, classification, and access policy.
• Weaknesses: needs a clear line between central and domain decisions, and capable domain owners and stewards to make it work.
• Fits: mid-size and large enterprises with several data-producing domains and shared reporting or AI needs.

Governance Bodies

Whatever the shape, most operating models are built from the same set of bodies and roles. Names vary by organization; the functions do not.

• Executive sponsor. A senior leader, often the chief data officer, CFO, or COO, who gives the program its mandate and budget and is the final escalation point. Without one, the council has no authority to enforce anything.
• Data governance council. A cross-functional body of domain owners plus representatives from IT, security, legal, and risk. It approves enterprise policies and shared definitions, prioritizes work, and settles disputes between domains. It should decide, not just discuss.
• Central governance office. A small team that runs the program day to day: maintains policies and standards, coordinates stewards, tracks metrics, and prepares council decisions. In a centralized model this team holds most of the authority; in a federated model it facilitates.
• Domain owners. Business leaders accountable for the data in their domain, such as finance, customer, or product. The full role is described under data ownership.
• Data stewards. Domain experts who carry out the owner's decisions: maintain definitions, monitor quality, review access requests. See data stewardship for the role in detail.
• Data custodians. IT and platform roles that implement controls in the systems: permissions, encryption, retention jobs, and pipeline fixes.
• Working groups. Time-boxed teams for a specific topic, such as a classification scheme or a data quality standard for one critical dataset.

Decision Rights & RACI

Bodies and roles do not govern anything until each recurring decision has an owner. The standard tool is a RACI matrix, which assigns every decision four kinds of involvement:

• R - Responsible: does the work.
• A - Accountable: makes the final call and answers for the outcome. Exactly one per decision.
• C - Consulted: gives input before the decision.
• I - Informed: is told after the decision.

The value of a RACI is less in the letters than in the arguments it forces early. Writing down that the finance owner, not the BI team, is accountable for the definition of "net revenue" settles a conflict before it shows up in a board report. The example below shows a typical federated split for six recurring decisions.

Two rules keep a RACI useful. First, there is exactly one A per decision; two accountable parties means nobody is. Second, the matrix should cover decisions that actually recur. Six to fifteen well-chosen rows that people use beat a hundred rows that nobody opens.

Choosing a Model

No model is correct in the abstract. The right one is the model that matches how your organization already makes decisions, with adjustments where that culture is getting in the way of data.

• Look at how the business is run. If budgets and P&L sit in strong business units, a centralized data model will be resisted. If the company is run as one integrated operation, a decentralized model will feel like chaos.
• Look at what must be shared. The more your reporting, regulatory filings, and AI use cases depend on data crossing domains, the more you need central control over shared definitions and classification.
• Look at domain maturity. Federation only works where domains have people able to take ownership. It is common to centralize first, prove the approach on one or two domains, then delegate as owners and stewards are in place.
• Look at regulatory exposure. Supervisors expect clear accountability. Regulations such as BCBS 239 in banking or the GDPR accountability principle push towards named owners and documented decisions, whatever the shape.

Write down explicitly which decisions are central and which are delegated. A common federated split keeps enterprise policies, shared business definitions, classification levels, and the platform central, and delegates domain-specific definitions, quality thresholds, and access approvals to domain owners.

Running It

An operating model is only real once it has a rhythm. The mechanics that make the difference are unglamorous:

• Cadence. The council meets on a fixed schedule, often monthly or quarterly, with a decision agenda prepared by the governance office. Stewards work continuously; domain groups meet as often as their backlog needs.
• Escalation path. A defined route from steward to owner to council to sponsor, with time limits, so an unresolved issue cannot sit for months.
• Decision log. Every ruling is recorded with who decided, when, and why, next to the asset or term it affects. The log is what stops the same question being reopened by the next team.
• Metrics. A short list that shows whether the model works: percentage of critical assets with a named owner, time to resolve an issue, number of definitions approved, policy exceptions open.
• Onboarding. New owners and stewards get a clear description of their decision rights. Most role confusion comes from people never being told what they are allowed to decide.

How Dawiso Supports It

An operating model fails quietly when it lives only in a slide deck. Dawiso makes it visible in the place where people work with data, so the roles and decision rights travel with the assets.

• Roles on real assets. Ownership and stewardship are assigned directly on tables, reports, and glossary terms in the data catalog, so anyone can see who decides about a given asset.
• Decisions as workflows. Configurable workflows move terms and assets through states such as draft, review, and approved, with the approval step assigned to the accountable role. The workflow is the RACI, executed.
• Automation for follow-up. Automation rules can change workflow states and send notifications when something needs a decision, so escalation does not depend on someone remembering.
• Context for the council. The business glossary and lineage show what a definition or change will affect, so cross-domain disputes are decided with the impact in view.

Whether you run centralized, federated, or decentralized, the same platform can reflect the split of decisions you choose and grow with it as domains take on more ownership.

Conclusion

A data governance operating model is the answer to "who decides what about our data, and how?" Centralized, decentralized, and federated models are points on one spectrum, and most larger organizations end up federated: shared rules at the center, ownership in the domains. The shape matters less than the clarity. Name the bodies, give each recurring decision exactly one accountable role, set a cadence and an escalation path, and record decisions where the data lives. That is what makes governance something an organization does rather than something it has.

Sources

• DAMA International - DAMA Data Management Body of Knowledge (DAMA-DMBOK)
• DAMA International - The 2024 Revision of the DAMA-DMBOK 2.0 (reframes the data governance program as a data governance function)
• EDM Council - DCAM: Data Management Capability Assessment Model
• GDPR - Article 5: Principles relating to processing of personal data (accountability)