When Does an Organization Need a Privacy Impact Assessment (PIA)?

A Privacy Impact Assessment should not begin when a system is ready to launch.

At that point, the most important decisions may already have been made: the vendor has been selected, the contract signed, the data fields configured and the business process designed.

A well-run Privacy Impact Assessment, or PIA, is different. It is a structured process for identifying how an initiative will affect personal information, assessing the risks to individuals, testing whether the proposed processing is necessary and proportionate, and determining what needs to change before the initiative proceeds.

Depending on the jurisdiction, that assessment may be called a Privacy Impact Assessment (PIA), Data Protection Impact Assessment (DPIA), or privacy risk assessment. The terminology — and the legal trigger — varies.

That distinction is increasingly important. Cisco's 2026 Data and Privacy Benchmark Study, based on more than 5,200 privacy-responsible technology and security professionals across 12 markets, found that 90% of organizations said their privacy programs had expanded because of AI, while 93% expected to allocate more resources to privacy and data governance over the following two years.¹

Privacy teams are already feeling that pressure. The IAPP's 2024 Privacy Governance Report found that 99% of respondents reported challenges delivering privacy compliance, and 55% reported five or more challenges. The report specifically identifies support for privacy impact assessments as one source of privacy-function workload.²

So when does an organization actually need a PIA?

The answer depends on three things: what is changing, what information is involved, and which laws apply.

Start with the change, not the document

A useful PIA trigger is not simply “we are collecting a new type of personal information.”

Organizations should screen an initiative whenever it materially changes what personal information is processed, why it is processed, how it is used, who can access it, where it goes, how long it is retained, or what technology does with it.

Consider an organization introducing an AI recruiting platform.

It may already collect résumés and candidate information. But the processing can change substantially if a third-party AI provider now receives that information, generates candidate scores or inferences, retains prompts, processes information outside Canada, or influences employment decisions.

The dataset may look familiar.

The privacy risk is not.

The same problem arises when an organization moves an existing database to a new cloud provider, introduces employee-monitoring software, connects previously separate datasets, deploys facial recognition, changes how customer information is shared, or begins using existing data for a new purpose.

Under PIPEDA, private-sector organizations do not face a universal statutory requirement to complete a PIA for every new project. But the Office of the Privacy Commissioner of Canada expressly recommends conducting privacy impact assessments and threat analyses of personal-information practices, including ongoing activities, new initiatives and new technologies, as part of organizational accountability.³

For some organizations and jurisdictions, however, the obligation goes considerably further.

The legal trigger changes by jurisdiction

A global organization should not rely on a single rule such as “do a PIA whenever sensitive information is involved.”

In several jurisdictions, the activity itself can trigger the assessment.

The differences matter.

A cloud migration that is a recommended PIA candidate under one regime can be an express statutory trigger under another.

Québec: a technology project can trigger the PIA

Québec provides one of the clearest examples in the Canadian private sector.

Section 3.3 of Québec's Act respecting the protection of personal information in the private sector requires an enterprise to conduct a privacy impact assessment for a project to acquire, develop or overhaul an information system or electronic service-delivery system where that system involves the collection, use, communication, keeping or destruction of personal information.⁵

The privacy officer must be consulted from the outset.

The assessment must also be proportionate to factors such as the sensitivity of the information, the purposes for which it will be used, the quantity and distribution of the information and the medium on which it is stored.⁵

That means the PIA question can arise during relatively ordinary technology decisions:

a new CRM, an HR platform, a customer portal, an applicant-tracking system, an AI application, a new SaaS provider or a material redesign of an existing information system.

Québec creates another significant trigger under section 17.

Before an enterprise communicates personal information outside Québec, it must conduct a PIA considering factors including sensitivity, purpose, safeguards and the legal framework applicable in the destination jurisdiction. The requirement also applies where a person or organization outside Québec is entrusted with collecting, using, communicating or keeping personal information on the enterprise's behalf.⁶

