Data Governance Model: How to Choose the Right Structure for Your Enterprise

Most enterprise data governance programs don’t fail because of the wrong tool. They fail because no one decided how governance would actually be organized before the tool went live. 

The Collibra instance gets configured, communities get created, workflows get designed – all based on assumptions that were never formally agreed on. Six months later, data stewards in different business units are applying different standards, metadata completion sits below 30%, and the CDO is explaining to the board why adoption is low despite a significant platform investment.

We call this the Model-First Gap: the space between buying a governance platform and deciding on the operating model that should have come first. It’s more common than most organizations admit – and it’s entirely avoidable.

This article covers what a data governance model actually is (and how it differs from a framework), the three primary models with their real trade-offs, how EU regulatory requirements constrain your choices, and – uniquely – what your model choice means for how Collibra gets configured in practice.

Key takeaways

• A data governance model defines the operating structure behind governance: who holds decision rights over data, who stewards it, and how governance policies are enforced across the organization.
• The three primary models – ccentralized, federated, and replicated – have different trade-offs that depend on your organizational structure and needs, not on abstract best practice.
• EU regulatory requirements (GDPR, DORA, BCBS 239) act as hard constraints on model choice in regulated industries – not soft considerations to weigh later.
• The replicated model has become the enterprise default for large, multi-domain organizations, but it requires more intentional Collibra architecture planning than either pure model.
• Your governance model directly shapes how Collibra is configured: community structure, workflow ownership, role hierarchy, and data catalog access controls all flow from this decision.
• The Model-First Gap is recoverable, but the cost – in refactoring, rework, and lost adoption momentum – grows significantly the longer it goes unaddressed.

What is a data governance model (and what it isn’t)

A data governance model is the operating structure that defines how governance decisions are made, who owns data, and how governance policies are enforced across the organization.

Notice what that definition doesn’t include: it doesn’t include the policies themselves, the tools used to enforce them, or the strategy that drives the program. Those belong to the data governance framework – the broader architecture of principles, processes, and controls within which the model operates. The model is specifically about organizational structure and decision authority.

This distinction matters practically. Two organizations can follow the same data governance framework, adopt the same governance policies, and use the same platform – and still have fundamentally different programs, because their governance models assign decision rights differently. One gives the central CDO office final say on all data definitions. The other distributes that authority to domain leads. The framework is the same; the operating model is not.

The model doesn’t describe what good data management looks like. It describes who is responsible for making it happen – and that’s the decision that determines whether governance lives or dies at implementation.

The three data governance models: centralized, federated, and replicated

Every organization that implements governance has to answer the same question: who decides? The three primary data governance models answer it differently.

In brief: centralized gives a single team authority over all data rules; replicated has each business unit run its own governance team under the same shared standards – like franchises using the same playbook; federated puts a central body in charge of strategy and definitions while business units execute locally, following common rules with local control.

Model	Decision authority	Stewardship	Best fit for
Centralized	Single governance function (CDO/council)	Central team of data stewards	Smaller organizations; heavily regulated industries requiring uniform standards
Federated	Domain leads / business unit owners	Local stewards per domain	Large, autonomous business units; organizations with distinct data cultures per division
Replicated	Central standards + local execution	Central policy owners + domain stewards	Large enterprises needing compliance uniformity with operational flexibility

Centralized data governance model

In a centralized data governance model, a single authority – typically the CDO or a central governance council – holds all significant decision rights. The central team defines data quality standards, controls the business glossary, approves data definitions, and manages the governance policies that apply across the entire organization.

This model works well when consistency is non-negotiable: financial institutions subject to BCBS 239, banks under FINMA requirements, or organizations early in their governance journey where establishing baseline standards organization-wide is the priority. Centralized governance eliminates inconsistent definitions and makes regulatory reporting straightforward – the same data means the same thing in every report.

The cost is responsiveness. When every data definition changes, every access request, every quality standard update runs through a central team, business units wait. If the central governance team is small relative to the organization’s data volume, the backlog becomes a chronic problem and business units start working around governance rather than through it.

