PIPEDA Requirements: A Practical Checklist

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 a SOC 2 report 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.

Access requests, in operational detail

The individual access principle is the one companies commit to in a policy and cannot execute when it is tested. It is worth understanding the mechanics before a request arrives, because the clock starts the day it does.

You have 30 days to respond to a written access request. That is a response deadline, not a best-effort target. You can extend it in defined circumstances, generally where meeting it would unreasonably interfere with your operations or where consultations are needed, and the extension has to be communicated to the requester within the original 30 days with the reason and the new date. An extension you decide on internally and never tell the individual about is not an extension.

Responses are generally provided at minimal or no cost. If you intend to charge, you have to inform the individual of the approximate cost first and give them the chance to withdraw or narrow the request.

Some information is withheld or refused, and the grounds are narrow. Solicitor-client privileged material, information that would reveal confidential commercial information, information generated in a formal dispute resolution process, and information about a third party that cannot be severed. That last category is the one that comes up constantly in B2B products. If your CRM record about the requester contains a colleague's notes and contact details, you sever the third-party content and disclose the rest rather than refusing the whole record. When you refuse, you must say so in writing, give the reason, and tell the individual they can complain to the Office of the Privacy Commissioner.

The operational test is whether anyone can actually assemble the response. For a typical SaaS company the personal information about one individual sits across the production database, the analytics platform, the support desk, the marketing tool, the payment processor, and backups. Work out now how you would pull all of it, and write down the query or export step for each system. Doing that once converts a 30-day scramble into a two-hour task, and it produces the data map a SOC 2 readiness assessment will ask for anyway.

The processor argument, and why it only half works

B2B SaaS companies routinely say "PIPEDA obligations sit with our customer, we are just the processor." That is broadly true about accountability for the collection purpose and consent, and it does not remove your obligations.

PIPEDA does not draw the controller and processor line the way European law does. It uses accountability: the organisation that collects the information remains responsible for it, including while it is in the hands of a third party, and that responsibility is discharged through contractual means and oversight. So your customer stays accountable for their end users' data, which is correct, and they are obliged to ensure a comparable level of protection while you hold it. In practice that obligation lands on you as contract terms, security requirements, audit rights, and questions you have to answer.

There are also two places where you have direct obligations regardless of the processor framing. You collect personal information about your own customers' staff, the users who log into your product, and about your own employees and prospects, and you are the accountable organisation for all of that. And if you use customer data for your own purposes, product analytics, benchmarking, model training, or anything beyond delivering the contracted service, you are no longer acting solely on instruction and the purpose you are using it for needs its own basis. That last point is where a lot of AI feature work quietly steps over a line that nobody documented.

Cross-border transfers

PIPEDA does not require data localisation. You can host Canadian personal information in the United States or anywhere else. What you must do is be transparent about it and remain accountable for it.

Transparency means your privacy policy should say that information may be processed outside Canada, and that while it is there it may be accessible to foreign courts and law enforcement. Being vague about this is a common finding in privacy reviews and it is trivially fixed.

Accountability means contractual protection with the receiving party and some evidence you assessed them: a signed agreement with security obligations, a review of their posture, and a record that you did the review. If you already maintain a vendor risk register for a security framework, that register is your evidence.

Note the divergence risk. Quebec's Law 25 takes a stricter position and requires an assessment before transferring personal information outside the province, with specific factors to consider. If you have Quebec customers, run that assessment and keep it. A federal-only posture is not sufficient there, and this is the most common gap we find in companies that assumed PIPEDA compliance covered the whole country.

What your breach log has to contain

The record-keeping obligation is the one companies discover during an investigation rather than before one. Every breach of security safeguards gets recorded, not only the ones you reported, and the records are kept for 24 months after the day you determine the breach occurred. The OPC can request them.

A usable record entry contains the date or period of the breach, the date you became aware of it, a description of the circumstances, the nature of the personal information involved, the number of individuals affected if known, your assessment of whether there was a real risk of significant harm and the reasoning behind that conclusion, and what you did about it including whether you notified.

That reasoning line is the important one. The most frequent weakness is a log full of entries stating "no real risk of significant harm" with no analysis behind the words. The statute points at sensitivity of the information and probability of misuse as the factors, so the entry should engage with both. A misdirected email containing a name and a meeting time is a different analysis from a misdirected email containing a spreadsheet of account balances, and the log should show you can tell the difference.

