Where Does Your Power BI Data Actually Live? A Plain‑English Guide to EU Data Residency

The Scenario: A Cross‑Border Power BI Tenant Under Scrutiny

Imagine this setup:

• Your company is headquartered in Germany.
• Power BI tenant region: North Europe (selected when the first admin signed up).
• Users in Germany, Netherlands, and the UK.
• Data sources:
  • Azure SQL in West Europe
  • On‑premises SQL Server in Germany
  • A SaaS HR system hosted outside the EU

Now compliance steps in with three questions:

1. Where does our Power BI data actually live?
2. Does the Microsoft EU Data Boundary cover us?
3. Are we allowed to use this setup for regulated reports (finance, HR, healthcare, etc.)?

We’ll keep coming back to this scenario as we unpack how Power BI handles data residency.

Tenant Region: The Starting Point for Power BI Data Residency

The first concept to get clear: your Power BI tenant region.

This is set when your organisation’s Microsoft 365 / Azure AD tenant is created. Power BI uses that to decide where to store most of your data at rest.

What the tenant region actually controls

Broadly, the tenant region determines where Power BI stores:

• Datasets and models (import mode and Direct Lake)
• Report definitions (the .pbix logic, visuals, measures)
• Dashboards, workspaces, and app metadata
• Refresh history and usage metadata
• Some cached query results

So if your tenant region is North Europe, your core Power BI artefacts live in that Azure region.

For our scenario, that means:

• Imported data from German SQL Server and West Europe Azure SQL is stored in North Europe.
• Reports and dashboards are also stored in North Europe.

How to check your tenant region

You don’t need global admin rights for this.

In the Power BI Service:

1. Click the gear icon (top right) → About Power BI.
2. Look for Your data is stored in or Tenant region.

Alternatively, an admin can check in the Power BI Admin portal under Tenant settings.

This is the line your security team is really asking about when they say “Where does our Power BI data live?”

EU Data Boundary: What It Is (And Isn’t)

The Microsoft EU Data Boundary is a commitment to keep customer data for certain cloud services within the EU/EEA (plus some closely aligned locations) for core processing and storage.

For Power BI, that affects where:

• Data is stored at rest.
• Data is processed for typical operations.

What the EU Data Boundary means in practice

If your Power BI tenant region is in the EU/EEA (for example, North Europe, West Europe, France, Germany, etc.), then:

• Power BI aims to keep your customer data inside the EU Data Boundary under normal operations.
• Routine activities like refresh, query processing, and rendering are handled within that boundary.

For our scenario:

• Tenant region is North Europe → that’s inside the EU Data Boundary.
• Imported data and models stay within that boundary.

Important limitations

The EU Data Boundary is not a magic switch that guarantees:

• That all data always stays in the EU in every edge case.
• That every third‑party integration you connect to is EU‑only.
• That your own data sources are EU‑only.

In our scenario:

• The HR SaaS system is hosted outside the EU. When you import data from it, that data ends up stored in North Europe (inside the boundary), but the source itself is still non‑EU.
• Power BI may still use non‑EU services for things like optional preview features, certain AI capabilities, or support operations, depending on the specific feature and Microsoft’s current implementation.

When compliance asks “Are we within the EU Data Boundary?”, the accurate answer is usually:

Our Power BI tenant is hosted in [region], which is inside the EU Data Boundary. Core data storage and processing are within that boundary, but some features and external data sources may involve processing outside the EU.

Where Different Types of Power BI Data Actually Live

“Power BI data” is not one thing. Different pieces live in different places. That’s where confusion starts.

Let’s break it down for our scenario.

1. Imported data (Import mode)

When you use Import mode:

• Data is copied from the source into the Power BI dataset.
• That dataset is stored in the tenant region.

In our scenario:

• Data from German SQL Server → imported → stored in North Europe.
• Data from West Europe Azure SQL → imported → stored in North Europe.
• Data from non‑EU HR SaaS → imported → stored in North Europe.

So even if the source is outside the EU, the Power BI copy lives in your tenant region.

2. DirectQuery / Live connection

With DirectQuery or live connection (for example, to Azure SQL, Synapse, Analysis Services):

• Power BI does not store full copies of the source data.
• It stores metadata (model definition) and some caches.
• Query execution happens against the source, from the Power BI region.

Implications:

• If your tenant is in North Europe and your SQL source is in West Europe, queries travel between those regions.
• If your source is outside the EU, queries cross the EU boundary when executed.

For regulated sectors, this pattern is often used to:

• Keep authoritative data in a controlled environment (for example, EU‑only database).
• Limit what is cached in Power BI.

3. Dataflows

Power BI dataflows store data in:

• The tenant region (for standard dataflows).
• A chosen region tied to your Power BI capacity (for some advanced scenarios).

In our scenario, if you build a dataflow that pulls from the HR SaaS system:

• The dataflow’s output tables are stored in North Europe.