It is worth noting that a centralized model carries a risk that the data management role becomes separated from core business processes, leading to domain knowledge being lost over time. 

Federated data governance model

In a federated data governance model, one central Data Governance body sets the overall strategy and shared definitions – while individual business units or domains execute governance to fit their local needs. It is a model of common rules, local control: domain leads hold decision rights over their data assets, local data stewards manage day-to-day quality within those domains, and each domain governs its data independently under a shared set of enterprise standards.

The federated model gives domains the autonomy to govern data at the pace and with the depth their specific context requires. A finance domain can enforce strict data quality standards for financial reporting. A marketing domain can iterate quickly on campaign data definitions. Neither needs to wait for central approval.

What the federated model requires – and where it often fails without explicit design – is that shared standards are actually shared. If each domain defines “customer” differently, the federated model doesn’t produce flexibility: it produces data silos that make cross-domain analytics unreliable. The enterprise standards layer must be both meaningful and enforced, or the federated model becomes fragmentation with governance branding.

Replicated model: the enterprise default

The replicated model has each business unit run its own Data Governance team – all following the same shared standards and model. Think of it as a franchise structure: the central governance function defines the playbook, and each domain adopts and applies it independently, without relying on constant central coordination. The enterprise-wide standards for critical concepts – what “customer lifetime value” means, what data quality thresholds apply to critical data elements – are defined once and replicated across every domain.

For large enterprises with multiple business units, distinct regulatory footprints across jurisdictions, or significant variation in data maturity across domains, the replicated model is typically the only realistic option. It accommodates organizational complexity without sacrificing the audit trail and policy consistency that regulated industries require.

The challenge is that the replicated model has the highest implementation complexity of the three. The boundary between “central standard” and “local discretion” must be explicitly designed – if it’s left ambiguous, every governance decision becomes a negotiation between the center and the domains, and the program stalls.

DMBOK2 also refers to it as potentially the only model that can work for large enterprises, but recommends evolving the model over time rather than selecting a default. 

How EU regulatory requirements shape your model choice

In the EU context, the choice of governance model is not purely an organizational design question. Regulatory frameworks impose specific accountability requirements that constrain which models are defensible.

1. GDPR requires a designated Data Protection Officer (Article 37) with direct accountability to the highest management level and clear visibility into how personal data is processed across the entire organization. Full decentralization – where each business unit governs personal data independently without central visibility – creates an accountability gap that is difficult to defend in a GDPR audit. The DPO needs a centralized view; the model must provide it.
2. DORA (Digital Operational Resilience Act), applicable to financial entities in the EU from January 2025, requires documented and auditable ICT risk management processes. Data lineage and data quality evidence are part of that documentation. A purely federated model where each domain maintains its own lineage records separately creates fragmentation that makes DORA compliance significantly harder to demonstrate under audit.
3. BCBS 239 (risk data aggregation for systemically important banks) explicitly requires that risk data be aggregated at the enterprise level with consistent definitions, validated quality, and clear governance ownership. A fully decentralized data governance model – where each risk domain defines and governs its own data independently – makes BCBS 239 compliance structurally difficult. The standard was designed to prevent exactly the inconsistencies that emerge from siloed data governance.

The practical implication for regulated EU enterprises: a purely decentralized model is rarely defensible. The question is not whether to have centralized oversight of certain data categories – sensitive data, financial risk data, personal data – but how to structure the balance between central accountability and operational flexibility. This is why the replicated model has become the default in banking, insurance, energy, and pharmaceuticals across Europe.

We’ve implemented governance models for organizations navigating exactly these regulatory constraints – including a Swiss private bank that needed FINMA-compliant governance for Sensitive Critical Data Elements across more than 100 applications. The regulatory requirement for centralized data ownership was not optional; the governance model had to accommodate it from day one.

How your governance model shapes your Collibra implementation

This is the gap that no one discusses – and it’s the most operationally consequential piece of the model decision.

Collibra’s architecture is built around communities, domains, and assets. How those communities are structured, who owns which Collibra workflows, and how the data catalog reflects accountability – all of this flows directly from the governance model. And once it’s built, restructuring it is expensive.

