Microsoft Fabric and Data Sovereignty: Making the New Government Cloud Policy Work in Real Projects

The Scenario: A Cross‑Border Fabric Tenant That No Longer Passes Review

You’re part of a BI and data engineering team for a national agency. Earlier this year you:

• Created a single Microsoft 365 tenant hosted in an EU region.
• Deployed Microsoft Fabric (F SKU or Capacity) in that tenant.
• Ingested data from:
  • National registers (strictly regulated, personal data).
  • A shared EU system hosted in another member state.
  • Several SaaS line‑of‑business apps.
• Built:
  • One central lakehouse for raw and curated data.
  • A semantic model with Direct Lake for your core Power BI reports.

The new government cloud policy now says:

1. Certain datasets (e.g. high‑sensitivity citizen data) must be stored and processed only in designated national or EU regions.
2. Data residency must be demonstrable and auditable at service level, not just at the tenant level.
3. Specific workloads (e.g. cross‑border analytics) must use approved isolation patterns (separate tenants/regions, controlled data movement).

Your current Fabric setup:

• Uses a single capacity region for everything.
• Mixes different sensitivity levels in the same lakehouse.
• Has pipelines writing to the same OneLake endpoint from multiple jurisdictions.

The architecture review feedback is blunt: "We can’t see clear guarantees of data residency and isolation. Show us how Fabric enforces this, or redesign."

Let’s unpack what Fabric actually guarantees, what it doesn’t, and how to redesign this setup without throwing away your work.

What Microsoft Fabric Actually Guarantees About Data Residency

Tenant and Capacity Regions

Key facts that matter for sovereignty decisions:

• Microsoft 365 tenant region

  • Determines where core directory and many shared services are hosted.
  • For Fabric, you also need to look at capacity region, not just tenant region.

• Fabric capacity region

  • When you create a Fabric capacity (F‑SKU or P‑SKU), you pick a region.
  • OneLake storage for items in that capacity is bound to that region (subject to Microsoft’s data residency model for that geography).
  • Compute for Fabric experiences (Data Engineering, Data Warehouse, Power BI, etc.) runs in that region.

• Workspaces are bound to capacities

  • A workspace inherits the region of its capacity.
  • Moving a workspace to a different capacity can change where its data is stored and processed.

For the scenario team, this means:

• Their single Fabric capacity region is the effective residency location for all lakehouses, warehouses, and semantic models in that workspace.
• If the capacity is in an EU region, data is stored and processed in that region according to Microsoft’s EU data residency commitments.

OneLake Behaviour

OneLake is the unified storage layer for Fabric:

• Files and tables in lakehouses, warehouses, and other Fabric items are stored in OneLake in the capacity’s region.
• Shortcuts can reference external storage (e.g. Azure Data Lake Storage Gen2, Amazon S3) in other regions.
  • Shortcuts do not copy data into OneLake; they reference it.
  • When you query data via a shortcut, Fabric reads from the external location over the network.

For sovereignty:

• Using a shortcut to an external storage account in another country does not move the data into the Fabric region.
• But any transformed or persisted outputs (e.g. new tables in a lakehouse, materialised views, warehouse tables) are stored in OneLake in the capacity’s region.

Power BI Within Fabric

Power BI in Fabric follows established Power BI rules:

• Power BI workspaces in Fabric also run on the capacity’s region.
• Import‑mode datasets and Direct Lake semantic models store their data in OneLake in that region.
• DirectQuery can reach out to data sources in other regions, but the semantic model metadata and any cached data stay in the capacity region.

So, for the scenario team:

• Their Direct Lake models over the lakehouse are fully resident in the capacity’s region.
• Any cross‑border access comes from external sources via shortcuts or DirectQuery, not from the storage of the core reports.

Where Fabric Does Not Solve Data Sovereignty For You

The new government policy pushes on areas Fabric does not solve automatically.

Mixed‑Sensitivity Data in a Single Lakehouse

Fabric lakehouses are flexible but do not enforce regulatory separation:

• You can store high‑sensitivity and low‑sensitivity data in the same lakehouse.
• Row‑level security and object‑level permissions help with access control, not residency or legal segregation.
• Auditing who accessed what is possible, but proving which data sets are physically segregated requires architectural choices, not just permissions.

Cross‑Region Data Movement via Pipelines

Fabric Data Factory pipelines and Dataflows Gen2 can:

• Read from sources in other regions (SQL, ADLS, REST APIs, etc.).
• Write into lakehouses, warehouses, and other Fabric items in the capacity’s region.

Nothing in Fabric prevents you from:

• Copying data from a foreign system into a capacity that is not allowed for that dataset under the new policy.
• Transforming data in a way that commingles regulated and non‑regulated data.

Multi‑Tenant and Multi‑Region Governance

Fabric itself does not:

• Automatically enforce that certain data types can only exist in specific capacities or tenants.
• Provide built‑in policy packs that match your country’s government cloud policy.

You need to design:

• Tenant and capacity layout.
• Workspace and item boundaries.
• Pipelines and shortcuts.

The scenario team’s problem is exactly here: they used Fabric’s flexibility, but the new policy now requires stricter patterns.

Redesigning the Scenario: A Sovereignty‑Aware Fabric Layout

The architecture board has given the team three constraints:

1. Citizen master data and high‑sensitivity personal data must be stored and processed only in approved national/EU regions.
2. Analytics on EU‑wide shared systems can live in a separate, more open environment, but must not mix with citizen master data.
3. Suppliers must be able to work in a controlled way without direct access to the sovereign data lake.

Here’s a concrete Fabric layout that satisfies these constraints.

1. Separate Capacities for Sovereign vs. Shared Analytics

Create two Fabric capacities in approved regions:

• Sovereign Capacity (SC)

  • Region: national or strictly controlled EU region.
  • Used for:
    • Lakehouses holding citizen data and sensitive registers.
    • Warehouses for core reporting and legal/statistical outputs.
    • Power BI workspaces for internal, regulated reports.

• Shared Analytics Capacity (SAC)

  • Region: an EU region aligned with cross‑border collaboration requirements.
  • Used for:
    • Lakehouses holding data from EU‑wide systems and non‑sensitive operational data.
    • Power BI workspaces that external partners or suppliers can access.

Effect:

• Data in SC is physically stored and processed only in the sovereign region.
• Data in SAC is isolated at capacity level, even though it’s in the same Microsoft 365 tenant.

2. Workspace and Lakehouse Design

For the SC:

• Create workspaces by domain (e.g. CitizenData, Registers, InternalReporting).
• In each workspace:
  • One raw lakehouse with only inbound data from approved sovereign sources.
  • One curated lakehouse with transformed data, still strictly sovereign.
  • A warehouse for structured reporting where needed.

For the SAC:

• Workspaces for EUSharedSystems, SupplierAnalytics, etc.
• Lakehouses and warehouses only for data allowed in the shared environment.

No shortcuts from SAC into SC. If you need derived aggregates from SC in SAC, you publish them via controlled exports (see next section).

3. Controlled Data Movement Between Capacities

The policy allows sharing aggregated, non‑identifying data with partners. The team needs a pattern for this.

Use a Fabric pipeline in the Sovereign Capacity to:

1. Read from the curated lakehouse/warehouse in SC.
2. Produce aggregated tables that meet legal anonymisation requirements.
3. Export them to a controlled external storage (e.g. an Azure Data Lake Storage Gen2 account in the shared analytics region).

Example: a simple SQL transformation in a Fabric Warehouse in SC to produce an aggregated table:

CREATE TABLE CitizenStats.AggregatedPopulation
AS
SELECT
    RegionId,
    YEAR(GETDATE()) AS ReferenceYear,
    COUNT(*) AS PopulationCount
FROM CitizenData.Person
GROUP BY RegionId;

Then a pipeline activity writes CitizenStats.AggregatedPopulation to a parquet file in the external ADLS account in the SAC region.

In the Shared Analytics Capacity:

• Create a lakehouse.
• Add a shortcut to the ADLS folder with the aggregated parquet files.

Now suppliers can build reports in SAC over the aggregated data, with:

• No direct access to citizen‑level data.
• Clear residency: SC data never leaves its region; SAC data lives in its own region.

4. Supplier Access Without Sovereign Data Exposure

To let suppliers work safely:

• Grant them access only to:

  • SAC workspaces.
  • SAC lakehouses and warehouses.
  • SAC Power BI reports and semantic models.

• Use Fabric’s item‑level permissions and Microsoft Entra ID groups to:

  • Ensure they cannot see SC workspaces.
  • Prevent them from creating pipelines that target SC.

This respects the new policy’s requirement for controlled supplier access while still using Fabric as a unified analytics platform.

Governance and Monitoring: Proving Compliance, Not Just Hoping

The architecture board will eventually ask: “How do we know you’re still compliant in a year?”

You need ongoing governance, not just a one‑time redesign.

Capacity‑Level Controls

Use the Fabric admin portal:

• Limit who can create capacities and assign workspaces to them.
• Restrict capacity assignment so only designated admins can move workspaces between SC and SAC.
• Regularly review:
  • Which workspaces are on SC vs. SAC.
  • Whether any new workspace holding sensitive data has accidentally been placed on SAC.

Workspace Standards

Define workspace templates:

• Sovereign workspaces must:

  • Use only data sources approved by the security architect.
  • Avoid shortcuts to non‑sovereign external storage.
  • Document their inbound and outbound data flows.

• Shared workspaces must:

  • Consume only aggregated / non‑identifying data from SC.
  • Keep a clear separation between supplier‑accessible and internal items.

Logging and Auditing

Within Fabric and the broader Microsoft 365 environment:

• Enable auditing of:
  • Pipeline runs that move data between regions or external storage.
  • Workspace and capacity assignment changes.
• Keep a simple register of:
  • Each dataset or lakehouse.
  • Its sensitivity classification.
  • Its capacity and region.

This doesn’t come out of the box as a single report; you’ll likely use a mix of Fabric admin APIs and Microsoft 365 auditing to build your own compliance views.

Practical Takeaway: Design Around Capacities and Data Flows First

For teams dealing with Microsoft Fabric and data sovereignty under the new government cloud policy, the most practical shift is this:

Treat capacity region + data movement as your primary design axes, not just workspaces and lakehouses.

Before you build anything new:

• Decide which datasets must live on a sovereign capacity.
• Decide which analytics can live on a shared capacity.
• Design controlled, auditable data flows between them.

If you get those two decisions right, most of the later questions about residency, supplier access, and compliance become implementation details instead of blockers.