Confidentiality Incident Register: A Law 25 Template

March, in the thick of tax season. An assistant at a bookkeeping practice in Kirkland emails a client’s T4 slip to a different client with the same name. The recipient politely flags it and deletes the email. No risk of serious injury, no notice to the CAI. Case closed?

Not quite. That incident still has to be recorded in the confidentiality incident register. It is the Law 25 obligation businesses forget most often, precisely because it covers every incident, even the mundane ones.

The good news: a compliant register fits in a spreadsheet. Here is what it must contain, a template you can copy and filled-in examples.

What the law requires, and for which incidents

Section 3.8 of the Act respecting the protection of personal information in the private sector is short: the business must keep a register of confidentiality incidents and provide a copy to the CAI on request.

Everything hinges on the definition in section 3.6. A confidentiality incident is:

1. access to personal information not authorized by law;
2. use of it not authorized by law;
3. communication of it not authorized by law;
4. its loss, or any other breach of its protection.

In a typical SMB, that means: an email to the wrong recipient, an employee snooping in a customer file out of curiosity, a lost USB key, a compromised Microsoft 365 account, ransomware. The CAI is explicit that the register also includes incidents that present no risk of serious injury.

Incidents at your vendors count too. If your payroll provider or MSP suffers a breach involving your employees’ or clients’ information, it belongs in your register, not just theirs.

The eight mandatory items

Section 7 of the Regulation respecting confidentiality incidents (CQLR c. A-2.1, r. 3.1) requires:

1. a description of the personal information involved, or why it cannot be described;
2. a brief description of the circumstances;
3. the date or period of the incident, or an approximation;
4. the date or period when you became aware of it;
5. the number of people affected, or an approximation;
6. the factors that led you to conclude whether or not there is a risk of serious injury: sensitivity, possible ill-intentioned uses, anticipated consequences, likelihood of injurious use;
7. if the risk is serious, the dates of the notices to the CAI and to individuals, and whether any public notice was issued and why;
8. a brief description of the measures taken to reduce the risk of injury.

Copy-ready register template

Rebuild this table in a spreadsheet: one row per incident, one column per field. Numbered fields are required by the Regulation; lettered fields are recommended to make follow-up easier. The example uses the Kirkland T4 incident.

Two more example entries

The same template handles very different incidents. Field 6 is where they diverge.

Compromised mailbox at a Montréal real estate brokerage. An attacker has access to a broker’s mailbox for four days. It holds copies of driver’s licences and proof of income for roughly 140 buyers. Field 6: sensitive information, malicious actor, high likelihood of identity fraud, so serious risk. Field 7: dates of the CAI notice and individual notices. Field 8: password reset, sessions revoked, forwarding rule removed, MFA enforced.

Curiosity browsing at a veterinary clinic in Gatineau. An employee opens the file of a client who happens to be her neighbour, for no work reason. Nothing was copied or shared. Field 6: contact details and billing history, no disclosure, low likelihood: no serious risk. Field 8: meeting with the employee, confidentiality undertaking re-signed, access rights reviewed.

Audit logs are invaluable for filling fields 3 to 5 accurately. If you are not sure yours are turned on, our Microsoft 365 security audit article explains what to check.

Retention and protection of the register

Register entries must be kept up to date and retained for at least five years after the date or period you became aware of the incident (Regulation, s. 8). If an investigation later shows 300 people were affected instead of 40, update the existing entry rather than creating a new one.

If your business is also subject to PIPEDA, the Office of the Privacy Commissioner of Canada requires breach records to be kept for two years. Keeping them for five covers both regimes.

The register is itself a sensitive document. Describe the types of information without copying SINs or files into it. Restrict access to the privacy officer and leadership, and include the file in your backups.

Check your register in five minutes

• Incidents not reported to the CAI are in it too.
• Field 6 justifies the conclusion instead of just saying “low.”
• Incident date and date of awareness are recorded separately.
• Incidents that happened at your vendors are included.
• No personal information is copied into it unnecessarily.
• Entries are updated as the investigation progresses.
• A named person is responsible for keeping it.

To know when an incident must also be reported, see our guide to reporting a confidentiality incident to the CAI. The register is only one piece: our Law 25 cybersecurity checklist covers the rest.

This template is provided for information only and is not legal advice: validate it with your legal counsel before adopting it. If you would like a second set of eyes on your register and the safeguards around it, our Law 25 compliance service can help.