Privacy Incident Register: Your Obligations Under Law 25

Quebec's Law 25 requires every business subject to the province's private sector privacy law to maintain an internal register of confidentiality incidents involving personal information, and — critically — that obligation applies to every qualifying incident, not just the ones serious enough to notify the Commission d'accès à l'information (CAI) or the affected individuals. This single distinction trips up a large share of Quebec SMBs, because most compliance conversations focus almost entirely on breach notification thresholds, leaving the quieter, more constant obligation to simply record incidents as an afterthought — or something that never gets built at all.

This article walks through what actually counts as a confidentiality incident, exactly what fields the register needs to capture, how the risk-of-serious-injury test works and why it's separate from the register duty, the five-year retention rule, a practical template you can copy today, and what happens to a business that gets audited without one. As always with anything touching Law 25, we'll say this plainly up front: IT Cares is an IT and cybersecurity company, not a law firm. This article is general information to help you understand the operational side of the obligation — the actual legal determination of risk, notification wording, and edge cases should go through a privacy lawyer or the CAI's own published guidance.

What Counts as a "Confidentiality Incident" Under Law 25

Law 25 defines a confidentiality incident broadly, and understanding that breadth is the first step to actually complying with the register requirement. Under the law, a confidentiality incident is any of the following involving personal information your organization holds or controls:

• Unauthorized access — someone views, opens, or retrieves personal information they had no legitimate reason or permission to see. This includes external attackers, but it also includes an employee browsing a coworker's HR file or a customer's account out of curiosity.
• Unauthorized use — personal information gets used for a purpose it wasn't collected for, or by someone without the authority to use it that way, even if no outside party ever sees it.
• Unauthorized communication — personal information gets shared, sent, disclosed, or otherwise transmitted to someone who shouldn't have received it. A misdirected email with an attached client file is the textbook example.
• Loss of personal information — a device, physical file, or backup containing personal information goes missing, whether or not anyone actually accessed the data on it. A lost unencrypted laptop or USB key qualifies the moment it's lost, regardless of whether it's later proven someone opened the files.

Notice what's absent from that list: any severity threshold. The law does not say "a serious unauthorized access" or "a significant loss." It captures the full range, from a single employee peeking at a colleague's file with no wider consequence, to a large-scale ransomware breach affecting thousands of customer records. Both are confidentiality incidents. Both must be logged. Only one of them is likely to require notifying the CAI.

Why the Register Requirement Is Separate From the Notification Requirement

This is the core conceptual point of this entire article, so it's worth stating twice in different ways. Law 25 creates two distinct obligations that many business owners collapse into one:

1. The register obligation — log every confidentiality incident internally, always, regardless of severity.
2. The notification obligation — notify the CAI and the affected individuals, but only when the incident presents a risk of serious injury to those individuals.

It's entirely possible — and in practice, common — for a small business to go an entire year logging several incidents in its register without a single one crossing the threshold that requires notification. That's not non-compliance. What is non-compliance is treating "this incident doesn't need to be reported to the CAI" as equivalent to "this incident doesn't need to be recorded anywhere." The register exists precisely to create a paper trail of an organization's full incident history — including the incidents it correctly decided not to escalate — so that a regulator reviewing that history later can see the reasoning, not just the end result.

Register-Only Incident vs. Notifiable Incident

The table below compares a typical incident that stays in the internal register with one that crosses into notifiable territory. The line between the two comes down almost entirely to the risk-of-serious-injury assessment covered in the next section.

The last row is the point of this whole article: both incidents get an entry. The only difference is what happens after the entry is made — one triggers outbound notification, the other doesn't.

The Risk-of-Serious-Injury Test: What Determines Notification

Once an incident is logged, the next step is assessing whether it presents a "risk of serious injury" to the individuals whose information was involved — the legal threshold that triggers mandatory notification to the CAI and to those individuals. Three factors drive this assessment, and they're meant to be weighed together rather than in isolation:

1. Sensitivity of the personal information involved

A name and postal code alone sit at the low end of sensitivity. Social insurance numbers, financial account details, health information, login credentials, and biometric data sit at the high end. The more sensitive the data, the lower the bar for the overall incident to be considered high-risk, even if the other two factors are moderate.

2. Anticipated consequences for the affected individual

This asks what could realistically happen to someone as a result of the incident — identity theft, financial fraud, discrimination, reputational harm, or in rarer cases physical safety risk. An incident with a plausible path to any of these consequences weighs toward notification, even if the volume of data or number of people affected is small.

3. Likelihood the information will be used for injurious purposes

