Kindly fill up the following to try out our sandbox experience. We will get back to you at the earliest.
How to structure a data governance model: centralized, federated or hybrid, the four bodies it needs, what each one decides, and how an issue escalates.
Updated on
A data governance model is the operating structure that says who makes each governance decision, who carries it out, who checks the result independently, and who answers for it when a reported number is wrong. It is not the same thing as a governance framework. The framework is the rulebook: the policies, standards, definitions and controls. The model is the organization design that keeps the rulebook enforced when two teams disagree. Most programs write a good framework and never build the model, which is why the policies exist and nothing changes. If you want the underlying concepts first, our guide to data governance concepts covers the definitions this article assumes.
Three shapes are in general use. A centralized model puts decision rights in one team, usually a governance office reporting to a chief data officer. A decentralized model pushes them into the business units, with the center offering guidance rather than authority. A federated or hybrid model splits them: the center sets the standards, the domains apply them. Choosing between the three is practice 2 below. Before that comes the harder step, which almost every organization skips: naming the bodies. If you are building the case for the model in the first place, the argument for data quality and governance together is a better starting document than a model diagram.
The most useful list of governance bodies in print was not written by a vendor. Section 3.3 of the European Central Bank Guide on effective risk data aggregation and risk reporting, published in May 2024, sets out the minimum elements a supervised bank has to have in place for its data governance framework to work. There are four of them, and although the guide is written for European banks, the structure transfers to any organization that publishes numbers somebody else relies on.
The four are data owners inside the business, a central data governance function, a validation function sitting in the second line of defense and independent of the units it reviews, and an internal audit function as the third line. The table below gives each one its membership, the decisions it can take alone, the decision it has to pass upward, and what stops working when the organization never creates it. The last column is the one to read first, because it describes the failure most governance programs are living with right now.
| Body | Who sits in it | What it decides alone | What it escalates | What breaks if it does not exist |
|---|---|---|---|---|
| Data owners | A named individual per key indicator and per critical data element, sitting in the business function that produces the data, not in IT and not in the governance team. | The definition of a data quality control on their own data, in agreement with the people who consume it. Which values are acceptable. Whether a specific issue has been remediated. | Any issue above the agreed materiality threshold, and any definition dispute with another domain. | Remediation has no address. An issue is found, logged, and then sits because no single person is answerable for the field. This is the most common missing body and the easiest to fix. |
| Central data governance function | A small permanent team, typically reporting to a chief data officer or an equivalent, with policy, metadata and data quality skills rather than delivery engineers. | The policies and processes for data quality management. The classification scheme. The contents of the definition register. Whether a proposed change to a shared definition is accepted. | Anything requiring budget or a change to the framework itself, and any dispute two domains could not settle. | Change happens to the estate without a governance view of it. The ECB names the cases explicitly: mergers and acquisitions of material entities, outsourcing to third parties, new product launches, new tool launches, upgrades of existing tools and other IT change initiatives. Each one silently reshapes what the model was written for. |
| Independent validation, second line | People with data, IT and reporting skills who do not report to the units that build the pipelines or run the governance program. Where they have to sit inside the same function, the ECB expects documented segregation of duties. | Whether the governance processes are working as intended. The scope and timing of its own assessments. | Its findings, directly to the management body rather than through the teams it assessed. | The people who built the process are the people assuring it. That is the conflict of interest the ECB names by name, and it is why a program can report green for two years and still fail an inspection. |
| Internal audit, third line | The existing internal audit function, accountable to the board or audit committee rather than to management. | Its own audit plan, coverage and timing, free of interference. | Its opinion to the governing body, with unrestricted access to the people and data it needs. | The validation function is never itself tested. Nobody is checking the checker, so a weak second line looks identical to a strong one from the outside. |
Above all four sits the accountable body itself, and this is where most models are vaguest. BCBS 239, the Basel Committee paper of January 2013 that started the modern discipline, is direct about it in paragraph 28:
A bank’s board and senior management should review and approve the bank’s group risk data aggregation and risk reporting framework and ensure that adequate resources are deployed.
Approval by a working group is not the arrangement either document describes. The ECB goes one step further and asks for a name. Among the eight things it lists as the management body's own responsibility is:
Selecting one or two members of the management body in its management function to exercise responsibility for implementing the data governance framework. This does not, however, in any way discharge the management body from its overall accountability and responsibility for the data governance framework of the institution.
A footnote to that sentence adds the practical version: appointing the chief risk officer, or the chief risk officer together with the chief financial officer, is described as a pragmatic solution, and the ECB says it observed that naming one or two specific people is what makes sufficient attention get paid at that level. If you take one thing from this section into your next steering meeting, take that. A model with a named executive owner behaves differently from a model owned by a committee. Our piece on what data governance leaders actually do covers what that person spends their week on.
Those components are the work the bodies divide between them, and there are six: stewardship, policies, integrity management, lineage, roles and responsibilities, and tooling. They map cleanly onto the four bodies. Stewardship and data integrity management belong to the data owners. Policies, roles and the classification scheme belong to the central function. Lineage belongs to both, because the ECB puts metadata for data lineage and the data dictionary inside the data owner's duties while the central function owns the standard it is recorded against. Tooling is the last decision, not the first. For the day to day mechanics of the ownership layer, see our guide to data stewardship.
One more thing belongs in this section because it removes an argument later. BCBS 239 paragraph 37 makes a dictionary of concepts a precondition rather than an outcome: data has to be defined consistently across the organization before the rest of the model can mean anything. Paragraph 36 asks the same of sources, saying an institution should strive towards a single authoritative source for risk data of each type. A model that has not settled definitions and sources is going to spend its meetings settling them one incident at a time. Metadata is where both of those live, and our guide to metadata governance covers how the register is maintained.
The three shapes get explained the same way everywhere: centralized is consistent but slow, decentralized is fast but inconsistent, federated is the sensible middle. That is true and it is useless, because it gives the reader no way to decide. Here is a test that does.
The shape follows the reporting obligation, not the headcount. Ask where the obligation to be right actually sits. If one legal entity signs one set of returns and one board carries the consequence, decision rights concentrate and a centralized model fits, because the people who sign want one definition and one source. If several domains each produce an output that leaves the building under a different obligation, a different regulator or a different customer promise, then execution has to sit with those domains and only the standards stay central. Company size is the wrong input to this decision. A 400 person fintech with one banking license is more centralized than a 40,000 person group with eleven of them.
The second half of the test is a boundary, and it is short enough to repeat in a meeting: the center owns the words, the domains own the numbers. Definitions, classifications, policies, the escalation path and the register of agreed terms are set once for everybody. Values, tests, thresholds and remediation happen where the data is produced, by the people who understand what it means. When somebody argues that a domain should be allowed to define its own version of active customer, that is a request to own a word, and the answer is no. When somebody argues that the central team should approve every test threshold, that is a request to own the numbers, and the answer is also no.
| Dimension | Centralized | Federated or hybrid | Decentralized |
|---|---|---|---|
| Best fit | One legal entity, one set of external obligations, or an organization in its first two years of governance work. | Several domains, each with its own output leaving the building under its own obligation. | Loosely coupled business units with genuinely separate estates and no shared reporting. |
| Who writes policy | The central governance office. | The central governance office, once, for everybody. | Each unit, which is why definitions drift. |
| Who owns definitions | The central office, in one register. | The central office holds the register; domains propose changes and the center approves them. | Each unit, so the same word means different things in two reports. |
| Who runs tests and fixes issues | A central data quality team, which becomes the bottleneck. | The domain that produces the data, against thresholds it sets and documents. | The domain, with nobody checking the thresholds are sensible. |
| Escalation path | Short. Issue goes to the central team, then to the executive owner. | Two steps. Domain owner first, then the central function, then the executive owner if it crosses the materiality threshold. | Usually undefined, which is the reason this shape fails audits. |
| The failure mode to watch | The center becomes a queue and the business routes around it. | The center quietly stops enforcing and the model becomes decentralized without anyone deciding to. | Nobody can answer a regulator's question about a number without a project. |
Whichever shape you pick, the rollout order is the same and it has not changed: agree the shape with the people who will live inside it, start on one domain rather than all of them, write a roadmap with dates and named owners against each step, train the people who will hold the roles, stand up the council with representatives from each domain, and only then choose the tooling. Running that order backwards, which is what happens when a platform is bought first, produces a well configured tool nobody has authority to use. Our article on governance in a modern data stack covers what the tooling layer has to support once the model exists.
Two numbers are worth knowing about tooling, and both come with a caveat. Decube's own comparison pages assess a Collibra deployment at three to nine months and an Alation deployment at two to four, with Collibra typically requiring a dedicated governance team and professional services. Those are Decube's own assessments rather than independent research, and they are named here as such. What matters for the shape decision is the implication: a platform that needs a dedicated team to run it pushes you towards a centralized model whether you chose one or not, because only the central team will ever know how to operate it. Collibra (collibra.com), Alation (alation.com) and Atlan (atlan.com) are all serious products, and Collibra in particular is the most mature enterprise governance platform on the market. The question is not which is best in the abstract but which one matches the model you have decided to run. Our list of data governance tools works through the options in detail.
If your estate is mostly cloud, the same shape decision applies one layer down to infrastructure and access, and our piece on the cloud governance model covers that boundary. If your problem is reference data rather than analytics data, master data governance is a different discipline with different owners.
Every governance model works until two people disagree. The moment a domain says its number is right and the central team says the definition is wrong, the model either has a route for that argument or it does not, and if it does not, the argument is settled by whoever is more senior or more persistent. That is the point at which a governance program starts to be described as bureaucratic, and it is the most common reason adoption fails.
The fix is to write the path down before you need it, and the most specific published version of that path is in section 3.5 of the ECB guide. It asks for a register of data quality issues and limitations carrying six things: an assessment of the severity of each issue, a root cause analysis, a quantitative impact analysis of material errors on the risk and business areas affected, clearly defined processes and responsibilities for remediating and escalating issues depending on materiality, a deadline for remediation, and a date of effective remediation with evidence attached. Six fields. That specification works in any industry, and if your issue tracker carries fewer than six of them, you know which ones to add on Monday.
The word doing the work in that list is materiality. Escalation is not a judgment call made in the moment, it is a threshold agreed in advance and applied mechanically. Write the number down: an issue affecting a figure that leaves the building goes to the executive owner within one working day, an issue contained inside a domain is that domain's to schedule, and a definition dispute between two domains goes to the central function within a week whether or not anybody is upset about it. The precise numbers matter less than having them fixed before the first argument, because a threshold agreed afterwards always looks like it was chosen to suit somebody.
The most frequent dispute is not about a value at all, it is about a word. Two domains use the same term for different things, both are internally consistent, and both reports are correct until somebody puts them side by side. This is why the definition register is the artifact a governance body argues from rather than a nice to have. The short walkthrough below shows what one looks like in practice: a hierarchy of glossaries, categories and terms, with a data owner and a business owner named on each glossary so the escalation has somebody to escalate to, custom attributes recording calculation logic and reporting cadence, and the assets that use each term linked to it.
Six things reliably stop a model being adopted, and each has a structural answer rather than a motivational one. They are worth naming plainly, because the usual advice for all six is to communicate better, which is not a fix.
The last of those is not hypothetical. In Decube's published case study, a Nasdaq listed regional bank was tracing lineage across Spark, Azure Synapse, ADLS, Azure Data Factory and Power BI by hand every time a question came up, and handling quality incidents ad hoc with no structured way to triage them, assign ownership or track resolution. That is the shape of a missing body rather than a missing tool. A Latin American fintech in the same set was spending close to 336 hours a month mapping lineage manually across more than 20 source systems, with analysts spending another 40 or more hours a month tracing SQL logic by hand to answer routine access requests from product, compliance and audit.
Independence is the last piece of the path, and it is the piece organizations quietly drop. BCBS 239 requires validation of the reporting process to be independent, and a footnote adds that it should be conducted separately from audit work so the distinction between the second and third lines is preserved. The Institute of Internal Auditors puts the same principle in plainer language in its Three Lines Model of July 2020:
Internal audit’s independence from the responsibilities of management is critical to its objectivity, authority, and credibility. It is established through accountability to the governing body; unfettered access to people, resources, and data needed to complete its work; and freedom from bias or interference in the planning and delivery of audit services.
One caution about that model, from its own footnotes: the three lines are roles, not boxes on an org chart, and they operate at the same time rather than in sequence. First and second line roles can be blended or separated depending on the organization. Plenty of governance programs have wasted a quarter drawing three columns and assigning departments to them, when the question was only ever whether the person assuring the work is the same person who did it.
A governance model that reports on itself gets ignored. A governance model that reports inside something the board already reads gets acted on. The ECB is specific about this: it expects data quality indicators to be defined and measured against accuracy, integrity, completeness and timeliness, with tolerance levels and documented processes for what happens when a tolerance is breached, and it expects those indicators to be communicated to the management body periodically alongside an analysis of what the current data quality means for the accuracy of risk measurement. Not a governance dashboard. An input to the risk report.
That reframes what to measure. The question is not how the governance program is doing, it is how much confidence the numbers deserve. The six indicators below each carry the threshold that should trigger an escalation rather than a note in the minutes.
| Indicator | What it measures | Threshold that triggers an escalation | Where the number comes from |
|---|---|---|---|
| Data quality by dimension | Accuracy, integrity, completeness and timeliness on each critical element, measured where the data is produced. | Any tolerance breach on an element that feeds a figure leaving the building, reported the same day. | Automated tests on the source systems, not a manual sample. |
| Compliance coverage | The proportion of critical elements with a named owner, an agreed definition and an active test. | Below 100 percent on anything in scope for an external report, at every review. | The definition register cross referenced against the test inventory. |
| Adoption | Whether the people who hold governance roles are actually using the process: definitions being proposed, issues being logged, changes going through approval. | A domain logging no issues for a full quarter, which usually means it is not looking rather than that it is clean. | The governance platform's own activity record. |
| Time to resolution | How long an issue takes from detection to a date of effective remediation with evidence, the sixth field the ECB expects on the register. | Any issue above the materiality threshold open past its committed deadline. | The issue register, which is why the register needs a deadline field. |
| Stakeholder confidence | Whether the people consuming the numbers believe them, gathered as a short structured question rather than a survey. | Any consuming team maintaining its own shadow version of a governed figure. | Ask the consumers directly, once a quarter, and count the shadow copies. |
| Manual effort removed | Hours a month spent tracing lineage, reconciling figures or answering access requests by hand. | No reduction across two consecutive quarters, which means the model is adding process without removing work. | Time recorded by the teams doing it, before and after. |
Two of those deserve a note. Adoption is the one people measure badly, because a login count says nothing. What tells you the model is alive is whether definitions get proposed by people outside the governance team, and whether a domain logs issues against its own data without being asked. And manual effort removed is the indicator that keeps the program funded, because it is the only one on the list that a chief financial officer already understands.
On cadence, the ECB guide points at its own guidance on internal capital adequacy, which expects reporting of outcomes to the management body at least quarterly and more often where the figures move faster. Quarterly is a reasonable minimum for a governance review in most organizations. What should not be quarterly is escalation: the register runs continuously and an issue above the threshold goes up when it is found, not when the calendar says so.
Tooling is the last decision in this article for a reason, but the model does eventually have to run somewhere. What a governance model needs from a platform is narrow: a place to hold the agreed definitions with an owner on each one, a way to classify data consistently without a human tagging every column, a record of where a number came from that survives an audit question, and an approval step so that a change to any of those leaves a trail. Decube's data governance module covers those four. Classification and tagging are policy driven, with automatic classification of personal data, role based access, group management and approval workflows on changes.
The business glossary is the register the second and third practices above depend on: terms organized into glossaries and categories, a data owner and a business owner named on each one, custom attributes for calculation logic, and the assets that use a term linked to it. On the lineage side, Decube records column level lineage across systems and puts a structured approval flow on changes to it, which is unusual: most catalogs treat lineage as a picture rather than as something governed. Decube's lineage is the layer the ECB's "front to end" expectation actually maps onto, and it is what removed the manual tracing in the two case studies above.
The other thing a governance model needs from a vendor is predictability, because a model that costs more every time it covers another domain gets frozen at its first domain. Decube publishes its pricing: Starter at 175 US dollars per user per month, from 21,000 a year with a minimum of 10 users, and Growth at 225 US dollars per user per month, from 54,000 a year with a minimum of 20 users. Single sign on and role based access are included on every plan rather than sold as a governance add on. Deployment is software as a service and does not require a professional services engagement, which matters most to the organizations running a federated model with a small central team. An Australian financial institution in the published case studies came to it as a consolidation problem rather than a greenfield one, replacing a legacy governance tool whose lineage could not reliably trace data across its stack.
Whatever you use, keep the boundary from practice 2 in mind while you evaluate: the tool holds the words and the evidence, the domains still own the numbers. A platform decision cannot substitute for naming the four bodies, and the two Decube case studies above are both stories of an organization that had the ownership question answered first. If you want to see how the pieces fit against your own estate, book a walkthrough.
A data governance model succeeds or fails on whether the decision rights inside it are named. Frameworks, policies and platforms are all downstream of that. The organizations that get stuck are almost never the ones with a bad policy document; they are the ones where nobody can say who is allowed to settle a definition argument, or who has to be told when a number that leaves the building turns out to be wrong.
If you are starting from nothing, the sequence is short. Name the executive who is accountable, one or two people, not a committee. Name a data owner for every element that feeds a figure leaving the building. Stand up the central function, however small, and put it in the room for every merger, outsourcing decision, product launch, tool purchase and tool upgrade. Decide the materiality threshold that sends an issue upward, and write it down while nobody is angry. Confirm that whoever assures the work is not the person who did it. Then pick the shape, then pick the tool.
The reason to do this is practical rather than regulatory. Once the bodies exist and the threshold is written down, arguments stop being about who is right and start being about what the register says, which is the difference between a governance program people route around and one they use.
A data governance model is the operating structure that says who makes each governance decision, who carries it out, who checks the result independently, and who is accountable when a reported number is wrong. It is different from a data governance framework, which is the set of policies, standards, definitions and controls. The framework is the rulebook and the model is the organization design that keeps the rulebook enforced when two teams disagree. Most programs write the framework and never build the model, which is why the policies exist and nothing changes.
A centralized model puts decision rights in one team, usually a governance office reporting to a chief data officer, which gives consistency at the cost of becoming a queue. A decentralized model pushes decision rights into the business units, which is fast but lets definitions drift until the same word means different things in two reports. A federated or hybrid model splits them: the center owns the words, meaning definitions, classifications, policies and the escalation path, and the domains own the numbers, meaning values, tests, thresholds and remediation. The main risk in a federated model is that the center quietly stops enforcing and the model becomes decentralized without anybody deciding to.
Choose by where the reporting obligation sits, not by headcount. If one legal entity signs one set of returns and one board carries the consequence, decision rights concentrate and a centralized model fits, because the people who sign want one definition and one authoritative source. If several domains each produce an output that leaves the building under a different obligation, a different regulator or a different customer promise, execution has to sit with those domains and only the standards stay central. A 400 person fintech with one banking license is more centralized than a 40,000 person group with eleven of them.
The European Central Bank Guide on effective risk data aggregation and risk reporting of May 2024 names four bodies in section 3.3. Data owners sit in the business function that produces the data and decide the quality controls and acceptable values on their own elements. A central data governance function issues the policies, owns the classification scheme and the definition register, and takes part in change management for mergers, outsourcing, new products, new tools and tool upgrades. An independent validation function in the second line of defense decides whether the processes are working as intended and reports directly to the management body. Internal audit forms the third line and reviews the validation function itself. Above all four, the ECB expects the management body to approve the framework and to select one or two of its own members to be responsible for implementing it.
Adoption fails at the moment two people disagree and the model has no route for the argument, so it gets settled by whoever is more senior or more persistent. The second cause is a review step that adds days with no published service level, which teaches the business to route around the governance body. The third is a model with no named owner for a given element, so an issue is found, logged and then sits because nobody is answerable for the field. The structural fixes are to write the escalation path and its materiality threshold down before the first dispute, to publish the number of days the central function commits to for each kind of request, and to name a person rather than a committee against every critical element.
Data governance decides who owns, defines, quality checks and can access the data itself. AI governance decides which systems may be built on that data, how models are approved before release, what has to be disclosed to the people affected, and who is accountable for an automated decision. They share the same underlying evidence, which is lineage, classification and quality history, and in most organizations they should share the same escalation path and the same accountable executive. What they do not share is the decision. An AI governance body reviewing a model needs the data governance model to already be able to answer where the training data came from, who owns it, and what its quality record looks like. If those answers do not exist, AI governance is a review with nothing to review.
Four things, and they are the same four a regulated report needs. A register of agreed definitions with a named owner on each term, so the agent and the humans mean the same thing by the same word. Classification applied consistently and automatically, so the agent cannot reach data it should not see and access is governed by role rather than by hope. Column level lineage that survives an audit question, so an answer the agent produces can be traced back to its source. And active quality tests with agreed tolerances on every element the agent reads, because an agent has no way to notice that a value looks wrong. If any of the four is missing, the honest position is that the agent can be built but its output cannot be relied on for anything that leaves the building.
Match the platform to the model rather than to the industry label. A healthcare organization usually has several domains, clinical, claims, operational and research, each answering to a different obligation, which points at a federated model, and a federated model needs a platform a small central team can run without a professional services engagement. The specific things to test are automatic classification of personal and health data rather than manual tagging, role based access with approval workflows on changes, column level lineage that can answer where a reported figure came from, and quality tests with tolerances on the elements that feed external reporting. Ask any vendor for the exact list of source systems its quality engine monitors, not the list its catalog can read, because those two lists are rarely the same length.
Measure the confidence the numbers deserve, not the activity of the governance program, and report it inside something the board already reads rather than on a separate dashboard. Six indicators cover it: data quality by dimension on each critical element, the proportion of critical elements with an owner, a definition and an active test, whether people outside the governance team are proposing definitions and logging issues, time from detection to a date of effective remediation with evidence, whether any consuming team is maintaining a shadow version of a governed figure, and hours a month of manual lineage tracing and reconciliation removed. Each one needs a threshold that triggers an escalation rather than a note in the minutes.
The framework is what is governed and by which rules: the policies, standards, definitions, classifications and controls. The model is who governs: the bodies, their membership, the decisions each can take alone, the decisions each has to pass upward, and the accountable executive above them. A framework without a model produces a policy library nobody enforces. A model without a framework produces meetings with nothing to decide. Regulators ask for both: BCBS 239 requires the board and senior management to review and approve the framework and to deploy adequate resources, which is a statement about the model.
First step to AI Readiness
Table of Contents
Sneak peek from the data world.
Bring lineage, quality, governance, and AI together in one platform—so your teams and AI agents can act with confidence.
_For%20light%20backgrounds.svg)
.svg){kind=small}
.webp)