Security

Real offensive depth

Testing and defence led by a published security researcher with five CVEs, including a CVSS 9.1 Mirai botnet kill-switch.

All security →
Compliance

Audit-ready, fixed scope

SOC 2, ISO, and the Canadian privacy stack, run end to end with an independent auditor.

All frameworks →
Resources

Learn the space

Original research, free tools, and plain-language guides on security and compliance, from a published security researcher.

Read the blog →
Compliance

Quebec Law 25 Requirements: A Practical Checklist

Quebec Law 25 (formerly Bill 64) is the real Canadian privacy stick. PIPEDA has been on the books for over two decades with fines that rarely bite. Law 25 is different: it carries administrative monetary penalties up to $10 million or 2% of worldwide turnover, and penal fines up to $25 million or 4% of worldwide turnover for the most serious violations. If your organization handles personal information belonging to Quebec residents, this law applies to you, regardless of where your company is headquartered.

The law rolled out in three phases between September 2022 and September 2024, and all three are now fully in force. There is no grace period left. Below is a practical checklist of what compliance actually requires, in plain language, without the legal jargon.

The Law 25 Compliance Checklist

1. Appoint a Privacy Officer

Every organization subject to Law 25 must designate a person responsible for the protection of personal information. By default, this is the most senior person in the organization (often the CEO or president) unless that responsibility is formally delegated in writing to someone else, such as a privacy officer, general counsel, or head of compliance. Their name and contact information must be published, typically on your website's privacy page.

2. Conduct Privacy Impact Assessments (PIAs)

Before acquiring, developing, or significantly redesigning any information system or electronic service that involves personal information, you need a documented privacy impact assessment. This applies to new SaaS products, CRM migrations, analytics tooling, and AI features alike. A PIA should be proportional to the sensitivity of the data involved, but skipping it entirely is a common gap we see in early-stage companies moving fast.

3. Get Consent That Actually Meets the Bar

Consent under Law 25 must be clear, free, and informed, and it must be requested separately from other information given to the person (no more burying it in a wall of terms and conditions). For sensitive personal information, consent must be given expressly. Pre-checked boxes and implied consent through inaction do not meet the standard.

4. Build a Data Breach Notification Process

If a confidentiality incident presents a risk of serious injury, you must notify the Commission d'acces a l'information (CAI) and the affected individuals as soon as possible. You also need to maintain an internal incident register, whether or not the incident met the notification threshold, and that register must be available to the CAI on request. Most organizations underestimate how fast "as soon as possible" needs to be in practice, so the process has to be built and tested before an incident happens, not during one.

5. Honour the Right to Data Portability

Individuals can request that computerized personal information you hold about them be transferred to them or to a third party, in a structured, commonly used technology format. This took effect in September 2024 and requires your systems to actually support structured export, not just deletion or access requests.

6. Implement Privacy by Default

Any technological product or service offered to the public that has default parameters allowing the identification, location, or profiling of a person must be configured, by default, to the highest level of privacy protection. This is one of the more overlooked requirements because it touches product and engineering decisions, not just legal policy documents.

7. Publish a Clear, Accessible Privacy Policy

Your privacy policy has to be written in clear and simple language and made available on your website. It should describe what personal information you collect, why, how long you retain it, and how individuals can exercise their rights. Generic, boilerplate policies copied from a template rarely hold up to scrutiny.

8. Assess Cross-Border and Third-Party Data Transfers

Before transferring personal information outside Quebec, whether to a cloud provider, a subprocessor, or a parent company in another country, you need to conduct a transfer assessment confirming the destination offers protection equivalent to Quebec's standard. This is especially relevant for companies using US-based SaaS infrastructure, which is most of them.

9. Establish Governance Policies and Procedures

Organizations must implement and publish governance policies and practices regarding the personal information they hold, covering the entire lifecycle from collection to destruction. This is the connective tissue that ties the other requirements together into something auditable rather than a one-time exercise.

10. Prepare for Automated Decision-Making Disclosure

If you use personal information to render a decision based exclusively on automated processing (credit scoring, algorithmic hiring screens, automated pricing), you must inform the individual at the time of the decision, and they have the right to request an explanation and to have a human review the decision. As more companies bolt AI into customer-facing workflows, this requirement gets triggered more often than founders expect.

Privacy obligations piling up? Law 25 and PIPEDA readiness, with a named privacy officer where the law asks for one. Privacy officer

Why This Checklist Isn't the Whole Story

Every item above sounds like a discrete task, but Law 25 compliance is really a governance program, not a checklist you complete once and file away. The CAI has shown it will investigate and fine organizations that treat privacy as a paperwork exercise rather than an operating practice. We break down the full requirement set, enforcement history, and how it maps to existing frameworks like SOC 2 in our Quebec Law 25 framework guide.

