How to Conduct a Privacy Impact Assessment in Canada

When to conduct a PIA

Conduct a PIA before deploying or significantly changing any system or process that involves personal information. The OPC recommends a PIA in each of these circumstances:

• New technology deployment — a new software platform, CRM, HR system, or data analytics tool
• New vendor onboarding — a service provider that will process personal information on your behalf
• Automated decision-making — any system that makes or assists in making decisions affecting individuals (hiring screening, credit assessment, insurance underwriting)
• AI systems — machine learning, large language models, or predictive analytics applied to personal information about identifiable individuals
• Significant change to existing processing — a material expansion of how existing personal information is collected, used, retained, or shared

Timing matters. A PIA conducted after a system is already live is less effective — findings that would have changed the design cannot easily be acted on. Conduct the PIA before deployment, while there is still time to change course.

---

The six-step PIA process

Step 1 — Define the scope

Document what you are assessing. A clearly defined scope prevents the PIA from expanding beyond what can be practically completed and ensures the findings are specific enough to act on.

Answer these questions:

• What system, process, or vendor relationship is being assessed?
• What is the purpose — what problem is this system solving or what function will it perform?
• What is the planned deployment timeline?
• Who within the organization is proposing this system or change?

Output: A one-paragraph scope statement that identifies the system, its purpose, the organization's role (controller, processor, or both), and the deployment timeline.

---

Step 2 — Map the personal information flows

Identify every type of personal information involved in the system or process being assessed. For each type, document where it comes from, where it goes, and how it is processed.

Personal information inventory — for each type, document:

Item	Questions to answer
What is it	What specific categories of personal information (name, contact info, SIN, health data, financial records, behavioral data)
Whose information	Customers, employees, website visitors, third parties
Where it comes from	Collected directly from individuals, received from another system, purchased from a data broker, generated by the system
Where it is stored	Your servers, a cloud platform, a vendor's system, a third country
Who has access	Which staff roles, which vendors, which third parties
Where it goes after processing	Retained, deleted, shared with another system or party
How long it is kept	Retention period and destruction trigger

Data mapping takes time but is the foundation of the rest of the PIA. If you cannot complete the data map, you do not have enough information to assess risk.

---

Step 3 — Assess legal compliance

For each personal information flow identified in Step 2, assess whether it complies with the applicable privacy law. Work through the PIPEDA principles (or AB/BC PIPA equivalents) for each flow.

Key questions by principle:

Accountability (Principle 1): Is there a designated privacy officer who will be responsible for overseeing this system's privacy compliance?

Identifying purposes (Principle 2): Is the purpose of each collection documented and specific? Would individuals understand why their information is being collected?

Consent (Principle 3): Is consent obtained before collection? Is the consent mechanism adequate for the sensitivity of the information? Is express consent obtained for sensitive categories (health, financial, SINs)?

Limiting collection (Principle 4): Is the organization collecting only what is necessary for the stated purpose? Are any fields collected "just in case" rather than for a specific identified purpose?

Limiting use, disclosure, and retention (Principle 5): Is the information used only for the purpose for which it was collected? Is a retention period defined and applied?

Accuracy (Principle 6): Is there a process to keep the information accurate and to correct errors on request?

Safeguards (Principle 7): Are technical and organizational safeguards appropriate to the sensitivity of the information? Is the vendor's security posture assessed?

Openness (Principle 8): Does the organization's privacy policy accurately describe this processing activity? If not, does the policy need to be updated?

Individual access (Principle 9): Can individuals access and correct their personal information held in this system?

Challenging compliance (Principle 10): If an individual raises a concern about this system, is there a process to investigate and respond?

Output: A compliance assessment table identifying which principles are met, which have gaps, and what remediation is required.

---

Step 4 — Identify and score privacy risks

A privacy risk is a scenario in which something goes wrong with the personal information in this system — it is accessed without authorization, it is used for a purpose beyond what was consented to, it is inaccurate and leads to a wrong decision, or it is shared with a party who should not have it.

For each risk, assess:

• Likelihood: How probable is this scenario, given the system's design, the sensitivity of the data, and the safeguards in place? (Low / Medium / High)
• Impact: If this scenario occurs, how significant is the harm to affected individuals? (Low / Medium / High)
• Risk level: Combine likelihood and impact (a 3x3 matrix produces Low, Medium, or High risk)

Common privacy risks for new systems:

Risk scenario	Typical factors that affect likelihood
Unauthorized access by external attacker	Quality of access controls, encryption, vulnerability management
Unauthorized access by internal user	Role-based access controls, audit logging, employee training
Data shared with an unintended third party	Vendor vetting, DPA terms, API configuration
Data retained beyond its permitted period	Existence of a retention schedule and automated enforcement
Inaccurate data used to make a decision about an individual	Data quality controls, correction process
Individuals not informed of how data is used	Privacy policy accuracy, consent mechanism adequacy
Vendor located in a foreign jurisdiction accesses data	Data residency, contractual protections, CLOUD Act risk

Output: A risk register listing each identified risk, its likelihood, impact, and risk level.

---

Step 5 — Plan mitigations

For each Medium or High risk identified in Step 4, document a mitigation: a specific action that reduces the likelihood or impact of the risk to an acceptable level.

Mitigation format for each risk:

Risk	Current state	Proposed mitigation	Risk level after mitigation	Owner	Deadline
Unauthorized external access	No MFA on admin account	Enable MFA on all admin accounts before go-live	Low	IT	[date]
Excessive data collection	Form collects date of birth for all users	Remove date of birth field unless required for the stated purpose	Low	Product	[date]
No retention enforcement	Records accumulate indefinitely	Configure auto-deletion at [X] months; add to retention schedule	Medium	IT	[date]