Decide in advance who makes the call and who signs off, and put it in the incident response plan. During an incident, at 11pm, with a customer on the phone, is a bad time to be discovering that nobody has authority to decide whether to notify. A retained incident response arrangement exists partly to make sure that decision has an owner and a documented rationale rather than being made under pressure and reconstructed later.

What an OPC complaint actually looks like

Most Canadian companies have no mental model for this, which makes it feel scarier than it is. The typical path starts with an individual complaining to you and being dissatisfied with your response. They then complain to the Office of the Privacy Commissioner, which will usually try early resolution first, meaning a phone call or letter to you asking what happened and what you propose to do.

A large share of complaints end there, because the underlying issue is often that someone could not get an answer out of a support queue. Companies that respond quickly and fix the specific problem tend to close matters at this stage. Companies that ignore correspondence escalate into a formal investigation.

A formal investigation involves written questions, requests for documents, and often an interview. What they ask for is predictable: your privacy policy and its version history, your retention schedule, your consent flows as the user actually experiences them, your breach log, evidence of your safeguards, and the name of the person accountable for privacy. The office has historically operated through findings and public reporting rather than administrative fines, and reform proposals to change that have been introduced and have lapsed more than once. Assuming the current regime lasts forever is optimistic, and building for a stricter one is not expensive.

The practical lesson from published findings is consistent. Organisations that had documentation and acted on the issue fared far better than organisations with equivalent underlying practices and no records. Your paper trail is the difference between a resolved complaint and a public finding.

Retention, worked through

Limiting retention is the principle most companies fail silently, because nothing breaks when you keep data forever. Building a schedule is less work than it sounds if you do it by category rather than by field.

Take a typical SaaS company. Customer account data is retained for the life of the contract plus a defined period after termination, commonly aligned to the contractual deletion commitment, often 30 to 90 days. Billing and tax records are retained on the schedule your tax obligations set, which is longer and overrides deletion requests for those specific records. Support tickets carry an operational retention, perhaps two or three years, chosen because you can articulate why. Marketing contact data is kept while the relationship is live plus a dormancy period, then purged. Logs run to a security retention period, commonly a year. Backups are the awkward category, and the honest answer is that backups age out on their own cycle and deletion requests are honoured in the live systems with backups excluded until they expire, which you should state plainly rather than pretend otherwise.

Write the schedule, then check whether anything actually enforces it. A retention policy with no deletion job behind it is a document that increases your exposure, because you have now written down a commitment you demonstrably do not meet. If you can only automate one, automate the marketing and support categories, because those grow fastest and carry the least business value.

When you do not need to hire anyone for this

Plenty of companies asking about PIPEDA do not need a privacy consultant, and the honest answer saves them money.

You are small, Canadian-only, and handling low-sensitivity data. A twelve-person B2B tool holding names, work emails, and usage logs can get most of the way there internally in a fortnight. Name an accountable person, write a privacy policy that describes what you actually do, set retention periods and enforce the easy ones, document the access request process, and add breach logging to your incident plan. That is not consulting work. That is an afternoon a week for a month.

You are already mid-way through a SOC 2 or ISO 27001 programme. The safeguards, vendor management, access control, and incident response work is already happening. Layering a separate privacy engagement on top duplicates effort. Ask whoever is running the compliance work to add the privacy-specific pieces, consent, purposes, retention, and access requests, to the same programme. That is how we structure it in compliance engagements rather than selling it twice.

Your real question is a customer questionnaire. If this started because an enterprise buyer sent a privacy section in their vendor review, the fastest path is to answer that questionnaire accurately and fix the two or three things you had to answer "no" to. That is a week of work, not a programme.

The situations where outside help genuinely earns its cost are narrower. You hold sensitive personal information, health, financial, or biometric. You have Quebec exposure and need the Law 25 pieces done properly, including the privacy impact assessments and the transfer assessments. You have had a breach and need the notification analysis to hold up. You are training models on data that was collected for a different purpose. Or you need a named privacy officer and there is genuinely nobody internal who can hold it. That last case is what a fractional arrangement from $3,000 a month is for, and outside those situations we would rather tell you to do it yourself.

If you want a straight read on which of those you are, send us what you collect and who you sell to and we will tell you whether this is a project or an afternoon.