Canadian Data Residency in Public-Sector and Health Procurement: Rules and Evidence

Most residency clauses in Canadian public-sector and health procurements do not come from one law that says “host in Canada”. They come from a federal directive that makes Canadian facilities the principal option to evaluate for sensitive government data. They also come from Québec laws that require a privacy impact assessment before personal information leaves Québec, a Nova Scotia statute for public bodies, and the buyer’s own procurement policy. A supplier has to show where every copy of the data lives, who can reach it and from where, and which contract terms hold that placement in place.

This guide is for the IT director, privacy officer or procurement lead at a Canadian public body or health organization. It is also for the SaaS company or agency that sells into them and has to answer a residency questionnaire. It is not legal advice. Counsel and the organization’s privacy officer decide what the law requires in a given case. The rules below were checked against their official sources on October 29, 2026.

For the general list of what to require from any hosting provider, see the companion guide on Canadian data residency requirements for a hosting provider. This article covers the rules behind public-sector and health clauses, and the evidence a supplier must produce.

What does a residency clause in a public or health procurement usually ask for?

Data residency is the physical location where data is stored and processed. Data sovereignty asks a wider question: which country’s laws can reach the data, which depends on who owns and controls the provider as well as on where the servers are.

Residency clauses in Canadian solicitations tend to take one of five shapes.

1. A storage rule. Data, backups included, must be stored on infrastructure located in Canada, or in Québec.
2. An access rule. Data may be accessed only from inside Canada, which reaches support staff and subcontractors as well as servers.
3. An assessment rule. Any communication of personal information outside the province requires a privacy impact assessment (PIA) first. A PIA is a documented review of the privacy risks of a project or a transfer.
4. A classification rule. Data at a given security category, such as Protected B, must sit in a defined kind of environment.
5. A flow-down rule. Every obligation binds the supplier’s own subcontractors.

The rest of this guide traces each shape back to the rule that usually produces it.

What do federal rules require for Government of Canada data?

The Treasury Board Directive on Service and Digital sets the federal rule. Section 4.3.24 makes the departmental chief information officer (CIO) responsible for certain computing facilities. These are facilities “located within the geographic boundaries of Canada”, or on the premises of a department abroad such as a diplomatic or consular mission. The CIO must ensure they are “identified and evaluated as a principal delivery option”. That applies to sensitive electronic information categorized as Protected B or Protected C, or classified.

Three points follow from the wording.

• It is an evaluation duty, not a statutory ban. The directive tells the department to evaluate Canadian facilities as the principal option. A solicitation usually converts that into a firm requirement, and the solicitation is what a supplier signs.
• It binds the department. A supplier meets it through the contract the department writes.
• It sits next to a cloud expectation. Section 4.3.2.4 covers proposals at Protected B or below that use a deployment model other than public cloud. The departmental CIO must send them to the Government of Canada Enterprise Architecture Review Board. A private or managed hosting design for a federal department therefore faces an extra architecture review.

The Government’s 2018 white paper on data sovereignty and public cloud concluded that, at that time, only data up to and including Protected B should be stored in commercial public cloud. It also stated that Canada “cannot ensure full sovereignty over its data when it stores data in the cloud”. The page now points readers to the Digital Sovereignty Framework, which says its intent is not to introduce new requirements.

Federal buyers may also ask whether a cloud service has gone through the Canadian Centre for Cyber Security’s cloud security assessment program. The program assesses the controls a vendor directly controls, against profiles for services processing up to Protected B. The Cyber Centre describes the output as a reusable report, and it states that each department must still conduct its own security assessment and authorization.

What does Québec law require before personal information leaves Québec?

Québec has three parallel rules, one per sector. Each requires an assessment and a written agreement before personal information goes outside Québec. None of them is a flat prohibition.

In each act, the PIA must weigh four factors. They are the sensitivity of the information, the purposes of its use, the protection measures including contractual ones, and the legal framework at the destination. Each act also applies the rule when the organization entrusts someone outside Québec with collecting, using, communicating or keeping the information on its behalf. A hosting supplier with a standby in Ontario or a log service in the United States is exactly that case.

Two related sections shape the contract. Section 18.3 of the private-sector act and section 67.2 of the access act require the mandate to be in writing. They also require it to set out the confidentiality measures, limit use to the mandate, and end retention when the contract ends. Public bodies must also conduct a PIA for any project to acquire, develop or overhaul an information system involving personal information (section 63.5 of the access act). Businesses have the same duty under section 3.3 of the private-sector act.

