The PIPEDA Compliance Checklist That Matches What the OPC Actually Looks For

Why Most PIPEDA Checklists Don't Help

Search "PIPEDA compliance checklist" and you'll find dozens of them. Almost all share the same structure: list the ten fair information principles, add a checkbox beside each, done. The problem is that a checkbox beside "accountability" tells you nothing about whether your accountability practices would survive OPC scrutiny — and a checkbox beside "safeguards" doesn't tell you whether your safeguards are actually adequate for the sensitivity of the information you hold.

The Office of the Privacy Commissioner publishes its investigation findings publicly. These aren't abstract guidance documents — they're records of real complaints against real organizations, the specific failures the OPC identified, and the remediation it required. The OPC has published hundreds of these findings since PIPEDA came into force. Reading them reveals a consistent pattern: the organizations that end up with adverse findings almost always failed on the same specific points, not because they were careless about privacy in general, but because they had conceptual gaps in understanding what specific principles actually require in practice.

This checklist is built from that reading. Every item below maps to a specific pattern of failure the OPC has actually investigated — not to what the statute says in the abstract.

A note on scope: PIPEDA applies to private-sector organizations engaged in commercial activities. If you're in Quebec, Alberta, or British Columbia, provincial legislation may apply instead of or in addition to PIPEDA. Quebec's Law 25 in particular has stricter requirements in several areas — where that's relevant, this checklist notes it.

How to Use This Checklist

Work through each section and mark items as: Done (you have documentation to prove it), Partial (the practice exists but isn't documented or consistent), or Gap (this isn't in place). Every Gap is a compliance exposure. Every Partial is a potential Gap under investigation conditions, because oral practices without documentation are difficult to prove existed.

At the end of this checklist, any Gap or Partial in sections 1, 3, 7, and 9 represents urgent priority — these are the areas where the OPC most frequently finds violations.

Principle 1: Accountability — Where Most Programs Fall Apart

Accountability is PIPEDA's first principle and the one that underlies everything else. It requires organizations to be responsible for personal information under their control, including information disclosed to third parties.

☐ Designate a named individual as accountable for PIPEDA compliance.

"The privacy officer role" without a specific person's name attached to it doesn't satisfy accountability in OPC investigations. The individual doesn't need a formal title. They need to actually perform the function. Document the designation in writing — an email, a board resolution, an HR record, or a policy document with the person's name. Update it when the person changes.

*OPC pattern:* In several investigated cases, organizations pointed to a "privacy team" or "IT department" as responsible for privacy. The OPC found this insufficient because no individual was accountable for the overall privacy program.

☐ Make the designated individual's contact information publicly accessible.

Your privacy contact doesn't need to be prominent — but it must be findable. A privacy email address in your privacy policy satisfies this. A generic "contact us" form that routes to a general inbox doesn't clearly satisfy it. If someone needs to reach your privacy person, they need to be able to do so without navigating an obstacle course.

☐ Maintain written privacy policies that accurately reflect current practices.

The OPC has made adverse findings against organizations whose written policies described practices that didn't match reality. A policy that says you don't share data with third parties when you in fact share it with a marketing analytics platform is an openness violation layered on top of whatever consent violation caused the share. Review your policy annually against your actual data flows, vendors, and practices.

☐ Audit your policy against your actual vendor stack.

List every third-party service your organization uses that handles personal information. Compare that list to what your privacy policy says about data sharing. If they don't match, update the policy — or stop the undisclosed sharing.

☐ Contractual protections for every third-party processor.

Every vendor that handles personal information on your behalf must be bound by contractual obligations to protect it. A data processing agreement (DPA) or equivalent clause in your service agreement must specify: what the vendor can do with your data, the security standards they must maintain, breach notification obligations to you, what happens to the data when the contract ends, and whether they can engage sub-processors.

