When I help European organizations roll out Microsoft 365 Copilot, the same topic comes up first almost every time: Copilot data residency, meaning where exactly the data is processed and stored. Microsoft completed all EU Data Boundary phases in February 2025, yet I still watch data protection officers and works councils wrestle with the details. They want to know which Copilot data ends up where, how Bing web search fits in, and whether Advanced Data Residency or Multi-Geo changes anything. Below is what I tell customers and how I handle the topic in DPIA documentation on real projects.

The EU Data Boundary now covers Copilot data residency

Since February 2025, Microsoft 365 Copilot has officially been part of Microsoft's EU Data Boundary commitments for European customers. Copilot interaction data (prompts, context and responses in Word, Outlook, Teams, Excel, etc.) is therefore processed and stored only within EU Data Boundary regions. That holds for tenants with standard data residency, Advanced Data Residency (ADR) and Multi-Geo. Copilot is included in all three, as the Advanced Data Residency documentation and the EU Data Boundary docs confirm.

In practice, Copilot prompts and responses are stored as message objects in the user's Exchange mailbox, so every existing compliance, retention and discovery policy applies to them. The large language model processing behind Copilot also takes place in the EU. Microsoft may process data outside the EU boundary only during rare capacity peaks, and those exceptions are logged and the affected organizations are notified. I have never actually seen this happen in the tenants I manage.

Copilot stores its interactions in the user's Exchange mailbox

Once you know that Copilot prompts and outputs live as items in the Exchange mailbox, the DPIA documentation gets a lot simpler. You can state plainly that Copilot does not create any new, separate data stores. The usual data residency commitments apply exactly as they do for mail or calendar, and Purview retention, eDiscovery and compliance policies apply in full. If you have to prove it, the Microsoft Purview audit log records Copilot interactions. I showed what those entries look like and how to search for them in Copilot retention and audit: What really happens to your prompts?.

Tip from the field: In every DPIA, I state explicitly that Copilot interaction data (prompts, responses and context) sits in the same Exchange mailbox as regular Microsoft 365 content and falls under the same compliance controls. Privacy officers appreciate having that spelled out.

A Mermaid diagram shows how Copilot data flows in the EU

Before I move on to web search and model processing, here is a flowchart I use to make the Copilot data flows for EU tenants easier to picture:

flowchart TD
    User["User (EU)"] --> CopilotApp["Microsoft 365 Copilot app/client"]
    CopilotApp --> EUProcessing["Processing & LLM (EU Data Boundary)"]
    EUProcessing --> Mailbox["Exchange mailbox (EU tenant)"]
    CopilotApp --> BingWeb["Web search (Bing)"]
    BingWeb --> BingEU["Bing servers (EU Data Boundary)"]
    BingWeb --"Capacity peak"--> BingGlobal["Bing servers (Global)"]

Figure: Simplified Copilot data flow in the EU, with web search shown as its own path.

The diagram makes three things visible at once. Copilot data stays in the EU, web search runs on a separate path, and processing exceptions are transparent.

Copilot web search follows its own flow and privacy boundaries

This is the part that tends to confuse privacy teams and works councils. Copilot can optionally pull in web content through Bing ("web grounding"), but those Bing search queries are technically and legally separate from the rest of the Copilot interactions. Since 2024, Bing web search queries from EU Copilot users have been processed in EU Data Boundary data centers whenever possible (Copilot privacy docs). During a temporary spike in demand, Microsoft may process them outside the EU, though this is documented and reported to customers.

For the DPIA, the key point is that web search is optional and that prompts sent to Bing web search leave the Microsoft 365 tenant through a separate channel. Organizations that want maximum transparency can turn off or restrict web search for Copilot in the admin portal. I cover the technical controls in Copilot web search: What really leaves Microsoft 365?. For most tenants, it is enough to document the technical separation and limit web search to approved user groups.

My DPIA checklist covers five points

Privacy officers and works councils usually expect clear documentation on the following:

  • Where and how Copilot interactions are stored (Exchange mailbox, EU Data Boundary)
  • Technical and organizational controls for web search (Bing, EU Data Boundary, transparency about exceptions)
  • What happens during rare capacity peaks (exceptions logged, notification)
  • References to existing compliance and retention policies (Purview, eDiscovery, sensitivity labels)
  • What IT can control (web search restriction, audit logs)

With these covered, you can answer most privacy questions and support your statements with Microsoft's own documentation (EU Data Boundary, Copilot privacy).

Works councils need realistic promises about web search and LLM processing

My conversations with works councils have shown me that acceptance depends heavily on being open about storage locations and about how web search is technically separated. I make a point of mentioning that web search can be switched off or scoped to specific groups. The LLM processing of Copilot prompts stays within the EU Data Boundary, and the rare exceptions can be audited if it ever comes to that. For the works council side and the technical measures involved, especially around data protection in co-determination, see my post Copilot works council: Technical controls in practice.

In my experience, Copilot data residency is now regulated as clearly as any new Microsoft 365 service I have worked with. What matters is explaining the details in plain terms, writing them down precisely in the DPIA, and taking a hard, specific look at how your organization uses web search.