Proof of Canadian data residency: what to ask for

A client asks you to prove their data stays in Canada. You're not the one buying hosting here, you're the vendor answering to your own client's procurement or security review, and you need your hosting provider to hand you something more useful than a marketing page.

"Proof" means specific documents: a named legal entity, a physical data center location, a subprocessor list, and a written answer on what happens to backups, logs, and support access. A region selector that says "Toronto" is not proof of anything by itself. It tells you nothing about who owns the company running that server or whether your data ever leaves that jurisdiction through a backup job, a support ticket, or a foreign parent company.

Why "hosted in Canada" isn't the same as "proof"

Plenty of hosting providers let you pick a Canadian region while the company itself, and often its backups, logs, and support staff, sit somewhere else entirely. A region label is a setting. It can be changed, it can have exceptions you were never told about, and it says nothing about corporate jurisdiction. Your client isn't asking where a server happens to sit today. They're asking what governs that data, and who can be compelled to hand it over.

Getting real proof means asking for documents, not a checkbox.

The documentation checklist

Ask your hosting provider for each of the following, in this order. Each one closes a specific gap the previous one leaves open.

1. The legal entity, and where it's incorporated. The registered company name and its jurisdiction, not a brand name. A .ca domain and a Canadian mailing address prove nothing about who owns the business.
2. The physical data center location, and who operates it. Which city, and which company runs the hardware. "AWS Canada" and "a Canadian company that owns its hardware in Toronto" are different chains of legal exposure.
3. The subprocessor list, and where each one sits. Email delivery, DNS, monitoring, payments. Your primary data can be Canadian while three or four ancillary services quietly are not.
4. Whether a foreign parent brings the US CLOUD Act into scope. A Canadian subsidiary of a US parent is generally still within reach of US legal process, because the parent can be compelled to produce data in its possession, custody, or control.
5. Backup and log locations. The gap almost everyone misses. A provider can truthfully say your primary data is Canadian while your database backups sit with another company in another country.
6. Support-access locations. A Canadian data center means little if a support team on another continent can remote into it to fix things.
7. What happens on termination. Whether there's a retention window, whether deletion is actually permanent, and whether you can export everything before you leave.

Most providers can answer item 2 without blinking. Fewer can produce a clean answer to item 3. By item 5, plenty of providers go quiet, because nobody has ever asked them to document where the backups actually go. That gap between a marketing claim and a written answer is exactly what your client is trying to find out before it's their problem.

What about SOC 2 and ISO 27001?

You'll see these mentioned constantly in generic advice about data residency documentation, so it's worth being precise about what they actually tell you. A SOC 2 report or an ISO 27001 certification is evidence of a security controls program: access management, change control, incident response, that kind of thing. Some SOC 2 reports do state the specific facilities in scope, which can be useful.

Neither certification is, by itself, an answer to "where does my data live and whose law governs it." A US company with servers in Virginia can hold both. Ask for them if your client's review requires them, but don't accept either one as a substitute for the seven items above. They answer a different question.

What MapleDeploy publishes against this checklist

We built this list because it's the same one we'd want handed to us if we were the client. Here's where each item lives for MapleDeploy.

If your client's review needs something these pages don't cover, email us and we'll answer directly rather than pointing you back at a marketing claim.

None of this replaces reading the full legal documentation yourself, or getting advice from your own counsel on what your specific client relationship requires. If the CLOUD Act itself is the part you need to explain to your client, we've written that up separately with the underlying legal mechanics: the US CLOUD Act, explained for Canadian businesses. For the broader case for Canadian data sovereignty, including how it interacts with PIPEDA and Quebec's Law 25, that page covers the ground this post doesn't.