If you implement a centralized data governance model in Collibra:

• You will typically create a single, enterprise-wide community structure managed by the central governance team.
• Workflows for approvals, data quality reviews, and definition changes are owned centrally.
• Data stewards are a central function, not embedded in business units.
• The data catalog reflects a single organizational view of data assets, with central certification.

If you implement a federated data governance model in Collibra:

• You create multiple communities – one per domain or business unit – each with its own local stewards and governance workflows.
• Central shared assets (master data definitions, critical data elements, business glossary terms) live in a shared community accessible to all domains.
• Local stewards have write permissions in their domain; cross-domain definitions require central approval.
• The data catalog has multiple “entry points” reflecting domain ownership.

If you implement a replicated model in Collibra:

• You build a hierarchical community structure: a parent community for enterprise-level governance, child communities per domain.
• Central governance policies are configured as templates that domain communities inherit and customize within defined bounds.
• The data catalog distinguishes between enterprise-certified assets (central ownership) and domain-managed assets (local ownership).
• Role hierarchy in Collibra explicitly maps to the governance org chart – central roles have cross-domain permissions, domain roles are scoped.

The Model-First Gap becomes a Collibra problem when an organization starts building communities and workflows before the governance model is decided. We’ve seen implementations where the Collibra architecture was built for a centralized model, and six months later the organization decided to move to a federated structure. The refactoring cost – not just in platform configuration, but in re-training stewards, re-mapping workflows, and re-communicating ownership to business units – is substantial. Starting with the model saves that cost entirely.

For more on how Collibra operationalizes data governance in practice, see our guide on Collibra data governance and the full Collibra implementation process.

Components of an effective data governance model

Regardless of which model you choose, an effective data governance model requires the same core components to function. The model determines who is responsible for each component – not what the component is.

• Decision rights define who has authority to approve data definitions, change data quality standards, grant access to sensitive data, and resolve disputes between domains. Without explicit decision rights, every governance question becomes a political negotiation.
• Data ownership assigns accountability for each data domain or critical data element to a specific role – typically a Data Owner at the business level. Data governance roles must be clearly mapped before implementation begins; a governance model without named owners is a governance model on paper only.
• Stewardship structure determines how data stewards are deployed – centrally, per domain, or both – and what their day-to-day responsibilities are. Data stewardship is the operational backbone of any governance program; steward placement and authority must match the chosen model.
• Governance policies establish the rules for data quality standards, data lifecycle management, data privacy compliance, and access control. The governance model determines who creates, approves, and enforces those policies across the organization. For a deeper look at policy design, see data governance policy and data governance pillars.
• Tooling – including your data catalog, workflow engine, and lineage tools – is the last component, not the first. The model must drive the tool configuration, not the reverse. This is the lesson the Model-First Gap teaches the hard way. For how successful teams operationalize these components day-to-day once the model is set, see our data governance best practices guide.
• Issue management defines how governance conflicts are identified, escalated, and resolved when decision rights alone don’t settle a dispute – domain boundary disagreements, conflicting business rules, data quality exceptions that cross ownership lines. Without it, contested decisions get resolved by whoever has the most organizational leverage, which isn’t governance – it’s politics. 

How to choose the right data governance model for your organization

There is a concrete set of criteria that determines which model fits your organization. Four diagnostic questions narrow the decision:

1. How decentralized is your organizational structure? If your business units operate with significant autonomy – separate P&Ls, distinct regulatory jurisdictions, different data cultures – a centralized model will generate constant friction. The governance structure should reflect the organizational reality, not fight against it. Highly decentralized organizations need federated or replicated models.
2. What is your regulatory footprint? If you operate in EU regulated industries (banking, insurance, energy, pharma) under GDPR, DORA, or sector-specific frameworks, you need centralized oversight for at least the regulated data categories. A purely federated model is difficult to defend under audit. The more stringent the regulatory environment, the more the model must lean toward centralization for critical data elements.
3. What is your governance maturity? Organizations early in their governance journey typically lack the domain expertise, steward capacity, and governance culture needed to run a federated model effectively. Starting with a more structured model model – even if the long-term target is replicated – lets the organization build governance habits, demonstrate value, and develop steward capability before distributing authority. Don’t start federated if you don’t yet have functioning stewardship anywhere.
4. Where are your data quality failures concentrated? If data quality problems are concentrated in specific domains and business units, those domains likely need more local accountability – a signal toward federated or replicated. If data quality failures are systemic and cross-domain (inconsistent definitions, conflicting master data, unreliable reporting), the problem is usually the absence of central standards – a signal toward centralization first.

