The short answer
PIPEDA applies to organizations that collect, use or disclose personal information in the course of commercial activities. It requires ten things, not one: accountability, stated purposes, valid consent, limited collection, limited use and retention, accuracy, safeguards, openness, individual access, and a way to challenge compliance.
Ask a small business owner what PIPEDA requires and you will usually get one of two answers: a shrug, or “we have a privacy policy on the website.” The second is closer, but it answers one principle out of ten.
None of this is difficult for a small business. It is just specific, and the specifics are not what people guess.
Does it apply to you at all?
PIPEDA applies to every organization in respect of personal information that the organization collects, uses or discloses in the course of commercial activities [1]. There is no employee-count threshold and no revenue threshold. If you take customer names, phone numbers, addresses or payment details in the course of doing business, you are in scope.
Two things genuinely change the answer.
Province. Alberta, British Columbia and Quebec have general private-sector privacy laws that have been deemed substantially similar to PIPEDA, and some provinces have health-specific laws declared substantially similar with respect to health information [5]. If your commercial activity happens inside one of those provinces, that statute is the one governing it, and the details differ.
Employee records. The Act's second application branch covers personal information about an employee of, or an applicant for employment with, the organization, but only where it is collected, used or disclosed in connection with the operation of a federal work, undertaking or business [1]. Most small businesses are not federal works, so their HR files sit outside PIPEDA. This is widely misunderstood in the other direction, with businesses assuming PIPEDA governs their personnel records when provincial law is the relevant regime.
The ten principles, in plain language
Schedule 1 is the operative part, and section 5(1) requires every organization to comply with the obligations set out in it [1]. The ten principles are Accountability, Identifying Purposes, Consent, Limiting Collection, Limiting Use Disclosure and Retention, Accuracy, Safeguards, Openness, Individual Access, and Challenging Compliance [2].
Here is what each actually asks of a nine-person business.
Accountability. Someone is responsible, by name. You remain responsible for personal information transferred to a third party for processing, and must use contractual or other means to provide a comparable level of protection while they process it [2]. For a small business, that is a real task: list your software vendors, and know what each holds.
Identifying Purposes. Know why you are collecting something before you collect it, and be able to say so. “Because the form had a field” is not a purpose.
Consent. Section 6.1 defines valid consent as consent where it is reasonable to expect that an individual to whom the organization's activities are directed would understand the nature, purpose and consequences of what they are agreeing to [1]. Note the framing: it is measured against your actual audience, not against a lawyer.
Limiting Collection. Collect what you need for the purpose you identified. The most common small-business failure is a form with fields nobody uses, quietly accumulating information the business has no reason to hold and now has to protect.
Limiting Use, Disclosure and Retention. The retention half is where most businesses are genuinely non-compliant, and it costs nothing to fix. Information kept forever because deleting it never came up is a live risk with no offsetting benefit.
Accuracy. Keep it correct enough for the purpose it is used for.
Safeguards. Protection appropriate to the sensitivity of the information, against loss or theft as well as unauthorized access, disclosure, copying, use or modification, regardless of the format it is held in [2]. Schedule 1 names three categories: physical measures such as locked filing cabinets and restricted office access; organizational measures such as security clearances and need-to-know access limits; and technological measures such as passwords and encryption [2]. Two of those three are free.
Openness. Make your practices readily available and understandable, including the name or title and address of the person accountable for them and to whom complaints can be forwarded, how to gain access to information you hold, and a description of what you hold and generally what it is used for [2]. Most website privacy policies omit the named accountable person, which is the easiest item on this list.
Individual Access. On request, tell someone whether you hold information about them, what it is used for, and give them access, with the ability to challenge accuracy and have it amended [2]. This is the principle that quietly punishes a fragmented software stack: if customer data is scattered across six systems, answering one request means searching six.
Challenging Compliance. A person must be able to complain to the accountable individual.
One word worth knowing: section 5(2) states that the word “should”, when used in Schedule 1, indicates a recommendation and does not impose an obligation [1]. When you read the Schedule, “shall” and “should” are doing very different work, and a lot of over-cautious compliance advice treats them as identical.
The test that sits above consent
Section 5(3) is short and does more work than the rest of the Act combined: an organization may collect, use or disclose personal information only for purposes that a reasonable person would consider are appropriate in the circumstances [1].
This is not a consent rule. It runs alongside consent, which means a purpose can be fully consented to and still unlawful because no reasonable person would consider it appropriate. For a small business the practical version is simple: if you would be uncomfortable explaining a data practice to the customer it affects, the checkbox will not save it.
The breach rules, including the two everyone gets wrong
Section 10.1 requires an organization to report to the Commissioner any breach of security safeguards involving personal information under its control if it is reasonable in the circumstances to believe the breach creates a real risk of significant harm to an individual, and to make that report as soon as feasible after determining the breach occurred. Unless otherwise prohibited by law, it must also notify the affected individual, with sufficient information for them to understand the significance of the breach and take steps to reduce the risk of harm [1].
Misconception one: the 72-hour deadline. It does not exist in PIPEDA. The standard is “as soon as feasible” [1]. The 72-hour figure is a European rule that has migrated into Canadian advice. In practice the Canadian standard can be stricter, because it does not license you to wait.
Misconception two: you only record reportable breaches. Section 10.3(1) requires an organization to keep and maintain a record of every breach of security safeguards involving personal information under its control [1], and the OPC states directly that businesses must keep records of all breaches regardless of whether they present a real risk of significant harm [4]. The regulations set retention at 24 months after the day the organization determines the breach occurred, and require the record to contain information enabling the Commissioner to verify compliance with the reporting and notification obligations [3].
So the small incident you decided was not reportable still needs a record, and that record needs to show your reasoning. The OPC is explicit that the records must contain enough detail for it to determine whether you properly assessed the risk of harm [4].
How to assess "real risk of significant harm"
The OPC frames the assessment around two factors: the sensitivity of the personal information involved, and the probability that the information will be misused [4]. Both are weighed together. It also publishes a self-assessment tool that walks through the questions, which is the sensible starting point for a business without counsel on retainer [4].
Where a report is required, the regulations prescribe what it must contain, and prescribe separately what a notification to an affected individual must contain [3]. Read those two sections before you need them, not during an incident.
What the penalties actually are
Section 28 makes an organization guilty of an offence where it knowingly contravenes the breach reporting provision or the breach record-keeping provision, or obstructs the Commissioner in investigating a complaint or conducting an audit. The fine is not more than ten thousand dollars on summary conviction, or not more than one hundred thousand dollars for an indictable offence [1].
Two honest observations. The word “knowingly” is doing real work — this is not a fine for having a bad day. And the fines are small enough that they are rarely the main risk. The bigger exposures are the complaint process, the Federal Court route available to complainants, and telling your customers what happened.
A realistic starting list
If you have done nothing, these five moves close most of the practical gap and cost nothing but an afternoon.
- Name the accountable person and put their title and address in your privacy policy. Openness requires it and almost nobody does it.
- List every system holding customer data, and for each one, what it holds and where it lives. Accountability is unachievable without this list, and you will need it in an incident.
- Write down a retention period for each category of information, and actually delete on it. This is the most common real non-compliance and the cheapest to fix.
- Decide in advance how you would answer an access request — who searches which systems, and how long it takes.
- Start a breach log today, even if it is a spreadsheet with a date, what happened, what information was involved, your risk assessment and what you did. Every breach goes in it, not only the serious ones.
None of this requires a consultant. It requires knowing where your data is, which is a good deal easier when it is not spread across six unconnected systems.