Health adds detail. The health information act came into force on July 1, 2024. Under section 77, a contract with a supplier that is not itself a health and social services body must, on pain of nullity, set out the provisions of the Act that apply. It must also set out the measures that protect the information, in line with the body’s information governance rules. A health-sector questionnaire therefore tends to arrive with contract language already drafted.

For what this means on a common hosting stack, see the knowledge base article on Québec data residency on cPanel in practice. Québec’s Law 25, adopted in 2021, introduced these assessment rules into the private-sector and access acts.

How does the Québec government approach cloud for public bodies?

The Ministère de la Cybersécurité et du Numérique (MCN) published the Énoncé d’orientations en infonuagique et en hébergement under Arrêté 2026-02. It applies to public bodies covered by Québec’s act on the governance and management of information resources. It covers information assets held on or after May 20, 2026, and replaces the cloud orientations of July 8, 2019.

• Orientation 1 hosts “highly sensitive” data on sovereign infrastructure. Highly sensitive means Protégé C, Secret or Très secret, plus Protégé B or Confidentiel data that the chief information officer judges critical. The sovereign options listed are the Nuage gouvernemental du Québec, a data centre owned by the Québec or Canadian government, or a public cloud infrastructure designated by the minister. A body that cannot meet the orientation may apply documented risk-mitigation measures.
• Orientation 2 requires that personal information entrusted to cloud providers located outside Québec respect section 70.1 of the access act.
• Orientation 6 asks public bodies to favour the offers of the government’s Courtier en infonuagique et en technologies spécialisées, the MCN’s cloud broker. The text invites bodies to favour these offers. It does not oblige them to.

For a supplier, the practical reading is that highly sensitive Québec government data is out of reach for a commercial host that is not on the sovereign list. For other personal information, the section 70.1 assessment decides.

What do other provinces and federal privacy law say?

Rules elsewhere in Canada differ, and some have changed. These are the ones this guide verified against official text.

• Nova Scotia. The Personal Information International Disclosure Protection Act (PIIDPA, 2006) requires public bodies to keep personal information in their custody or control stored and accessed only in Canada, with exceptions. One exception lets the head of the body allow storage or access outside Canada to meet the necessary requirements of its operations. The PIIDPA regulations require those decisions to be reported to the Minister each year.
• British Columbia. The 2021 amendments to the Freedom of Information and Protection of Privacy Act repealed the storage-and-access-in-Canada rule (former section 30.1). Section 33.1 now lets a public body disclose personal information outside Canada only in accordance with the regulations, if any, made by the minister.
• Federal private sector. The Office of the Privacy Commissioner’s guidelines for processing personal data across borders state that PIPEDA, the federal private-sector privacy law, does not prohibit transfers for processing. The transferring organization stays accountable and must tell individuals their information may be processed in a foreign country.

Health-sector buyers in Ontario and Alberta may cite PHIPA or Alberta’s Health Information Act. This guide does not summarize either on location, because we did not verify a storage-location rule in them. Ask counsel, and expect the requirement to arrive through the contract and the PIA.

What do residency questionnaires typically ask, and what answers them?

A residency questionnaire turns these rules into questions a supplier answers in writing. The table pairs each common question with the evidence that answers it.

In one example scenario, a Canadian healthcare-adjacent SaaS rebuilt its platform for customer-keyed residency. The trigger was a hospital network procurement officer who asked for written confirmation that data, backups included, stayed on infrastructure located in Canada. The words “backups included” are the part a supplier has to check copy by copy.

For the wider evidence reviewers expect, see the guide on what infrastructure evidence buyers expect after a failed security questionnaire.

How should a supplier answer questions about the US CLOUD Act?

The US CLOUD Act often comes up in public-sector residency reviews. Keep the answer factual.

The US Department of Justice published a white paper on the CLOUD Act. It says the 2018 Act clarified that providers subject to US jurisdiction must disclose data responsive to valid US legal process, wherever they store it. The same paper notes that many countries already have domestic powers of the same kind. The Department’s CLOUD Act resources page records that the United States and Canada announced negotiations toward a CLOUD Act agreement in March 2022.

