Quebec Law 25 Compliance: The Privacy Law Every SaaS Company Should Know About (But Probably Doesn't)

Quebec Law 25 is the province's modernized private-sector privacy law: a set of amendments (adopted in 2021 as Bill 64) to the Act respecting the protection of personal information in the private sector (P-39.1), fully in force since September 2024. It applies to any private-sector organization that collects personal information from Quebec residents, regardless of where the company is headquartered. A SaaS company in Ontario, Texas, or Berlin with a handful of Quebec users is in scope, and the penalty ceiling reaches $25 million or 4% of worldwide turnover.

The teeth are what changed. The Commission d'accès à l'information (CAI) can impose administrative monetary penalties up to $10 million or 2% of worldwide turnover (s. 90.1), penal fines up to $25 million or 4% (s. 91), and individuals can pursue punitive damages of not less than $1,000 per violation (s. 93.1). Where PIPEDA is enforced through recommendations, Law 25 gives the regulator direct penalty authority.

Most Law 25 guides are written by privacy software vendors or law firms and explain what the law says. This checklist covers what security and IT teams need to implement, mapped to the sections of the legislation itself.

A note on scope: Truvo Cyber is not a law firm and this is not legal advice. What follows is a security practitioner's reading of Law 25 as it maps to technical controls and operational processes. On client engagements we coordinate with qualified privacy counsel to validate the legal specifics.

Who needs to care about Quebec Law 25

Any private-sector organization that collects personal information from people in Quebec. A services firm with one employee working remotely from Montreal is in scope. So is a US SaaS company whose signup form accepts Quebec email addresses. There is no revenue threshold and no employee-count exemption.

For organizations already pursuing SOC 2 or ISO 27001, the overlap is substantial. Many of the technical safeguards Law 25 requires are controls a well-built security program already runs. The gaps tend to sit in privacy governance, consent management, and data lifecycle processes rather than in security infrastructure.

The revenue angle is direct. Enterprise buyers with Quebec operations now ask about Law 25 in security questionnaires the same way they ask about SOC 2. An organization that can answer with a named privacy officer, a breach register, and a PIA process stays in the deal; one that cannot gets flagged for legal review, and legal review is where deals go to stall.

The Law 25 compliance checklist

1. Designate a privacy officer (s. 3.1)

By default, the person with the highest authority in the organization is responsible for compliance. That responsibility can be delegated in writing to any member of personnel, and the privacy officer's title and contact details must be published on the company website.

• Formally designate the privacy officer in writing
• Publish their title and contact details on the website, accessibly, not buried in a footer
• Give the role real authority and resources

In smaller organizations this often lands on the person already running the security program. That works, as long as the responsibilities are documented.

2. Establish a privacy governance policy (s. 3.2)

Organizations must establish and implement governance policies and practices for protecting personal information: retention and destruction rules, roles and responsibilities, and a complaint process. A simplified version must be published in clear, simple language. This is an internal governance document, separate from the website privacy policy.

• Document what personal information is collected, why, where it lives, who has access, how long it is retained, and how it is destroyed
• Align retention periods with business needs, not indefinite defaults
• Publish the simplified public version

Teams with an existing ISMS under ISO 27001 or a SOC 2 program already have most of this governance structure. The gap is usually privacy-specific language and data lifecycle documentation.

3. Breach notification and the incident register (ss. 3.5 to 3.8)

When a confidentiality incident presents a risk of serious injury, the organization must notify the CAI and the affected individuals. A confidentiality incident is any unauthorized access, use, or communication of personal information, or any loss of it, and every incident, notifiable or not, must be recorded in a register.

• Add privacy breach notification procedures to the incident response plan
• Stand up a breach register: what happened, what information, how many people, remediation, whether the CAI and individuals were notified
• Define serious injury criteria internally so the response team can make the notification call quickly, weighing sensitivity and anticipated consequences (s. 3.7)

Teams already running SOC 2 CC7.1 (event monitoring) and CC7.3 (incident response) have the infrastructure. The addition is the privacy notification workflow and the formal register.

4. Privacy impact assessments (s. 3.3)

PIAs are mandatory for any project involving the acquisition, development, or overhaul of an information system that handles personal information, and the privacy officer must be consulted from the project's start. The CAI has published its own PIA guide and template; the template is optional, but it is a solid starting point.

• Build PIA triggers into project intake so assessments happen before development starts
• Keep assessments proportionate to the sensitivity, purpose, and volume of the information
• For cross-border transfers, assess whether the receiving jurisdiction offers protection equivalent to Quebec's standards

5. Consent management (ss. 8, 8.1, 12)

Law 25 takes a stricter position on consent than PIPEDA. At collection, individuals must be told the purposes, the means of collection, their access and rectification rights, and their right to withdraw consent, all in clear and simple language. Any technology that can identify, locate, or profile a person requires prior notification and consent, and sensitive personal information requires express consent.

• Audit every collection point and attach a clear, specific consent mechanism to each
• Implement cookie consent that defaults to off, with no pre-checked boxes
• Record proof of consent: what was consented to, when, by whom
• Make withdrawing consent as easy as giving it

This is where security programs tend to have the largest gap. Security controls protect data after collection; consent management governs whether it should be collected at all, and that usually means new tooling outside the traditional security stack.

6. Data subject rights (s. 27)

Individuals have the right to access their personal information, have it corrected, and receive computerized personal information in a structured, commonly used technological format. Requests must be answered within 30 days.

• Publish a clear request process next to the privacy officer's contact details
• Build workflows that fulfill access, correction, and portability requests inside the 30-day window
• Support de-indexation requests, where individuals ask that their information stop being disseminated

The 30-day window is firm, and meeting it requires knowing where personal information lives. Companies without a data inventory struggle here, and building one tends to turn up personal information in systems nobody remembered to include: logging pipelines, analytics tools, old CRM exports.

7. Technical security safeguards (s. 10)

Section 10 requires security measures that are reasonable given the sensitivity of the information and the purposes for which it is used. The law does not prescribe specific controls; the expectation is proportionality.

• Encryption at rest and in transit for systems holding personal information
• Least-privilege access with periodic access reviews
• Logging and monitoring of access to personal information
• Vulnerability scanning with timely remediation
• Secure disposal when retention periods expire

Organizations with a program aligned to SOC 2 or ISO 27001 typically meet this section without significant new work: the controls map to CC6.1 through CC6.3, CC7.1 and CC7.2, and CC8.1. The difference is scope. Law 25 applies these expectations specifically to personal information, so the documentation needs to say so.

8. Automated decision-making transparency (s. 12.1)

When a decision about a person is based exclusively on automated processing of their personal information, the organization must tell them at the time of the decision and, on request, explain the information and reasons behind it and give them a path to human review.

• Inventory automated decision-making systems that process personal information
• Notify individuals at decision time and offer human review on request
• Document the logic behind the automated processing

This requirement grows more relevant as companies adopt AI-driven tools, and it overlaps considerably with the transparency requirements in ISO 42001.

How Law 25 maps to SOC 2 and ISO 27001

The security safeguards and incident response requirements are well covered by SOC 2 and ISO 27001. The privacy-specific requirements, PIAs, consent, and data subject rights, sit in the gap between security and privacy governance. ISO 27701, the privacy extension to ISO 27001, closes most of that gap, but few organizations have adopted it yet. For the wider Canadian picture of how Law 25 sits alongside PIPEDA, the Bill C-27, PIPEDA, and Law 25 guide covers the federal side.

Where organizations get stuck

Data inventory. Fulfilling data subject requests and conducting PIAs requires knowing where personal information lives. Organizations tend to underestimate how many systems contain it, from CRM and HR platforms to logging systems and analytics tools.

Cross-border transfers. Nearly every cloud-hosted company is transferring data outside Quebec. The transfer assessment is not a one-time exercise: it needs revisiting when providers change jurisdictions, when new services are adopted, or when the receiving jurisdiction's laws shift.

Consent architecture. Retrofitting explicit consent into existing systems is harder than building it in from the start, and the requirement extends beyond cookies to every collection point: form submissions, account creation, email tracking, analytics.

The practical sequence

1. Designate the privacy officer and publish the appointment. Immediate, and it closes the compliance gap most visible to regulators.
2. Build the data inventory. Every other requirement depends on knowing what personal information exists and where.
3. Update the incident response plan with privacy breach notification and create the register.
4. Draft the governance policy based on what the inventory reveals about real practices.
5. Add PIA triggers to project intake so new initiatives are assessed before launch.
6. Fix consent management at existing collection points, starting with customer-facing systems and marketing tools.
7. Stand up data subject request workflows and test them end to end before they are needed.

The advantage of approaching Law 25 through an existing security program is that the technical safeguards, the most resource-intensive piece, are already in place. The remaining work is governance, process, and documentation, and each item on the checklist above is one more question a Quebec-exposed buyer's questionnaire stops being able to stall a deal with.

Frequently Asked Questions

Does Quebec Law 25 apply to companies outside Quebec?

Yes. Law 25 applies to any private-sector organization that collects personal information from people in Quebec, regardless of where the organization is headquartered. A SaaS company in another province or country with Quebec-based users, customers, or employees is in scope.

What are the penalties for Law 25 non-compliance?

The CAI can impose administrative monetary penalties up to $10 million or 2% of worldwide turnover, and penal fines can reach $25 million or 4% of worldwide turnover. Individuals can also pursue punitive damages of not less than $1,000 per violation through private action.

Is Law 25 the same as Bill 64?

Yes. Bill 64 was the bill's number before adoption; it became Law 25 (An Act to modernize legislative provisions as regards the protection of personal information) and amended Quebec's private-sector privacy act, P-39.1. All requirements have been in force since September 2024, when the data portability right took effect.

Does SOC 2 or ISO 27001 compliance cover Law 25?

Partially. The security safeguards and incident response requirements overlap heavily with SOC 2 and ISO 27001 controls. The privacy-specific requirements, including privacy impact assessments, consent management, and data subject rights, are not covered and need dedicated processes. ISO 27701 closes most of that remaining gap.

What is the first step toward Law 25 compliance?

Designate a privacy officer in writing and publish their title and contact details on the company website, then build a data inventory. Every other requirement, from breach notification to data subject requests, depends on knowing what personal information the organization holds and where it lives.

Does Law 25 require cookie consent banners?

Law 25 requires prior notification and consent for any technology that can identify, locate, or profile a person, which covers most tracking cookies and analytics. Consent must be opt-in, in clear and simple language, with no pre-checked boxes, making Quebec the strictest Canadian jurisdiction for tracking consent.