Building the full data governance strategy – including stakeholder buy-in, roadmap sequencing, and AI alignment – is a separate exercise from model selection. If that’s the next step, our data governance strategy guide covers it in depth.

Signs your data governance model isn’t working

The Model-First Gap surfaces predictably. These symptoms appear within 6-12 months of go-live when the governance model is mismatched to the organizational reality.

1. Data stewards in different domains apply different standards despite official central policies. This signals that the centralized model lacks enforcement or that the federated model lacks the shared standards layer it requires to function.
2. Metadata completion in Collibra is below 30% after 12 months. Low metadata completion almost always traces to either the wrong steward structure (stewards don’t have time or authority) or the wrong ownership model (nobody believes it’s their job).
3. Business units are maintaining parallel governance artifacts – Excel trackers, SharePoint lists, local glossaries – alongside Collibra. This is the clearest signal that the governance model doesn’t match how the organization actually works. People route around governance when governance routes around them.
4. The CDO cannot definitively name the data owner for any of the top 10 critical data elements. If ownership isn’t enforced by the model, it doesn’t exist in practice.
5. Regulatory audits surface inconsistent data definitions for the same terms across different reports or systems. This is the BCBS 239 failure mode – and it’s a direct consequence of a federated model without functioning central standards.
6. Collibra adoption is stalled and the team is planning a training campaign to fix it. Training rarely fixes a structural problem. If adoption is low because stewards don’t understand their responsibilities, the issue is the model definition, not the training content. For context on what healthy data governance adoption looks like – and how to measure it – see our data governance metrics guide.

If more than two of these symptoms apply to your program, the issue is almost certainly structural. The tool is not the problem.

When to fix it yourself vs. bring in specialists

Not every model misalignment requires external help. Here’s an honest breakdown.

Handle it internally if:

• The governance model needs clarification, not redesign – you know the right structure, you just need to document and communicate it formally.
• Changes are incremental: adjusting steward assignments, refining community boundaries in Collibra, adding missing decision rights documentation.
• You have CDO sponsorship, internal Collibra expertise, and the capacity to run a redesign alongside ongoing governance operations.
• Data quality issues are improving slowly rather than stalled.

Bring in specialists if:

• The Collibra community structure needs to be rebuilt to reflect a different governance model – this requires expertise in both governance design and Collibra architecture.
• You have a regulatory deadline (DORA compliance, BCBS 239 audit, FINMA review) and the current model is not defensible.
• Data governance adoption is critically low and the program lacks internal credibility to drive a redesign from within.
• You know something is wrong but can’t pinpoint whether the issue is model design, steward structure, tooling configuration, or some combination.
• The program has been stalled for more than six months and leadership is questioning whether governance is worth the investment.

We’ve helped organizations diagnose and fix exactly these situations – including an energy company that transformed its Collibra implementation after the original governance structure stopped scaling. The fix wasn’t retraining users. It was redesigning the operating model and the Collibra architecture that reflected it.

Once you’ve chosen and stabilized your governance model, the next step is execution sequencing. Our data governance roadmap guide covers how to translate a model decision into a phased implementation plan that delivers measurable value.

If you’re designing a governance model ahead of a Collibra implementation, or diagnosing why your existing program isn’t delivering the adoption and data quality results you expected, talk to our governance specialists. 

We’ve built and rebuilt governance operating models for enterprises in banking, energy, pharma, and retail across the EU – and we know where the Model-First Gap hides before it becomes a board-level conversation.