Privacy impact assessments
A privacy impact assessment looks at a new system or project before it goes live and asks what could go wrong with the personal information it handles. Quebec and Ontario's public sector now require them in defined situations. Most PIAs are weak on the technical side; that is the part we strengthen.
Reviewed by the ITRS security team · Last updated
This page is general information, not legal advice. For advice on your obligations, speak with your lawyer.
When a PIA is required in Ontario and Quebec
In Quebec, section 3.3 of the private-sector privacy act, as amended by Law 25, requires a business to conduct a privacy impact assessment for any project to acquire, develop or overhaul an information system or electronic service delivery system that involves personal information. The business must consult its person in charge of the protection of personal information while doing it.
Several Canadian rules now make PIAs mandatory in specific situations:
Outside those rules, a PIA is still good practice whenever you introduce a system that handles sensitive information at scale: a new practice management or EMR platform, a CRM migration, a customer portal, an AI tool, employee monitoring, or moving data to a new cloud provider. PIPEDA does not mandate PIAs for private organizations, but its accountability and safeguards principles are much easier to demonstrate with one on file. Quebec's law also says a PIA must be proportionate to the sensitivity of the information, the purposes, the quantity and distribution of the information and the medium on which it is stored. That proportionality principle is a good guide everywhere.
| Rule | When a PIA is required |
|---|---|
Quebec private-sector Act, s.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 |
Quebec private-sector Act, s.17 | Before communicating personal information outside Quebec, including entrusting it to a service provider outside the province |
Ontario FIPPA (provincial institutions) | Before collecting personal information, in force July 1, 2025, according to the IPC |
Ontario MFIPPA (municipal institutions) | Same requirement, in force January 1, 2027, according to the IPC |
Scoping the project and data
A useful PIA starts with an accurate description. We work with the project owner to document what the system does, which personal information it collects and from whom, the purpose for each data element, who can access it, which vendors are involved, where data is stored, how long it is kept and how it is destroyed. We draw a data-flow diagram that follows information from collection through use, sharing, storage and deletion. In Quebec, the person in charge of the protection of personal information must be consulted from the outset of the project; we build that into the plan.
Technical risk analysis
This is where most PIAs fall short: they ask whether the vendor is 'secure' and accept a yes. We look at the actual configuration and evidence:
- Authentication: single sign-on, MFA and how administrator access works.
- Authorization: roles and permissions, and whether staff will see more than they need.
- Encryption in transit and at rest, and who controls the keys.
- Logging: whether access to personal information is recorded and retained long enough to investigate.
- Integrations and APIs: what other systems can pull data out.
- Data location, subprocessors and support access from outside Canada.
- Backups, recovery and how deletion actually works, including in backups.
- Vendor security assurance: independent audit reports, penetration testing and breach history.
- For Quebec projects: whether the system can export a person's computerized information in a structured, commonly used technological format, as section 3.3 requires.
Mitigations and residual risk
Each risk is rated on likelihood and impact, then paired with a mitigation: a configuration change, a contract clause, a process step, a training item, or a decision to collect less. We distinguish mitigations that are already in place from those that are planned, and name an owner and a date for each planned item. What remains after mitigation is residual risk, which leadership must consciously accept, reduce further, or decide is too high to proceed.
The PIA report
You receive a report that can stand up to review by a client, auditor or regulator, structured as follows:
Ontario institutions can also refer to the IPC's guide for public institutions, Planning for success: Privacy impact assessment guide; we follow its structure for public-sector clients.
Project summary
What the system does and why.
Data inventory and flow diagram
What personal information is involved, where it goes and who touches it.
Legal and policy context
The privacy laws and contract terms that apply, as confirmed by your counsel.
Risk analysis
Each risk, its rating and the evidence behind it.
Mitigation plan
Actions, owners and dates.
Residual risk and sign-off
What leadership is accepting, and who approved it.
Keeping it current
A PIA describes a system at a point in time. Revisit it when the system changes materially: new data types, new integrations, a new vendor or hosting location, AI features switched on, or a security incident. We recommend a light annual check for high-risk systems. If you have a managed IT agreement with us, we can flag changes that should trigger a PIA update as part of normal change management.
Frequently asked questions
The business owner of the project, with the privacy officer approving it. We do the analysis and drafting, but the organization has to own the decisions about risk, and in Quebec the person in charge of the protection of personal information must be consulted from the start.
It helps, but it describes the vendor's product in general, not your configuration, your data and your users. We use vendor material as evidence inside your assessment rather than as a substitute for it.
Before the contract is signed and before data is migrated. Many of the best mitigations, such as collecting less, choosing a hosting region or negotiating a breach-notice clause, are only cheap at the start.
Related work.
- Case studyFrom Breach Forensics to a Company-Wide Identity PlanFrom reconstructing a 2018 mailbox compromise minute by minute to scoping centralized Entra ID and Intune management for a 40 to 50 person pharma firm.
- Case studyEmail Authentication for a Vaughan Smart-Home IntegratorHow IT Rapid Support audited a Vaughan smart-home integrator's email authentication and implemented DKIM and DMARC to shut down domain spoofing.
Related.
- PracticePrivacy, Data Governance & AIPIPEDA and Quebec Law 25 readiness, data mapping, breach notification and AI governance.
- ArticleQuebec Law 25: confidentiality incidents and the incident registerQuebec's private-sector privacy law has its own incident regime: its own definition, its own 'risk of serious injury' test, specific notice contents for the Commission…
- ArticleFIPPA and MFIPPA: what vendors to Ontario public bodies need to knowIf you host, process or support systems for an Ontario ministry, municipality, police board or other public institution, their privacy law becomes your contract.
- ServiceAI tool risk assessmentsBefore a new AI tool touches client, patient or employee data, someone should check where that data goes, whether it trains the vendor's models, how long it is kept and…
Not sure what your obligations require of your systems?
Speak with our privacy practice. We are staffed 24/7. Active incident? Call (289) 582-9930, 24/7.