Governance & Catalog

Data sovereignty in cloud data platforms: what to check before you choose

Residency is not sovereignty. A practical guide to the legal, operational and architectural questions to ask of Microsoft Fabric, Databricks, Snowflake, and any other cloud data platform.

By UDP Editorial · 5 August 2025 · 8 min read

Drafted with AI assistance. Sources checked by the editor on 5 August 2025.

Editor's note (draft): Drafted with AI assistance on 17 September 2026. Platform features and regulations change often, so check every product claim against the linked official documentation before publishing. This article is not legal advice.

The short version

Data residency is about where data is stored. Data sovereignty is about whose laws and whose control the data is subject to. Choosing a UK or EU region solves the first problem, but not necessarily the second.
On a cloud data platform, data isn't only in your tables. Metadata, logs, backups, AI features, support access and data sharing can all cross borders unless you configure them not to.
Microsoft Fabric, Databricks and Snowflake all let you keep data in a chosen region. They differ in what else leaves that region, who holds the keys and how cross-region AI processing is controlled, so check each one explicitly.

Residency, sovereignty and localisation are different things

Term	The question it answers	Example requirement
Data residency	Where is the data physically stored?	Customer records must be stored in UK data centres
Data localisation	Must the data stay in the country?	A law requires certain data, or a copy of it, to be kept in-country
Data sovereignty	Which jurisdiction's laws apply, and who can compel access?	Data must not be accessible to foreign authorities without a local legal process
Operational sovereignty	Who operates and supports the platform, and who can access it?	Only vetted in-country staff may administer the service

Residency is a configuration setting. Sovereignty combines configuration, contracts, key control and the provider's own legal exposure.

Why the cloud makes this harder

1. The law follows the provider, not just the data

Storing data in an EU or UK region doesn't remove the provider's own legal obligations. The US CLOUD Act (2018), for example, allows US authorities to require providers under US jurisdiction to disclose data in their possession, custody or control, wherever it's stored.

European regulators have been cautious about transfers since the Schrems II judgment (2020) struck down the EU–US Privacy Shield. Its replacement, the EU–US Data Privacy Framework (2023), has faced legal challenges, so check its current status before relying on it.

For personal data, GDPR and UK GDPR restrict international transfers (Chapter V) unless an adequacy decision or appropriate safeguards are in place, such as Standard Contractual Clauses. The European Data Protection Board expects supplementary measures where the destination country's laws undermine those safeguards.

2. A data platform has more moving parts than your tables

Control planes that store metadata: table names, schemas, query text, lineage
Serverless and AI features that may process data in another region
Telemetry, logs and support tooling operated from other countries
Backups, replicas and disaster recovery copies
Data sharing and marketplaces that deliver data to consumers elsewhere

Query text can itself contain personal data (for example WHERE email = '...'), so where metadata lives matters too.

3. Resilience pulls against residency

Disaster recovery needs a second region; sovereignty may require that region to be in the same jurisdiction. Not every country has two regions from every provider, and some default region pairings cross borders: Azure's Brazil South region, for example, is paired with a region in the United States. Design disaster recovery deliberately rather than accepting the defaults.

The regulatory landscape: a starting map, not legal advice

EU GDPR and UK GDPR: restrictions on international transfers of personal data
EU Data Act (applies from September 2025): cloud switching obligations for providers, and safeguards against unlawful access by non-EU governments to non-personal data
NIS2 and DORA: security and ICT third-party risk requirements for essential entities and EU financial services, including exit planning for critical cloud providers
Sector rules: health, the public sector and defence often add hosting requirements based on data classification
Beyond Europe: laws such as India's DPDP Act, China's PIPL and Saudi Arabia's PDPL include cross-border transfer or localisation provisions

Map each dataset to the rules that actually apply to it. Making everything "sovereign" is expensive; under-applying the rules is a compliance risk.

Seven questions to ask any cloud data platform

Where is data at rest? Include metadata, query history, logs, backups and temporary storage, not just tables.
Where is data processed? Include serverless compute and AI features, which may route requests to other regions.
Who can access it, and from where? Vendor support and operations staff, where they're located, and whether their access needs your approval.
Who holds the encryption keys? The provider, you (customer-managed keys), or a key service outside the provider altogether.
Where do copies go? Replication, failover, data sharing, marketplace listings and exports.
Which jurisdictions apply to the provider? Its headquarters, the operating entity and its sub-processors.
Can you leave? Open formats, export tooling and contractual exit terms.

How Microsoft Fabric, Databricks and Snowflake approach it

Draft comparison: verify every row against current vendor documentation. Features, tiers and regional availability change often.

