The Canadian data residency trap

"Our data is hosted in Canada" is one of the most-said and least-true statements in Canadian software. The intent is honest. The architecture, almost always, is not.

For most teams building for Canadian clients — provincial governments, healthcare, education, or anyone serving public-sector buyers — data residency isn't a marketing checkbox. It's a contractual requirement, sometimes a statutory one (BC's FOIPPA, Alberta's PIPA, federal PIPEDA, sector-specific obligations on top). And the most common failure mode isn't malice. It's a default setting nobody reviewed.

1. Region selection is necessary but not sufficient

Choosing AWS ca-central-1 is the first 30% of the problem. It guarantees that the primary copy of data in services like RDS and S3 lives in Canada. It guarantees nothing else.

The remaining 70%:

• S3 cross-region replication can be configured to a US bucket with one checkbox. Often, it's enabled by an early team member and forgotten.
• RDS automated snapshots stay in-region by default. Manual snapshots someone copied to another region for "backup safety" do not.
• CloudWatch logs are regional by default — but only if you didn't enable any of the "send logs to a central account" patterns that move them.
• IAM, billing, Route 53 — global services. Their underlying metadata sits in the US. This is usually defensible, but it's a question on every serious privacy review and you should know the answer.

2. The managed-service trapdoors

The most painful surprises tend to be services that look regional but quietly aren't, or aren't fully:

• CloudFront caches your content at edge locations worldwide. If you put PII behind CloudFront without thinking about cache headers, that PII has been to dozens of countries by the end of the week. Sign-the-URL or no-cache it, or don't put it there.
• AI/ML services change region availability frequently, and "available in ca-central-1" doesn't always mean "model inference happens in ca-central-1." Re-check for every service you adopt. Re-check when you upgrade.
• SES, SNS, third-party email and SMS providers often route through US infrastructure even when the API endpoint looks Canadian. Email content, recipient addresses, and delivery logs may all leave the country in transit.
• Observability and error-tracking SaaS — Sentry, Datadog, Bugsnag, anything that ingests stack traces — is a near-universal blind spot. Stack traces routinely contain user input, request bodies, and identifiers. If your error tracker is US-hosted, your "Canadian-hosted" app is exfiltrating user data to the US on every exception.

3. PIPEDA isn't the only law in the room

Federal PIPEDA gets most of the attention, but if you're building for provincial public bodies, the constraints are stricter and very specific. BC's FOIPPA historically required that personal information in the custody of a public body be stored and accessed only in Canada (with significant 2021 amendments that loosened — but did not eliminate — those rules). Alberta's PIPA, Quebec's Law 25, and healthcare-specific frameworks add their own layers.

The practical implication: read the actual contract. Many public-sector contracts incorporate residency requirements that go beyond statute. "We comply with PIPEDA" doesn't answer whether you're complying with the specific clause your buyer just signed.

4. What a real privacy review actually checks

Reviewers we've worked with on government engagements consistently ask about the same things, in roughly this order:

• A list of every service in your data flow, with the region/jurisdiction where data is stored and processed.
• A list of every subprocessor (third-party SaaS that touches data), with the same.
• Where backups go, how long they're retained, and who can access them.
• Where logs go (including error tracking and analytics), what's in them, and how long they're retained.
• Encryption at rest and in transit, with key management explicit.
• The access model — who, internally and at vendors, can reach production data.
• The breach-notification process and timelines.

Most of these are not architecture questions. They're inventory questions. The teams that pass have a current diagram and a current list. The teams that struggle don't.

5. A practical checklist

If you haven't done this exercise, run it this week:

• Enumerate every cloud service in production and confirm its region.
• Enumerate every third-party SaaS that receives, processes, or stores customer data — including logs, analytics, error tracking, email, SMS, file conversion, AI inference, CDN.
• For each, document the jurisdiction and the contractual basis for using them.
• Verify your S3 bucket replication, RDS snapshot copy settings, and any "copy to another region for safety" jobs you forgot existed.
• Check CloudFront for cached PII. Audit cache-control headers on any authenticated endpoint.
• Run an outbound network capture from your production environment for an hour. Note any traffic to non-Canadian destinations and explain each one.

The actual takeaway

Data residency isn't a region setting. It's a continuous discipline of knowing exactly where your customer's data is, who can see it, and what changed last week. The "Canadian-hosted" claim is easy to make on a marketing page and surprisingly hard to defend on a privacy review. The teams that get it right treat it like security: an inventory you maintain, not a state you achieved once.