Privacy Impact Assessments in Canada: Law 25 PIA Guide

Quebec's Law 25 makes Privacy Impact Assessments (PIAs) mandatory for high-risk processing activities, technology implementations, and outsourcing arrangements. With monetary administrative penalties under the Act of up to $10 million or 2% of worldwide turnover (s. 90.12), understanding when and how to conduct PIAs is critical for Quebec businesses.

This comprehensive guide covers everything you need: mandatory PIA triggers, step-by-step assessment process, risk rating frameworks, mitigation strategies, and ready-to-use templates.

---

Understanding PIAs Under Law 25

What Is a Privacy Impact Assessment?

Law 25 Definition (Section 3.3):

"Any person carrying on an enterprise must conduct a privacy impact assessment for 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." (LégisQuébec, P-39.1)

In Plain English: A Privacy Impact Assessment (PIA) - called "Évaluation des facteurs relatifs à la vie privée" (EFVP) or "Analyse d'impact relative à la vie privée" (AIPVP) in French - is a systematic process to identify and minimize privacy risks in new or significantly changed technology, processes, or business activities.

Why PIAs Are Required

Legislative Intent:

• Prevention over cure: Identify privacy risks before they materialize
• Privacy by design: Build privacy into systems from the start
• Accountability: Document privacy considerations and decisions
• Transparency: Demonstrate due diligence to CAI and individuals

Business Benefits:

• Avoid costly retrofitting after launch
• Reduce breach risk
• Build customer trust
• Demonstrate compliance
• Identify data minimization opportunities

Law 25 PIA Requirements vs. PIPEDA

Aspect	PIPEDA	Law 25
PIA Requirement	❌ Not mandatory (best practice)	✅ Mandatory for specified activities
Timing	Any time	⚠️ Before implementation
Documentation	Recommended	📄 Required
Regulatory Review	OPC may request	🔍 CAI may review at any time
Penalties	None specific	💰 No PIA-specific amount; the Act's general AMP maximum is $10M or 2% of worldwide turnover (s. 90.12)

Key Difference: Law 25 makes PIAs legally mandatory, not optional

---

When PIAs Are Mandatory

Law 25 Section 3.3 - Technology Systems

PIAs Required BEFORE:

1. Acquiring an Information System

• Purchasing new software (CRM, HR system, marketing platform)
• Implementing SaaS solutions
• Adopting cloud services
• Procuring databases

Example: Buying Salesforce CRM → PIA required before implementation

2. Developing an Information System

• Building custom software
• Creating databases
• Developing mobile apps
• Building websites that collect personal info

Example: Developing customer portal → PIA required before launch

3. Acquiring or Developing an Electronic Service Delivery System

• Online services
• Mobile apps
• Web portals
• E-commerce platforms
• Customer self-service systems

4. Overhauling Information Systems

• Major system upgrades
• Platform migrations
• System consolidations
• Architecture changes

5. Substantial Modifications (Assess Whether They Amount to an Overhaul)

• Adding new features that collect/process personal info
• Changing data flows
• Implementing new integrations
• Expanding system purposes

Example: Adding AI chatbot to website → PIA required

When PIAs Are NOT Required

Small/Minor Changes:

• Bug fixes
• Performance improvements (no new data processing)
• UI updates (no functional changes)
• Routine maintenance

Non-Personal Information:

• Systems processing only business data
• No personal information involved
• Purely transactional systems (no individual identifiers)

Existing Systems (No Changes):

• System already operational before Law 25
• No modifications planned
• But if modified substantially → PIA required

High-Risk Processing Requiring Enhanced PIAs

Processing that generally warrants a more thorough PIA (s. 3.3 requires the assessment to 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):

Sensitive Data:

• Health information
• Financial data
• Biometric data
• Geolocation tracking
• Children's data
• Genetic information

Large-Scale Processing:

• Large databases of Quebec residents
• Systematic monitoring
• Profiling
• Automated decision-making

New Technologies:

• Artificial Intelligence/Machine Learning
• Facial recognition
• Biometric authentication
• Behavioral analytics
• IoT devices collecting personal data

Vulnerable Populations:

• Children
• Employees
• Patients
• Elderly

---

PIA vs. Transfer Risk Assessment

Distinguishing the Two