Canada’s Digital Sovereignty Framework makes the same point from the other side. Most countries, Canada included, let their authorities request information held by organizations within their borders. Using a Canadian supplier or storing data in Canada does not by itself place data outside foreign courts’ jurisdiction. The framework also states that the Government of Canada found no documented cases of foreign governments seeking access to Canadian enterprises’ data held by suppliers. The OPC guidelines add that no contract can override the laws of the country where information is held.

A supplier’s useful answer covers three facts. It names who owns and controls the company and the facilities. It states the policy for responding to a legal demand, including whether the client is told. It also lists which subcontractors are subject to foreign jurisdiction. Counsel then weighs the risk for the specific workload.

What evidence should a supplier have ready before the questionnaire arrives?

A supplier that prepares these eight items in advance can answer a residency questionnaire from records instead of from memory.

1. A data-flow diagram that shows every system that stores or processes the data, tooling included. The knowledge base article on Canadian-only deployment patterns with explicit data-flow diagrams shows what a defensible diagram contains.
2. A location register for the primary, standby, backups, logs and monitoring data.
3. A subcontractor inventory with each subcontractor’s role and location.
4. An access statement naming where staff and support access come from, backed by access logs.
5. Draft contract clauses on residency, subcontracting, incident notification and return or destruction of data, written so they can sit inside the buyer’s mandate contract.
6. Input for the buyer’s PIA organized by the four Québec factors: sensitivity, purpose, protection measures and the legal framework at the destination.
7. Third-party attestations labelled with the holder’s name, so a reviewer never mistakes a facility’s report for the supplier’s own.
8. Operational records, such as restore tests, patch logs and audit-log samples. The knowledge base covers building a PIPEDA and Law 25 evidence trail and audit log retention across several regimes.

Which kind of hosting fits a public-sector or health residency clause?

The right environment depends on the data’s category and on who the buyer is.

When should residency not drive the hosting decision?

Residency is one requirement among several. It should not decide the architecture in these cases.

• The data is neither personal nor classified. A public brochure site or open-data portal can be placed on latency, cost and who operates it.
• A federal department expects public cloud. At Protected B or below, the directive sends non-public-cloud designs to an extra architecture review. A Cyber Centre-assessed public cloud service in a Canadian region may be the shorter path.
• The data is highly sensitive under Québec’s orientations. Only the sovereign infrastructure listed by the MCN qualifies, and a commercial host does not belong in that decision.
• The real gap is operations. If backups are untested and patches are months behind, moving the servers will not satisfy the reviewer. Fix the operation first.
• The PIA concludes that a Canadian location outside Québec gives adequate protection. Then a Québec-only design may add cost without reducing a risk the organization has accepted.
• The workload needs services or regions a Canadian provider does not offer. A global platform’s Canadian region, carefully pinned, may be the right answer.

Where Stack Harbor fits

Stack Harbor Inc. is a Canadian-owned managed services provider headquartered in Montréal, Québec. It runs production cloud environments for SaaS companies, agencies and publishers, in English and French. In public-sector and health procurement, its typical client is the vendor or agency answering the questionnaire, or an organization that needs its application hosted and operated in Canada.

Stack Harbor’s own infrastructure runs in two data centres in Montréal. One of them is operated by eStruxture, and the knowledge base explains why Stack Harbor hosts in eStruxture data centres. A workload placed on Cloud Compute stays in Canada, and the placement is documented. Because both data centres are in Montréal, a design with its primary and standby there keeps those copies in Québec. Any use of a US or partner region is a decision made with the client at design time and recorded.

Residency, subcontracting, breach notification and the return or destruction of data are written into the agreement. Stack Harbor does not certify a platform compliant. The client’s privacy officer makes that determination, and Stack Harbor supplies operational evidence for the controls it runs. Ongoing operations run under Managed Cloud Ops, with the scope set per environment.

The limits are stated on the Trust & Security page. Stack Harbor holds no SOC 2 report and no ISO 27001, PCI DSS or HIPAA certification of its own. eStruxture states that all its facilities are ISO/IEC 27001:2022 certified and externally audited for a SOC 2 Type 2 report (eStruxture’s security and compliance page). Those attestations are eStruxture’s and cover the facility layer. Availability and response commitments are in the published SLA. The residency statements above apply to Stack Harbor’s data centres. They do not extend to a client-owned AWS, Azure or Google Cloud account that Stack Harbor operates.

Stack Harbor does not publish prices. Compliance and data residency needs are a named driver in how Stack Harbor scopes and prices engagements. To test a residency clause against a real design, request an infrastructure plan and bring the clause and the questionnaire with you.