Canadian Data Residency on Azure: FIPPA, PIPA and Canada Central vs Canada East

For most BC organizations, no law says your data has to stay in Canada. BC public bodies lost that requirement in 2021, when amendments to the Freedom of Information and Protection of Privacy Act (FIPPA) replaced it with a risk assessment: if sensitive personal information will be stored outside Canada, the public body completes a supplementary assessment inside its privacy impact assessment (PIA). Private organizations under BC’s PIPA or the federal PIPEDA have never had a general residency rule, but they remain accountable for anything they send abroad, and a client contract can still impose one.

In practice, most of our BC clients still keep regulated data in Canada, because it is the simplest position to defend in a PIA. On Azure that means Canada Central (Toronto) and Canada East (Quebec City), enforced with Azure Policy at management group scope. It also means knowing which services and AI deployment types process data outside the region you picked, which is where most reviews fall short.

This article describes our consulting approach. It is not legal advice. Confirm your obligations with your privacy officer or legal counsel.

What FIPPA requires of BC public bodies

The amendments received royal assent on November 25, 2021. The province’s own summary says they remove “restrictions that prevented public bodies from storing information outside of Canada” and strengthen PIA requirements in their place (BC government, Data Residency Changes). Three provisions now carry the weight.

Section 33.1 of the Act. A public body may disclose personal information outside Canada only in accordance with the regulations, if any, made by the minister (FIPPA, BC Laws).

The Personal Information Disclosure for Storage Outside of Canada Regulation (B.C. Reg. 294/2021). It requires the head of a public body to assess any program, project or system in which sensitive personal information is disclosed to be stored outside Canada, and to do it as part of the PIA under section 69 (BC Laws). Programs that existed when the regulation took effect are exempt, as is information made public under section 33(2)(f).

PIAs for every public body. Section 69 requires ministries and other public bodies to conduct PIAs in accordance with the minister’s directions. The province’s guidance on disclosures outside of Canada notes that ministries document the supplementary assessment in the PIA, while other public bodies may choose their own format.

Sensitive personal information is not defined

FIPPA does not define “sensitive personal information”. Provincial guidance treats it as a question of type and context, with health, financial, biometric and criminal records as common examples.

Section 30 still applies

Public bodies still have to make reasonable security arrangements under section 30, and the Commissioner’s office says disclosure outside Canada “demands a very high level of rigour” (OIPC BC, March 2022). Its assessment factors include the legal framework of the destination country, the volume and sensitivity of the data, and whether a reasonable alternative exists in Canada.

That last factor is the practical one. When Azure offers two Canadian regions, a PIA that stores health data in a US region has to explain why the Canadian option was not reasonable.

PIPA and PIPEDA for private organizations

BC’s Personal Information Protection Act (PIPA) covers corporations, not-for-profits, charities, trade unions and credit unions in the province (OIPC BC). The federal Office of the Privacy Commissioner lists BC’s PIPA as substantially similar to PIPEDA, but PIPEDA still applies to federally regulated businesses such as banks and telecoms, and to personal information that crosses provincial or national borders (OPC).

Neither law contains a general data residency rule. The OPC’s cross-border guidance is explicit that PIPEDA does not prohibit transfers for processing, but the transferring organization stays accountable. It must use contracts to secure a comparable level of protection and tell individuals their information may be processed in another jurisdiction (OPC guidelines).

Residency still reaches the private sector through contracts. A company that processes data for a health authority usually inherits that client’s residency clause, and the contract becomes the binding constraint.

Canada Central or Canada East?

Microsoft runs two Azure regions in Canada, and they are paired with each other (Azure regions list).

	Canada Central	Canada East
Location	Toronto	Quebec City
Availability zones	3	None listed
Paired region	Canada East	Canada Central
Service breadth	Broader	Narrower; check each service
Typical role	Primary production region	Disaster recovery and backup target

Because the pair sits inside the Canada geography, geo-redundant storage replicates to Quebec City rather than to a US region. Microsoft is also clear that a pair does not give you disaster recovery by itself (region pairs). You still design and test failover.

The design we usually recommend for BC clients: production in Canada Central across availability zones, replication to Canada East for disaster recovery, and a check that every service in the design exists in both regions before sign-off, because Canada East lacks some services and SKUs.

