To meet a Canadian data residency requirement, require the hosting provider to state in writing where the primary environment, the standby, the backups and the logs are located. Require that any placement outside Canada is opt-in and recorded, and that residency, subcontracting, breach notification and the return or destruction of data are clauses in the agreement. A Canadian region on a product page is a starting point. The documented placement and the contract are what a privacy officer, an auditor or a customer’s procurement team will read.
This provider-selection guide is for the chief technology officer (CTO), privacy officer or procurement lead who has been handed a residency clause. It is not legal advice. Your privacy officer or counsel decides what the law requires of your organization.
What does Canadian data residency mean in a hosting contract?
Data residency is the physical location where data is stored and processed. A Canadian data residency requirement says that a defined set of data must stay on infrastructure located in Canada.
Data sovereignty is a wider idea. It asks which country’s laws can reach the data, and that depends on who owns and operates the provider as well as where the servers sit. A provider headquartered outside Canada can store data in a Canadian region and may still be subject to legal process in its home country. Whether that matters is a question for your counsel.
Two privacy laws appear in most Canadian residency conversations. PIPEDA, the Personal Information Protection and Electronic Documents Act, is the federal private-sector privacy law. Law 25 is the Québec law that modernized the province’s rules on the protection of personal information. Under PIPEDA’s accountability principle, your organization stays accountable for personal information even when a provider runs the infrastructure.
Many residency requirements arrive from a customer contract, a request for proposals (RFP) or a public-sector policy rather than from a statute. Read the clause you have been given before you choose an architecture.
A warm standby is a second region kept running at reduced capacity, ready to take over if the primary region fails.
What should you require from a hosting provider in writing?
These six requirements apply to any provider, from a global cloud platform to a Canadian managed hosting provider.
- The location of every copy. Ask for the region of the primary environment, the standby, the backups, the logs and the monitoring data. Backups and logs are easy to overlook. In one example scenario, a Canadian software-as-a-service (SaaS) company that moved from Amazon Web Services (AWS) to managed Cloud Compute had a Crown-corporation deal that turned on one requirement: production data, including backups and logs, in Canada.
- Non-Canadian placement as an exception. The default should be Canada. Any use of a foreign region, such as an edge cache or a shard for US customers, should be a decision made with you and recorded.
- Where the standby lives. Disaster recovery copies data to a second location by design. Ask which city holds the standby and whether a failover moves data across a provincial or national border.
- The clauses in the agreement. Residency, subcontracting, breach notification, and the return or destruction of data at the end of the engagement belong in the contract. Ask which attestations cover the physical and platform layers underneath the provider.
- Who makes the compliance determination. Treat the phrase compliant hosting with caution. Compliance is a determination about your organization, made by your privacy officer or auditor. A provider documents facts and operates controls.
- The evidence you will receive. Ask what you can hand to a reviewer: a data-flow diagram, restore-test records, access reviews and audit-log samples. The knowledge base article on Canadian-only deployment patterns with explicit data-flow diagrams shows what a defensible diagram contains.
For selection criteria beyond residency, see the guide on what to look for in a managed hosting provider.
Which kinds of hosting provider can meet a Canadian residency requirement?
Four kinds of provider can host a workload in Canada. They differ in where the residency commitment comes from and how much work stays with your team.
| Option | Source of the residency commitment | What your team still owns | Choose when | Avoid when |
|---|---|---|---|---|
| Global cloud platform, Canadian region, run by your team | You pin each service to a Canadian region yourself | Every region setting, backup target and log destination, plus the evidence | You have cloud engineers and use platform-native services | Nobody owns the account day to day |
| Global cloud platform, Canadian region, run by a managed operations provider | The same regions, with a third party operating the account | The account and the residency design decisions | You want to stay on the platform and lack operations staff | You expect the operator’s own-region commitments to cover your account |
| Canadian-owned managed cloud provider with its own Canadian regions | The provider’s regions and the agreement you sign | The application, data classification and your own third-party services | Location and provider ownership both matter, and you want one party for infrastructure and operations | You need regions outside Canada, or a certification report the provider does not hold |
| Commodity shared host or commodity managed WordPress host | The plan you pick, where a Canadian location is offered | Verification of every copy | A brochure site holds little personal information | A contract requires backup, log and standby placement in writing and the plan terms do not provide it |
The right option is the one whose written commitments match your clause, at a level of operational work your team can sustain.
Do you need to leave AWS to meet Canadian data residency requirements?
No. A Canadian data residency requirement alone does not force a company off a global cloud platform. AWS, Microsoft Azure and Google Cloud each operate Canadian regions. Stack Harbor’s example scenario about a move off AWS says that AWS’s Canadian regions “are credible” and that AWS is the right answer for a lot of workloads.
On a global platform, each service has to be pinned to a Canadian region, and that includes backups, log storage, identity, analytics and support tooling. Some platform services are global by design, and each one needs a decision. If nobody on your team owns the account day to day, a managed operations provider can run it. AWS Operations is Stack Harbor’s offer for operating a client-owned AWS account. The account stays with the client, and so do the decisions about which regions it uses.
Leaving a global platform is a separate decision, usually driven by cost, by who operates the account, or by a customer who asks about foreign ownership. The article on managed cloud versus AWS for a small or mid-sized business covers that decision.
What does Québec’s Law 25 change about where data is placed?
For a Québec organization, Law 25 adds a provincial question to the Canadian one. Québec’s privacy law treats communication of personal information outside Québec, including to Ontario, as something that has to be assessed. That is how Stack Harbor’s Trust & Security page states the point. A design with its primary and its standby both in Montréal keeps data in Canada and in Québec.
For many organizations that is acceptable once assessed. Some organizations take the posture, by policy or by contract, that personal information remains in Québec. If that is your posture, ask every provider where the standby and the backups live, and whether a Québec-only placement is available as a documented design decision. A Québec-only design changes the disaster recovery plan, because the second copy cannot sit in another province.
For technical depth, see what the platform has to support for Law 25 on WordPress, Québec data residency on cPanel in practice, and the Law 25 incident notification playbook for SaaS operators.
What drives the cost of a Canadian data residency requirement?
Residency has a cost, and it is rarely the hosting line alone. Four drivers move a quote.
- A second Canadian location. A standby region adds capacity you pay for before you need it. Stack Harbor’s Multi-Region DR solution uses warm standby as its default topology, sized for steady state after a failover and not for peak load.
- Per-region copies of tooling. Monitoring, logging and analytics may need a separate instance per region so that Canadian data does not flow into a foreign account.
- Untangling global dependencies. Identity, billing, audit logs, analytics and support tooling are often built as single global systems. Splitting them can take more engineering time than building the second region.
- Documentation and legal review. Data-flow diagrams, exception clauses and privacy-officer reviews take time on both sides.
One example scenario shows the trade. In one example scenario, a dual-region residency build for a healthcare-adjacent Canadian SaaS, infrastructure cost rose 38% from running a second region with separate monitoring and analytics. In the same engagement, four enterprise deals closed within ninety days with residency as a named contract clause. The example scenario puts three weeks on standing up the second region and eleven on untangling global dependencies. Those figures describe one engagement, not a typical result.
To estimate your own cost, list every system that stores or processes personal information, mark which ones are global, and estimate the work to split each. The article on how managed cloud hosting is priced explains how drivers like these turn into a quote.
When should residency drive your hosting decision, and when should it not?
Make Canadian residency a hard requirement when:
- A signed contract, an RFP or a public-sector policy names it.
- You hold personal information about Québec residents and your privacy officer’s assessment calls for it.
- Deals are stalling or closing at a lower value because you cannot answer the residency question in writing.
Do not let residency drive the architecture when:
- The workload holds no personal information and no contract asks for Canadian placement. Choose on latency, cost and who operates it.
- The only foreign element is a third-party service your customers accept. In one example scenario, the dual-region residency build, billing data held by a US payment processor stayed US-resident under a documented exception.
A Canadian-owned managed provider is not the right choice when:
- Your customers require a SOC 2 or ISO 27001 report, a third-party security attestation, held by the hosting provider itself, and the provider has none.
- You need regions in other countries, or more Canadian locations than the provider operates.
- The workload falls under a government security classification that requires a cloud service assessed for that classification. Ask the provider for the assessment.
- Your cloud engineers already run a well-governed account in a Canadian region. Document what you have.
What questions should you take into a vendor call about data residency?
Take this checklist into the call and ask for the answers in writing.
- In which city does the primary environment run?
- In which city does the standby run, and what triggers a failover?
- Where are backups stored, and are any copies kept outside Canada?
- Where do logs, monitoring data and support tickets live?
- Is placement outside Canada possible by default, or only by a recorded decision?
- Can standby and backups stay in Québec if our assessment requires it?
- Which clauses cover residency, subcontracting, breach notification and return or destruction of data?
- Which attestations cover the facilities and platforms underneath, and who holds them?
- From which countries can provider staff access the environment?
- What evidence will we receive for a reviewer, and who makes the compliance determination?
A provider that answers all ten in writing has given your privacy officer facts to assess. A provider that answers with a logo or the word compliant has not.
Where Stack Harbor fits
Stack Harbor Inc. is a Canadian-owned managed services provider headquartered in Montréal, Québec. It serves SaaS companies, agencies and publishers that run production systems without a 24/7 operations team of their own.
Stack Harbor’s own Canadian infrastructure runs in two data centres in Montréal. A workload placed there on Cloud Compute stays in Canada, and the placement is documented. A US or partner region is a decision made with the client at design time and recorded, not a default. If a client’s posture requires data to remain in Québec, where standby and backups live is a placement decision made with the client and written down.
Residency, subcontracting, breach notification and 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 operates.
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. Our Montréal data centres include eStruxture facilities, and 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). These residency statements 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, and the quote is fixed for a written scope after an assessment. To test a residency clause against a real design, request an infrastructure plan and bring the clause with you.
