ISO 27001 · ISO 42001 · GDPR · PCI DSS · Loi 25

Quebec Law 25: Confidentiality Incidents, Register, and Notice Deadline

Quebec Law 25: Confidentiality Incidents, Register, and Notice Deadline

Law 25 handles confidentiality incidents differently from GDPR. It requires a register for *every* incident, and notice to the CAI and affected individuals only when there is a risk of serious prejudice. But unlike GDPR, it sets no 72-hour clock: notice must be given "as soon as possible." That absence of a precise clock is what catches SMBs — "as soon as possible" is not "when we have time."

Articles 3.5 through 3.8 of the Act respecting the protection of personal information in the private sector, in force since 22 September 2022, frame the management of confidentiality incidents. The content below is grounded in the Cybereco primary guide on Law 25; the CAI also publishes an official incident-register schema. Confirm the exact wording against the official text on the CAI website and LégisQuébec before relying on it legally.

What constitutes a confidentiality incident

The Law gives four situations that may qualify as confidentiality incidents:

1. Unauthorized access by law to a personal information. 2. Unauthorized use by law of a personal information. 3. Unauthorized communication by law of a personal information. 4. Loss of a personal information or any other breach of the protection of such information.

The scope is broad. An email containing personal information sent to the wrong recipient, an employee consulting a file without a professional motive, a stolen laptop with customer data, a server breach — each may qualify. Qualification does not depend on scale; a minor incident is an incident.

The register: mandatory for every incident

The Law requires an organisation to keep a register of every confidentiality incident, communicated to the CAI on request. The register is not a proactively submitted document — it is retained and produced when the CAI asks. It is the accountability artifact proving the organisation recorded each incident.

The CAI publishes an official register schema (confidentiality-incident schema). Absent using that exact schema, a simple template — spreadsheet or table — capturing the elements the Law requires is sufficient. The information to capture per incident typically includes: the nature of the incident, the personal information concerned, the individuals affected, the discovery date, the serious-prejudice risk assessment, the measures taken, and the notification decision (notify or not, and whom).

The common mistake, flagged in the Law 25 pillar, is believing only major ransomware incidents must be recorded. Every incident goes in the register — the decision to notify is distinct from the decision to record.

Notice: conditioned on a risk of serious prejudice

The Law imposes a dual notice — to the CAI and to the affected individuals — only when an incident presents a risk of serious prejudice. The Cybereco guide gives examples of serious prejudice: reputational harm, credit-file harm, identity theft, and the like.

The logic is therefore in two steps:

1. Every incident is recorded in the register. Unconditionally. 2. The incident is assessed for a risk of serious prejudice. With legal counsel and the personal-information officer, the organisation determines whether the incident presents a risk of serious prejudice. 3. If yes, notice to the CAI and to the affected individuals. If no, the incident stays in the register without external notice — but the decision and its rationale are documented.

The serious-prejudice risk assessment is the critical step. It is what triggers or does not trigger the notice obligation, and it is what the CAI will examine if an un-notified incident is later discovered. Document the assessment.

The deadline: “as soon as possible,” not 72 hours

This is where Law 25 differs most from GDPR. GDPR (Article 33) sets a 72-hour clock from awareness to notify the supervisory authority. Law 25 sets no numbered deadline. Notice must be given “as soon as possible” — without undue delay.

The absence of a precise clock is not permission to stall. “As soon as possible” reads in practice as a short delay, measured in days, and the organisation must be able to show it notified as soon as it had the necessary elements (incident identified, risk assessed, individuals identified). An unjustified late notice is a failure. The parallelism with GDPR is covered in the Law 25 and GDPR parallelism article — an SMB subject to both can adopt the 72-hour standard as an internal target to satisfy both regimes.

The notice content

The notice to affected individuals must inform them of the incident and of the measures they can take to protect themselves (for example, monitor their credit file, change a password). The notice to the CAI presents the incident, the information concerned, the number of individuals, the risk assessment, and the measures taken or planned. The register, kept current, supplies most of this content.

The response plan an SMB needs before the incident

As with GDPR, the cost of preparation is paid before, not during:

1. An internal reporting channel. Any employee who suspects an incident must know whom to tell — the officer or a designated contact — and reporting must be immediate. 2. The register template. A spreadsheet or table with the CAI schema’s columns, ready to fill. Do not draft it during the incident. 3. The serious-prejudice assessment grid. A list of criteria — data nature (sensitive, identity, financial), number of individuals, potential for malicious use — that helps the officer and legal counsel decide. Document the decision and its rationale. 4. The notice templates. One template for the CAI and one for individuals, pre-filled with the officer’s contact, to complete with the incident’s elements. 5. The containment runbook. The immediate measures — revoke an access, isolate a system, recover a device — that appear in the notice’s “measures taken” section.

The link to the rest of the programme

The incident rests on the personal-information officer appointed under Article 3.1 — it is that officer, with legal counsel, who leads the serious-prejudice risk assessment. The parallelism with GDPR shows how to merge the Law 25 register and the GDPR breach register into one artifact. The SMB getting-started checklist places the incident register among the first phase-1 actions. If the organisation also runs ISO 27001, the incident register is the Law 25 view of the ISMS incident-response procedure (Annex A.5.24–A.5.27).

How this fits the series

This is the operational companion to the Law 25 pillar, the second phase-1 obligation. It assumes the officer is appointed — that officer keeps the register and leads the assessment. The parallelism with GDPR covers fusing the two incident regimes.

What to do next

Stand up the incident-register template this week — a table with the CAI schema’s columns, stored alongside the governance policies. Draft the serious-prejudice assessment grid with your legal counsel. Prepare the two notice templates (CAI and individuals). And remind the team that every incident — not only the major ones — goes in the register. Notice is given “as soon as possible”; the register is kept for everything.

Want a Law 25 incident-readiness check? Book a **45-minute Law 25 programme start** — we review your register template against the CAI schema, test your serious-prejudice assessment grid, and prepare the notice templates. Bilingual FR/EN, no obligation.

/loi-25-starter/ · download the Law 25 SMB getting-started checklist

Get Your Free Security Readiness Assessment

Map your controls, identify compliance gaps, and secure your systems before the audit.

About the author

adsystemsentry

Governance, Risk, and Cybersecurity leader enabling enterprise resilience and SaaS scale through strategic security architecture. I design and lead integrated governance frameworks that align regulatory compliance, risk oversight, and business growth objectives. Certified ISO 27001 Lead Implementer with direct exposure to senior leadership and governance bodies across SaaS, cloud, and regulated environments.

View LinkedIn profile →

Related articles

Search

Stay Secure

Get weekly security insights and actionable guidance straight to your inbox.