If your organization is also pursuing SOC 2 or other security attestations, there's meaningful overlap between Law 25's governance requirements and standard compliance controls, which is worth mapping early rather than building two separate programs. Our compliance advisory services cover this kind of framework alignment for Canadian and cross-border companies.

Get a Straight Answer on Where You Stand

If you're not sure whether your organization is fully covered under Law 25, or you've completed some of the checklist above but not all of it, it's worth getting a direct assessment rather than guessing. Contact traztech to talk through your current privacy posture and what a practical path to compliance looks like for your team.

What the CAI actually looks at when it opens a file

The checklist above describes the obligations. What decides whether you have a bad month is the order in which the Commission d'acces a l'information asks for things once something has gone wrong or once someone has complained about you. In practice the first request is narrow and documentary. The CAI asks for your governance policies as they existed on a specific date, your incident register, the privacy impact assessment covering the system involved, and the name and appointment record of the person responsible for the protection of personal information. Notice that every one of those is a document with a date on it. An organization that wrote its policy the week after the complaint arrived is visible immediately, because the version history says so.

The second request is usually about a specific flow of data. Where did this information come from, what were the individuals told at the point of collection, who inside the company can see it, which suppliers process it, and where do those suppliers hold it. Companies that have a real data inventory answer that in a day. Companies that do not spend three weeks interviewing engineers and still produce something they are not confident is complete. The inventory is the artifact that makes every other obligation cheap, and it is the one most often skipped because nobody outside the company ever asks to see it directly.

The incident register is a specific document, not a spreadsheet you invent

Requirement four above says to build a breach notification process. The part that gets missed is that the register itself has a prescribed shape under the regulation respecting confidentiality incidents. For each incident you record a description of the personal information involved, the date or period of the incident, the date you became aware of it, the number of people affected including how many are in Quebec, a description of the elements of injury that could result, the date notices went to the CAI and to individuals or the reason you decided none were required, and a description of the measures you took to reduce the risk of injury and to prevent recurrence. That record is kept for five years from the date you became aware of the incident.

Two consequences follow. First, the register covers every confidentiality incident, including the ones that clearly did not meet the risk of serious injury threshold, so a laptop left in a taxi and recovered the same afternoon still generates an entry. Second, because the register asks you to write down why you decided not to notify, your risk assessment has to exist in writing at the time of the decision. Reconstructing that reasoning eighteen months later, in front of a regulator, with a plaintiff's lawyer also asking, is a far worse position than spending forty minutes documenting it on the day.

On timing, Quebec did not adopt a fixed hour count the way some jurisdictions did. The standard is to notify with diligence. That sounds softer than seventy-two hours and in practice it is harder, because there is no number to hide behind. What the CAI weighs is whether your delay was justified by the work of investigating. A company that took eight days but can show a dated timeline of containment, forensic scoping, and legal review is in a defensible position. A company that took four days because the person who found it was not sure who to tell is not.

Cross-border transfers: what a real assessment contains

Item eight is where most Canadian SaaS companies quietly fail, because the honest answer is that their production database sits in a US region of a hyperscaler and roughly thirty vendors touch some slice of customer data. The law does not prohibit that. It requires a documented assessment before the transfer, weighing the sensitivity of the information, the purpose of its use, the protections it would receive including contractual ones, and the legal framework of the destination jurisdiction including the rules that apply there.

A defensible assessment for a single vendor runs two or three pages and names things. Which data elements go, at what volume, under which contract clauses, with what encryption and key custody, under which subprocessor list, and what the destination regime allows a government to demand. The conclusion is not that the destination is identical to Quebec, because no assessment would ever conclude that. The conclusion is that the information receives adequate protection in light of those factors, and the reasoning is on the page. You then keep it current, because the vendor changes its subprocessors and its regions without telling you in a way anyone reads.

The practical shortcut for a company with a long vendor list is to tier. Vendors that process identifiable customer data get a full written assessment. Vendors that receive only pseudonymized operational telemetry get a short one. Vendors that never touch personal information get a line in the register saying why they are out of scope. Trying to write the full document for all sixty tools is how this project stalls in month two.

Biometrics, minors, and the edge cases that carry their own rules

If you use facial recognition, voiceprints, or fingerprint authentication, you are in a separate regime layered on top of Law 25. Creating a database of biometric characteristics must be disclosed to the CAI no later than sixty days before it is brought into service, and consent for biometric verification has to be express. Product teams that added face unlock to a mobile app because the platform made it easy are frequently surprised by this. The saving grace is that when the biometric template never leaves the user's device and you never hold it, you are usually not creating the database at all. That distinction is worth confirming in writing with counsel rather than assuming.

