What Law 25 means for Québec startups — a practical walkthrough

If you're building a company that touches personal data in Québec — and almost every health-tech company does — Law 25 is not an afterthought. It is an architectural constraint. The sooner you treat it as one, the less rework you will eventually have to do.

This is the plain-language version of what I wish someone had handed me a year ago. It is practical, not comprehensive. For authoritative guidance, consult the Commission d'accès à l'information and qualified privacy counsel. This is not legal advice.

The short version

Canada has a federal private-sector privacy law — PIPEDA. Québec has its own, modernized in 2021 as Law 25 (the Act to modernize legislative provisions as regards the protection of personal information, originally Bill 64). The modernization moved Québec's framework closer to the GDPR, added meaningful obligations, and introduced real penalties.

Three things to know up front. If you operate in Québec, Law 25 applies regardless of where your servers, team, or customers are. The rules are not a subset of PIPEDA — in several places they are stricter. And the full statute has been in force since September 2024, including the data portability right. There is no grace period left to lean on.

The five operational surfaces

Across the statute, five surfaces show up in almost every product conversation.

1. Consent that is specific, informed, and granular

Under Law 25, consent is not a single switch. If you collect personal information for multiple purposes, you need specific consent for each purpose, and you cannot bundle them. "By using this service, you agree to all of the following" is not a Law 25 consent pattern.

In a health-tech product, this means multiple consent screens, not one. Clinical use is one thing. Research or AI training use is separate. Communications preferences are a third. Each must be explicitly opted into, clearly explained, and independently withdrawable without affecting the others.

This is not cosmetic. Your data model, from day one, has to track consent at the purpose level with full history — every grant, modification, and withdrawal logged with a tamper-evident timestamp. Retrofitting this later is expensive. Designing for it at the schema level on day one is almost free.

2. Data residency and cross-border transfers

Law 25 imposes real obligations around sending personal information outside Québec: you must conduct a privacy impact assessment, evaluate the adequacy of protection in the destination, and be prepared to demonstrate that the transfer is compliant.

For most health-tech startups, the cleanest answer is to avoid the question: keep personal information in Québec by default. A Canadian cloud region, production workloads in Québec where possible, and deliberate choices about any third-party processors that touch the data.

At CuraDia, we treat hosting and third-party processor decisions as privacy-review items, not commodity infrastructure choices. The point is to know what information leaves Québec, why it leaves, who can access it, and what contractual and technical safeguards apply before a procurement team asks.

3. Breach notification

If a confidentiality incident occurs and presents a risk of serious injury, Law 25 requires that you notify both the Commission d'accès à l'information and the affected individuals, promptly. You must also keep a register of all incidents — including the ones that did not meet the notification threshold.

Operationally: write your incident response plan before you need it. Name your escalation contacts and decision thresholds. Keep an actual register, with timestamps and severity assessments — not a folder of emails.

For a pre-pilot company, "incident" can feel abstract. It isn't. A lost laptop, a misaddressed email containing PHI, a contractor with overly permissive access — each is a potential confidentiality incident. The register is not theatre. It is the evidence that your organization took the obligation seriously.

4. Privacy by default

Privacy by default is a design obligation. Where your product offers privacy settings, the most protective setting must be the default. Users opt into less protective configurations, not out of them.

This shapes real product decisions. Communications preferences default to the minimum necessary. Research participation is opt-in, never opt-out. Any data sharing — including analytics and marketing — requires affirmative, specific consent.

Founders used to growth-hacking defaults sometimes struggle here. Law 25 moves the default in the user's favour, and the product follows. In health tech, this is the right default regardless of jurisdiction. Québec makes it a legal obligation rather than a philosophical preference.

5. Rights and responses

Individuals have specific rights: to know what you hold about them, to correct it, to have it deleted, and to have it transferred in a portable format to another provider. Each triggers an obligation to respond within a reasonable timeframe — in practice, weeks, not months.

Meeting these rights means your systems need a concept of all data for one individual that is actually queryable. If you cannot, on demand, assemble a complete export of what you hold on a single user, you cannot meet the portability requirement. If you cannot delete that user's data from every system within your SLA — including backups, audit logs, and any derived datasets — you cannot meet the deletion requirement.

The cheapest time to solve this is at the schema and pipeline level, on day one.

What it costs, honestly

For a pre-revenue startup, Law 25 costs founder time, infrastructure choices, and deferred features. Roughly:

A couple of founder-weeks to read the statute, map obligations to the product, and produce the internal documentation (DPO role, incident response plan, privacy policy, consent copy). A non-trivial chunk of engineering time for hosting choices, audit logging, and schema-level consent tracking. A legal review from Québec counsel on consent language and privacy policy — not optional if you handle health data. And product decisions: features you would otherwise ship, now deferred, redesigned, or gated behind additional consent. That last one is the cost founders most often underestimate.

Penalties for non-compliance are genuinely significant — modelled on the GDPR, with the most serious cases attracting amounts measured as a percentage of worldwide turnover or in the tens of millions of dollars. But the penalty is rarely the thing that kills a deal. The thing that kills the deal is a hospital procurement team, or an enterprise client's security review, finding that your privacy posture does not survive basic questioning.

Where founders underestimate it

Three patterns, from conversations with other founders:

Consent is a data model, not a checkbox. Build with a boolean accepted_tos field and nothing else, and you will rebuild within a year.

The DPO role is real even if fractional. A named person, a published email, a response SLA, a documented process. Not a law firm you put on retainer — a role inside your company.

Research use of data is the landmine. If you ever want to use your production data — even de-identified — to train models, the time to get the consent architecture right is before the data is collected. Retroactive research consent is a painful path.

A closing thought

Law 25 is often framed as a burden on startups. On bad days I've said similar things. But the honest version, for health-tech in particular, is that the law is pushing in the direction we should have been building anyway. Granular consent, transfer assessments, privacy by default, clean deletion — these are the things patients already expect us to be doing, and the things procurement teams will already be asking about.

The law turns those expectations into obligations. For a company whose product depends on trust, that turns out to be a feature, not a bug.

---

Dr. Christian Diab is the Medical Director and co-founder of CuraDia Santé Inc., a Québec medtech company building Uro-OS — the clinical operating system for urology and pelvic medicine. This article is a founder's perspective, not legal advice.