British Columbia's Freedom of Information and Protection of Privacy Act (FIPPA) historically imposed the strictest data residency requirement in Canada. Section 30.1 required public bodies to store personal information "only in Canada" and ensure it was "accessed only in Canada." In 2021, Bill 22 fundamentally changed this framework. The blanket prohibition is gone. In its place is a risk-assessment model that creates more compliance work, not less — and most BC public bodies haven't caught up.

What changed

2004
Section 30.1 enacted. BC becomes the only province to require public bodies to store and access personal information exclusively in Canada. The strictest data residency provision in the country.
2016
Legislative review. Health authorities, universities, and school districts push for relaxation. The committee recommends no changes, citing "adequate alternatives" like Canadian cloud regions.
2020
COVID-19 emergency order temporarily lifts the Canada-only restriction so public bodies can use collaboration tools like Zoom and Teams for remote work. The temporary measure signals the government's intent to modernize.
2021
Bill 22 amends FIPPA. The blanket Canada-only storage prohibition is removed. Public bodies can now store sensitive personal information outside Canada — but must complete a privacy impact assessment that evaluates the jurisdictional risks of the receiving country.

The key shift: BC moved from a geography-based rule (data must stay in Canada) to a risk-assessment model (data can leave Canada if you've evaluated and documented the jurisdictional risk). This is conceptually similar to Quebec's Law 25, which requires Transfer Impact Assessments for cross-border data transfers.

What BC public bodies must do now

Under the amended FIPPA, any BC public body that uses — or plans to use — a SaaS tool that stores sensitive personal information outside Canada must complete a privacy impact assessment. The BC government has issued directions on how these assessments must be conducted. Here's what the process looks like for SaaS tools:

Step 1
Inventory your SaaS stack
Identify every SaaS tool your organization uses that processes personal information. For each tool, determine: what personal information flows through it, where the data is stored, and whether any data is stored or accessed outside Canada. Most BC public bodies use 20-60 SaaS tools. See our SaaS inventory guide →
Step 2
Classify the data sensitivity
The PIA requirement applies specifically to sensitive personal information stored outside Canada. FIPPA does not define "sensitive," but the BC Privacy Commissioner's guidance indicates that medical, financial, genetic, and biometric information is almost always sensitive. Contextual factors matter — even routine data can be sensitive depending on how it's used. Public bodies must make this determination for each tool.
Step 3
Assess the jurisdictional risk
This is the core of the new framework. For each tool that stores sensitive data outside Canada, the PIA must evaluate: the legal protections (or lack thereof) in the foreign jurisdiction, whether foreign government access laws apply (e.g., the US CLOUD Act), the likelihood of unauthorized access, and the impact to individuals if it occurs. This is where jurisdictional intelligence matters — and where most public bodies get stuck. Understand the CLOUD Act →
Step 4
Evaluate mitigations
If jurisdictional risk exists, the PIA must document what mitigations reduce it. Common mitigations include: customer-managed encryption keys, contractual restrictions on foreign government access, Canadian data residency where available, and minimizing the personal information stored in the tool. The effectiveness of these mitigations varies — for example, Canadian data residency does not eliminate CLOUD Act exposure if the vendor is US-parented. Data residency vs sovereignty →
Step 5
Document and maintain
The PIA must be documented and maintained. Any significant change — a vendor acquisition, a change in data storage location, a new subprocessor — requires the PIA to be updated. This is not a one-time exercise. Minimum compliance documentation →

Common SaaS tools and their jurisdictional risk

Most BC public bodies rely on a core set of SaaS tools. Here's a summary of their jurisdictional profile relevant to the FIPPA PIA requirement:

Microsoft 365
US parent (Microsoft Corp)
CLOUD Act exposed
Google Workspace
US parent (Alphabet Inc)
CLOUD Act exposed
Salesforce
US parent (Salesforce Inc)
CLOUD Act exposed
Zoom
US parent (Zoom Video Comm)
CLOUD Act exposed
Slack
US parent (Salesforce Inc)
CLOUD Act exposed
AWS
US parent (Amazon.com Inc)
CLOUD Act exposed
ServiceNow
US parent (ServiceNow Inc)
CLOUD Act exposed
TELUS Cloud
Canadian parent (TELUS Corp)
Canadian controlled
OpenText Sovereign Cloud
Canadian parent (OpenText Corp)
Canadian controlled

The majority of tools used by BC public bodies are operated by US-parented companies. This doesn't mean they can't be used — it means each one requires a PIA that evaluates the CLOUD Act risk and documents the mitigations in place. Search the full Sovereignty Index for 292+ tools →

Who this applies to

FIPPA applies to all BC public bodies, which includes:

Health authorities — Vancouver Coastal Health, Fraser Health, Interior Health, Island Health, Northern Health, PHSA, Providence Health Care
Universities and colleges — UBC, SFU, BCIT, UNBC, UVic, all BC colleges and institutes
School districts — all 60 BC school districts
Municipalities — City of Vancouver, City of Surrey, City of Burnaby, and all BC municipalities
Crown corporations — BC Hydro, ICBC, BC Housing, BC Lottery Corporation
Provincial ministries — all BC government ministries and agencies
Regulatory bodies — professional regulatory organizations under FIPPA jurisdiction

Each of these organizations uses SaaS tools. Each tool that stores sensitive personal information outside Canada requires a PIA under the amended FIPPA. The practical challenge is scale — a health authority with 40 SaaS tools needs 40 jurisdictional assessments, not one.

The gap between requirement and reality

The 2021 amendment created a more sophisticated compliance obligation, but most BC public bodies are still catching up. Common challenges include:

No complete SaaS inventory. Most public bodies don't have a comprehensive list of every SaaS tool in use, let alone a jurisdictional map of each vendor's parent company and data storage locations.

No standardized jurisdictional analysis. The PIA requires evaluating "the legal protections in the receiving jurisdiction." For most privacy officers, this means researching the CLOUD Act, understanding parent company jurisdiction, and evaluating subprocessor chains — from scratch, for each tool.

No monitoring. Vendor ownership changes (acquisitions by foreign companies), data centre relocations, and new subprocessors can change a tool's jurisdictional risk overnight. Most PIAs are point-in-time documents that aren't updated.

This is the problem Upper Harbour's Sovereignty Index and HarbourScan are designed to solve — providing the jurisdictional intelligence layer that makes PIA completion systematic rather than manual.

How to start

If you're a privacy officer, IT director, or procurement lead at a BC public body, here's a practical starting point:

1. Run a free HarbourScan. HarbourScan maps your SaaS stack to parent jurisdictions in minutes. You'll see which tools are CLOUD Act exposed, which have Canadian data residency, and which require a PIA under the amended FIPPA.

2. Prioritize by data sensitivity. Not every tool needs the same level of assessment. Start with tools that process health data, financial data, employee records, and student records — these are almost always "sensitive" under the PIA framework.

3. Use the Sovereignty Index. Search the Index for any tool to see its parent jurisdiction, CLOUD Act status, data residency options, and Canadian alternatives.

4. Document systematically. Use a consistent PIA template for each tool. Upper Harbour provides a free FIPPA PIA template designed specifically for SaaS vendor assessments under the amended framework.