Aspect	PIA (Technology)	TRA (Outsourcing)
Legal Basis	Law 25 Section 3.3	Law 25 Section 17
Trigger	New/modified technology system	Outsourcing outside Quebec
Focus	Technology privacy risks	Transfer jurisdiction risks
Key Questions	What data collected? How secured?	Where is data going? What are foreign risks?
Primary Risks	Unauthorized access, breach, misuse	Foreign government access, weaker laws

When You Need Both

Common Scenario:

• Implementing new SaaS CRM (Salesforce)
• Data will be processed in US

Requirements:

1. ✅ PIA: New system being acquired/implemented
2. ✅ TRA: Data being transferred outside Quebec (to US)

Solution:

• Conduct PIA for system implementation
• Conduct TRA for cross-border transfer
• Can combine into single document with both sections
• But address both distinct sets of risks

---

Step-by-Step PIA Process

Phase 1: PIA Initiation (Week 1)

Step 1: Determine PIA Necessity

Questions:

• Does project involve personal information?
• Is it new, reorganized, or substantially modified system?
• When is planned implementation?

Step 2: Establish PIA Team

Required Members:

• Project Lead: Understands technical details
• Privacy Officer: Privacy expertise
• IT Security: Security knowledge
• Legal Counsel: Compliance review
• Business Owner: Business context

Step 3: Define Scope

Document:

• Project name and description
• Business objectives
• Systems involved
• Timeline
• PIA completion deadline

Phase 2: Information Gathering (Weeks 2-3)

Step 4: Describe the Project

Document:

Project Overview:

• What problem does it solve?
• How will it work?
• Who will use it?

Technical Architecture:

• System components
• Infrastructure (cloud, on-premise)
• Third-party services
• Integrations

Personal Information:

• What personal information collected?
• How collected (forms, automated, third-party)?
• From whom (customers, employees, children)?
• Why collected (purposes)?
• How long retained?

Data Flows:

• Where does data come from?
• Where is it stored?
• Who accesses it?
• Where is it transmitted?
• How is it eventually disposed?

Step 5: Identify Legal Basis

For Each Processing Purpose:

• What is the legal basis?
• Consent? Contract? Legal obligation? Legitimate interest?
• Is basis appropriate and sufficient?

Step 6: Data Inventory

Create detailed inventory:

Data Element	Sensitivity	Purpose	Legal Basis	Retention	Source
First Name	Low	Account creation	Contract	7 years	User input
Email	Medium	Communications	Contract	7 years	User input
Credit Card	High	Payment processing	Contract	Not stored	User input
IP Address	Medium	Fraud prevention	Legitimate interest	90 days	System captured

Phase 3: Risk Assessment (Weeks 3-4)

Step 7: Identify Privacy Risks

For Each Data Element/Process, Ask:

Collection Risks:

• Collecting more than necessary?
• Collection method secure?
• Individuals aware of collection?
• Consent obtained where required?

Use Risks:

• Data used beyond stated purposes?
• Access controls adequate?
• Data sharing appropriate?

Disclosure Risks:

• Unauthorized disclosure possible?
• Third parties properly vetted?
• Contracts adequate?

Storage Risks:

• Storage location appropriate?
• Encryption implemented?
• Backup secure?
• Retention period justified?

Disposal Risks:

• Secure deletion process?
• Timely disposal?
• Verification of deletion?

Step 8: Assess Risk Level

Risk Rating Formula:

Risk = Likelihood × Impact

Likelihood Scale:

• 1 - Rare: <5% probability
• 2 - Unlikely: 5-25% probability
• 3 - Possible: 25-50% probability
• 4 - Likely: 50-75% probability
• 5 - Almost Certain: >75% probability

Impact Scale:

• 1 - Negligible: No real harm
• 2 - Minor: Slight inconvenience
• 3 - Moderate: Some harm but manageable
• 4 - Major: Significant harm (financial loss, reputation)
• 5 - Severe: Catastrophic harm (identity theft, safety risk)

Risk Matrix:

Likelihood ↓ × Impact →	1	2	3	4	5
5 Almost Certain	5 Medium	10 High	15 High	20 Critical	25 Critical
4 Likely	4 Low	8 Medium	12 High	16 High	20 Critical
3 Possible	3 Low	6 Medium	9 Medium	12 High	15 High
2 Unlikely	2 Low	4 Low	6 Medium	8 Medium	10 High
1 Rare	1 Low	2 Low	3 Low	4 Low	5 Medium

Risk Levels:

