Key takeaways
- Law 25 applies to municipalities as public bodies handling personal information — IoT is in scope when sensors can identify people.
- Data minimization is the cheapest control: collect counts and aggregates, not identities, wherever the use case allows.
- Known residency and an audit trail are what auditors and procurement actually ask to see.
- Access control and a tested incident response turn policy into evidence.
- Choose a platform that produces governance artifacts automatically, so compliance is a by-product of operation, not a separate project.
Why Law 25 reaches municipal IoT
Quebec’s Act respecting the protection of personal information in the private sector and its public-sector counterpart — together known as Law 25 — modernized privacy obligations across the province. Municipalities are public bodies that process personal information, so the moment a smart-city sensor can identify or single out a person, that data falls under the regime. A pedestrian counter that stores anonymous totals is low-risk; a licence-plate reader or a camera that captures faces is squarely in scope. The practical question for a municipal team is not whether Law 25 applies, but how to design the deployment so compliance is built in.
The five obligations to design for
1. Data minimization
Collect the least personal data the use case requires. For most municipal sensing — traffic flow, parking occupancy, air quality, waste-bin fill levels — you need counts and states, not identities. Favour LoRaWAN sensors that report aggregates over devices that capture images or plates. When a camera is genuinely needed, process on the edge and transmit only the derived metric. Minimization is the single control that reduces every downstream obligation at once.
2. Known data residency
You must be able to state where personal data is stored and processed, and govern any transfer outside Quebec. A platform with Canadian data residency removes the hardest part of that obligation by default. If a workload must touch a public cloud, the question auditors ask is whether you can name the location and the safeguards — not whether you used a hyperscaler.
3. Access control
Personal data must be accessible only to those who need it, by role, with credentials you can revoke. Role-based access control, per-device identity and least-privilege defaults are the mechanism. A shared admin login is the kind of finding that turns a routine audit into a remediation order.
4. Incident reporting
Law 25 requires notifying the Commission d’accès à l’information and affected individuals of a confidentiality incident presenting a risk of serious injury. You cannot report what you cannot detect, so you need logging, alerting and a rehearsed response runbook before an incident — not improvised during one.
5. Demonstrable governance
Finally, you must be able to show your compliance: who accessed what, when devices were updated, how data flows, and which policies are enforced. An audit trail generated automatically by the platform is worth more than a binder of policies, because it is evidence rather than intention.
Obligation-to-control map
| Law 25 obligation | What it requires | Concrete control |
|---|---|---|
| Data minimization | Collect only necessary personal data | Aggregate-only sensing; edge processing; LoRaWAN counts vs. imagery |
| Known residency | State and govern where data lives | Canadian-resident platform; documented transfer safeguards |
| Access control | Limit access by role, revocably | Role-based access, per-device identity, least privilege |
| Incident reporting | Detect and notify on qualifying incidents | Logging, alerting, rehearsed response runbook |
| Demonstrable governance | Prove compliance on request | Automatic audit trail of access and updates |
Build compliance in, don’t bolt it on
Each obligation is far cheaper to satisfy by design than to retrofit. A deployment that defaults to aggregates, runs on a residency-known platform with role-based access and an audit trail, and has a tested incident runbook will pass an audit because the evidence already exists. The discipline that ties it together is choosing infrastructure that turns these obligations into operational defaults — see our smart-cities IoT hub and smart-cities practice for how this fits a full deployment.
This article is general information, not legal advice; confirm your specific obligations with qualified counsel.
Where Fundamentum fits
The five obligations become operational defaults when the platform is built for them. Fundamentum, our Canadian IoT platform, keeps personal data with Canadian data residency, enforces role-based access policies, and generates an audit trail of every access and update — the exact evidence Law 25 and procurement auditors ask to see. It interfaces with a public cloud only if your architecture requires it. See the platform →
Frequently asked questions
Does Law 25 apply to municipal sensors that don’t collect names?
It applies whenever a sensor can identify or single out a person, even without a name — a licence plate, a face, or a device identifier can be personal information. Sensors that store only anonymous aggregates (a pedestrian count, an occupancy state) are far lower risk. The dividing line is identifiability, not whether a name is stored.
What is the cheapest way to reduce Law 25 risk in an IoT deployment?
Data minimization. Collecting counts and states instead of identities reduces every downstream obligation at once — there is less to secure, less to report on, and less to govern. Favour aggregate-reporting LoRaWAN sensors, and process on the edge when a camera is genuinely required so only the derived metric leaves the device.
Why does data residency matter for a Quebec municipality?
Law 25 requires you to know where personal data is stored and processed and to govern transfers outside Quebec. A platform with Canadian data residency satisfies that by default. If a workload must touch a public cloud, what matters is that you can name the location and the safeguards — which is documentable rather than a barrier.
What does an auditor actually want to see for governance?
Evidence, not intentions: an audit trail showing who accessed what and when, when devices were updated, how data flows, and which access policies are enforced. A platform that generates these artifacts automatically makes a governance review pass because the proof already exists — a binder of policies alone does not.
When must a municipality report an incident under Law 25?
When a confidentiality incident presents a risk of serious injury, the municipality must notify the Commission d’accès à l’information and the affected individuals. Because you cannot report what you cannot detect, logging, alerting and a rehearsed response runbook must be in place before an incident — not assembled during one.
Related reading
Talk to an IoT engineer — free
Book a FREE 30-minute consultation with our team. No slides, no obligation — a working session on your connectivity, platform or compliance questions.