A mitigation that reduces a High risk to Low or Medium is a design change — it changes how the system works before it goes live. A mitigation that reduces a risk that is already Low is a safeguard — it confirms an existing control.

Not every risk requires a mitigation that eliminates it entirely. Some residual risk is acceptable if it is documented and understood. The PIA records what risks remain and why they are acceptable.

Output: A mitigation plan with named owners and deadlines for each action.

---

Step 6 — Document, approve, and review

Document the PIA. Compile the outputs of Steps 1–5 into a PIA record:

• Scope statement
• Data flow inventory
• Compliance assessment
• Risk register
• Mitigation plan
• Residual risk summary

Approve the PIA. The privacy officer reviews and approves the PIA before the system is deployed. For high-risk deployments, involve legal counsel in the review. The approval is a documented decision that the identified risks are acceptable and that the mitigations will be implemented.

Set a review date. A PIA is not a one-time document. Set a date to review the PIA — typically one year after deployment, or sooner if the system changes materially. Add the review date to the PIA document header.

Retain the PIA. The PIA is a compliance record. Retain it for as long as the system is operational, plus the applicable limitation period. If the OPC investigates a complaint about the system, the PIA demonstrates you assessed the privacy risks before deployment.

---

The AI module — additional steps for automated decision-making

If the system being assessed uses machine learning, predictive analytics, a large language model, or any form of automated decision-making applied to personal information about identifiable individuals, the PIA requires an additional module addressing AI-specific risks.

Trigger questions — apply the AI module if any of these are true:

• The system generates outputs (scores, classifications, recommendations, decisions) that affect individuals
• The system is trained on personal information about identifiable individuals
• The system was built or is operated by a third-party AI vendor that processes personal information on your behalf

Additional AI module questions:

Input data: What personal information is used as input to the AI system? Is the training dataset or inference dataset documented? Does the organization know what personal information the AI vendor used to build the model?

Output and decision logic: What outputs does the system produce? Are those outputs used to make or assist in making decisions that affect individuals? Can the decision-making logic be explained to an affected individual in plain language?

Consent and transparency: Have individuals been meaningfully informed that their personal information is processed by an AI system? Is this disclosed in the privacy policy? If the system makes decisions about individuals, are those individuals told that an AI was involved?

Discriminatory risk: Does the training data reflect historical patterns that could produce discriminatory outputs for individuals based on race, gender, age, disability, or other protected characteristics? Has the organization assessed this risk?

Human oversight: Is there a human review process for high-stakes AI-generated decisions? Can an individual request human review of a decision made or supported by the AI?

Vendor accountability: If an AI vendor processes personal information on your behalf, is there a Data Processing Agreement in place? Does the DPA address what the vendor can use your data for — specifically, whether the vendor can use your data to train or improve their model?

Output: An AI module assessment appended to the main PIA, addressing each question above with a finding and any required mitigation.

---

PIA document structure — quick reference

A complete PIA document contains:

1. Cover page — system name, assessment date, privacy officer name, approval date, next review date
2. Scope — what is being assessed and why
3. Data flow inventory — personal information types, sources, destinations, retention
4. Compliance assessment — PIPEDA principles 1–10 (or AB/BC PIPA equivalents) with finding and gap notes
5. Risk register — identified risks with likelihood, impact, and risk level
6. Mitigation plan — action for each Medium/High risk, owner, deadline
7. Residual risk summary — risks that remain after mitigation and the rationale for accepting them
8. AI module (if applicable) — input data, output logic, consent, discriminatory risk, human oversight, vendor accountability
9. Approval signature — privacy officer, date
10. Review log — dates and findings of subsequent reviews

---

Common mistakes

Conducting the PIA after the system is already deployed. A PIA completed after go-live cannot change the design. It can only document what exists and identify what needs to be retrofitted — which is harder, more expensive, and a weaker compliance position than assessing before deployment.

Treating the PIA as a checkbox exercise. A PIA completed by answering every question "yes" without substantive review is not a compliance document — it is a false record that may be worse than having no PIA at all if the answers are inaccurate.

Not assigning owners to mitigations. A mitigation without a named owner and a deadline is an intention, not a plan. If the PIA identifies that MFA must be enabled before go-live, someone specific must be responsible for enabling it by a specific date.

Omitting the vendor. If the system is operated by a third-party vendor that processes personal information, the PIA must assess the vendor's data practices — what the vendor does with your data, what security they apply, and what rights you have under the contract to audit or require changes. Assessing only the data flows within your own systems misses the largest source of risk in most cloud deployments.

Never reviewing the PIA again. Systems change. A PIA completed at deployment is accurate at that point in time. If the system's data flows, retention practices, or vendor relationships change materially, the PIA must be updated. A stale PIA is not a reliable compliance record.

---

Related guides

• Do You Need a Privacy Impact Assessment? — when a PIA is required vs. recommended
• PIPEDA Compliance Requirements for Canadian Organizations
• Alberta PIPA Compliance Requirements
• Personal Information Retention and Destruction Under Canadian Privacy Law
• Vendor or Third-Party Breach: What Canadian Organizations Must Do — what happens when a vendor you assessed in a PIA is subsequently breached

---

This guide covers the PIA process under PIPEDA, Alberta PIPA, and BC PIPA for private-sector organizations. Government institutions subject to the Privacy Act or the Access to Information Act operate under a different PIA framework (Treasury Board policy) not covered here. Quebec's Law 25 mandates PIAs for technological projects under a specific process overseen by the Commission d'accès à l'information — not covered here.