• 1-3: Low (acceptable with documentation)
• 4-8: Medium (mitigation recommended)
• 9-15: High (mitigation required)
• 16-25: Critical (significant mitigation or reconsider project)

Step 9: Identify Existing Safeguards

For Each Risk, Document:

• What controls already exist?
• How effective are they?
• Do they adequately address risk?

Phase 4: Mitigation Planning (Week 4-5)

Step 10: Develop Mitigation Strategies

For Each Medium/High/Critical Risk:

Options:

1. Avoid: Eliminate the risk (don't collect that data)
2. Reduce: Implement additional safeguards
3. Transfer: Insurance, contractual liability shift
4. Accept: Document why risk acceptable

Step 11: Cost-Benefit Analysis

For Significant Mitigations, Document:

• Cost of mitigation
• Benefit (risk reduction)
• Alternatives considered
• Justification for decision

Phase 5: Documentation and Approval (Week 5-6)

Step 12: Complete PIA Report

Required Sections:

1. Executive Summary
2. Project Description
3. Legal Compliance Analysis
4. Risk Assessment
5. Mitigation Plan
6. Residual Risk Acceptance
7. Conclusions and Recommendations
8. Approvals
9. Appendices

Step 13: Obtain Approvals

Required Sign-offs:

• Privacy Officer
• Legal Counsel
• Executive Sponsor
• Project Manager

Phase 6: Implementation and Monitoring (Ongoing)

Step 14: Implement Mitigations

Track Implementation:

• Mitigation task list
• Assigned responsibilities
• Deadlines
• Verification evidence

Hold-Point: Do not launch project until required mitigations complete

Step 15: Post-Implementation Review

Within 3 months of launch:

• Verify mitigations effective
• Check for unforeseen issues
• Update risk assessments
• Document lessons learned

Step 16: Ongoing Monitoring

Establish:

• Regular PIA review schedule (annual minimum)
• Trigger events for PIA updates
• Metrics tracking
• Continuous improvement process

---

Risk Identification Framework

Systematic Risk Identification Checklist

Collection Phase Risks: ☐ Over-collection: Collecting more data than necessary ☐ Unclear purpose: Purpose not specified at collection ☐ No legal basis: Lacking valid legal basis ☐ Inadequate notice: Individuals not informed ☐ No consent: Required consent not obtained ☐ Sensitive data: Collecting sensitive categories unnecessarily ☐ Insecure collection: Transmission not encrypted

Use Phase Risks: ☐ Purpose creep: Using data beyond original purpose ☐ Excessive access: Too many employees have access ☐ No access controls: Anyone can access any data ☐ No logging: Access not monitored ☐ Profiling: Creating profiles without transparency ☐ Automated decisions: Without human review ☐ AI/ML risks: Algorithm bias or unexplainable decisions

Disclosure Phase Risks: ☐ Unnecessary sharing: Sharing with third parties unnecessarily ☐ No due diligence: Third parties not vetted ☐ No contracts: Processing agreements not in place ☐ Cross-border transfers: Transfers to jurisdictions with weaker protection ☐ Government access: Foreign government potential access

Storage Phase Risks: ☐ Insecure storage: No encryption at rest ☐ Cloud risks: Cloud provider security unknown ☐ Geographic location: Data stored in risky jurisdictions ☐ Retention too long: Keeping data longer than necessary ☐ Legacy systems: Old systems with poor security

Disposal Phase Risks: ☐ No disposal process: No secure deletion procedures ☐ Incomplete deletion: Data not fully removed ☐ Backup retention: Data remains in backups indefinitely ☐ Third-party disposal: Vendors don't delete when required

---

Risk Rating Methodology

Detailed Likelihood Assessment

Factors Increasing Likelihood:

Technical Factors:

• Weak security controls (+1 to +3)
• Complex architecture (+1)
• Many integrations (+1)
• Legacy systems (+2)
• Internet-facing (+1)

Organizational Factors:

• Insufficient staff training (+1)
• High staff turnover (+1)
• Poor security culture (+2)

Factors Decreasing Likelihood:

• Strong security controls (-1 to -3)
• Mature security program (-1)
• Regular audits/testing (-1)
• Security certifications (SOC 2, ISO 27001) (-2)
• Strong access controls (-1)
• Encryption everywhere (-1)

Detailed Impact Assessment

Sensitivity Scoring:

Data Type	Base Impact Score
Critical Sensitivity	5
Health records, SIN, Biometric, Genetic, Children's data	5
High Sensitivity	4
Credit card numbers, Precise geolocation, Sexual orientation	4
Medium Sensitivity	3
Full name + address + DOB, Employment records	3
Low Sensitivity	2
Name + email, Business contact info	2
Minimal	1
Email address only, Anonymous usage data	1

Volume Multiplier:

Number of Affected Individuals	Multiplier
<100	1.0x
100-1,000	1.2x
1,000-10,000	1.5x
10,000-100,000	2.0x
>100,000	2.5x

---

Mitigation Strategies

Technical Mitigations

Data Minimization:

• Collect only essential data
• Remove unnecessary fields from forms
• Implement progressive disclosure
• Regular data audits

Encryption:

• TLS 1.3 for data in transit
• AES-256 for data at rest
• End-to-end encryption where possible
• Customer-managed encryption keys (CMEK)

Access Controls:

• Role-based access control (RBAC)
• Principle of least privilege
• Multi-factor authentication (MFA) required
• Regular access reviews (quarterly)
• Automated access provisioning/deprovisioning

Monitoring and Detection:

• Security Information and Event Management (SIEM)
• Intrusion detection/prevention (IDS/IPS)
• Data loss prevention (DLP)
• Real-time alerting

Application Security:

• Secure coding practices
• Input validation
• Regular vulnerability scanning
• Penetration testing (annual minimum)

Organizational Mitigations

Policies and Procedures:

• Comprehensive privacy policy
• Data handling procedures
• Incident response plan
• Vendor management policy
• Data retention schedule

Training and Awareness:

• Annual privacy training (all staff)
• Role-specific training
• Phishing simulation exercises
• Security awareness campaigns

Governance:

• Privacy Officer designation
• Privacy steering committee
• Regular privacy reviews (quarterly)
• Executive reporting

Vendor Management:

• Vendor security questionnaires
• Due diligence before engagement
• Data Processing Agreements (DPAs)
• Regular vendor audits

---

PIA Documentation Requirements

Mandatory PIA Contents

Law 25 doesn't specify exact format, but CAI expects:

1. Project Information

   • Name, description, objectives
   • Timeline and milestones
   • Stakeholders

2. Personal Information Details

   • Types of personal information
   • Data sensitivity assessment
   • Quantity/volume
   • Sources of data
   • Legal basis for processing

3. Data Lifecycle Description

   • Collection methods
   • Use purposes
   • Disclosure/sharing
   • Storage location and duration
   • Disposal methods

4. Technology Architecture

   • System components
   • Infrastructure (cloud/on-premise)
   • Third-party services
   • Security controls

5. Risk Assessment

   • Systematic risk identification
   • Risk rating methodology
   • Risk scores
   • Existing safeguards
   • Residual risks

6. Mitigation Plan

   • Proposed mitigations for each risk
   • Implementation timeline
   • Responsible parties
   • Post-mitigation risk levels

7. Compliance Analysis

   • Law 25 requirements mapping
   • Individual rights considerations
   • Consent requirements

8. Recommendation and Conclusion

   • Proceed/don't proceed/conditional
   • Conditions for proceeding
   • Sign-off requirements
   • Review schedule

---

CAI Review Process

When CAI May Review PIAs

CAI Review:

• CAI may ask for PIA documentation in the course of an investigation, including one arising from a complaint

Potential CAI Actions

Law 25 does not set a PIA-specific penalty amount. The Act's general maximums are:

• Monetary administrative penalties of up to $10,000,000 or 2% of worldwide turnover, whichever is greater, for enterprises (s. 90.12), for the contraventions listed in s. 90.1
• Penal fines of $15,000 up to $25,000,000 or 4% of worldwide turnover, whichever is greater, for enterprises (s. 91), doubled for subsequent offences (s. 92.1)

---

Common PIA Mistakes to Avoid

Top 10 PIA Mistakes

1. Conducting PIA After Implementation ❌ Mistake: Building system, then doing PIA ✅ Correct: PIA before any implementation begins

2. Checkbox Exercise ❌ Mistake: Superficial PIA just to check compliance box ✅ Correct: Genuine risk analysis informing decisions

3. Not Involving Right People ❌ Mistake: IT department alone conducts PIA ✅ Correct: Cross-functional team (privacy, legal, security, business)

4. Underestimating Risks ❌ Mistake: Rating all risks as "low" to justify proceeding ✅ Correct: Honest assessment, even if uncover high risks

5. Vague Mitigations ❌ Mistake: "We will implement appropriate security" ✅ Correct: "We will implement AES-256 encryption at rest, TLS 1.3 in transit, and role-based access control with MFA by March 15"

6. No Follow-Through ❌ Mistake: PIA recommends mitigations, but not implemented ✅ Correct: Track mitigation implementation, verify completion

7. Generic Templates ❌ Mistake: Using generic template without customization ✅ Correct: Tailor assessment to specific project

8. Ignoring Third Parties ❌ Mistake: Focusing only on internal systems, ignoring vendors ✅ Correct: Assess all data flows including third parties

9. No Update Process ❌ Mistake: One-time PIA, never revisited ✅ Correct: Regular reviews, updates when changes occur

10. Poor Documentation ❌ Mistake: PIA not documented or poorly written ✅ Correct: Comprehensive, clear documentation

---

When to Update Your PIA

PIA Update Triggers

Mandatory Updates:

System Changes:

• New features added
• Architecture changes
• New integrations
• Data types added
• Purpose changes
• Third-party changes

Regulatory Changes:

• New laws (amendments to Law 25)
• CAI guidance updates
• Industry standards changes

Risk Environment Changes:

• New threats identified
• Previous breach occurred
• Vulnerability discovered
• Vendor breach

Periodic Review:

• Annual minimum for high-risk systems
• Every 2-3 years for lower-risk systems

---

Automation Tools for PIAs

Manual PIA Challenges

Time-Consuming:

• Comprehensive PIAs take significant effort
• Expert involvement required
• Difficult to maintain consistency

Error-Prone:

• Risk ratings subjective
• Risks may be missed
• Documentation gaps

Automated PIA Solutions

Key Features:

✅ Guided Questionnaire

• Step-by-step wizard
• Contextual help text
• Law 25 requirements mapped

✅ Automated Risk Scoring

• Consistent methodology
• Quantitative risk calculation
• Priority ranking

✅ Integrated Data Inventory

• Pull from data mapping
• Automatic data flow diagrams
• Sensitivity auto-classification

✅ Mitigation Library

• Pre-built mitigation strategies
• Cost estimates
• Implementation guides

✅ Automated Report Generation

• Professional PIA documents
• CAI-compliant format
• Export to PDF/Word
• Version control

---

Frequently Asked Questions

Q: Do I need a PIA for every small change to our website? No. Minor changes like design updates don't require PIAs. But adding new data collection (e.g., new form field) or new functionality (e.g., analytics) triggers PIA requirement.

Q: Can I use a PIA template? Templates can help structure your assessment, but must customize to your specific project. Generic, uncustomized templates won't satisfy Law 25.

Q: Who should conduct the PIA? Privacy Officer leads, but requires cross-functional team: project lead, IT security, legal counsel, business owner. External consultants can help for complex projects.

Q: How long does a PIA take? Varies by complexity. The assessment 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 (s. 3.3), so a simple, low-risk project needs far less effort than a complex, high-risk one.

Q: What if PIA reveals high risks? Options: (1) Implement strong mitigations, (2) Redesign project to reduce risks, (3) Don't proceed with project. Document decision.

Q: Do I need to submit PIA to CAI? Not proactively required, but you should be able to produce it if the CAI requests it during an investigation.

Q: What's the penalty for not conducting a PIA? Law 25 does not set a PIA-specific amount. The Act's general maximums for enterprises are monetary administrative penalties of up to $10 million or 2% of worldwide turnover (s. 90.12) and penal fines of up to $25 million or 4% of worldwide turnover (s. 91).

---

Conclusion

Privacy Impact Assessments are not just a Law 25 checkbox—they're a strategic tool to build privacy into your systems from the start, avoid costly redesigns, and demonstrate accountability to regulators and customers.

Key Takeaways:

• ✅ PIAs mandatory for new/modified systems involving personal information
• ✅ Must be completed BEFORE implementation
• ✅ Systematic risk identification and mitigation required
• ✅ Comprehensive documentation essential
• ✅ Regular updates when changes occur

Start your next project right—with a comprehensive Privacy Impact Assessment.

---

This guide is for informational purposes only and does not constitute legal advice. Consult with a qualified privacy professional for specific compliance questions.