What Is EU Data Boundary?

By Weapp · Updated

EU Data Boundary is Microsoft's commitment to store and process customer data for covered enterprise services within the EU and EFTA, with certain defined, limited transfers outside the boundary. The promise only applies to the services and configurations explicitly covered – in Azure AI Foundry, for example, it doesn't hold for the default Global SKU.

When a company is buying AI or cloud services from Microsoft, the term EU Data Boundary comes up quickly. It sounds like a guarantee: the data stays in Europe. But the promise has a precise meaning and clear limits, and anyone who reads it as more than that risks building their compliance on a misunderstanding.

The definition

EU Data Boundary (EUDB) is Microsoft’s commitment to store and process customer data for its covered enterprise cloud services within the EU and EFTA area. It covers large parts of Microsoft 365, Dynamics 365, Power Platform, and Azure.

The commitment isn’t absolute, though. It allows certain defined, limited transfers outside the boundary – for example for technical operations, security, and customer support. So it’s not a promise that no data ever crosses the boundary, but that storage and processing generally take place within the EU and EFTA, with the exceptions clearly described.

It’s also worth understanding what the commitment covers. EUDB is about customer data – what you and your users enter and create in the service. That’s not the same as Microsoft, as a company, ceasing to be American. EU Data Boundary moves where data is stored and processed; it doesn’t change which jurisdiction the provider ultimately falls under. That distinction is exactly why EUDB reduces, but doesn’t remove, exposure to US law.

The trap in Azure AI Foundry

This is where it gets technical, and it’s where many buyers stumble. In Azure AI Foundry, EU Data Boundary doesn’t apply automatically just because your resource is located in an EU region. What matters is which deployment SKU you choose.

  • DataZone and Standard/regional keep data within the boundary under EUDB.
  • Global – which is the default – routes calls globally even if the resource was created in a European region.

That means you might think you’re running within EU Data Boundary, while the default setting in practice sends traffic out. The boundary only applies if you actively opt out of Global. This isn’t a bug but how the product is built – and exactly the kind of detail an audit gets stuck on.

GitHub isn’t included

A second trap involves GitHub. Even though Microsoft owns GitHub, the service isn’t covered by EU Data Boundary. For anyone buying GitHub Copilot and assuming “it’s Microsoft, after all,” this is an unpleasant surprise: Copilot data sits outside the EUDB commitment.

A concrete scenario: an organization rolls out Copilot broadly across its development teams, assuming Microsoft’s EU promise covers the code. During an audit, it turns out the GitHub link sits outside the boundary – and the assumption was never correct. The point is that scope must be verified per service, not assumed based on ownership.

This illustrates a broader principle that’s especially important for a Swedish buyer: EU Data Boundary isn’t a single on/off switch for Microsoft’s entire portfolio, but a commitment that applies to a defined list of services in defined configurations. Two products from the same provider can therefore have completely different status. That one service is included says nothing about the next, and that one feature is included says nothing about a neighboring one. For anyone documenting their data processing, it’s therefore not enough to write “we use Microsoft, so EU Data Boundary applies” – each service and feature needs to be confirmed individually.

How to use EU Data Boundary correctly

EU Data Boundary is a useful tool for reducing the volume of data transfers, but it’s not the whole answer to GDPR’s third-country question. The exceptions still exist, and since Microsoft ultimately falls under US jurisdiction, EUDB doesn’t neutralize the CLOUD Act.

Treat it as one piece of a larger architecture, together with the right deployment type, retention settings, and a documented transfer analysis. Above all: since the list of covered services is updated on an ongoing basis, you need to verify the current service scope in Microsoft’s own EUDB documentation before drawing conclusions for a specific flow.

Want to understand how EU Data Boundary connects to residency, retention, and government access across a full AI project? There’s more on our AI page. Need help figuring out whether a specific Microsoft setup holds up? Get in touch and we’ll go through it.

Frequently asked questions

Which services are covered by EU Data Boundary?

The commitment applies to covered enterprise cloud services, primarily within Microsoft 365, Dynamics 365, Power Platform, and large parts of Azure. The scope isn't total, though, and the list is updated on an ongoing basis. Always check Microsoft's current EUDB documentation to confirm that the specific service and feature you intend to use is actually included.

Does EU Data Boundary mean no data ever leaves the EU?

No. The commitment allows certain defined, limited transfers outside the boundary, for example for technical operations, security, and support. The point is that storage and processing generally take place within the EU and EFTA, not that the boundary is absolute. What the exceptions are is set out in Microsoft's documentation.

Does EU Data Boundary apply to GitHub?

No, and that surprises many people. GitHub isn't included in EU Data Boundary, even though Microsoft owns the service. That's especially important for anyone buying GitHub Copilot who assumes the data is covered by Microsoft's EU commitment – it isn't.

Is EU Data Boundary enough to resolve the GDPR transfer question?

Not on its own. EU Data Boundary reduces the volume of transfers but doesn't remove US jurisdiction via the CLOUD Act, and the exceptions still apply. Treat it as a data-minimizing tool, not a complete answer to the third-country question – that still requires its own assessment.

How do I know if my Azure AI service stays within the boundary?

It's determined by the deployment type. In Azure AI Foundry, EU Data Boundary only holds when the SKU is DataZone or Standard/regional. The default choice, Global, routes globally even if the resource itself is located in an EU region, so you have to actively opt out of Global for the boundary to apply.