*OPC pattern:* The absence of contractual protections for third-party processors is one of the most consistently cited factors in OPC adverse findings. It appears in roughly 30% of published enforcement summaries. The OPC does not accept "we trusted the vendor" as a safeguard.

☐ Conduct annual privacy program reviews.

Accountability isn't a one-time designation — it's an ongoing function. At minimum annually: review what personal information you collect and whether the stated purposes are still current, review your vendor list and DPA status, review access controls, and review breach preparedness. Document that this review happened.

Principle 2: Identifying Purposes — You Must Say Why Before You Collect

☐ State the purpose for collection at or before the point of collection.

Purpose statements buried in a privacy policy that users are not directed to read before submitting a form don't satisfy this principle in OPC investigations. The purpose must be communicated at the moment information is collected — on the form itself, in the disclosure text adjacent to the form, or through an explicit reference that the user encounters before providing their information.

☐ State purposes specifically enough to be meaningful.

"Improving our services" is not a purpose. "Sending you promotional emails about new product features" is a purpose. The OPC has found violations where purposes were stated at a level of generality that prevented individuals from understanding what they were actually consenting to. The purpose statement must be specific enough that a reasonable person could decide whether they want to provide the information for that purpose.

☐ Maintain a record of what purpose was communicated at collection.

Your data practices will evolve. You'll add vendors, build new features, change your marketing approach. When that happens, you need to know what purposes you communicated to individuals at the time they provided their information — because that determines what you can and cannot do with it. Keep dated records of your consent mechanisms and purpose statements as they existed at different points in time.

☐ New purposes require new consent.

If you want to use personal information for a purpose that wasn't identified when it was collected, you need to go back and get consent for the new purpose before using the information that way. There is no grandfather clause for data you already have. Organizations that assume they can extend existing data to new uses without additional consent are a consent violation waiting for a complaint.

Principle 3: Consent — The Most Litigated Principle

☐ Implied consent is appropriate only for obvious and expected uses.

Implied consent applies where individuals would reasonably expect their information to be used in a particular way given the context of collection. Sending an order confirmation to the email provided during checkout — implied consent applies. Adding that email to a promotional list — it does not. The OPC draws this line clearly and consistently.

☐ Sensitive information requires express consent.

Social Insurance Numbers, health information, financial account details, biometric data, and personal information about minors require explicit, active consent — not implied, not buried in fine print. A user clicking through a 4,000-word terms of service without being directed to a consent provision for sensitive data does not constitute express consent for that data.

*Quebec Law 25 note:* Law 25 raises the consent standard for all personal information to "manifest, free, and informed" — essentially an express consent standard. If you have Quebec users, your consent mechanisms should satisfy this higher standard across the board.

☐ Consent requests are unbundled.

Bundled consent — a single checkbox that covers multiple processing purposes — is increasingly disfavored by the OPC and doesn't satisfy Law 25. Separate consent for separate purposes is the defensible approach. If you're collecting an email address for transactional messages and you also want to send marketing, those are two separate consent requests.

☐ Consent withdrawal is honoured within days, not months.

Once someone withdraws consent — by unsubscribing, by revoking access, by sending a written request — you have a reasonable time to stop. "Reasonable" is measured in days for straightforward withdrawals. Organizations that continue using personal information weeks or months after a withdrawal request have been found in violation. Your technical systems must be capable of processing withdrawal promptly, not just acknowledging it.

☐ Consent mechanisms are documented and dated.

If an OPC investigation asks how you obtained consent for a specific use, you need to be able to show the mechanism — the form language, the checkbox text, the disclosure statement — as it existed at the time the consent was obtained. Screenshots, version-controlled HTML, or archived policy documents serve this purpose.

Principle 4: Limiting Collection

☐ Every data field has a documented, current purpose.

Go through every form, every intake process, every data element you collect. For each one, write down the specific business purpose it serves. If you can't articulate a specific current purpose, you probably shouldn't be collecting it.

