Databricks Unity Catalog for Multi-Country Data Estates: Access Control and Lineage

A group operating across the GCC, India and Europe faces a governance problem that pulls in two directions. Each country has its own rules: data that must stay in-region, access that must be limited to local staff, reporting formats that differ by regulator. At the same time, the group board wants a single consolidated view — one revenue number, one inventory position, one margin — across all of them.

Handle only the first and you get governed silos that cannot be consolidated. Handle only the second and you get a consolidation that violates residency and over-shares data across borders. The platform has to do both: strict local governance and clean group-level roll-up, from the same foundation.

Databricks Unity Catalog is designed for this shape — a single governance layer across many workspaces, with the fine-grained controls to keep local data local and the lineage to make the consolidation defensible.

Unity Catalog governs data through a three-level namespace — catalog, schema, table — above the workspace, so governance is defined once and applies across every workspace attached to the metastore. For a multi-country estate, the natural structure is a catalog per region or legal entity: a UAE catalog, an India catalog, a Europe catalog, each holding that entity’s schemas and tables.

This gives you a clean unit of ownership and access. Permissions, ownership and policies are set at the catalog or schema level, so "who can see UAE data" is a single, auditable grant rather than a scattering of table-level rules. The group consolidation then reads across catalogs through views that the group role is entitled to, while local roles are scoped to their own catalog.

The structure is the design decision that matters most. Mirror your legal-entity and residency boundaries in the catalog layout, and the access model becomes simple to reason about; flatten everything into one catalog and you spend the rest of the project writing table-level exceptions.

Beyond catalog-level grants, Unity Catalog supports row-level and column-level security, which is what lets a shared table serve different geographies safely. A single customer or sales table can be filtered by a row policy so a UAE analyst sees only UAE rows and an India analyst only India rows, while the group role sees all of them — one table, governed to each viewer.

Column-level controls handle the fields that are sensitive in some jurisdictions and not others: mask a personal identifier or a salary field for roles that should not see it, while leaving it available to the ones that must. This is how you avoid building a separate copy of a table per country — the governance does the separation at query time.

The access model should map to your organisation’s real structure: roles aligned to legal entities and functions, group memberships that reflect who is actually local to each market, and least privilege throughout. That mapping is the governance work; Unity Catalog enforces it once it is defined.

Consolidation across countries raises an inevitable question from finance and audit: where did this group number come from? Unity Catalog captures end-to-end lineage automatically — table-level and column-level — across the workloads that run on it, so a consolidated figure can be traced back through the transformations to the source tables in each country.

That lineage is what makes a cross-border consolidation defensible. When the group revenue number is questioned, you can show the exact path from the board figure to the UAE, India and Europe source transactions that fed it, including the transformations applied along the way. "The number is right because here is where every part of it came from" is a far stronger position than "the pipeline produced it".

Lineage also makes change safe. Before altering a source table or a transformation in one country, you can see every consolidated report downstream of it, so a local change does not silently break the group view. In a multi-country estate where teams work independently, that visibility is what stops one region’s change from surprising another.

The one thing governance tooling cannot wish away is data residency. Where regulation requires a country’s data to physically remain in-region, that is a constraint on where the data is stored and processed, not just on who can see it — and it shapes the physical architecture: region-specific storage, and careful design of what actually crosses a border for consolidation.

The usual pattern is to keep raw and detailed data in-region and consolidate on aggregated or permitted data that is allowed to move, so the group view is built without relocating restricted records. Unity Catalog governs access across that structure, but the residency boundaries have to be designed into where catalogs and their underlying storage physically live.

This is why a multi-country governance project starts with the legal and residency map, not the tool. Establish what must stay where, what may cross a border, and in what form — then the catalog structure, access model and consolidation design follow from that map rather than being retrofitted when a regulator asks.

A multi-country estate on Unity Catalog comes down to: catalogs structured to your legal entities and residency boundaries; row- and column-level access mapped to who is genuinely local to each market; automatic lineage so every consolidated number is traceable to its source country; and a physical design that honours residency by keeping restricted data in-region and consolidating on what may move. The tooling is capable; the work is the modelling.

Done this way, the board gets its single consolidated view and each country keeps its data governed to its own rules — the two requirements that seemed contradictory, held together. We build Microsoft-first by default, and deliver this on Databricks and Unity Catalog where a client’s estate runs there; the cross-border discipline — map residency first, structure governance to the legal entities, make consolidation traceable — is the same on either platform.