Information concerning a minor under fourteen requires consent from the person having parental authority, unless collection is clearly for the minor's benefit. Any company running a consumer product with teenage users should know which side of that line its onboarding sits on. Separately, if you sell to Quebec consumers, the Charter of the French language obligations that arrived with Bill 96 sit alongside your privacy work, because a privacy policy and a consent notice presented to Quebec residents are exactly the kind of public-facing documents expected in French. Running an English-only consent flow while claiming clear and simple language is an awkward argument.

De-identification is not anonymization, and the difference has a regulation

Teams use the two words interchangeably in engineering channels and then write the wrong one into a policy. Under Quebec law, de-identified information no longer allows the person to be directly identified but is still personal information, so the obligations continue. Anonymized information is irreversibly stripped so that identification is no longer reasonably foreseeable, and only then does it fall outside the regime. The anonymization regulation sets a bar: it must be carried out according to generally accepted best practices, using criteria the regulation sets out, under the supervision of a person qualified in the field, and you keep a record of the process including the techniques used and the re-identification risk analysis.

The reason this matters commercially is that anonymization is the standard route to using historical customer data for analytics or model training after the original purpose has expired. If you are relying on that route, the record described above is the thing that makes the claim survive contact with a regulator or an enterprise buyer's diligence team. A pipeline that drops the email column and calls the result anonymous will not.

Where the money actually goes

Buyers ask what a Law 25 program costs and the honest answer is that the price is driven by four things. The number of distinct systems holding personal information, because every one of them needs an inventory entry, a retention rule, and an export path for portability requests. The number of third parties, because each tier-one vendor needs a transfer assessment and a contract review. Whether you have any automated decision-making in the product, because that pulls product engineering into the work rather than just legal. And whether anything in the environment is genuinely undocumented, which is where the schedule slips, since discovery work has no predictable end until it ends.

What is usually cheap is the policy set. What is usually expensive is making portability and deletion real in a system that was built to append and never remove. If your analytics warehouse, your support tool, your email platform, and three backup generations all hold copies of a record, honouring a deletion or export request is an engineering project, not a legal one. Scope that before you promise a thirty-day response time in a public policy, because the access and rectification response window is thirty days and a policy that quietly commits you to the same for everything else is a commitment you have to keep.

When you should not hire anyone for this

Plenty of companies do not need an advisory engagement. If you are a ten-person B2B company with one production database, no consumer users, no automated decisions, and a handful of well-known SaaS vendors, the entire program is a weekend of inventory work, a privacy policy drafted or reviewed by a Quebec-qualified lawyer, a written appointment of the responsible person, an incident register template, and a calendar reminder to review it. Buying a multi-month privacy program for that shape of company is spending money to produce documents nobody will read.

Likewise, if you genuinely hold no personal information about Quebec residents and have no near-term plan to sell there, the correct answer is to write down how you concluded that, put a trigger in place for when it changes, and move on. Compliance work you do not need still consumes the same attention as work you do.

Where outside help earns its keep is narrower. A confidentiality incident in progress, where the notification decision has a five-year paper trail attached to it. An enterprise or public-sector deal where the buyer's privacy schedule is asking for assessments you do not have. An automated decision feature about to ship. Or the case where you are already building toward SOC 2 or ISO 27001 and want the governance, vendor, retention, and incident work counted once instead of built twice, which is the framework alignment our compliance work is organized around. If you would rather keep the register, the vendor list, and the assessment records in one place with dates attached, the free traztech Workspace will hold them, and ongoing operation of the program is what a retainer covers. When you are not sure which of those you need, tell us what triggered the question and we will say plainly if the answer is nothing.

Privacy obligations piling up? Law 25 and PIPEDA readiness, with a named privacy officer where the law asks for one.

Privacy officerOr talk about a retainer

Before you go

Want the rest of this by email?

If this was useful, I send a few short notes on privacy law. Unsubscribe in one click, and replies reach me directly.

From Jacob Masse, principal of traztech. No spam, unsubscribe in one click.

Want a second opinion on where you stand?

We run SOC 2, ISO 27001 and the rest of the compliance stack for startups and SMEs, and the security testing that sits behind it. The first call is free, and we will tell you if you are not ready to start yet.

Book a free call

Track record

Who is actually doing the work

5
Published CVEs, including a CVSS 9.1
76
Controls taken from nothing to a passed SOC 2 Type II
Zero
Exceptions on that Type II report
20+
Penetration testing engagements delivered

Published vulnerability research

Five published CVEs. CVE-2024-45163 (CVSS 9.1) is a flaw in the Mirai botnet itself, which gave defenders a way to shut down attacker infrastructure. CVE-2026-42626 takes HP ENVY 5000 printers offline from any unauthenticated device on the same network.

A SOC 2 Type II built from nothing

At Humera, a venture-backed US security company, Jacob built the compliance programme in-house from nothing: no report, no policies, no documented controls. It ended in a Type II attestation across 76 controls with zero exceptions, on a team of 15.