4. Logs, usage data, and metadata

Power BI generates a lot of metadata:

• Audit logs
• Usage metrics
• Workspace and sharing metadata

These are also tied to the tenant region, but:

• Audit logs may be surfaced via Microsoft 365 compliance tools, which have their own residency story.
• Some telemetry used by Microsoft for service health and improvement may be processed in different ways than your customer data.

When documenting for compliance, it helps to treat customer data and service metadata as separate topics.

Regulated Sectors: Questions You Should Be Ready to Answer

Back to our scenario. Compliance wants to know if this setup is acceptable for, say, HR or finance reporting.

Here are the questions you should be ready for, and how to tackle them.

1. Where is each data element stored at rest?

Make a simple table:

You can export dataset lists via the Power BI REST API or document them manually for critical workspaces.

A quick way to list datasets in a workspace with PowerShell:

# Requires Power BI Management module and appropriate permissions
Connect-PowerBIServiceAccount

$workspaceId = "<workspace-guid>"
Get-PowerBIDataset -WorkspaceId $workspaceId |
  Select-Object Id, Name, DefaultMode

This helps you identify which datasets use Import vs DirectQuery (DefaultMode).

2. What cross‑border data flows exist?

Map:

• Source → Power BI region (for refresh or queries).
• Power BI region → end users (report viewing).

For our scenario:

• HR SaaS (non‑EU) → North Europe (import).
• North Europe → users in Germany, Netherlands, UK (report access).

Most regulators care more about where data is stored and processed, not where users sit. But you should still be clear about both.

3. Which features might move data outside the EU Data Boundary?

You’ll need to review:

• AI features (for example, some advanced text analytics, image processing).
• Preview features that explicitly say they may use non‑EU processing.
• Integrations with third‑party visuals or services.

A practical approach:

1. Identify workspaces used for regulated content.
2. Standardise on a limited set of visuals and features for those workspaces.
3. Disable unapproved features via tenant settings in the Admin portal.

Designing a Data Residency‑Aware Power BI Architecture

Once you understand where things live, you can design around your constraints instead of fighting them.

Pattern 1: EU‑only core, flexible edge

For our scenario, suppose HR and finance are highly regulated, but operations is less strict.

You could:

• Use EU‑hosted databases (for example, West Europe or Germany) as the main sources for regulated datasets.
• Use Import mode for performance, accepting that data is stored in North Europe (still within EU Data Boundary).
• Keep non‑EU SaaS data in separate, clearly labelled workspaces and apps.

Pattern 2: DirectQuery for sensitive tables

Where copying data into Power BI is a concern:

• Use DirectQuery to an EU‑only database for sensitive tables (for example, names, personal identifiers).
• Import less sensitive fact tables if needed for performance.

In Power BI Desktop:

let
    Source = Sql.Database("eu-db-server", "HRDB", [CreateNavigationProperties=true]),
    Employees = Source{[Schema="dbo",Item="Employees"]}[Data]
in
    Employees

Then set the storage mode to DirectQuery in the model for that table, while other tables stay in Import.

This hybrid setup can reduce the amount of sensitive data stored at rest in Power BI.

Pattern 3: Separate tenants for strict segregation

Some organisations in heavily regulated sectors choose to:

• Run a separate Power BI tenant dedicated to regulated workloads.
• Host that tenant in a specific EU region that aligns with their policies.

This is heavier operationally (licensing, administration, user management), but it gives a clean story:

All regulated Power BI content lives in Tenant X, hosted in Region Y.

If you go this route, design clear rules:

• Which teams use which tenant.
• How data is moved between them (if at all).

Practical Checklist for Your Own Tenant

Use this as a working list with your security/compliance team.

1. Confirm tenant region

   • Check About Power BI → region.
   • Document it in your internal wiki.

2. List critical workspaces and datasets

   • Finance, HR, healthcare, customer data.
   • Identify Import vs DirectQuery.

3. Map data residency per dataset

   • Source region.
   • Power BI storage region.
   • Any known cross‑border flows.

4. Review tenant settings

   • Limit or disable risky preview/AI features for regulated workspaces.
   • Control export, sharing, and publish to web.

5. Align with the EU Data Boundary story

   • Confirm your tenant is in an EU Data Boundary region.
   • Document which parts of your architecture rely on that.

6. Create a one‑page explainer for auditors

   • Plain diagram of data flows.
   • Bullet list of controls (regions, features disabled, patterns used).

This turns a vague “Is our data in the EU?” conversation into something concrete and defensible.

One Concrete Next Step

Pick your top three most sensitive Power BI workspaces and, for each one, write down:

• Tenant region
• Source system locations
• Storage mode (Import/DirectQuery)
• Any non‑EU sources or features in use

You’ll end up with a short, factual note you can share with security and legal. From there, decisions about the EU Data Boundary, tenant region, and architecture become much easier—and you won’t be guessing where your Power BI data actually lives.