Microsoft 365 Copilot in Canada: Data Residency vs. Inference

A Microsoft 365 Copilot deployment project in Canada should never be reduced to a binary question: "do the data stay in Canada?" This formulation masks at least four distinct issues — where data is stored at rest, where a query is processed, what the user can actually find in their organization, and the progress of your own compliance work. This article is intended for Microsoft 365 administrators, privacy officers, and governance teams who must decide whether to deploy now or wait.

Data Residency and Inference: Two Concepts Not to Confuse

The most useful way to evaluate Microsoft 365 Copilot is to clearly separate two concepts: storage ("data at rest") and processing ("inference").

For a tenant eligible and provisioned in Canada and meeting applicable product conditions, Microsoft commits to storing at rest, in the geography concerned, certain categories of customer data — notably the content of Microsoft 365 Copilot interactions retained, as well as the associated semantic index. This is a real contractual commitment: it sets a geographic location for specific data stored by the service, rather than leaving this location completely undetermined.

This commitment does not mean that each element of each Copilot interaction is processed exclusively in Canada. Inference is the calculation that interprets a request (prompt) and produces an answer. Currently published Microsoft documentation indicates that, for customers located outside the European Union, queries can be processed in the United States, in the EU, or in other regions.

Concretely, an organization can rightly claim to have qualifying Copilot interaction content stored at rest in Canada — if its tenant and subscription meet applicable conditions. It should not transform this statement into a guarantee that inference is already taking place entirely in the country.

This distinction is crucial for your vendor questionnaires. A yes/no field "do the data stay in Canada" is too crude to produce a defensible answer. The right answer identifies the data category, the product functionality, the at-rest commitment, the current position on processing location, and your safeguards in case of transfer.

Canada's Local Inference Timeline Postponed to 2027

In November 2025, Microsoft had initially placed Canada in a group of countries targeted by an extension planned for 2026. A subsequent update modified this timeline: the currently published target is a deployment of local inference in Canada in 2027.

This revision has two practical consequences:

• Do not build your compliance case on a now-defunct 2026 deadline. A roadmap is not an available control, and a 2027 target does not equate to a contractual implementation date for your tenant.
• Postponing all preparation until the arrival of local inference can be counterproductive. The highest risks in most Microsoft 365 environments — oversharing, unclear ownership of sites, inactive sites, sensitive documents with broad access — exist today. Local inference will not solve them.

There is a reasonable counter-argument: when a risk assessment concludes that processing certain information abroad is unacceptable, deferring certain use cases until local inference may be prudent. The key point is to make it a documented decision based on data classification, not an implicit assumption.

Bill 25 in Quebec and PIPEDA: What Compliance Actually Requires

A Microsoft service commitment is not enough, by itself, to establish that an organization has met its privacy obligations. The organization must evaluate its own data, purposes, legal framework, suppliers, and operating model.

For a private Quebec business that communicates personal information outside Quebec, Bill 25 requires a privacy impact assessment (PIA) before this communication — including when a third party is tasked with processing the information. The transfer must also be governed by a written agreement that reflects this assessment and the measures it identifies.

In a Copilot context, this assessment should not stop at the "Microsoft 365" label. It should identify, at minimum:

• personal information potentially present in SharePoint, OneDrive, Teams, and Exchange;
• categories of users able to query Copilot on this content;
• the at-rest storage arrangement applicable to the actual tenant;
• the documented position on processing location for the activated functionality;
• technical and contractual measures relevant to the identified flow;
• restrictions and approval conditions necessary for high-risk content.

At the federal level, PIPEDA (Personal Information Protection and Electronic Documents Act) does not categorically prohibit transfer to another jurisdiction for processing. The organization remains accountable: it must use contractual or other means to ensure a comparable level of protection while a third party processes the information.

Not all organizations face exactly the same analysis: Quebec public bodies, federally regulated organizations, or regulated sectors may have additional obligations. A Microsoft 365 license configuration can never establish that an organization has completed a required assessment or negotiated adequate conditions. These are decisions unique to each organization, to be validated with the privacy officer and legal advisors.

Copilot Amplifies Existing Permissions, It Does Not Replace Them

Microsoft 365 Copilot operates within the user's existing permissions: it only surfaces content that the individual has at minimum permission to view. This is an important security boundary, but it does not guarantee that the result produced will be harmless.

The major practical risk is inherited oversharing. A file with broad access, a Teams team with accidental membership, a SharePoint site without an active owner, or a sensitive document in a generally accessible folder may have been difficult to discover through classic navigation. Conversational prompts make it easier to locate and summarize information that was already accessible.