*OPC pattern:* "We collect it because our platform has a field for it" and "it might be useful someday" are rationalizations the OPC explicitly rejects. The limitation is on collection, not just use — you can't collect broadly and then decide purposes later.

☐ You collect the minimum necessary, not the maximum possible.

If age verification requires knowing a user is over 18, you don't need their birthdate — you need a birthdate-based age check that returns a yes/no. If postal code serves your geographic purpose, you don't need a full mailing address. If the last four digits of a credit card number serve your reference purpose, you don't need the full number. Apply the minimum-necessary standard to each data element.

☐ SINs are collected only when legally required.

The OPC has issued specific guidance that SINs should be collected only when required by law and should not be retained beyond the period of legal necessity. Collecting SINs for identity verification when the verification purpose doesn't legally require a SIN is a limiting collection violation. This comes up regularly in employment and financial services contexts.

Principle 5: Limiting Use, Disclosure, and Retention

☐ Personal information is not used for secondary purposes without consent.

This is the single most commonly found violation in published OPC enforcement summaries. Using customer contact information for marketing when it was collected for service delivery. Using employee data for purposes beyond the employment relationship. Using data collected for one product to personalize another product. Each of these is a secondary use violation without fresh consent.

☐ A retention schedule exists and is enforced.

You must have a documented schedule specifying how long different categories of personal information are retained and a mechanism for actually deleting them when retention periods expire. The schedule should be based on legal minimums (some records must be kept for specific periods under tax law, employment law, or health regulations) and business necessity (what do you actually need, not what might be nice to have).

☐ Deletion is actually happening.

A retention policy that exists but isn't enforced is a PIPEDA violation waiting to be discovered. Spot-check your data stores periodically to confirm that records past their retention date are actually being purged.

☐ Internal access is role-based.

Employees should only have access to personal information their role requires. Customer financial records should not be accessible to marketing staff. Employee health information should not be accessible to peers. HR records should not be accessible across departments. Role-based access controls that match information access to business need are a standard OPC expectation.

Principle 6: Accuracy

☐ A correction process exists and is documented.

Individuals have the right to request correction of their personal information. Your organization needs a process for receiving correction requests, evaluating them, making corrections where appropriate, notifying relevant third parties who received the inaccurate information, and communicating the outcome to the requestor. Document this process. Test it periodically.

☐ Data quality reviews happen for long-held records.

Personal information that changes over time — addresses, phone numbers, employment status, financial information — should be reviewed periodically for accuracy, particularly if it's used in decisions that affect individuals.

Principle 7: Safeguards — The Most Technically Complex Principle

☐ Encryption at rest for sensitive categories.

Personal health information, SINs, financial account numbers, and other high-sensitivity data must be encrypted when stored. Unencrypted databases containing SINs or health records are an OPC red flag. The standard for encryption adequacy is current cryptographic practice — not the standard from five years ago when your database was configured.

☐ Encryption in transit for all personal information.

All personal information transmitted over networks should be encrypted in transit using current TLS standards. Unencrypted HTTP for any form that collects personal information is inadequate. Email containing sensitive personal information should use encrypted transmission where feasible.

☐ Access controls are implemented and reviewed.

Every system containing personal information should have access controls limiting who can read, modify, or export it. Access lists should be reviewed when employees change roles or leave. Former employees should lose access promptly — the OPC has found violations where departing employees retained access to customer databases for months after their departure.

☐ Access logs exist for sensitive systems.

You need to know who accessed personal information, when, and from where. This matters both for breach assessment (if a breach occurs, you need to know the scope of exposure) and for demonstrating safeguards adequacy (you can show the OPC that access to sensitive data was monitored). Systems containing SINs, health information, or financial account details should have audit logging enabled.

☐ Employee training is documented.

