Quebec's Law 25 modernized the province's private-sector privacy rules, and its obligations land directly on the software you build or buy: portals, dashboards, CRMs, and every spreadsheet someone exports from them. This guide translates the main requirements into architecture decisions.
This article is general information, not legal advice. Have counsel review your specific obligations.
What changed, in plain terms
The law phased in over three years. The pieces that matter most for internal software are:
- A person in charge of privacy. By default, the head of the organization, unless they delegate in writing.
- Confidentiality incident handling. Incidents presenting a risk of serious injury must be reported to the Commission d'accès à l'information and to affected people, and every incident goes in a register.
- Privacy governance and transparency. A published privacy policy, clear consent, and defined retention.
- Privacy impact assessments (PIAs). Required for projects to acquire, develop, or overhaul an information system involving personal information.
- Controls on transfers outside Quebec, which require an assessment first.
- Individual rights, including access, rectification, and, since September 2024, portability.
The penalties are significant: administrative monetary penalties of up to $10 million or 2% of worldwide turnover, and penal fines of up to $25 million or 4%, whichever is greater.
Turn the legal text into an architecture checklist
1. Start with a data inventory
You cannot protect what you have not listed. For each system, record what personal information it holds, why, who can see it, where it is hosted, and how long you keep it. This inventory feeds your PIA, your privacy policy, and your incident response.
2. Collect less
The cheapest data to protect is data you never stored. Challenge every field in every form: if no workflow depends on it, remove it. Separate optional fields clearly, and never pre-tick consent boxes.
3. Role-based access control from day one
Law 25 expects access limited to those who need it. Build RBAC into the data model, not into the interface: permissions enforced on the server, per role and per tenant, with the principle of least privilege as the default. Hiding a button is not access control.
4. Privacy by default
Where a product offers privacy settings, the most protective configuration should be the default. For internal tools, that means private-by-default records, no public links unless explicitly created, and short-lived sessions.
5. Immutable audit logging
Record who viewed, changed, exported, or deleted sensitive records, and when. An append-only audit trail makes incident investigation possible and demonstrates accountability. It is also what lets you answer an access request accurately.
6. Retention and deletion as code
"Delete after 24 months" is a policy until a scheduled job enforces it. Implement retention rules as automated jobs, and make deletion cascade to backups on a defined schedule. Prefer anonymization where you need aggregate history.
7. Build the rights workflow before you need it
Access, rectification, deletion, and portability requests have a 30-day response window. Make sure you can export one person's data in a structured, commonly used format, and find every place it lives. If answering a request takes a week of manual searching, the architecture needs work.
8. Be deliberate about hosting
Hosting in a Canadian region such as AWS ca-central-1 (Montreal) simplifies the cross-border question, but it does not remove it: sub-processors, support access, logs, and email providers can all move data elsewhere. List them, and run the required assessment before any transfer outside Quebec.
9. Encrypt, and plan for failure
Enforce TLS in transit and encryption at rest, manage secrets properly, and rehearse your incident response. Know in advance who decides whether an incident presents a risk of serious injury, and where the register lives.
A sensible order of operations
- Appoint and publish the person in charge of privacy.
- Inventory your personal information and systems.
- Run a PIA before the next system build or major change.
- Implement RBAC, audit logging, and retention in the architecture.
- Document the rights workflow and test it with a dry run.
- Review sub-processors and hosting yearly.
Compliance is far cheaper to design in than to retrofit. If you are planning a new internal system, the PIA is the right first deliverable, because it forces the questions that shape the architecture.