How to Write a PIPEDA Breach Notification Letter That Holds Up

A payroll vendor in Mississauga found an exposed database on a Friday afternoon. Names, social insurance numbers, and direct-deposit details for roughly 4,000 employees across a dozen client companies. By Monday they had a letter drafted. It ran two paragraphs, apologized at length, and told nobody what had actually happened or what to do about it. When the Office of the Privacy Commissioner asked for that letter during its inquiry, it became the clearest piece of evidence that the company had not taken the breach seriously.

This is the part of breach response that almost everyone underestimates. Forensics gets the panic and the budget. The letter to the people whose data leaked gets written in twenty minutes by whoever is least busy. That order is backwards. The notification is the only piece of your response affected individuals ever see, and it is the piece a regulator reads most closely when deciding whether you handled the incident like an organization that cares.

What the law actually requires you to include

Since November 1, 2018, PIPEDA's Division 1.1 and the *Breach of Security Safeguards Regulations* have made notification mandatory wherever a breach creates a real risk of significant harm (often shortened to RROSH). That phrase carries weight. Harm includes bodily harm, humiliation, damage to reputation or relationships, loss of employment or business opportunity, financial loss, identity theft, and negative effects on a credit record. Clear that bar and you must notify affected individuals as soon as feasible. PIPEDA sets no fixed hour count federally; the standard is promptness, and delay is something the OPC will ask about.

The required content lives in section 2 of the Regulations, not section 6 (section 6 is the record-keeping rule, which I'll come back to). These elements are mandatory, not suggestions. A compliant PIPEDA breach notification letter must contain:

• A description of the circumstances of the breach, and its cause if known
• The day or period during which the breach occurred
• A description of the personal information involved
• The steps your organization has taken to reduce or mitigate the risk of harm
• The steps the individual can take to reduce or mitigate their own risk of harm
• Contact information the person can use to obtain further information
• Information about your internal complaint process and the individual's right to file a complaint with the Commissioner under the Act

That last element is the one people forget exists. Most deficient letters I review are missing two or three items, usually the cause, the concrete protective steps, and the line about the right to complain. A letter that says "we experienced a security incident involving some of your information" and stops there fails on its face. It doesn't describe the information, doesn't say what you did, and gives the reader nothing to act on.

Notice what is *not* required: a disclaimer that you accept no liability, three paragraphs about how deeply you value privacy, a marketing sign-off. Those things dilute the message or annoy the recipient. Cut them.

Be specific about what leaked

The hardest instinct to fight is the urge to soften. "Certain personal information may have been accessed" is the kind of sentence lawyers love and regulators distrust. If you know SINs were in the file, write SINs. If it was names, email addresses, and hashed passwords, list exactly those three and say the passwords were hashed. Precision is what lets a person assess their own risk, which is the entire reason you are telling them.

There is a practical payoff too. A SIN exposure and a marketing-list exposure call for completely different reactions. Bury both under "personal information" and you force every recipient to assume the worst, which floods a support line you probably haven't staffed and burns the goodwill you are trying to keep. Tell people what you know. If the investigation is ongoing and the scope could grow, say so plainly and commit to a follow-up.

The protective steps are where you earn trust

The two steps-related elements are the heart of the letter, and the part businesses skip most. There is a clean split. First, what *you* did: contained the server, reset credentials, engaged a forensics firm, reported to the OPC. Second, what *they* should do: change a password, watch their statements, place a fraud alert with Equifax and TransUnion, or, for a SIN exposure, contact Service Canada about protecting their number.

Offering credit monitoring? Name the provider, state the duration, and explain enrolment in one line. Don't make people hunt. A SIN breach with no offer of at least a year or two of monitoring tends to draw a pointed follow-up from the OPC about whether your mitigation was adequate.

Write like a person who is sorry, not a press office

The regulator wants compliance. The recipient wants to feel like a human being told them the truth. You can satisfy both, and voice is how.

Use plain language. Short sentences. Address the reader as "you." A real apology near the top, before you ask anything of them, lands far better than a defensive one buried at the bottom. Compare these:

"We regret any inconvenience this incident may have caused and remain committed to the protection of your personal information."

"We're sorry. Your information was in a file that should have been secured and wasn't. Here is exactly what happened and what we're doing about it."

The first is corporate throat-clearing. The second tells the truth and respects the reader's intelligence. Regulators read tone as a proxy for organizational attitude. A cold, lawyered letter signals a company managing optics. A direct one signals a company managing the actual problem.

A few tone rules I hand every client. Don't bury the lede; the recipient should know within the first two sentences that their data was affected. Don't blame a third party even when a vendor caused it, because to the individual *you* are the organization that collected their data. And don't promise "this will never happen again." Nobody believes it, and it can be used against you later.

Quebec, health data, and the regimes that change the rules

PIPEDA is the floor, not the ceiling. If you have customers or employees in Quebec, Law 25 imposes its own duty to notify affected individuals and the Commission d'accès à l'information when a confidentiality incident presents a risk of serious injury. The CAI expects notice promptly. Quebec letters must be available in French, and not machine-translated French that reads like a phone settings menu. For Quebeckers, the French version is the one most of them will actually read. The penalties make the stakes real: Law 25 allows administrative monetary penalties up to $10 million or 2% of worldwide turnover, and penal fines that can run higher.

Health information adds a layer. Under Ontario's PHIPA, a custodian must notify the affected individual at the first reasonable opportunity when their personal health information is stolen, lost, or used or disclosed without authority, and must notify the Information and Privacy Commissioner of Ontario in the circumstances the statute and regulation prescribe, such as theft or unauthorized use by someone who knew better. The IPC publishes breach statistics and has no more patience for vague notices than the OPC does. If your breach touches regulated financial data, FINTRAC obligations may run in parallel, though those are reports to the regulator, not letters to individuals.

The pattern across all of them holds: specific facts, honest tone, concrete next steps, a real contact. Get the federal letter right and the others become variations on a template rather than separate inventions.

Keep the record, because the letter is evidence

Section 6 of the Regulations requires you to keep a record of every breach for 24 months, not just the ones you reported, and to hand those records to the Commissioner on request. The notification letter is the centrepiece of that file. Save the version you sent, the date, the recipient list, and your RROSH analysis showing why you concluded notification was or wasn't required. When the OPC opens an inquiry, the organization that can produce a clean, dated, reasoned file stands in a very different position from the one reconstructing events from memory.

Writing a strong PIPEDA breach notification letter under deadline, in two languages, while forensics is still running, is genuinely hard. That is the moment most teams produce their worst work, and the moment that gets scrutinized. If you would rather have a compliant, plain-language, bilingual draft built from your breach details in minutes instead of agonizing over wording at 11 p.m., Valdra generates your notification letters for you.