Verbal training that nobody recorded might as well not have happened from an OPC investigation standpoint. Written training records — a log of who completed training, what it covered, and when — are what you can actually produce. Training should cover: what personal information the organization holds, how to handle it appropriately, what to do when something goes wrong, and how to respond to individual access requests.

☐ A documented breach response plan exists.

The plan should specify: who is notified internally when a breach is suspected, who assesses the risk of significant harm, who decides whether OPC reporting and individual notification are required, who drafts the OPC report, who drafts individual notifications, and what records are kept of the response. Test this plan annually — a tabletop exercise with your key decision-makers is sufficient.

☐ Physical safeguards match electronic ones.

Paper records containing personal information require physical protection commensurate with their sensitivity. Locked filing cabinets for sensitive documents, clean desk policies, secure document destruction, and visitor access controls are physical safeguards the OPC considers part of an adequate safeguards program.

Principle 8: Openness

☐ Privacy policy is accurate and current.

Your policy must describe what you actually do, not what you planned to do when it was written. It must identify your privacy contact, explain what information you collect and why, describe who you share it with, and explain how individuals can exercise their rights. Audit it against reality at least annually.

☐ Privacy policy is accessible.

Linked in your website footer, accessible from any data collection form, and written in plain language that a non-lawyer can understand. A privacy policy that exists but requires significant effort to find fails the openness principle.

Principle 9: Individual Access — Frequently Triggered, Often Mishandled

☐ Access requests are responded to within 30 days.

PIPEDA requires a response within 30 days, or written notice of an extension if more time is needed, within that 30-day period. The extension is available for complex requests but must be communicated before the original deadline. Organizations that simply don't respond, or respond after 45 days without having communicated an extension, are in violation.

*OPC pattern:* Access request handling failures appear in a significant number of OPC investigations. Often the failure isn't intentional — the request was received, routed to the wrong person, and forgotten. Having a designated process with a ticketing or tracking mechanism prevents this.

☐ Access responses are substantive.

The response must actually provide the personal information you hold about the individual, explain how it's being used, and identify who it has been disclosed to. "We take your privacy seriously and will look into your request" is not an access response. Acknowledge the request immediately, then provide the substantive response within 30 days.

☐ Exemptions are applied correctly and documented.

PIPEDA has limited exemptions to the access right — information that would reveal information about a third party who hasn't consented, information subject to solicitor-client privilege, information collected during an investigation. When you withhold information based on an exemption, document which exemption applies and why. The OPC can review your exemption decisions.

☐ A process exists for verifying requestor identity.

Before providing an individual's personal information in response to an access request, verify that the person asking is who they say they are. The verification mechanism should be proportionate to the sensitivity of the information being requested.

Principle 10: Challenging Compliance

☐ A documented complaint procedure exists.

Individuals must be able to complain about your privacy practices. This means a named contact (satisfied by your accountability designation), a way to reach them (satisfied by your public contact information), and an actual process for receiving, investigating, and responding to complaints.

☐ Complaints reach the right person.

Privacy complaints routed to a general customer service queue without escalation to the designated privacy person are complaints that never receive appropriate attention. The procedure must result in the complaint being reviewed by someone with authority to investigate it and change practices if necessary.

Quick Priority Reference

Fix these first (highest OPC violation frequency):

1. Missing or incomplete third-party vendor contracts
2. Secondary use of personal information without consent
3. Absent or inadequate breach response plan
4. Access requests not responded to within 30 days
5. Retention without a deletion schedule

Fix these second (significant but less frequently litigated):

1. Purposes stated at collection but not specifically enough
2. Implied consent used where express consent is required
3. Employee training without documentation
4. Access controls not reviewed when staff changes

Maintain continuously:

1. Privacy policy accuracy vs. actual practices
2. Vendor list completeness and DPA status
3. Retention schedule enforcement

Organizations that work through this list completely — not just reading it but actually checking each item against documented evidence — are in a fundamentally different compliance position than the ones that treat PIPEDA compliance as having a privacy policy and nothing more.