Enforcing residency in Azure

A residency decision that lives only in a PIA will drift. The control that holds up in audits is Azure Policy, assigned at the management group so every current and future subscription inherits it. This belongs in the landing zone from day one.

Use two built-in definitions together:

• Allowed locations (e56962a6-4747-49cd-b67b-bf8b01975c4c) denies resources outside the regions you list.
• Allowed locations for resource groups (e765b5de-1225-4ba3-bd56-1ac6695af988) covers resource groups, which the first policy skips.

# Deny any resource outside the two Canadian regions, for every subscription under the management group
az policy assignment create \
    --name "allowed-locations-canada" \
    --display-name "Allowed locations: Canada only" \
    --policy "e56962a6-4747-49cd-b67b-bf8b01975c4c" \
    --scope "/providers/Microsoft.Management/managementGroups/<mg-id>" \
    --params '{"listOfAllowedLocations": {"value": ["canadacentral", "canadaeast"]}}'

Two limits matter. The built-in definition excludes resources that use the “global” region, so non-regional services pass straight through (built-in policy reference). And genuine exceptions belong in policy exemptions with an expiry date and a named approver.

Services that can quietly process data outside Canada

Region policy controls where a resource lives. It does not control where every service processes data. Three categories need to be named in the PIA.

Non-regional services. Microsoft Entra ID is non-regional and may store identity data globally for most geographies. CDN and Front Door cache content at edge locations worldwide (Microsoft Learn). Keep sensitive content out of edge caches and document identity data as a known flow.

AI model deployment types. This is the gap we see most often in AI reviews. In Microsoft Foundry, a Global deployment may process prompts and responses in any geography where the model is deployed. A Data Zone deployment keeps processing inside a Microsoft-defined zone, such as the US or the EU, and none of those zones is Canada. Data at rest stays in the resource’s geography in both cases (deployment types). Only a Standard (regional) or regional provisioned deployment keeps inference in Canada.

The trap is that a Foundry resource in Canada Central passes the Allowed locations policy while a Global deployment underneath it sends prompts elsewhere. Microsoft documents a custom policy that denies deployments by SKU name, such as GlobalStandard. Assign it next to the location policy for any workload that handles personal information, and check which models are offered as regional deployments in Canada before you promise one to the business.

Replication settings. Storage GRS stays in Canada because of the pairing. Azure SQL active geo-replication can target any region, so check it too.

Common questions

Is Azure OpenAI data kept in Canada?

It depends on the deployment type. Standard (regional) deployments in a Canadian region process prompts in that region. Global deployments can process them in any geography, and Data Zone deployments process within a zone such as the US or EU.

Does the Allowed locations policy catch everything?

No. It skips resources in the “global” region, and it checks where a resource lives, not where a model deployment processes prompts. Pair it with the resource group variant and a SKU deny policy for AI deployments.

Do geo-redundant backups leave Canada?

Not for storage. GRS replicates to the paired region, and Canada Central and Canada East are paired with each other. Azure SQL active geo-replication is configured separately and can target any region, so confirm its target.

A checklist for your privacy review

We use this table to structure the joint review between privacy and cloud teams.

#	Question	Evidence the cloud team should provide
1	Which law applies: FIPPA, PIPA, PIPEDA, or a contract clause?	Legal basis confirmed by privacy office
2	Is any of the data sensitive personal information?	Data classification per system
3	Does any sensitive data leave Canada, at rest or in processing?	Data flow diagram including non-regional services
4	Is residency enforced, not just documented?	Allowed locations assignments at management group scope
5	Are AI deployments regional?	Deployment type inventory and SKU deny policy
6	Where do backups and replicas go?	Storage redundancy and database replication settings
7	Are exceptions time-bound and approved?	Policy exemptions with expiry and approver
8	Who can reach the data from outside Canada?	Support access and admin access model
9	Is a supplementary assessment required?	Completed assessment in the PIA, where applicable

Techrupt builds these controls into a landing zone a privacy officer can sign off, as part of our Azure landing zone consulting and wider Azure consulting in Vancouver. If you want your residency policy and PIA evidence checked against this table, book a consultation.