Federated Data Governance: How to Put Data Mesh into Real Practice

Quick Answer

Federated data governance is the way to govern data when ownership is spread across departments or domains, as Data Mesh proposes. Instead of a central committee approving every decision, a federated council with representatives from each domain and the platform team agrees only the minimum shared standards: shared identifiers, information classification, privacy, minimum quality requirements and interoperability.

Those standards do not stay in a document: the data platform enforces them automatically as code (Governance-as-Code) every time a domain publishes data. Everything else is decided by each domain, which knows its data best.

The result is governance that is faster and more reliable at the same time: domains do not wait for approvals, and the rules are followed without depending on anyone remembering them.

A committee does not govern data. The rules that run every time someone publishes data do.

Many organisations have adopted the vocabulary of Data Mesh: domains, data products, a self-service platform. But when it comes to governance, they keep the usual model: a central committee that meets once a month, reviews requests and publishes policies in a shared document. The result is usually one of two extremes. Either the committee becomes a bottleneck and domains wait weeks to publish data, or domains bypass the process and each applies its own rules.

Neither extreme is Data Mesh. The first recentralises what was meant to be decentralised. The second fragments the organisation into data islands that cannot understand one another.

Decentralising data ownership without automating the rules is not Data Mesh: it is fragmentation under another name.

What Federated Governance Is in Data Mesh

Data Mesh rests on four principles: domain ownership of data, data as a product, a self-service data platform and federated computational governance. The first three distribute responsibility; the fourth stops that distribution from ending in chaos.

The key word is computational. Shared decisions are made in a federated way, across all domains, but are enforced automatically on the platform. Governance stops being a human review process and becomes a set of rules that the system itself checks and applies.

Why Traditional Committees Do Not Work with Decentralised Domains

• Latency: a committee that meets monthly cannot keep up with dozens of teams publishing data every week.
• Distance from context: whoever approves does not know the data as well as the domain that produces it, so their decisions are slow or superficial.
• Compliance by document: a policy written in a wiki depends on every person reading, understanding and remembering it; in practice, it is followed unevenly.
• No feedback: the committee does not see how often a rule is broken until an audit or an incident arrives.

The problem is not having a shared body, but its role. In a federated model, that body does not approve data one item at a time: it defines a few well-chosen rules and makes sure the platform enforces them.

What Is Decided Jointly and What Each Domain Decides

The first decision in federated governance is drawing the line between global and local. The smaller the global part, the faster everything else will work.

What is decided jointly, because it affects everyone:

• Shared identifiers: how a customer, a product or a site is identified so that data from different domains can be joined.
• Information classification: which sensitivity levels exist and which tags are mandatory, such as the personal data tag.
• Privacy and access: how personal data is treated and who can see each sensitivity level.
• Minimum requirements for a data product: owner, description, contract, quality tests and service level.
• Interoperability: formats, naming and minimum metadata.

What each domain decides, because it knows it best: its internal data model, its business quality rules, its roadmap and who accesses its data within the shared limits.

Governance-as-Code: How to Turn Policies into Executable Rules

Governance-as-Code means expressing governance policies as versioned code that the platform executes, rather than as text that people interpret. In practice, it comes down to four mechanisms:

• Classification that triggers protection: when a column is tagged as personal data, the platform automatically applies a masking policy to it. Both Unity Catalog and Snowflake let you bind masks and row filters to tags.
• Requirements checked before publishing: a data product does not reach production if it lacks an owner, a description, a contract or tests. The check lives in the domain's CI, with tools such as Open Policy Agent or with custom rules.
• Permissions as code: access is declared in versioned repositories, for example with Terraform, so that every change is reviewed and audited.
• Automated catalogue and lineage: the platform registers each data product and its end-to-end lineage without anyone having to document it by hand.

A data product descriptor can be as simple as this:

# data product: sales.daily_orders
owner: sales-data-team
description: Confirmed orders by day and channel
classification: internal
columns:
  - name: customer_email
    tags: [personal_data]   # the platform applies the masking
quality:
  max_freshness_hours: 24
contract: v2

If the owner is missing or a column containing personal data is not tagged, the deployment fails. Nobody has to remember to check it.

How to Implement It Step by Step with the Galde Method

Federated governance is not implemented through a large upfront design project, but by showing it works in a real domain and extending it afterwards. It is the approach of our methodology: governance co-created with the teams, operational from the start and with visible results in the first weeks, with a technical sponsor dedicating two hours a week.

Weeks 1 and 2: One High-Impact Domain and a Minimal Council

A domain whose data feeds a visible business decision is chosen, and the federated council is formed with its lead, the platform team and whoever looks after privacy and security. Nothing more.

Weeks 3 and 4: Three or Four Global Rules, Already as Code

The council agrees only the essential rules, usually classification, the treatment of personal data and the minimum requirements for a data product, and the platform implements them as automated checks from day one.

Weeks 5 and 6: The First Governed Data Product, in Production

The domain publishes its first data product, meeting the shared rules automatically, with an owner, a contract, tests and a catalogue entry.

Weeks 7 and 8: Measure and Extend to the Next Domain

What has changed is measured, such as publishing time, incidents or improper access detected, and the second domain is brought in, reusing the same rules and the same platform.

How to Tell Whether Your Federated Governance Works

• Time to publish: how long a domain takes from wanting to publish a data product to it being available.
• Coverage: what percentage of data products meet the minimum requirements, measured by the platform rather than by a survey.
• Where problems are caught: whether access or quality incidents are detected by the platform or discovered by an audit.
• Manual exceptions: how often a rule has to be bypassed. If it happens a lot, the rule is badly designed.

How Galde Can Help Put Federated Governance into Practice

Through data governance, we co-create with your domains the federated council, the minimum shared rules and the division of responsibilities, with the same operational and agile approach we apply to any data governance.

Through data platforms, we implement those rules as code: classification that triggers masking, requirements checked in CI, permissions declared in repositories and automated catalogue and lineage.

And through generative AI, we extend the same governance to the data your assistants and agents use, so that generative AI governance is not a separate process.

Conclusion

Data Mesh promises that the teams who know the data best become its owners. That promise is only kept if governance stops depending on committees and documents and comes to depend on a few shared rules, enforced by the platform. Starting with one domain, automating from day one and measuring results within weeks is the difference between a real Data Mesh and a reorganisation on paper.