Transfers outside Quebec

Section 17 of the PPIPSA is one of the most impactful for modern SMBs: any communication of personal information outside Quebec requires a prior privacy impact assessment (PIA). This includes, in principle, any cloud service whose servers are not in Quebec — even if the vendor is Canadian (Ontario, British Columbia, etc.).

This chapter clarifies when a PIA is required, how to structure it, and how to minimize the administrative burden.

What is a transfer outside Quebec?#

Communication = any act that makes information accessible to an entity physically located outside Quebec. This includes:

• Hosting on a server outside Quebec (Microsoft Azure East US, AWS us-east-1, Google Cloud us-central1).
• Subcontracting: a Quebec vendor that hosts data on its own out-of-province provider.
• Remote access: an Ontario-based employee who connects to the Quebec server and views data from their workstation.
• Backup: a backup shipped to a non-Quebec data centre.
• Analytics: sending data to Google Analytics, Mixpanel, Hotjar, etc.

What is not a transfer outside Quebec:

• Access by a Quebec-based employee to a Quebec server (data never leaves the territory).
• Hosting in a Canadian data centre located in Quebec (Azure Canada Quebec, GCP Montréal, Cologix MTL, etc.).
• Transmission to a Quebec subcontractor that hosts in Quebec, with express contractual commitment.

The PIA obligation (s. 3.3 + s. 17)#

Before communicating personal information outside Quebec, the person carrying on an enterprise must conduct a privacy impact assessment.

The PIA must analyze:

1. The sensitivity of the information.
2. The purpose of its use.
3. The protection measures (contractual and technical) that would accompany it.
4. The legal regime applicable in the destination country, including the principles of personal information protection that apply there.

And section 17 adds:

The communication is permitted if the assessment shows that the information would benefit from equivalent protection.

The equivalence test#

"Equivalent" does not mean identical. The CAI has indicated that the overall test is whether:

• Individual rights (access, rectification, withdrawal) are guaranteed.
• An independent oversight body exists.
• Effective remedies exist.
• Onward transfers are framed.

Countries with generally equivalent protection#

• Other Canadian provinces: yes for Alberta and British Columbia (provincial regimes recognized as substantially similar to PIPEDA). Case-by-case for other provinces under PIPEDA.
• European Union: yes (GDPR is generally stricter).
• United Kingdom: yes (UK GDPR).

Countries without equivalent protection#

• United States: not globally. The U.S. sectoral regime (HIPAA, GLBA, California CCPA) does not cover all personal information, and governmental access (FISA, CLOUD Act) exposes data beyond Quebec standards.
• Other jurisdictions: assess case by case.

For a transfer to a country without equivalent protection, the communication is still permitted if sufficient contractual measures compensate for the gap. This is the situation of most American SaaS vendors.

Compensatory contractual measures#

A contract with the vendor must, at minimum:

• Frame the purpose of use (the vendor can only use the data for contract purposes).
• Prohibit onward communications without consent.
• Provide for notification of a confidentiality incident on the vendor's side.
• Allow audit, or failing that require external certifications (SOC 2, ISO 27001, ISO 27701).
• Provide for return or destruction of data at end of contract.
• Jurisdiction clauses: Quebec or a friendly jurisdiction.

Microsoft, AWS and Google all publish Data Processing Addenda (DPA) containing standard contractual clauses. For a Law 25 transfer, you must verify and supplement — the "GDPR only" wording is not in itself sufficient.

Structure of a PIA for an SMB#

A PIA doesn't need to be an 80-page document. For an SMB deploying a new SaaS, a 3–5 page structured report usually suffices.

PIA template — condensed version#

1. Description of processing: which service, which vendor, which information, how many people, for how long.
2. Purpose: why the transfer is necessary. Canadian alternatives evaluated.
3. Sensitivity: ordinary / sensitive / mixed. Justification.
4. Data flow: simple diagram showing where the data goes.
5. Legal regime of recipient: country, applicable law, supervisory authority, remedies.
6. Technical measures: encryption at rest, encryption in transit, tenant isolation, restricted access.
7. Contractual measures: reference to the signed DPA, specific clauses added.
8. Residual risks: what remains despite the measures, probability, impact.
9. Decision: transfer authorized / authorized with conditions / not authorized.
10. Review: date of the next review (annual is typical).

Our role on the IT side#

At Hilo Tech, we produce the technical portion of the PIA: data-flow architecture, encryption configuration, access logging, verification of the DPA's technical clauses (residency, encryption, subprocessors, notifications). The legal analysis of the applicable regime and the final decision belong to the client's lawyer.

Concrete examples#

Microsoft 365 Canada Central#

• Default residency: data at rest in Canada (Toronto + Quebec City depending on the service).
• Access: Microsoft employees worldwide can access for support. Microsoft DPA frames this.
• PIA required: yes. But typical conclusion = authorized with conditions (DPA + MFA + logging). Reusable template for all Hilo Tech clients.

ChatGPT Enterprise / OpenAI API#

• Residency: United States. European/Canadian residency available on some plans.
• Use policy: OpenAI commits not to train its models on API data (by default).
• PIA required: yes. Typical conclusion = authorized for non-sensitive uses only; not authorized for health or minor data absent enhanced measures. Alternative: private AI platform (see HiloIntelligence).

On-premises server at head office#

• Residency: Longueuil, QC.
• PIA: not required (no transfer outside Quebec).
• This remains the simplest path under Law 25, at the cost of scalability.

Subcontracting a Quebec vendor hosted outside Quebec#

Classic case: you engage a Quebec billing vendor that, in turn, hosts its servers on a U.S. hyperscaler. Yes, this is a transfer outside Quebec. The Quebec vendor must disclose its dependencies and assume the responsibility of documenting compliance.

Quick checklist#

• Inventory of data flows with identification of those leaving Quebec.
• A PIA exists for each identified flow.
• DPAs for the main vendors are signed and archived.
• Technical conditions (encryption, MFA, isolation) are verified annually.
• Quebec-residency alternatives have been evaluated (even if rejected).
• The privacy officer maintains a central register of PIAs.

Common mistakes#

• "Our SaaS is Canadian, so we're fine." — Canadian ≠ Quebec. An Ontario vendor hosting in Ontario constitutes a transfer outside Quebec. The assessment is still mandatory.
• Copy-pasting the GDPR assessment. — The regimes are comparable but not identical. The CAI expects Law 25-calibrated reasoning.
• Ignoring vendor subprocessors. — Microsoft has subprocessors. AWS has subprocessors. A DPA without an up-to-date subprocessor list is incomplete.
• Doing one global PIA only. — Each distinct purpose, each distinct data category, calls for its own analysis. A global PIA for "Microsoft 365" does not cover a new integrated AI use case added by Copilot.

Questions to ask your legal counsel#

• Is the Ontario regime (de facto provincial PIPEDA) considered equivalent for our Quebec–Ontario transfers?
• Do our current vendor contracts meet section 17, or are addenda necessary?
• What materiality threshold allows a lightweight PIA to suffice?
• Does the U.S. CLOUD Act change the equivalence analysis? How do we document the residual risk?