For organizations relying on global cloud infrastructure, that can make vendor architecture and data location part of the PIA decision before procurement is finalized.

Ontario: PIAs are now expressly mandatory under FIPPA

Ontario's public-sector framework changed materially in 2025.

Section 38(3) of the Freedom of Information and Protection of Privacy Act now generally requires the head of a provincial institution to ensure that a written privacy impact assessment is prepared before the institution collects personal information.⁷

The required assessment goes beyond simply identifying the data.

It addresses the purposes and legal authority for the processing, the types and sources of personal information, who will have access, retention, safeguards, risks to individuals and the measures proposed to reduce those risks.⁷

The Ontario Information and Privacy Commissioner confirms that the PIA requirement has applied to institutions governed by FIPPA since July 1, 2025. Equivalent requirements for municipal institutions governed by MFIPPA take effect January 1, 2027.⁸

That distinction is important for organizations contracting with provincial institutions, hospitals, universities, agencies, municipalities, school boards and other public-sector bodies.

A PIA may not simply be internal privacy documentation. It can become part of procurement, implementation and project-governance readiness.

Health information should trigger early scrutiny

The legal rules differ by province, but personal health information should almost always result in an early PIA screening decision.

Health information can reveal diagnoses, treatments, medications, disabilities, genetic characteristics, mental-health information and other deeply consequential facts about an individual.

Alberta demonstrates how seriously some sectoral regimes treat that risk.

Section 64 of Alberta's Health Information Act requires custodians to prepare a privacy impact assessment describing how proposed administrative practices and information systems relating to individually identifying health information may affect privacy. The PIA must be submitted to the Office of the Information and Privacy Commissioner for review and comment before implementation.¹⁰

This can apply not only to entirely new systems, but also to changes to existing practices or information systems involving identifying health information.¹⁰

The broader governance principle extends beyond healthcare:

the greater the potential consequence to the individual, the earlier privacy review should begin.

Under the GDPR, “high risk” is the threshold

The GDPR uses a risk-based trigger rather than requiring a DPIA for every processing operation.

Article 35 requires a controller to conduct a DPIA before processing where the nature, scope, context and purposes of the proposed processing — particularly where new technologies are used — are likely to result in a high risk to the rights and freedoms of individuals.¹¹

The GDPR specifically identifies three important examples: systematic and extensive automated evaluation that produces legal or similarly significant effects; large-scale processing of special-category or criminal-offence data; and large-scale systematic monitoring of publicly accessible areas.¹¹

European guidance makes the screening exercise more practical.

The Article 29 Working Party's DPIA guidance, endorsed by the European Data Protection Board, identifies indicators including evaluation or scoring, consequential automated decision-making, systematic monitoring, sensitive or highly personal data, large-scale processing, combining datasets, vulnerable individuals, innovative technology and processing that prevents individuals from exercising rights or accessing services.¹⁴

As a rule of thumb, processing meeting two of these criteria is generally more likely to require a DPIA, although a single criterion can sometimes be sufficient depending on the risk.¹⁴

That makes context important.

Employee activity data, for example, might appear routine when used for basic systems administration. The same information becomes materially different when it is used for continuous employee monitoring, behavioural profiling and automated performance scoring.

California: the processing activity can trigger the assessment

California's CCPA risk-assessment regime became effective January 1, 2026.¹²

Under section 7150 of the California regulations, a covered business must conduct a risk assessment before initiating processing that presents a significant risk to consumers' privacy.

Specified triggers include activities such as selling or sharing personal information and processing sensitive personal information, subject to particular regulatory exceptions. The regulations also address higher-risk automated decision-making and other specified processing activities.¹²

This is not called a PIA under California law, but operationally the lesson is similar:

before engaging in higher-risk processing, the organization should be able to demonstrate that it has identified the benefits, risks and controls before the processing begins.

For multinational privacy programs, that is why one global assessment methodology can be useful — but one global trigger rule is rarely enough.

Which personal-information categories should raise the flag?

