If your business collects, uses, or discloses personal information in the course of commercial activity in Canada, the Personal Information Protection and Electronic Documents Act applies to you. Most founders and operators know PIPEDA exists. Far fewer know exactly what it requires day to day, because the law is written in principles rather than a checklist.
This is that checklist. It is not legal advice, and PIPEDA compliance ultimately depends on your specific data practices, but it will tell you what to look at first and where the gaps usually are.
Who PIPEDA applies to
PIPEDA covers private-sector organizations that collect personal information during commercial activity, which is a broad definition covering nearly any business-to-consumer or business-to-business transaction. If you are federally regulated (banks, airlines, telecoms), PIPEDA applies directly. If you operate only within a province that has its own substantially similar privacy law, such as Quebec's Law 25, the provincial law governs instead for intra-provincial activity, but PIPEDA still applies to any personal information that crosses provincial or national borders. Most SaaS companies with customers in multiple provinces end up under both regimes.
The 10 fair information principles, as a checklist
PIPEDA is built around ten principles set out in Schedule 1 of the Act. Here is what each one means in practice.
- Accountability. Name a specific person responsible for privacy compliance, even if that is a part-time role. Regulators expect an identifiable owner, not "the team."
- Identifying purposes. Document why you collect each category of personal information before you collect it. This becomes the basis for your privacy policy and your consent language.
- Consent. Get meaningful consent for collection, use, and disclosure. For sensitive data this generally means explicit opt-in; for routine data tied to an obvious purpose, implied consent can be sufficient. Pre-checked boxes and buried consent language are the most common enforcement targets.
- Limiting collection. Collect only what you need for the identified purpose. Extra form fields that "might be useful someday" are a liability, not an asset.
- Limiting use, disclosure, and retention. Use data only for the purpose it was collected for, and set actual retention periods with deletion schedules, not indefinite storage.
- Accuracy. Keep personal information accurate and up to date for the purposes you use it for. This matters most where decisions get made on the data, such as credit or employment.
- Safeguards. Apply security controls appropriate to the sensitivity of the data, including access controls, encryption, and vendor due diligence. This is the principle that most directly overlaps with a SOC 2 program.
- Openness. Publish a privacy policy that is easy to find and actually describes your real practices, not a generic template.
- Individual access. Have a working process to respond to a request from someone asking what personal information you hold about them, and to correct it if it's wrong. You need to be able to actually execute this, not just promise it in the policy.
- Challenging compliance. Provide a way for individuals to complain about your privacy practices and get a response, with an escalation path to the Office of the Privacy Commissioner of Canada if unresolved.
Breach obligations most companies miss
PIPEDA's breach requirements are specific and frequently underestimated:
- Report any breach that creates a "real risk of significant harm" to the Office of the Privacy Commissioner of Canada, as soon as feasible after you determine the breach occurred.
- Notify affected individuals directly, using language they can actually understand, not just a legal disclosure.
- Keep a record of every breach, including ones that did not meet the reporting threshold. The OPC can ask to see this log, and an incomplete log is itself a finding during a review.
The "real risk of significant harm" test requires judgment, which is exactly why an incident response plan should define who makes that call before an incident happens, not during one.
Where PIPEDA overlaps with SOC 2 and Law 25
PIPEDA is a legal obligation, not a certification. SOC 2 is a voluntary audit framework that enterprise customers increasingly require as a condition of doing business. The two overlap heavily on the safeguards principle: encryption, access controls, vendor management, and incident response are common to both. Companies pursuing SOC 2 often find they are most of the way to PIPEDA compliance already, and vice versa, but neither one automatically satisfies the other. SOC 2 has no consent or individual-access requirements, and PIPEDA has no audit or attestation component.
If your customers are in Quebec, Law 25 layers on additional requirements, including mandatory privacy impact assessments for certain projects and stricter consent rules. Our PIPEDA framework page breaks down the specific overlaps and gaps between PIPEDA, Law 25, and SOC 2 in more detail, including which controls satisfy more than one regime at once.
A short gap-check
Before you assume you're covered, ask honestly:
- Can you name who owns privacy compliance at your company right now?
- Do you have a documented, tested breach response process with defined notification timelines?
- Can someone on your team actually pull every record tied to a specific customer within a reasonable timeframe, if asked?
- Does your privacy policy describe what you actually do, or what a template says you do?
- If you sell to enterprise customers, are your PIPEDA safeguards documented in a way that would hold up during a SOC 2 readiness assessment?
If any of those gave you pause, that's the starting point, not a reason to panic. PIPEDA enforcement in Canada tends to focus on organizations that ignored obvious gaps rather than ones working through a remediation plan in good faith.
Getting there without overbuilding
Most companies do not need a standalone privacy program built from scratch. If you are already working toward SOC 2 certification or another compliance framework, the safeguards, access control, and incident response work you're doing there should be structured to satisfy PIPEDA at the same time, rather than duplicated later as a separate exercise.
If you want a straight answer on where your current practices stand against PIPEDA, and how much overlap exists with any compliance work you're already planning, get in touch and we'll walk through it.