Privacy Impact Assessment in Québec: Adding the Security Lens

A Laval food distributor is replacing its old payroll software, running on a server in a basement closet, with a cloud platform hosted in the United States. The vendor is reputable, the demo was slick, the contract is ready to sign. Nobody has mentioned a privacy impact assessment.

Yet this project likely triggers two. First under section 3.3 of the Act, as amended by Law 25: it is the acquisition of an information system involving personal information. Then under section 17, because payroll data will be hosted outside Québec.

Many SMBs treat the privacy impact assessment (PIA, or EFVP in French) as a legal exercise. In reality, its most important part, the risk analysis, is a security exercise. Here is how to run one without it taking all winter.

When is a PIA mandatory?

The Act sets three triggers. The most common one for SMBs is section 3.3: any project to acquire, develop or overhaul an information system or electronic service delivery system involving the collection, use, communication, keeping or destruction of personal information.

The CAI’s examples are broad: videoconferencing software, payroll systems, artificial intelligence, video surveillance, a members’ area on a website, a mobile app, a self-service kiosk.

Note that “outside Québec” includes the rest of Canada. A Toronto-hosted SaaS tool counts just as much as one hosted in Virginia.

AI tools raise particular issues; our article on generative AI and data leaks covers them.

Good news for smaller businesses: the assessment must be proportionate to the sensitivity of the information, the purposes of its use, its quantity, its distribution and its medium (s. 3.3). A small, low-sensitivity project deserves a short PIA.

The six steps suggested by the CAI

The Act does not say how to conduct a PIA. The CAI publishes a guide (version 3.1, April 2024, in French; BLG has published an unofficial English translation) and a report template. Neither is mandatory, but both are useful. The steps:

1. Determine whether an assessment is required.
2. Define the project and the scope of the assessment.
3. Prepare the assessment: inventory the information, map how it flows, list your obligations.
4. Assess the privacy factors and adopt mitigation strategies.
5. Write a report.
6. Keep the assessment up to date.

Security comes in mostly at steps 3 and 4. That is where most homegrown PIAs stay vague.

Security questions to put to the vendor

For the Laval payroll project, these are the questions to build into any PIA for a cloud system:

• Where will the data be hosted and backed up (country, cloud region)?
• Who will have access, on your side and the vendor’s? Is access named and logged?
• Is multi-factor authentication available, and can you enforce it for everyone?
• Is data encrypted in transit and at rest? Who manages the keys?
• Does the vendor have a recent SOC 2 report or ISO 27001 certification that covers the service you are buying?
• Does the contract require it to notify your privacy officer without delay of any confidentiality breach (s. 18.3)?
• How will data be destroyed when the contract ends?
• Can you export data in a structured, commonly used technological format, as section 3.3 requires?
• What happens to the data on the old system?

Ask these questions before you sign, not after. When data leaves Québec, section 17 requires the communication to be covered by a written agreement that takes into account the results of the assessment and, where applicable, the terms agreed to mitigate the risks it identified. Once the contract is signed, your leverage over security clauses, incident notice and data destruction drops sharply. With a large U.S. vendor, the standard terms may not budge at all, which is itself a finding worth recording in the PIA.

Scoring risks: the severity × likelihood grid

The CAI guide suggests a simple method: rate severity from 1 (very low) to 4 (very high), likelihood from 1 to 4, then multiply. Result: very low (1–2), moderate (3–4), high (6–8), very high (9–12), unacceptable (16). A risk whose severity is unacceptable, for instance because it means breaking the law, must be eliminated before the project can proceed.

Applied to the payroll project (180 employees):

Then re-score each risk after mitigation. That residual risk is what leadership is accepting, and the report should show that decision.

Attach technical evidence to the report

The CAI guide suggests annexing, where relevant, a list of your policies, a summary of security advice produced with vendors or partners (it specifically mentions penetration tests), the communication agreement and any certifications obtained. It also recommends that the report record its approval by senior management.

If your project includes custom development, such as a customer portal or a mobile app, a web application penetration test before go-live is the most convincing evidence you can attach. Reminder: a penetration test requires written authorization from the system owner (Criminal Code, s. 342.1), and often from the hosting provider too.

Keep the PIA alive

The CAI guide is clear: a PIA evolves and must be revisited throughout the project. In practice, update it when:

• you add a module that processes new types of information;
• the vendor changes subcontractors or hosting region;
• an incident reveals a risk you had not considered.

This article explains Law 25 obligations in plain terms and is not legal advice: validate the scope of your PIAs with your legal counsel. For the security side (vendor questions, risk scoring, technical evidence), our Law 25 compliance service can work alongside your privacy officer.