Not every jurisdiction defines “sensitive” information in the same way, and sensitivity is often contextual.

But certain categories and uses should routinely lead to PIA screening.

Health, genetic and biometric information merit heightened scrutiny because misuse may result in discrimination, identity harms, physical consequences or loss of confidentiality.

Financial information, account credentials and government identifiers can create significant fraud and identity-theft consequences.

Children's information deserves particular attention because children may have reduced ability to understand or challenge processing and are expressly recognized as vulnerable data subjects in European DPIA analysis.¹⁴

Precise geolocation, surveillance and behavioural data can reveal movements, routines, relationships, sensitive locations and activities that may not be apparent from individual data points.

Employee information warrants stronger review where it is used for surveillance, productivity monitoring, behavioural analysis, disciplinary decisions or automated employment decisions.

Biometric identifiers require particular attention where facial recognition, fingerprints, voiceprints or other characteristics are used to uniquely identify or authenticate individuals.

Profiles and inferred information should not be considered low risk merely because the organization created the inference rather than collected it directly. A prediction about health, financial vulnerability, employability, reliability or behaviour may be more consequential than the source data from which it was derived.

And combined datasets can create risk that does not exist in either dataset individually. Linking purchase history, location, browsing behaviour and demographic information may reveal characteristics that an individual never expressly provided.

The right screening question is therefore not just:

“Is this sensitive data?”

It is also:

“What can this processing reveal or enable?”

AI can change the privacy risk without changing the original dataset

AI makes this distinction particularly important.

Organizations sometimes conduct an AI governance assessment while assuming the existing privacy review remains valid because the underlying data has not changed.

But AI can change the purpose, inference capability, recipients, decision-making role and consequences of processing.

An AI initiative involving personal information should therefore examine questions such as whether prompts or training inputs contain personal information, what the provider retains, whether information is used to improve external models, what new inferences are generated, where processing occurs, who has access to outputs, how long data is retained and whether the system influences consequential decisions about individuals.

AI governance and privacy assessments can be integrated.

They should not be treated as interchangeable.

The scale of this challenge is already visible. Cisco's 2026 findings that 90% of surveyed organizations expanded their privacy programs because of AI suggest that organizations themselves increasingly recognize that AI governance changes the scope of privacy work.¹

A practical screening rule: has the data story changed?

Organizations do not need a lengthy PIA every time a minor configuration changes.

They do need a reliable way of deciding when an assessment is necessary.

“Has this initiative materially changed what personal information we process, why we process it, who receives or accesses it, where it is processed, how long we retain it, or what decisions or inferences can be made from it?”

If the answer is yes, the initiative should at least undergo PIA screening.

The organization can then determine whether applicable law makes a full assessment mandatory or whether the scale, sensitivity, technology, affected individuals and potential consequences make an assessment appropriate even when it is not legally compulsory.

That distinction is particularly important under accountability-based regimes.

PIPEDA requires organizations to remain accountable for personal information under their control, including information transferred to third parties for processing, and requires safeguards appropriate to the sensitivity of the information.³

A defensible privacy program therefore needs more than completed PIA documents.

It needs a process that reliably identifies when the privacy function should become involved.

Do the assessment while the organization can still change the answer

The most useful outcome from a PIA is not always a statement that a project can proceed.

It might be a finding that the organization does not need to collect a particular field.

That a vendor should not retain prompts.

That employee access is too broad.

That a five-year retention period cannot be justified.

That the privacy notice does not explain the proposed use.

That a cross-border arrangement requires additional safeguards.

That an automated recommendation should not become a decision without meaningful human review.

Or that de-identified information would achieve the same business objective with less privacy risk.

Those conclusions are commercially useful before systems have been purchased, configured and deployed.

They become considerably more expensive after implementation.

That is why the better question is not simply:

“Are we legally required to complete a PIA?”

It is:

“Is there a privacy decision we should make before this project goes any further?”

When the answer is yes, the assessment should already be underway.

