PIPEDA in practice: the checklist we run before every Canadian SaaS deploy.

A note before the list. This post is not legal advice. We are not lawyers. We are a software studio that has, more than once, been the second-to-last person to look at a Canadian SaaS product before it goes live to real customers. After one project where we inherited a codebase that was a single missed setting away from a reportable PIPEDA breach, we wrote down what we actually check. This is that list.

If you are a founder building anything that handles personal information in Canada — names, emails, IP addresses, anything that could identify a person — PIPEDA applies to you the moment you accept commercial information from a single Canadian. Not when you incorporate. Not when you raise. From the first signup.

Things we check on the code

1. Logs do not contain PII. Specifically: no full email addresses in application logs, no plaintext passwords in error traces, no JWTs in error reports. Sentry-style tools have settings for this — we turn them on by default.
2. Database backups are encrypted at rest. Both the primary and the backup. RDS-style "encrypted by default" is usually fine; we still verify it on the snapshot itself, not on the cluster config.
3. Connection strings are not in the repo. Sounds obvious. Was not, in the codebase we inherited. git log -p on environment files tells you the truth, including what was in there last year and is now public on a fork.
4. Soft-delete is honest. If a user requests deletion, what actually happens? In most rushed codebases, "delete" sets a flag and the row stays. PIPEDA says you have to be able to actually remove personal information on request. Build the hard-delete path, even if the default is soft.
5. Third-party data flows are documented. Every external service that receives user data — Stripe, Intercom, Mailchimp, Mixpanel, the lot — listed in one place, with what is sent and why. This document is the single most useful artifact when a customer asks the question. They will ask.
6. Cookies and trackers match the policy. If your privacy policy says "we use cookies for X" and your document.cookie tells a different story, you have a problem on the second day a regulator looks. We diff the policy against actual cookie set events at deploy time.

Things we check in the product

7. Consent is meaningful, not bundled. The "I agree to terms, privacy policy, marketing emails, and being contacted by partners" single checkbox is not consent for the second three things. Separate them. Default the optional ones to off.
8. Data minimization at signup. If you ask for a phone number at signup but only use it during 2FA — make 2FA the prompt, not signup. The instinct is to grab everything in case you need it later. PIPEDA's instinct is the opposite.
9. Account deletion is reachable from the UI. Not "email us and we'll delete it." That is technically allowed; it is also a signal you are not serious about this. A button, with a confirmation, that does the thing.
10. Data export works. The right of access is one of the PIPEDA principles. Build it before someone asks for it, because they will ask for it and you do not want to build it under time pressure.

Things we check in the org

11. There is a named privacy contact. A person, not a generic privacy@ alias that nobody owns. PIPEDA requires you to designate someone responsible. We make sure that person knows they are it.
12. Breach response is written down. Not perfect — just written. Who calls who in the first 24 hours. Which lawyer. Which clients get notified first. We have used the document we wrote for our own studio more than once when helping clients.
13. Vendors have data processing terms. If your CRM, analytics, or hosting provider does not have a DPA you can point to, that is a problem you will inherit eventually. Most major providers have one — sign it before you go live, not after.
14. The privacy policy reflects reality. The most common failure we see is a policy that was written for the product the team imagined twelve months ago, not the product that exists today. We re-read the policy against the actual product at every major release. Sometimes the policy needs updating. Sometimes the product does.

A privacy policy that does not match the product is worse than no policy at all. It is the policy a regulator quotes back to you.

Why we wrote this down

Two reasons. First, because every founder we work with asks us a version of "is this enough for PIPEDA," and we needed a single document to point at. Second, because we want to be honest about the limits of what a software studio can do here. We can build the controls. We cannot tell you whether your specific data flows meet the law for your specific industry. For that you need an actual lawyer — there are good ones in Toronto and Vancouver who specialize in this, and we are happy to refer.

If you are about to go live and you have not run a list like this, we will look at your codebase for a fixed fee in one week. We are not trying to upsell; the offer exists because every time we do it we sleep better, and so does the founder.

— K.