Quebec Law 25: The Interprovincial Cloud Compliance Trap

The Compliance Boundary Is Quebec, Not Canada

A Québec business chooses a cloud provider with Canadian servers. The application runs in Toronto, backups stay in Ottawa, and the supplier promises that customer data never leaves Canada.

That sounds like a strong data-residency story. It still leaves one important question unanswered: will personal information be communicated to, or handled by, a person or organization outside Québec?

Québec’s Commission d’accès à l’information guidance for private-sector enterprises describes the outside-Québec obligation as applying both interprovincially and internationally. Ontario and Alberta are therefore outside Québec for this analysis even though they are inside Canada.

This does not mean a Québec business is prohibited from using Toronto hosting, Calgary cloud infrastructure or an international provider. It means that “hosted in Canada” is not the end of the compliance review.

I think this is the easiest place for hosting buyers to get tripped up. The Canadian border feels like the obvious sovereignty boundary. Section 17 forces the organization to look one level closer at the provincial boundary and at the actual service arrangement.

What “Law 25 Section 17” Actually Requires

Law 25 amended Québec’s existing Act respecting the protection of personal information in the private sector. In cloud-procurement discussions, “Law 25 section 17” usually refers to section 17 of that amended private-sector Act.

Before an enterprise communicates personal information outside Québec, section 17 requires a privacy impact assessment. In French this is an évaluation des facteurs relatifs à la vie privée, or EFVP. English material generally calls it a PIA.

The strengthened outside-Québec requirements have been in force since September 22, 2023. Section 17 also applies where an enterprise entrusts a person or body outside Québec with collecting, using, communicating or keeping personal information on its behalf.

The statute identifies four factors that the assessment must consider in particular:

The key point is that the law asks for an assessment of the arrangement, not a country-name check. A Toronto deployment and a Calgary deployment both cross the Québec boundary, but the data, provider, safeguards and legal circumstances can be very different.

If the assessment establishes that the information would receive adequate protection, the communication can proceed. Section 17 also requires the outside-Québec communication to be governed by a written agreement that takes the assessment results and any agreed risk-mitigation terms into account.

Canadian Cloud Regions Can Still Cross Provincial Lines

Cloud-region names make this distinction less obvious than it sounds. “Canada Central” can mean one province at one provider and a different province at another.

The locations below come from provider documentation and are included as geographic examples. They are not findings that any provider or configuration is compliant or non-compliant with Law 25. The CAI’s collection and transparency guidance gives a directly relevant example of personal information being stored with a cloud provider in Ontario.

Redundancy can create the interprovincial flow

Microsoft currently lists Canada East and Canada Central as paired Azure regions in its Azure reliability documentation. Microsoft also makes an important distinction: a region pair does not automatically mean every service replicates data. The actual service and redundancy configuration determine what happens.

For example, Azure Storage configured for geo-redundant storage can copy data from the primary region to its paired secondary region. A Québec organization using Canada East with that type of replication can therefore end up with an Ontario copy even though the architecture is entirely Canadian.

Click to enlarge

This is why I would not accept “everything is in Canada” as the final answer on a Québec hosting questionnaire. I would ask for the provinces, the service configuration, the contracting entities and the backup and recovery locations.

A Practical EFVP Workflow for Out-of-Province Hosting

The steps below are a practical procurement workflow based on the legal requirements and guidance. They are not a regulator-issued checklist.

1. Define the service before evaluating the supplier

Describe the real deployment. “Canadian cloud hosting” is too vague. A useful description might be: a Toronto application server, a managed database in the same region, backups in Ottawa and a separate support-ticket service.

I would record the enabled services, contracting entity, processing locations, backup locations, administrator locations, retention settings and connected third-party tools. Another reviewer should be able to understand exactly what is being approved.

2. Identify the personal information involved

Do not stop at the customer database. Review account records, form submissions, uploaded documents, support tickets and diagnostic exports. Logs can contain names, email addresses, IP addresses, identifiers or request content depending on the application.

Removing personal information that is not necessary can simplify the design and reduce the scope of the arrangement.

3. Involve the privacy officer early

A hosting migration can engage more than section 17. Québec’s private-sector framework also requires an EFVP for projects to acquire, develop or overhaul an information system or electronic service involving personal information. The privacy officer must be consulted from the outset of those projects.

I would put the privacy officer, technical owner and legal counsel in the same discussion before the architecture becomes expensive to change.

4. Request evidence that can be checked

A sales questionnaire is not enough by itself. Ask for the signed terms, a data-location schedule, relevant security reports, a subcontractor list, privileged-access information, retention and deletion procedures, and the provider’s process for legal demands.

Record the date and scope of each document. A report for one service or subsidiary may not answer the questions for another.

5. Reach an adequacy conclusion before going live

An EFVP is not complete simply because the risks have been listed. The assessment needs to support the conclusion required by section 17 about adequate protection.

6. Revisit the assessment when the service changes

Cloud deployments do not stay frozen. A new backup region, a new support arrangement, a provider acquisition, a new subcontractor or an optional feature can change how information is handled.

The assessment should describe the deployment you actually use, not the deployment that existed on procurement day.

Does a US-Owned Cloud Provider in Ontario Change the Analysis?

US ownership does not automatically make an Ontario deployment unlawful. It also does not, by itself, prove that a Québec customer has additional liability.

What it can do is add questions about legal access and operational control that a location-only assessment cannot answer.

The CLOUD Act is about control, not just the server address

The US CLOUD Act amended the Stored Communications Act so that covered providers subject to US legal process can be required to produce information within their possession, custody or control regardless of whether the information is stored inside or outside the United States. The US Department of Justice’s CLOUD Act overview explains that physical storage location is not the whole jurisdiction test.