Need to determine whether an initiative requires a PIA?

Closson Advisory supports organizations with PIA screening, assessment, remediation and privacy-by-design review across technology implementations, vendor engagements, new data uses and privacy programs.

Start a conversation

This article is provided for general informational purposes and does not constitute legal advice. Requirements depend on the applicable jurisdiction, sector, facts and processing activities.

Footnotes & Sources

1. Cisco, 2026 Data and Privacy Benchmark Study. Cisco reports that the study surveyed more than 5,200 IT, technology and security professionals with privacy responsibilities across 12 markets; 90% reported their privacy programs had expanded because of AI and 93% planned to allocate more resources to privacy and data governance over the following two years. Cisco — Data and Privacy Benchmark Study ↩ Return to text
2. International Association of Privacy Professionals, Privacy Governance Report 2024. The IAPP reports that 99% of respondents experienced challenges delivering privacy compliance and 55% experienced five or more; PIA support is identified among privacy-function workload demands. IAPP — Privacy Governance Report ↩ Return to text
3. Personal Information Protection and Electronic Documents Act, S.C. 2000, c. 5, Sch. 1, Principle 4.1 (Accountability); Office of the Privacy Commissioner of Canada, PIPEDA Fair Information Principle 1 — Accountability. The OPC recommends privacy impact assessments and threat analysis covering personal-information practices, including ongoing activities, new initiatives and new technologies. Office of the Privacy Commissioner of Canada — Accountability ↩ Return to text
4. Treasury Board of Canada Secretariat, Directive on Privacy Practices, Appendix C: Standard on Privacy Impact Assessment, ss. C.2.2.6–C.2.2.10. The federal standard establishes PIA requirements for specified new programs or activities and substantial modifications involving personal information. Treasury Board of Canada Secretariat — Directive on Privacy Practices ↩ Return to text
5. Act respecting the protection of personal information in the private sector, CQLR c. P-39.1, s. 3.3. Légis Québec — P-39.1, s. 3.3 ↩ Return to text
6. Act respecting the protection of personal information in the private sector, CQLR c. P-39.1, s. 17. Légis Québec — P-39.1, s. 17 ↩ Return to text
7. Freedom of Information and Protection of Privacy Act, R.S.O. 1990, c. F.31, s. 38(3)–(5). Government of Ontario — FIPPA ↩ Return to text
8. Municipal Freedom of Information and Protection of Privacy Act, R.S.O. 1990, c. M.56, as amended; Information and Privacy Commissioner of Ontario guidance regarding FIPPA/MFIPPA amendments. Government of Ontario — MFIPPA ↩ Return to text
9. Freedom of Information and Protection of Privacy Act, R.S.B.C. 1996, c. 165, s. 69(5)–(5.4). BC Laws — FOIPPA ↩ Return to text
10. Health Information Act, R.S.A. 2000, c. H-5, s. 64; Office of the Information and Privacy Commissioner of Alberta, Privacy Impact Assessment guidance. OIPC Alberta — Privacy Impact Assessment process ↩ Return to text
11. Regulation (EU) 2016/679, General Data Protection Regulation, Article 35. EUR-Lex — Regulation (EU) 2016/679 ↩ Return to text
12. California Code of Regulations, title 11, § 7150; California Privacy Protection Agency risk-assessment regulations. California Privacy Protection Agency — Regulations ↩ Return to text
13. Digital Personal Data Protection Rules, 2025 (India), Rules 1(4) and 13. Rule 13 provides for periodic DPIAs by Significant Data Fiduciaries but is not yet operative as of September 2026. Ministry of Electronics and Information Technology (India) ↩ Return to text
14. Article 29 Working Party, Guidelines on Data Protection Impact Assessment (DPIA), WP248 rev.01, endorsed by the European Data Protection Board. European Data Protection Board — Endorsed WP29 guidelines ↩ Return to text

Related services

• Privacy Program Builder
• Closson Privacy Office
• AI Governance