For administrators, the right question is not whether Copilot bypasses permissions. It is: what could a typical employee discover if Copilot made interrogable the entire material they can already view? The answer often reveals a data access debt predating AI.

Implementation: A 5-Step Preparation Program

The most credible path to a defensible deployment is a structured program that reduces exposure before broad activation, leveraging Microsoft Purview and SharePoint Advanced Management to locate sites and files that are overshared, without an owner, inactive, or sensitive.

1. Frame the Scope Precisely

Document which product is activated, which users will receive it, which data sources can feed answers, and confirm the actual provisioning geography of the tenant. Never generalize from another tenant in the same corporate group. Map out envisioned connectors and agents: each has its own privacy conditions.

2. Classify At-Risk Data and Correct Oversharing

Prioritize repositories containing personal information, HR files, legal material, financial data, or sensitive plans. The following script produces a read-only report of SharePoint sites whose sharing capacity exceeds an acceptable threshold:

1# Required module: SharePoint Online Management Shell (Microsoft.Online.SharePoint.PowerShell)
2# Installation: Install-Module -Name Microsoft.Online.SharePoint.PowerShell -Scope CurrentUser
3# Minimum permission: SharePoint Administrator role (read-only for this report)
4# Output: CSV export of sites whose sharing capacity exceeds the accepted threshold
5 
6Connect-SPOService -Url "https://contoso-admin.sharepoint.com"
7 
8# Retrieves all sites, excluding personal OneDrives
9$sites = Get-SPOSite -Limit All -IncludePersonalSite $false
10 
11# Filters sites whose sharing is open to external users or guests
12$sitesAtRisk = $sites | Where-Object {
13    $_.SharingCapability -eq "ExternalUserAndGuestSharing" -or
14    $_.SharingCapability -eq "ExistingExternalUserSharingOnly"
15}
16 
17$sitesAtRisk |
18    Select-Object Url, Title, SharingCapability, StorageUsageCurrent, LastContentModifiedDate |
19    Export-Csv -Path ".\report-sites-at-risk.csv" -NoTypeInformation -Encoding UTF8
20 
21Write-Host "Report generated: $($sitesAtRisk.Count) site(s) to examine before Copilot activation."

This script does not modify anything: it produces a CSV to be validated by business owners. Once a site is validated for correction, the sharing capacity can be tightened individually:

1# Tightens the sharing capacity of a specific site after business validation
2# To be executed site by site, never in an unsupervised loop across the entire tenant
3Set-SPOSite -Identity "https://contoso.sharepoint.com/sites/FinanceProject" -SharingCapability Disabled

3. Apply Protection Controls Before the Pilot

Configure sensitivity and data loss prevention (DLP) controls suited to the organization's data categories, and test them with real workflows — not just in a policy console. For Quebec deployments, integrate these measures into the PIA analysis and written agreement: they constitute proof of adequate protection sought, not just checkboxes.

4. Pilot with Bounded Groups

Start with a group whose data access is understood and whose benefits can be measured. Define allowed scenarios, excluded categories, escalation paths, and who can adjust permissions if the pilot reveals oversharing. A successful pilot produces findings on data exposure and policy effectiveness — not just anecdotal productivity gains.

5. Monitor and Continuously Reassess

Use available risk alerts and governance reports to identify emerging issues, and re-examine each new feature, agent, or connector before activation. This work remains necessary after the arrival of Canadian local inference: a change in processing location improves a geographic posture, it does not correct excessive access nor replace an up-to-date PIA.

Troubleshooting: Common Errors

• Confusing at-rest residency and local inference: verify the documentation of residency currently published for your tenant rather than general marketing communication.
• Answering "yes" to a vendor questionnaire without specifying the data category: systematically detail storage, processing, and scope.
• Activating Copilot before an updated oversharing report: if Get-SPOSite returns a high number of sites in external sharing without an active owner, delay activation for this scope.
• Treating the PIA as a one-time document: revise it with each significant change (new agent, new connector, change in inference geography).
• Forgetting the written agreement required by Bill 25: an assessment without an agreement formalizing identified measures is not complete.

Key Takeaways Before Deployment

The choice is not simply "deploy now" versus "wait until 2027". Most organizations can follow an intermediate path: correct content, complete legal assessment, apply controls, and pilot lower-risk use cases while excluding scenarios that do not meet their risk threshold under the current processing model.

The central discipline is precision: describe Canadian at-rest residency as at-rest residency, not as a guarantee of local inference. Treat permissions as the doorway Copilot uses, but address oversharing as a genuine exposure multiplier.

Concretely, this week: run the SharePoint oversharing report above, have your privacy officer validate the list of points to cover in the PIA, and set a review date for the local inference timeline — without making it a blocking condition for the entire preparation program.