Testing and defence led by a published security researcher with five CVEs, including a CVSS 9.1 Mirai botnet kill-switch.
All security →SOC 2, ISO, and the Canadian privacy stack, run end to end with an independent auditor.
All frameworks →Original research, free tools, and plain-language guides on security and compliance, from a published security researcher.
Read the blog →Almost no Canadian privacy law requires data to stay in Canada. Almost every Canadian enterprise and public sector buyer asks for it anyway. Both of those facts matter, and confusing them costs deals.
No general Canadian privacy statute requires personal information to be stored in Canada. PIPEDA permits transfers for processing, treating them as a use rather than a disclosure, subject to the accountability principle and comparable protection through contract. Quebec Law 25 requires an assessment of privacy-related factors and a written agreement before communicating personal information outside Quebec, and permits the communication where the assessment establishes adequate protection. Real residency requirements exist in a small number of places: certain public sector statutes and policies, federal government cloud direction for classified and Protected data, and sector-specific record access rules. Everything else you will encounter is contractual or procurement policy, which is just as binding on a deal but is negotiable and is answered differently. The honest answer to the questionnaire question names your regions, your backups, your logs and your support access geography, and does not pretend the law says something it does not.
When a Canadian buyer asks whether your data stays in Canada, they are usually asking one of four different things and they rarely say which.
Sometimes they are asking a legal question: are we permitted to let this information leave the country. Sometimes they are asking a policy question: our internal standard says Canadian hosting and I need to record whether you meet it. Sometimes they are asking a risk question: who can compel access to this data, and under whose law. And sometimes they are asking a procurement question: the template says Canada, tick or explain.
The answers differ. The legal answer is almost always that no statute prohibits the transfer, with a short list of exceptions. The policy answer is that their standard is binding on them whatever the statute says. The risk answer is about foreign lawful access, which is a real concern with a nuanced answer. The procurement answer is a checkbox with an exception process behind it.
Vendors get into trouble by giving the legal answer to the policy question. Telling a public body's procurement officer that the residency provision was repealed in 2021 is correct and irrelevant, because their contract template still says Canada and they do not have authority to change it in your favour. Vendors get into different trouble by giving the policy answer to the legal question, agreeing to a residency commitment they cannot actually meet because logs and support tooling live elsewhere.
The rest of this guide separates the four, so you can tell which one you are being asked.
PIPEDA contains no data localization requirement. It does not mention where personal information may be stored. What it contains is the accountability principle: an organization is responsible for personal information in its possession or custody, including information that has been transferred to a third party for processing, and it must use contractual or other means to provide a comparable level of protection while the information is being processed by that third party.
The Privacy Commissioner of Canada has taken the long-standing position that a transfer for processing is a use of personal information rather than a disclosure, which matters because a disclosure would generally require consent while a use for the purpose the information was collected for does not. That position was reconsidered in a public consultation and the Office ultimately confirmed it, so the operating rule for Canadian companies is unchanged: you may use a foreign processor without obtaining separate consent, provided the processing is for the purpose the information was collected for, you remain accountable, and you have contractual protection in place.
There is a transparency expectation attached. Organizations should be open about their personal information handling practices, including advising individuals that information may be processed in a foreign country and may be accessible to law enforcement and national security authorities of that jurisdiction. This belongs in your privacy policy, in plain language, and its absence is a finding that costs nothing to fix and looks careless when someone notices.
So the PIPEDA answer is: transfer is permitted, accountability does not transfer with the data, contract for comparable protection, be transparent about it. Nothing about geography.
Quebec is where the most confusion lives, because Law 25 imposes a real, specific obligation on cross-border communication that is frequently and incorrectly described as a residency requirement.
Before communicating personal information outside Quebec, an enterprise must conduct an assessment of the privacy-related factors. The assessment must take into account the sensitivity of the information, the purposes for which it is to be used, the protection measures that would apply to it including contractual measures, and the legal framework applicable in the jurisdiction where the information would be communicated, including the privacy principles applicable there. The information may be communicated only if the assessment establishes that it would receive adequate protection, in particular in light of generally recognized principles regarding the protection of personal information. The communication must be the subject of a written agreement that takes into account the results of the assessment and, where applicable, the terms agreed on to mitigate the risks identified.
Read that carefully. It is an assessment-and-document requirement, not a prohibition and not a localization rule. Quebec does not say the information must stay in Quebec or in Canada. It says you must think about it in a structured way, conclude that protection is adequate, and paper it.
The word "outside Quebec" also does more work than people notice: the obligation applies to communicating information to Ontario as much as to Ireland or Virginia. A Montreal company using a Toronto-hosted service is making an out-of-province communication and owes the assessment.
In practice, for a major cloud provider with a mature contractual framework, the assessment is a document rather than an obstacle. The work is doing it properly, keeping it current when you change providers or regions, and being able to produce it. Companies that re-architected to keep Quebec data in Quebec on the basis of this provision usually spent money they did not need to spend. Our guides on what Law 25 requires and the implementation checklist cover the rest of the statute.
The list is short, and knowing it precisely is what lets you push back credibly everywhere else.
Nova Scotia public bodies. Nova Scotia's personal information international disclosure legislation requires public bodies and municipalities, and their service providers, to store and access personal information only in Canada, subject to limited exceptions such as consent or a necessary disclosure. This is a genuine statutory residency rule and it applies to vendors serving those bodies.
British Columbia, historically. BC's public sector privacy statute contained an equivalent prohibition from the mid-2000s until it was removed by amendment in 2021. It is no longer a statutory requirement, but it shaped an entire generation of BC public sector architecture and it persists in procurement templates and institutional policy. Treat it as policy, not law, and meet it anyway. Our Alberta and BC guide covers the detail.
Federal government cloud use. Treasury Board direction for federal institutions requires that cloud-based services handling information classified up to and including Protected B be hosted within Canada, alongside a set of security control requirements. This is government policy binding on federal institutions rather than a statute binding on you, but for a vendor selling to a federal department it is functionally a hard requirement. Our public sector guide covers what else comes with it.
Sector record-keeping rules. Some regulated sectors have record access and record-keeping requirements that have historically pushed institutions toward keeping records in Canada or toward specific arrangements when they are held elsewhere. Financial institution legislation is the main example. The obligation is generally that the regulator must be able to access the records, rather than that the servers must be in a particular place, but the practical effect on procurement is similar. Our OSFI B-13 guide covers how that lands on a vendor.
Some provincial health system policy. Health statutes generally do not impose residency, but health authorities, hospitals and provincial health ministries frequently do through policy and procurement. PHIPA in Ontario, for instance, contains no residency requirement at all, yet Ontario hospital templates routinely require Canadian hosting.
Notice what is not on this list: PIPEDA, Quebec Law 25, Alberta PIPA, BC PIPA, PHIPA, the Alberta Health Information Act. None of the general privacy or health privacy statutes that most vendors are subject to impose a residency requirement.
The residency requirement in front of you is far more likely to be a clause than a statute, and that changes how you handle it, not whether you have to.
Procurement templates and enterprise security schedules require Canadian hosting for a mix of reasons: institutional risk appetite, a historical statutory requirement that has since changed, a policy written by a predecessor, concern about foreign lawful access, a board commitment, or simple habit. Very often nobody in the current process knows which of these it is.
This matters because a contractual requirement is negotiable in a way a statute is not, but only if you engage with the actual concern. The productive move is to ask what the requirement is protecting against. If the answer is foreign lawful access, you can discuss encryption, key management, the categories of data involved and your response to legal process. If the answer is "our template says so", you can sometimes get an exception approved with a documented rationale. If the answer is a genuine statutory obligation on their side, you cannot, and you should know that within a week rather than a month.
What does not work is the argument that the law does not require it. You are telling a person their own policy is unnecessary, which is not their decision to make and is not persuasive coming from a supplier.
Where a Canadian region is available to you, offering it converts an argument into a checkbox and is almost always worth the operational cost. Where it is not, the second best position is a precise, complete disclosure plus specific mitigations, offered proactively.
This is where honest vendors get caught out, because selecting a Canadian region for your primary database is the easy part and it is not what the commitment means.
A Canadian region means your primary compute and storage for that service run in Canadian data centres. It does not automatically mean any of the following, and each of these has caused a real problem for a real vendor in a real review.
Backups and snapshots. Cross-region replication for durability is a sensible default that quietly moves a full copy of your data to another country. Check where your backups land, including database snapshots, object storage replication and any managed backup service.
Logs and telemetry. Application logs, error tracking, performance monitoring, session replay and analytics frequently ship to a service whose default region is in the United States or Europe. Logs contain personal information far more often than teams assume: identifiers, email addresses, request bodies, stack traces containing record contents. This is the most common residency finding in a security review.
Support tooling. The ticketing system, the customer data platform, the screen sharing tool and the internal admin console. If a support engineer can view production data, the tool they view it through is part of your data footprint.
Managed and platform services. Email delivery, SMS, search, queueing, feature flags, authentication providers, payment processing, document conversion, and any machine learning or model API. Each has its own region behaviour and some have none.
Support and engineering access geography. A Canadian region does not stop a support engineer in another country from opening a session against it. Buyers increasingly ask about access location separately from storage location, and correctly so, because access is where the exposure actually is.
Content delivery and edge. Caching layers and edge functions may process requests outside Canada even when origin storage is inside it.
The credible version of a residency claim is a table: for each of primary storage, backups, logs, telemetry, support tooling, each material subprocessor and administrative access, the actual location. Producing that table once is a day of work and it answers this question permanently.
The substantive risk concern behind most residency requirements is foreign government access, usually framed around United States legislation. It deserves a real answer rather than a reassurance.
The accurate position has several parts. Storing data in Canada does not by itself put it beyond the reach of foreign legal process, because process can attach to a company subject to a foreign jurisdiction regardless of where its servers are. Conversely, Canadian companies and Canadian data are subject to Canadian legal process, which also permits compelled access in defined circumstances. Residency changes the jurisdictional analysis; it does not eliminate compelled access.
What genuinely reduces exposure is a combination of factors: minimizing what you hold at all, encrypting data at rest and in transit, holding encryption keys in a way that limits what a provider can produce, having a published policy of challenging overbroad legal demands and notifying customers where lawfully permitted, and publishing a transparency report if your volume justifies one.
When a reviewer raises lawful access, respond with what you actually do: where the data is, who holds the keys, what your policy is on responding to legal demands, whether you have ever received one, and what you would tell the customer. That answer is more reassuring than a claim that Canadian storage makes the question go away, and it is defensible if it is ever tested.
The related question worth pre-empting is government access on the Canadian side, which sophisticated buyers in some sectors also ask about. The same structure of answer works.
Security questionnaires ask this badly, usually as a yes or no question with no room for nuance. Here is how to answer it so that you are accurate, credible and easy to buy from.
If everything genuinely is in Canada: say so, and enumerate. "All customer data, including primary storage, backups and application logs, is stored in the Canada Central region. Administrative access is restricted to personnel located in Canada. The following subprocessors process customer data and their locations are listed in our subprocessor register, attached." Precision here is worth more than the yes.
If most of it is in Canada: say what is, say what is not, say what data that component touches, and say what protects it. "Primary storage and backups are in Canada. Application error telemetry is processed by a subprocessor in the United States; it contains user identifiers and request metadata and is retained for 30 days. It is covered by a data processing agreement with standard contractual protections and is scoped out of the customer data store." Reviewers respect that answer. It reads as someone who knows their own system.
If none of it is in Canada: do not hide it and do not lead with the legal argument. State the location, state the protections, offer what you can, and be clear about whether a Canadian region is on your roadmap and when. If it is not on the roadmap, say so, because a vendor who promises a region to close a deal and does not deliver it loses the renewal and the reference.
Never answer yes on the strength of your primary region alone. This is the single most common source of a mid-review credibility collapse: the vendor says yes, the reviewer asks about backups or log shipping, and the answer changes. Everything after that gets re-examined.
Keep the answer in a maintained document rather than reconstructing it per questionnaire. Our questionnaire helper and the subprocessor register guide cover how to keep that answer current.
If Canadian residency is going to be a recurring requirement in your market, the question is how much architecture to spend on it. The answer depends on how the requirement is actually worded in the deals you are losing.
The cheapest useful step is data minimization: hold less, and hold less of it in the places that are hard to localize. Scrubbing personal information out of logs and telemetry is usually a week of work and it removes the most common finding entirely, regardless of where the logging service lives.
The next step is regional configuration of the services you already use. Most major providers offer Canadian regions for compute, storage, databases and increasingly for managed services. Moving primary storage, backups and the search index into a Canadian region is often configuration rather than re-architecture.
After that comes subprocessor substitution, replacing components that have no Canadian option with ones that do. This is where cost rises, because the alternative is usually less mature. Do it selectively and only where a specific deal requires it.
The expensive end is a fully separate Canadian deployment, with its own infrastructure, its own operational processes and its own release pipeline. It is the right answer for some markets, particularly public sector and health, and it roughly doubles your operational surface. Do not commit to it because of one deal, and do not commit to it before you have done the cheaper three steps, because they frequently make it unnecessary.
A middle path that works for many vendors: a Canadian region for the data plane, a documented and minimized set of out-of-country components, region-restricted administrative access, and a clear statement of both. That posture passes most enterprise reviews and many public sector ones.
Residency touches several controls you already have or need, and treating it as a standalone topic causes duplicated work.
Your data map is the source of truth for the residency answer. If it records, per store, the categories of information, the region, the retention period and the subprocessor, the residency answer is a query rather than an investigation.
Your subprocessor register is the second half. Every buyer who asks about residency will ask about subprocessors within two questions, and a register with purpose, location, data categories and assessment status answers both.
Your vendor management control covers the contractual side: the data processing terms, the transfer mechanism, and for Quebec, the assessment and written agreement the statute requires. Keep the Quebec assessment with the vendor file so it is renewed when the vendor is reviewed.
Your privacy policy carries the transparency obligation: individuals should be told that information may be processed outside Canada and may be subject to the laws of that jurisdiction.
None of this requires a separate residency project. It requires the data map and the subprocessor register to be real and current, which is the same thing every other part of a SOC 2 or ISO 27001 program needs.
Claiming Canadian residency on the strength of the primary region. Backups, logs and support tooling are where the claim breaks, and reviewers check.
Telling a buyer their residency requirement is legally unnecessary. Correct, unhelpful, and not their decision. Ask what the requirement protects against instead.
Re-architecting for Quebec. Law 25 requires an assessment and a written agreement, not Quebec-only storage. Do the assessment.
Forgetting that out of province counts. Quebec's obligation applies to communications to Ontario as much as to another country.
Treating storage location as the whole answer. Access location is often the real exposure, and buyers increasingly ask about it separately.
Answering lawful access with reassurance. Canadian storage does not put data beyond foreign process. Answer with keys, minimization, and your policy on legal demands.
Promising a Canadian region to close a deal. If it is not funded and scheduled, do not commit to it in a contract.
| Source | What it actually requires | How to handle it |
|---|---|---|
| PIPEDA | No residency rule. Transfers for processing are a use, not a disclosure. Accountability stays with you, comparable protection by contract, and transparency to individuals. | Contract properly, disclose in your privacy policy, keep the subprocessor register current. |
| Quebec Law 25 | A privacy-related factors assessment before communicating personal information outside Quebec, adequacy conclusion, and a written agreement reflecting it. | Do the assessment, file it with the vendor record, renew it on vendor review. Do not re-architect. |
| Alberta PIPA and BC PIPA | No residency rule. Alberta adds notice expectations where a service provider outside Canada handles personal information. | Make sure your customer can accurately describe where processing happens. |
| PHIPA and provincial health statutes | No residency rule in the statutes themselves. | Expect the requirement from institutional policy anyway. Offer a Canadian region. |
| Nova Scotia public sector legislation | A genuine statutory requirement that public bodies and their service providers store and access personal information only in Canada, subject to limited exceptions. | Hard requirement. Meet it or do not bid. |
| BC public sector legislation | The storage and access prohibition was removed in 2021. Reasonable security arrangements and assessment expectations remain. | Treat as policy. Meet the contractual requirement rather than arguing the amendment. |
| Federal government cloud direction | Cloud services handling information up to Protected B are directed to be hosted in Canada, with associated security control requirements. | Functionally hard for federal deals. Plan a Canadian deployment before bidding. |
| Financial sector record access expectations | The regulator must be able to access institutional records; historically this has pushed institutions toward Canadian record-keeping or specific arrangements. | Answer with region detail, access geography and your ability to produce records. Offer a Canadian region where possible. |
| Enterprise contract and procurement templates | Whatever the template says, which is frequently Canada without a stated reason. | Ask what the requirement protects against, then meet it, mitigate it, or seek a documented exception. |
Not as a general rule. PIPEDA, Quebec Law 25, Alberta PIPA, BC PIPA, PHIPA and the provincial health statutes contain no data localization requirement. Genuine statutory residency rules exist for Nova Scotia public bodies and their service providers, and federal government cloud policy directs Canadian hosting for information up to Protected B. Everything else you encounter is contractual or procurement policy, which binds the deal but comes from a different place and is handled differently.
No. It requires an enterprise to conduct an assessment of privacy-related factors before communicating personal information outside Quebec, considering the sensitivity of the information, the purposes, the protection measures including contractual ones, and the legal framework of the destination. The communication may proceed where the assessment establishes that the information would receive adequate protection, and it must be covered by a written agreement reflecting the assessment. It applies to communications to other Canadian provinces as well as to other countries.
Yes. The provision in British Columbia's public sector privacy legislation requiring personal information in the custody or control of a public body to be stored and accessed only in Canada was removed by amendment in 2021. Public bodies must make reasonable security arrangements and follow the province's assessment expectations instead. The practical effect on vendors is smaller than the change suggests, because procurement templates, ministry policies and health authority requirements still commonly require Canadian hosting as a contractual term.
Only that the primary compute and storage for that service run in Canadian data centres. It does not automatically cover backups and cross-region replication, application logs and telemetry, error tracking, support and ticketing tools, managed platform services such as email delivery or search, content delivery and edge processing, or the geographic location of the staff who can access production. Each of those has to be checked and configured separately, and each is a place where a residency claim commonly breaks during a review.
Precisely and proactively. Name what is in Canada, name what is not, say what data the out-of-country component touches, how long it is retained, and what contractual and technical protections apply. Reviewers respond well to that level of specificity because it demonstrates you know your own system. What destroys credibility is answering yes on the strength of the primary region and then revising the answer when the reviewer asks about backups or logging.
Not by itself. Legal process can attach to a company subject to a foreign jurisdiction regardless of where its servers sit, and Canadian data is also subject to Canadian legal process. What actually reduces exposure is holding less data, encrypting it, managing keys so that a provider can produce less, having a stated policy of challenging overbroad demands and notifying customers where lawfully permitted, and being able to say whether you have ever received such a demand. That answer is both more accurate and more reassuring than a claim about geography.
Frequently yes, and this is the most common finding in a residency review. Logs and telemetry routinely contain user identifiers, email addresses, IP addresses, request parameters and stack traces carrying record contents, and the services that receive them often default to a region outside Canada. Scrubbing personal information out of logs is usually a week of engineering work and it removes the issue regardless of where the logging service lives, which makes it the highest-value residency work most vendors can do.
Only after the cheaper steps, and only if the market requires it. Start with data minimization, particularly in logs and telemetry. Then move primary storage, backups and indexes into a Canadian region, which is often configuration rather than re-architecture. Then substitute subprocessors selectively where a deal requires it. A fully separate Canadian deployment roughly doubles your operational surface and is the right answer mainly for sustained public sector or health market entry, not for one deal.
traztech Workspace has every control of whichever frameworks apply to you, written in plain English, with somewhere to attach the proof. Free to use, with no card and no trial clock.
No credit card, no trial clock, no locked features. We make money when someone wants help closing the gaps, not from the Workspace.
| traztech Workspace | Other GRC platforms | |
|---|---|---|
| Licence cost | $0. Free forever, no card, no paid tier | $7,500 to $50,000 a year, on an annual contract |
| Control library, evidence register, policy templates, risk register, vendor questionnaires, readiness scoring | Included | Included |
| What it costs inside an engagement with us | $0. You need a workspace either way | Unchanged. The subscription sits on top of the fee |
| What it does to your audit quote | $11,000 off a five-figure quote on one engagement, for a documented readiness position | Nothing. The audit firm prices your readiness, not your tooling |
Pricing in the right column is what compliance automation platforms are publicly reported to charge; none of them publish a number, so treat it as a range rather than a quote. The $11,000 came off the audit firm's own number once the readiness position was documented (the engagement). Where a paid platform is the better buy, and the fuller comparison, is on the Workspace page.
We map where your data actually lives, fix the parts that break the claim, and write the answer once so every questionnaire after that is a copy and paste.
Book a strategy callWant the human version?
Jacob sends a few short, practical notes on getting security and compliance right without the months of pain. No fluff, unsubscribe in one click. Reply anytime; it reaches him directly.
From Jacob Masse, founder of traztech. No spam, unsubscribe in one click.
Track record
Five published CVEs. CVE-2024-45163 (CVSS 9.1) is a flaw in the Mirai botnet itself, which gave defenders a way to shut down attacker infrastructure. CVE-2026-42626 takes HP ENVY 5000 printers offline from any unauthenticated device on the same network.
At Humera, a venture-backed US security company, Jacob built the compliance programme in-house from nothing: no report, no policies, no documented controls. It ended in a Type II attestation across 76 controls with zero exceptions, on a team of 15.