That does not mean US authorities have unrestricted access to every Canadian server, and it does not mean every foreign subsidiary is automatically controlled by a US parent for every legal purpose.

For an EFVP, I would ask counsel to look at the contracting entity, parent and subsidiary relationships, who can actually obtain readable information, and which entities could be required to respond to valid legal process.

A Canadian server address does not answer those questions. A Canadian ownership label does not automatically answer them either.

This is also where HostScout’s broader data-centre ownership research becomes relevant. Data location and corporate control are separate facts, and both may matter depending on the risk being assessed.

FISA Section 702 Is a Separate, Date-Sensitive Question

The CLOUD Act and FISA Section 702 are often mentioned in the same sovereignty discussion, but they are different legal mechanisms.

Section 702 has been used for foreign-intelligence collection targeting non-US persons reasonably believed to be outside the United States under a certification and provider-assistance framework. It is not the ordinary criminal-investigation process described above, and its existence is not evidence that every Québec customer of a US cloud company is a surveillance target.

There is an additional 2026 wrinkle. Section 702’s statutory authorization lapsed on June 12, 2026 after Congress did not pass another extension. That does not mean every existing collection activity stopped on that date. A Brennan Center overview of Section 702 explains the sunset and why existing court-approved certifications can remain relevant during the transition period.

For a 2026 provider assessment, I would avoid a checkbox that simply says “Section 702 active” or “Section 702 expired.” The useful question is what authority and provider obligations are actually in force for the service and entity being assessed at the time of the review.

Encryption Helps, but Key Control Matters

“Encrypted at rest” is useful information. It is not a complete answer to who can read the data.

For the technical side of an EFVP, I would ask the provider to walk through one concrete example: who can retrieve a customer record, through which systems, with whose authorization, and using which keys?

Then I would check whether the provider can access or invoke the decryption keys, whether privileged administrators can obtain readable data, and whether logs, backups and exported diagnostics receive comparable protection.

Customer-controlled keys can reduce some forms of provider access, but the benefit depends on the architecture. If the application must decrypt information inside the provider’s environment to perform its work, the assessment still needs to account for that processing path.

The Hosting Contract Has to Match the Assessment

Two provisions are easy to blur together: section 17 and section 18.3. They deal with related cloud-procurement issues, but they are not the same requirement.

Section 17: the outside-Quebec agreement

When section 17 applies, the communication outside Québec must be covered by a written agreement that takes the EFVP results into account, including any terms agreed to mitigate identified risks.

If the assessment only approves Toronto and Ottawa, or depends on a particular access restriction or retention limit, the signed terms should support that condition. A broad statement that a supplier will “comply with applicable law” can leave the actual architecture undocumented.

Section 18.3: service-provider conditions

Section 18.3 allows certain communications of personal information without individual consent where the information is necessary to carry out a mandate or perform a service contract, subject to its conditions.

For an ordinary commercial hosting arrangement relying on that provision, the mandate or contract must be in writing and address confidentiality, use limited to the mandate or contract, and non-retention after the mandate or contract ends. The service provider also has duties around notifying the privacy officer of confidentiality violations or attempted violations and allowing verification of confidentiality requirements.

Beyond those statutory points, I would use the EFVP to identify contract topics that need more precise treatment:

A contract can make safeguards enforceable. It cannot make another jurisdiction’s binding law disappear. The review still needs to separate what the supplier has promised from what the supplier could be legally required to do.

Worked Example: A Montreal Business Choosing Toronto Hosting

Consider a fictional Montréal retailer moving its customer portal. The application and database will run in Toronto. Backups will be stored in Ottawa. A support provider has technicians in the United States.

The customer database contains names, delivery addresses, order histories and messages submitted through the portal.

I would document the Toronto environment and Ottawa backup service as separate locations. Then I would ask what the support technicians can actually access.

There is a meaningful difference between access to an empty test environment, access to encrypted infrastructure without decryption capability, and access to readable production records.

I would also check whether support tickets receive database extracts, screenshots or log files containing personal information. A tightly controlled production system does not help much if troubleshooting routinely copies customer data into another platform.

Possible design changes could include removing unnecessary personal information from logs, using synthetic test data, restricting production support access, or changing the backup arrangement. None of those is an automatic compliance solution. They are options for the privacy, technical and legal teams to assess.

The decision record then needs to match the final purchased service. If the EFVP approves restricted support access but the actual support plan provides broader access, the assessment no longer describes reality.

Does Hosting Entirely in Quebec Remove the Problem?

Québec-only infrastructure can remove a particular out-of-province storage flow. That can simplify the analysis. It does not automatically prove that the entire service is compliant.

You still need to know where backups go, who administers the service, which organization provides support, whether subcontractors handle personal information, and what optional integrations do.

There is also a separate EFVP requirement for certain information-system or electronic-service projects involving personal information, even when the replacement system stays in Québec.

A local region is evidence about location. It is not evidence about every other part of the service.

This is closely related to the distinction in HostScout’s data residency vs. data sovereignty guide. Residency answers where the information sits. Compliance and sovereignty questions can extend into who controls the service, the hardware, the keys and the legal relationships around it.

The hosting question I would ask first

I would not start by asking a provider: “Are you Law 25 compliant?”

I would ask: Can you document where our personal information will be handled, who can access it, which entities are involved, and which protections we can rely on?

That gives the privacy officer, lawyer and technical team something concrete to assess.

For Québec businesses evaluating Canadian cloud services, “hosted in Canada” should be the start of the investigation, not the conclusion. If you only need to establish the network-location side first, HostScout’s Is It Hosted In Canada? tool can help identify where a public-facing service resolves before the deeper contractual review begins.

Frequently Asked Questions