Where does your data
actually live?
Most Canadian organizations believe their data is protected because it is stored in Canada. That belief is usually half right, and the half that is wrong is the half that matters.
This guide explains the difference in plain terms, then names specific vendors: where they store Canadian data, where they do not, and what each position means for your obligations.
Every vendor claim carries a date and a link to that vendor’s own documentation, so you can verify it independently.
We receive nothing from any product named here, whether we describe it favourably or not.
Residency terms change frequently. Everything is dated so you can judge how current it is.
Please read before relying on anything below
This guide is educational. It reflects our own experience together with published sources, and is offered as a starting point for your own research. It is not legal advice, not a compliance assessment, and not advice concerning your organization, your contracts or your regulatory obligations. We are not lawyers.
Vendor terms change without notice, and often. A provider may add a Canadian region, withdraw one, alter which services are covered, or move a capability behind a paid tier, sometimes within a matter of weeks. Every claim below is dated and linked to the vendor’s own documentation. Treat that documentation as authoritative and this page as a summary. Where the two disagree, the vendor is correct and we are out of date.
Nothing here should be read as a statement that a named company is unsafe, negligent or unsuitable. Where we note that a service does not offer Canadian data residency, we are describing a published feature set on a specific date — not passing judgement on the company, and not recommending that you leave it.
If you are a health information custodian, hold regulated financial data, or are bound by contractual residency terms, obtain qualified legal advice before acting on any of this. You proceed at your own risk.
Three terms that are used interchangeably, and should not be
Most of the confusion in this area comes from treating these as one idea. They are three separate questions, and they have different answers.
Residency
Where does the data physically sit? Which country holds the disks. This is the question vendors advertise against, because it is the easiest to promise and the easiest to demonstrate.
Sovereignty
Whose laws can compel its disclosure? This is determined by who controls the data — the company and its corporate structure — rather than by where the building stands.
Access
Who can actually read it? Support staff, sub-processors, offshore engineering teams, and increasingly the AI features enabled inside the product itself.
A vendor can answer the first question perfectly and still leave you exposed on the second and third. This is not a trick or a loophole; it is the ordinary state of affairs, and it is why a Canadian data centre is a genuine feature that resolves less than most buyers assume.
The point most organizations miss
If your provider is a US company, storing your data in Canada does not place it beyond the reach of US authorities.
The US CLOUD Act allows US authorities to compel a US-incorporated provider to produce data under its control, regardless of the country in which that data is stored. The test is corporate control, not geography. A Canadian data centre operated by a US parent is still operated by a company answerable to US courts.
Canada and the United States have discussed a bilateral agreement governing how such requests would be handled. At the time of writing, that agreement has not been concluded.
The statement “our data is stored in Canada” therefore answers a narrower question than the person making it usually intends.
It remains worth having. It satisfies contractual residency terms, reduces latency, limits which staff can reach the data, and for certain regulated obligations it is genuinely required. What it does not do is place your data beyond the reach of a foreign government.
This matters more than it once did, for reasons that have nothing to do with the law. The volume of data now leaving organizations through AI features far exceeds anything a residency clause was drafted to contemplate. A document pasted into an assistant, a meeting captured by a note-taker, a mailbox summarized by a built-in feature: each is a transfer, and few have ever been assessed as one.
Who this genuinely affects
- Health information custodians. The rules are stricter and the accountability is personal. See the PHIPA section below.
- Anyone holding a residency clause in a client contract. Read what you signed. Many specify “stored in Canada” and say nothing about foreign legal process, which means you can be fully compliant and still caught off guard.
- Organizations serving Quebec residents. Law 25 imposes its own assessment obligation before personal information is transferred outside the province.
- Anyone about to sign a multi-year SaaS agreement. This is the least expensive moment to ask these questions. After signature, you have no leverage.
And one group it affects very little: a small business holding no regulated data, bound by no residency clause, and keeping no sensitive client records. If that describes you, the honest answer is that this guide is worth understanding but not urgent. We would rather say so than manufacture a concern.
The Canadian rules, as they actually stand
Plenty of pages on this subject are describing a law that never passed. Here is where things genuinely sit as of 30 September 2026.
PIPEDA — the federal baseline
Still the operative federal private-sector privacy law, and it is from 2000. It does not require personal information to be stored in Canada. What it requires is that you remain accountable for information you hand to a third party, use contractual means to give it comparable protection, and be transparent with people about it.
The practical reading: you can use a foreign provider, but you own the consequences, and “the vendor handles that” has never been a defence.
Bill C-36 — the Protecting Privacy and Consumer Data Act
The successor to Bill C-27, which died on the Order Paper in January 2025 when Parliament was prorogued, taking the CPPA and AIDA with it. If a page tells you the CPPA is coming, it was written before that happened.
What C-36 proposes that bears directly on this page:
- An explicit obligation to assess and mitigate privacy risk before transferring personal information outside Canada. Today that is best practice. If this passes, it becomes a requirement.
- A new Digital Safety and Data Protection Commission taking over private-sector complaints and investigations.
- Binding enforcement with penalties up to CAD $10 million or 3% of global revenue, without a separate tribunal step.
- Stronger consent and deletion rights, and specific obligations around children’s data.
It is a bill, not a law. It can change substantially or die like its predecessor. But the direction of travel has been consistent across three attempts now, and the cross-border assessment requirement has survived each one.
PHIPA — and the distinction that catches people out
PHIPA contains no outright prohibition on storing personal health information outside Ontario or Canada. Many summaries say otherwise and they are wrong.
What it does restrict is disclosure. Section 50 governs disclosure of personal health information outside Ontario, and unless one of its conditions is met — patient consent among them — information cannot flow to agents outside the province. Because using an offshore cloud provider routinely involves exactly that, the practical effect is a residency requirement even though the statute never states one.
Alongside it, custodians must keep administrative, technical and physical safeguards: unique user accounts, audit logs recording every access to health information, encryption at rest and in transit, breach notification at the first reasonable opportunity, and a written privacy impact assessment for any new system touching patient data.
The custodian remains accountable for the acts of its agents. Signing with a vendor does not move that accountability anywhere.
Law 25
Quebec moved first and went furthest. Before communicating personal information outside the province, organisations must conduct a privacy impact assessment considering the sensitivity of the information, the purposes, the protections in place, and the legal framework of the receiving jurisdiction — which is a direct instruction to think about exactly the CLOUD Act problem described above.
If you serve Quebec residents, this applies to you regardless of where your own office is.
Finding out where your own data lives
Before any vendor list is useful, you need to know what you are actually running. Most organisations discover they have more tools than they remembered.
List every system holding personal information
Not every app — every system holding information about a person. Clients, patients, donors, members, staff. Include the spreadsheet on someone’s laptop and the shared mailbox. This list is always longer than expected, and the items nobody remembered are usually the ones with the weakest controls.
Check the billing statement, not your memory
Pull twelve months of card and bank statements and mark every software charge. This surfaces the subscriptions nobody mentions in a meeting — the trial that converted, the tool one department bought, the service still billing for someone who left.
For each one, find the vendor’s own residency page
Search the vendor name plus “data residency” or “sub-processors”. Serious vendors publish both. If you cannot find either, that is itself an answer — and worth noting next to that system’s name.
Check what tier you are actually on
This is where most organisations are wrong. Canadian residency is frequently a paid add-on or an enterprise tier, and a capability existing is not the same as you having bought it. Microsoft’s Advanced Data Residency is exactly this shape.
Write down what you find, with the date
One page. System, vendor, where data sits, which tier, date checked. That document is what a board, an insurer or a client is actually asking for when they ask about data governance — and it is worth more than any tool you could buy.
Five questions worth asking a vendor
Ask before you sign, when you still have leverage. The answers are more revealing than the marketing page.
1. In which country is our data stored at rest — and is that included in our plan, or an add-on?
Two questions deliberately joined, because answering only the first is the most common way a truthful answer misleads.
2. Which of your sub-processors can access it, and where are they?
Your vendor has vendors. Support tooling, analytics, backups, and increasingly an AI provider sitting behind a feature.
3. Is your company, or its parent, subject to the US CLOUD Act?
The question almost nobody asks, and the one that separates residency from sovereignty. It is a factual question about corporate structure.
4. Are our contents used to train any AI model, by you or by a provider behind your features?
Ask about both. A vendor may not train on your data while passing it to a provider whose terms differ.
5. What happens to our data when we leave, and how do we get it out?
Exit terms are negotiable before signature and immovable after. Ask for the export format and the deletion timeline in writing.
Found something here you cannot answer about your own stack?
That is the normal result, and it is not a failing. Most organisations have never been asked these questions, and the tools arrived one at a time over years.
The one-page inventory described above is the whole job. If you build it yourself and never speak to us, this page has done what it was written to do.
Still being written
The vendor-by-vendor tables — nonprofit, healthcare, finance and general business stacks — are being researched and verified against each vendor’s own documentation before they go up.
We would rather publish this section late than publish it wrong. A dated claim about where a named company stores your data is not something to guess at, and a table that is confidently out of date is worse than no table.
Educational only, and use at your own risk. This page reflects our own experience and published sources, offered as a starting point for your own independent research. It is not legal advice, not a compliance assessment, and not advice about your organisation, your contracts or your obligations. We are not lawyers. Where money, health information, regulators or contracts are involved, get qualified professional advice before acting.
Nothing here is affiliate-linked. We earn nothing from any product named on this page, whether we describe it favourably or not.
On accuracy. Vendor residency terms change frequently and without notice. Every claim is dated and linked to primary sources. If our summary and the vendor’s own documentation disagree, the vendor is right and we are out of date — and we would be grateful if you told us.
Primary sources for this page: Office of the Privacy Commissioner statement on Bill C-36 · LEGISinfo on Bill C-27 · BLG on data sovereignty and the CLOUD Act · Information and Privacy Commissioner of Ontario, PHIPA FAQ · Microsoft 365 Advanced Data Residency documentation.
Our methodology and limitations statement explains how we reach the positions we take, and where we are relying on judgement rather than evidence.