This factor looks at circumstances around the incident itself: Was the data encrypted? Was it recovered quickly? Is there any evidence it's already been accessed or shared further? Was the recipient or party who gained access a known, trusted party, or an unknown outside actor? An encrypted laptop that goes missing and is later recovered unopened carries a much lower likelihood of injurious use than the same laptop, unencrypted, found to have had its files accessed.

What Your Register Must Capture, Field by Field

Law 25 doesn't mandate a specific software tool or file format for the register — a spreadsheet, a shared document, or a dedicated compliance platform can all satisfy the requirement, as long as the required information is captured consistently and the record can be produced if requested. At minimum, each entry needs the following fields:

Notice that this template doubles as a defensible audit trail. If the CAI ever asks "how do you handle confidentiality incidents," a properly maintained register answers that question with evidence rather than a verbal assurance.

Setting Up a Register: A Step-by-Step Process

Checklist: What Your Privacy Incident Register Must Capture

Use this as a quick self-audit against your current process, or as a build list if you're starting from nothing:

• ☐ A written internal definition of "confidentiality incident" covering unauthorized access, use, communication, and loss
• ☐ A designated privacy officer or equivalent owner responsible for the register
• ☐ A simple internal reporting channel staff actually know about and will use
• ☐ A template capturing date/period, description, data categories, and number of persons affected
• ☐ A documented risk-of-serious-injury assessment for every entry, not just the notifiable ones
• ☐ A field recording whether the CAI and affected individuals were notified, and when
• ☐ A field recording corrective or preventive measures taken after each incident
• ☐ Access controls restricting who can view or edit the register itself
• ☐ A retention policy confirming entries are kept a minimum of five years
• ☐ A periodic (at minimum annual) review of past entries to spot recurring risk patterns
• ☐ A process for producing the register quickly if requested during a CAI audit or investigation

Three Illustrative Quebec SMB Scenarios

The following scenarios are fictional composites built from common patterns we see across Quebec small businesses — they're illustrative, not case studies of specific real clients, but the numbers and outcomes reflect realistic situations.

Scenario 1 — Montreal retail boutique: a misdirected marketing email

A 6-employee home goods retailer in the Plateau neighbourhood sent a promotional email to its customer list and accidentally used the "To" field instead of "BCC," exposing roughly 340 customer email addresses to each other. No names, phone numbers, or purchase history were included — just email addresses. The owner logged the incident in a new register the same afternoon after a staff member flagged it, assessed the sensitivity as low (email addresses only, no other identifiers), the anticipated consequences as minimal (no realistic path to fraud or harm from an exposed email address alone), and concluded the incident did not meet the risk-of-serious-injury threshold. No CAI notification was made. The register entry recorded the corrective measure taken: switching the email platform's default send behaviour to BCC for all list-wide sends going forward. Total cost: about 90 minutes of the owner's time and no external fees, since the incident was straightforward enough to assess without outside help.

Scenario 2 — Quebec City professional services firm: an employee snooping incident

A 14-person accounting firm discovered, through routine access log review, that a junior employee had looked up a former romantic partner's client file three times over two months, despite having no work reason to access that account. This is a textbook unauthorized access incident under Law 25's definition, entirely internal, with no external exposure. The firm's privacy officer logged the incident, assessed the risk considering the sensitivity of financial data involved and the personal (non-business) motive behind the access, and determined this did meet the risk-of-serious-injury threshold given the targeted, motivated nature of the access to sensitive financial records. The affected client was notified directly, and the incident was reported to the CAI. The firm also used the register's "measures taken" field to document new access-log alerting rules and a revised employee conduct policy. Estimated cost: roughly 4 hours of the privacy officer's time plus a one-time $650 CAD consultation with a privacy lawyer to confirm the notification approach and wording.

Scenario 3 — Laval e-commerce SMB: a third-party vendor data spill

An 8-person e-commerce business using a third-party fulfillment vendor discovered the vendor had mistakenly included full customer shipping addresses, phone numbers, and order values in a data export sent to an unrelated client of the vendor's, affecting about 1,150 of the e-commerce business's customers. Because the data included addresses and phone numbers alongside order values, and because it was sent to a genuinely unrelated third party outside any trust relationship, the business assessed this as meeting the serious injury threshold — the combination of contact information and purchase behaviour created a real (if moderate) risk of targeted phishing or scam attempts against affected customers. The CAI was notified, and affected customers received a notification email explaining what happened and recommending they watch for suspicious contact referencing their recent orders. The register entry also recorded a new vendor contract clause requiring the fulfillment company to notify the e-commerce business within 24 hours of any incident on their end going forward. Estimated cost: about $1,800 CAD in combined legal review, a mass notification email send, and the time spent updating the vendor agreement.