Consideration	Microsoft Fabric	Databricks	Snowflake
Choosing a region	A tenant home region, plus capacities that can be created in other regions (multi-geo)	Each workspace is deployed to a chosen cloud region	Each account lives in one cloud region
Where metadata lives	Some tenant-level metadata stays in the home region even when capacities are elsewhere	Control plane services run in the workspace's region	Held within the account's region
Where compute runs	In the capacity's region, fully managed as SaaS	Classic compute in your own cloud account; serverless compute in a Databricks-managed account in the same region	Virtual warehouses in the account's region
Customer-managed keys	Available for some Fabric items and scenarios; check current scope	Available for managed services and workspace storage on supported tiers	Tri-Secret Secure combines a customer-managed key with a Snowflake key (Business Critical edition)
AI features and cross-region processing	Tenant settings control whether AI features may process data outside your geography	Account settings control whether AI assistive features may use processing outside the workspace's geography	Cortex AI cross-region inference is controlled by an account parameter
Copies across regions	OneLake shortcuts and mirroring can reference or bring in data from other regions and clouds	Delta Sharing and replication can move data across regions and clouds	Replication, failover groups and cross-region sharing must be configured explicitly
Sovereign or government options	Microsoft EU Data Boundary; Microsoft sovereign cloud offerings	Government and regulated-industry deployments on some clouds	Government regions on some clouds

Microsoft Fabric

Fabric is SaaS, so sovereignty is mostly about where the tenant and capacities are placed and how tenant settings are configured. Know your tenant's home region: some metadata stays there even if capacities run elsewhere. Review the admin settings that allow AI features to process data outside your geography, and check whether any OneLake shortcuts point to storage in other jurisdictions. Microsoft's EU Data Boundary commitments cover many of its cloud services for EU customers; confirm which Fabric workloads and data types are in scope.

Databricks

Databricks separates a control plane, run by Databricks, from compute. With classic compute, clusters run in your own cloud account and network, which gives strong control over where data is processed; serverless compute runs in a Databricks-managed account in the same region. Check where Unity Catalog metadata and query history are stored, set up customer-managed keys where required, and treat Delta Sharing to other regions or clouds as a cross-border transfer.

Snowflake

A Snowflake account is tied to one cloud region, and data stays there unless you set up replication, failover or cross-region sharing, which makes residency easy to reason about. For tighter key control, Tri-Secret Secure combines your key with Snowflake's. If you use Cortex AI, check its cross-region inference setting, which is controlled per account:

SQL

-- Snowflake: check and restrict Cortex AI cross-region inference (requires ACCOUNTADMIN).
-- Check the allowed parameter values in the current documentation before running.
SHOW PARAMETERS LIKE 'CORTEX_ENABLED_CROSS_REGION' IN ACCOUNT;
ALTER ACCOUNT SET CORTEX_ENABLED_CROSS_REGION = 'DISABLED';

Enforce it with guardrails, not good intentions

Region choices drift as teams create new resources. Enforce allowed locations through infrastructure as code and cloud policy. For example, this Terraform assigns Azure's built-in Allowed locations policy to a subscription:

Terraform (HCL)

data "azurerm_subscription" "current" {}

resource "azurerm_subscription_policy_assignment" "allowed_locations" {
  name                 = "allowed-locations-uk"
  subscription_id      = data.azurerm_subscription.current.id
  # Built-in policy definition: "Allowed locations"
  policy_definition_id = "/providers/Microsoft.Authorization/policyDefinitions/e56962a6-4747-49cd-b67b-bf8b01975c4c"

  parameters = jsonencode({
    listOfAllowedLocations = { value = ["uksouth", "ukwest"] }
  })
}

Check residency continuously as part of your data catalogue, not once a year:

Plain text / pseudo-code

for each dataset in catalogue:
    rules     = requirements_for(dataset.classification)   # e.g. "personal data: UK only"
    locations = platform_region(dataset) + replica_regions(dataset) + share_targets(dataset)
    if any location is outside rules.allowed_regions:
        raise finding(dataset, "stored or shared outside the allowed jurisdiction")
    if dataset.uses_ai_features and not rules.allow_cross_region_processing:
        confirm the platform's AI processing is pinned to allowed regions

Trade-offs to be honest about

Features can lag in sovereign or government clouds, and new AI features often launch in only a few regions first.
Costs rise with in-country disaster recovery, customer-managed key infrastructure and dedicated sovereign offerings.
Fewer regions can mean weaker resilience or higher latency.
Holding your own keys reduces provider access risk but doesn't remove it: services still have to decrypt data to process it.
Portability is part of sovereignty. Open table formats (Delta Lake, Apache Iceberg) and tested export paths keep you able to move if the legal position changes.

A practical checklist

Platforms in this article

Compare their capabilities side by side →

Tags: data-sovereignty, data-residency, gdpr, compliance, architecture