EU data residency M365 tools
26 Aug 2026
Why EU data residency matters when choosing M365 tooling
Before you connect a third-party tool to your tenant, ask where your data sleeps. Not where the vendor's website is hosted, not where their support desk answers the phone — where the copy of your directory, your mailbox statistics and your device inventory sits at three in the morning, and who can reach it there. It is the one question that never comes up in a demo, and the only one that shows up again in a procurement review eight months later.
The confusion has a specific source: your tenant already has a residency answer, it is a good one, and it does not travel.
Your tenant's boundary is not the tool's boundary
The EU Data Boundary is Microsoft's commitment to store and process customer data and personal data for Azure, Dynamics 365, Power Platform and Microsoft 365 inside the EU and EFTA — 27 EU countries plus Iceland, Liechtenstein, Norway and Switzerland. For Microsoft 365 specifically the rule is blunt: customers with a sign-up location in one of those countries are in scope. You do not configure it, you inherited it when someone created the tenant.
Two details in that page are worth knowing before you quote it at anyone. Customers who bought Multi-Geo Capabilities are not in scope for the EU Data Boundary — even when the tenant is listed as being in an EU or EFTA country. And the per-workload answer is not one answer: Exchange Online, SharePoint, Teams, Purview and the rest each publish their own data location, with Advanced Data Residency available in a specific list of local region geographies and not elsewhere.
All of which describes Microsoft. The moment a tool calls the Graph and writes the response to its own disk, none of it applies any more. What applies then is whatever you signed.
Three ways a tool can touch your tenant
Every product that reports on Microsoft 365 picks one of three shapes, and the choice decides your residency exposure before a single feature is built.
| Shape | Where the data sleeps | What it costs you | The question that settles it |
|---|---|---|---|
| Read-through, nothing kept | Only in your tenant; the answer lives as long as the browser tab | No history, no trend, and every page load pays the Graph's latency | Does anything survive a logout — cache, session store, export folder? |
| Collected and stored by the vendor | In the vendor's database, backups and logs, in the vendor's region | A second processor in your chain, with its own retention clock | Which region, which sub-processors, and how is erasure executed? |
| Self-hosted in your own infrastructure | Wherever you put it — the boundary is yours to keep or break | You own the patching, the backups and the on-call rota | Who upgrades it in month fourteen, and where do the backups land? |
The middle row is where nearly every commercial product lives, including this one. That is not a problem to hide; it is a set of facts to publish. A vendor that stores a copy is a processor acting on your instructions, and Article 28 is explicit about what that means: process only on documented instructions, engage sub-processors only with the controller's consent and stay liable for them, assist with data subject requests, and delete or return the data when the service ends. A tool that cannot name its sub-processors has not thought about the question.
The endpoint tells you nothing about the location
A recurring mistake in vendor questionnaires is treating the API hostname as
evidence. There is no EU-only Graph. Microsoft operates
two national cloud
deployments — US Government and China operated by 21Vianet, each with its
own endpoints — and everything else, including every tenant in Frankfurt,
Dublin and Amsterdam, is served by the single global service root
graph.microsoft.com. Tokens are not interchangeable across those
clouds, and an app can only reach tenants registered in the cloud it was
registered in.
So the call itself proves nothing about geography. The data crosses a border at the moment the response is written to disk, not at the moment it is requested — which means residency is a property of the vendor's storage architecture, and no amount of "we use the official Microsoft API" answers it.
Six questions to ask before the consent screen
- Where is the data stored, by name? A country and a provider, not "the EU" as a marketing bullet. Backups and log aggregation count — they are the two that quietly land somewhere else.
- Who are the sub-processors? Hosting, error tracking, analytics, email delivery, the AI feature added last quarter. Article 28 puts the consent for those in your hands; you cannot give it to a list you have never seen.
- What is the retention period, and is it configurable? "Forever" is a common default and an indefensible one. Ask what the number is, then ask what deletes the data when it expires.
- What exactly does erasure delete? Rows in a database, the stored snapshots, or both? A deletion that leaves the parquet files and the nightly backup untouched is a UI change, not an erasure.
- Which permissions does it request, and are any of them
write? Read-only application permissions cap the blast radius of a
breach at your side of the boundary. A tool asking for
ReadWritebecause one feature needs it is asking you to accept that risk for all the features that do not. - Is there a DPA, signed, before the consent link is clicked? Not after the trial. The processing starts at consent.
Two levers you control regardless of the vendor
The first is pseudonymisation at source. Since 1 September 2021 Microsoft hides user information in the usage reports by default, controlled by Conceal user, group, and site names in all reports under Settings → Org Settings → Services → Reports in the admin center. With it on, anything reading those reports — the admin center, your tool, a script — receives opaque identifiers instead of UPNs. You lose per-user drill-down and you keep every aggregate. For a lot of tenants that trade is correct, and it is one checkbox.
The second is scope discipline. Data that never leaves your tenant needs no residency answer at all, which is the strongest argument against the reflex of exporting everything to a spreadsheet before anyone thinks about it — a habit with costs beyond the residency one. Every CSV in a Downloads folder is a copy nobody inventoried, with no retention policy and no erasure path, and it is statistically likelier to end up in a personal mailbox than any vendor's database.
GraphPaaS sits squarely in the middle row of that table and answers accordingly: processing and storage stay inside the EU, we act as data processor under a DPA, the application permissions are read-only, retention is configurable per tenant, and erasure removes both the database rows and the stored snapshots. The reason for collecting at all is the same reason the admin centers cannot show you a trend — a copy is what makes history possible. Which is exactly why the copy deserves an address you can say out loud.
- What is the EU Data Boundary? — the 27 EU plus 4 EFTA countries, the sign-up location rule for Microsoft 365, and the Multi-Geo exclusion.
- Microsoft 365 data locations — the per-workload data location pages and which local region geographies have Advanced Data Residency.
- General Data Protection Regulation — controller versus processor, the Article 28 processor duties including sub-processor consent, 72-hour notification and the fine ceiling.
- Microsoft Graph national cloud deployments — the single global service root, the two national clouds, and that tokens are not interchangeable between them.
- Reports show anonymous instead of actual user names — concealment on by default since 1 September 2021, the affected reports, and where the toggle lives.
Tenant metrics collected read-only, processed and stored inside the EU, with retention you set and erasure that removes the snapshots too.
See how it is built →