Budgeting for a Compliant Register in CAD

Setting up and maintaining a Law 25 confidentiality incident register doesn't require a large budget for most SMBs, but the cost scales with how much outside expertise you bring in and how automated you want the underlying detection to be.

For most Quebec SMBs under 20 employees, a reasonable starting budget is a DIY template built internally, paired with an hour or two of a privacy consultant or lawyer's time to sanity-check the risk assessment process — typically landing in the $500–$1,500 CAD range as a one-time setup cost, with negligible ongoing cost beyond staff time to log entries as they occur.

Consequences of Not Maintaining a Proper Register

The register requirement is not a soft suggestion. Law 25 introduced meaningful administrative monetary penalties for private sector organizations, and failing to maintain an adequate confidentiality incident register is treated as its own standalone compliance failure — separate and apart from whether any specific incident ever needed to be reported.

• Administrative monetary penalties. The CAI has the authority to issue penalties for privacy law violations, and a missing or clearly inadequate register is straightforward evidence of non-compliance during a review, independent of whether a serious breach ever occurred.
• Exposure during a CAI audit or investigation. The CAI doesn't need a specific breach to trigger a review — audits can arise from complaints, sector-wide initiatives, or routine oversight. A business asked to produce its register with nothing to show has no way to demonstrate it identifies and tracks incidents as required.
• Weakened position if a real breach does happen. An organization with a documented history of small, properly-assessed, correctly-not-notified incidents is in a far stronger position when a genuinely serious incident occurs — it can show a consistent, good-faith process rather than scrambling to explain its practices for the first time under pressure.
• Reputational and contractual risk. Increasingly, larger clients and partners ask SMB vendors to confirm their Law 25 compliance posture as part of due diligence before signing contracts — an inability to describe or produce an incident register can cost business relationships even absent any regulatory action.

Where the CAI Fits Alongside Federal and General SMB Resources

Quebec's Law 25 is enforced by the Commission d'accès à l'information du Québec (CAI), the provincial regulator responsible for both the public and private sector privacy regimes in the province — the CAI is your primary point of reference for anything specific to the confidentiality incident register requirement. Businesses operating outside Quebec, or across multiple provinces, should also be aware of the federal Office of the Privacy Commissioner of Canada (OPC), which oversees PIPEDA and maintains its own breach record-keeping and notification requirements that run in parallel to Law 25 rather than replacing it — our Law 25 vs PIPEDA comparison breaks down exactly where the two overlap and diverge.

For general SMB compliance and advisory support beyond the strictly legal dimension, both the Business Development Bank of Canada (BDC) and Innovation, Science and Economic Development Canada (ISED) publish resources aimed at helping small businesses build sound data-handling and cybersecurity practices. None of these bodies substitute for a privacy lawyer's advice on your specific situation, but they're legitimate starting points for general guidance:

• cai.gouv.qc.ca — Commission d'accès à l'information du Québec, the primary Law 25 regulator
• priv.gc.ca — Office of the Privacy Commissioner of Canada, for federal PIPEDA context
• bdc.ca — Business Development Bank of Canada, general SMB advisory resources
• ised-isde.canada.ca — Innovation, Science and Economic Development Canada, SMB and digital resources

Where IT Cares Fits — and Where We Deliberately Stop

To be direct about scope: IT Cares helps Quebec and Canadian SMBs with the technical and operational side of privacy incident management — setting up logging and monitoring so incidents actually get detected rather than discovered by accident months later, building access controls and alerts that flag unauthorized access patterns, helping structure and populate the register itself, and responding to active incidents (a compromised account, a ransomware event, a lost device) with the kind of incident response that produces the clean, factual documentation your register needs.

What we don't do is provide legal opinions on whether a specific incident meets the risk-of-serious-injury threshold, draft your official CAI notification, or represent your business in a CAI investigation. That's squarely a privacy lawyer's role, and we'll say so plainly to any client who asks — better to be told clearly what we're not qualified to do than to get a confident-sounding answer from the wrong source on something with real legal consequences.

If your business needs an experienced security audit to understand where confidentiality incidents are most likely to originate, or ongoing cybersecurity monitoring to catch them early, that's exactly the kind of groundwork that makes a Law 25 register something you can actually keep populated accurately, rather than a document that only gets updated after something goes wrong. Our related guide on what an annual compliance audit should cover also walks through how the register fits into a broader yearly review cycle.

Frequently Asked Questions