Privacy impact assessments: the program a commissioner will actually test

A privacy impact assessment is a document, and a document is easy to produce once. What regulators test is whether the assessment was produced before the collection or the change, whether it covers what the regime prescribes, whether the risks it names were acted on, whether it was updated when the program changed, and whether the office can hand it over with its approvals and history when asked. Those are properties of a program, not of a template, and they are the same in Toronto, Edmonton, Halifax, Ottawa, London and Brussels even though the section numbers are not.

This guide is deliberately jurisdiction-neutral. Where a regime prescribes something specific, it says so and links the regime guide; where regimes only differ in vocabulary, it uses the plainest word. It is general information for privacy practitioners, not legal advice.

01The mandate: know which duty binds you

Start from the statute, not from a template someone inherited. The duty has a trigger, a scope and a recipient, and each varies more than most offices assume. The table gives the regimes this site covers; each links to a guide that quotes the provision.

Two practices make the mandate real. Write the trigger and the prescribed contents into your own procedure in your regime's words, so a program manager can tell whether their project is caught without calling you. And review that procedure against the statute once a year: Ontario's duty arrived in July 2025 and reaches municipalities in 2027, Nova Scotia's arrives in April 2027, the federal directive was replaced in October 2024, and the UK's Act was restructured in 2025. A mandate written in 2023 is already out of date in four of the eight regimes above.

02The inventory: a subject record per program

An assessment describes one program's handling of personal information. If the office has no durable record of which programs exist, what they collect, who owns them, how long they keep it and which vendors touch it, every assessment starts from a blank page and the second one contradicts the first. The GDPR makes this record explicit as the Article 30 record of processing activities; Alberta and British Columbia fold it into the privacy management program the statutes require; Ontario's ten contents include the categories of personal information, the retention period and the safeguards, which are inventory fields under another name.

Build the inventory as the assessment's by-product rather than as a separate project. When the template asks for the categories of personal information, the retention period, the sources and the recipients, those answers should populate the subject record on approval, so the inventory and the assessment cannot drift apart. The register is then the index of what has been assessed, what has not, and what has changed since.

03The screener: document the decision not to assess

Most projects do not need a full assessment, and a program that assesses everything at full depth will stop assessing at all. The answer is a threshold screener: a short set of questions that determines whether personal information is involved, whether the trigger is met, and how much risk the project carries. Under the GDPR the Article 29 Working Party's nine criteria, endorsed by the European Data Protection Board, give the screener its logic (two or more criteria usually means a DPIA); the federal standard and the Alberta and BC templates each carry a preliminary analysis of their own.

The point regulators check is not the screening but its record. A project screened out with no stored determination looks, eighteen months later, like a project nobody assessed. Keep the screener's answers, the determination, who made it and when, as a lightweight compliance record on the same subject, so the decision to not assess is itself evidence.

04The template: cover every content your regime prescribes

Regimes prescribe contents at different levels of detail, but the union is short. A template that carries all of the following satisfies Ontario's ten paragraphs, the GDPR's four elements, the federal standard and the provincial templates, with the regime-specific wording supplied by a pack rather than rewritten by hand:

• The program, its purpose, and the legal authority for collecting, using and disclosing personal information.
• The categories of personal information, the individuals it concerns, and the sources it comes from.
• The information flows: who collects, who uses, who receives, where it is stored, and what leaves the organization or the country.
• Necessity and proportionality: why this information, in this amount, for this purpose, and what less-intrusive option was considered.
• Retention, access controls and safeguards, with the position titles responsible for each.
• The risks to individuals, each with its likelihood and impact, and the measures that address it.
• The approvals: who reviewed, who signed, when, and the date the assessment will be reviewed.

Keep the template versioned. When the regulation changes, as Ontario's did in 2025 and the UK's in 2025, the office needs to know which assessments were completed under which version, and it needs new assessments to start on the current one without anyone editing a shared document.

05Program-area input, on the record

The privacy office rarely knows how a program actually moves data, and the program manager rarely knows what the statute requires. An assessment written by either alone is wrong in a predictable direction. The working pattern is delegation: the coordinator assigns sections (the flows, the retention, the vendor arrangements) to the people who run the program, they answer in the assessment itself rather than in email, and the coordinator reviews and approves each section. The GDPR adds two named participants: the data protection officer, whose advice must be sought under Article 35(2), and the data subjects or their representatives, whose views should be sought where appropriate under Article 35(9).

The record of who answered what matters as much as the answers. When a commissioner asks why an assessment said a system did not disclose to third parties, the office should be able to show which program lead said so and when, not reconstruct it from a mailbox.

06Risks that outlive the document

An assessment that lists risks and mitigations and is then filed has done half the job. The risks belong in a register that persists after approval: each with its likelihood and impact, a determination of the harm to the individuals concerned, the controls that address it, and the commitments the program made, tracked until they are done. Ontario's contents include the risks and the measures to mitigate them; the GDPR's fourth element is the measures envisaged to address the risks; the federal standard and the Alberta template ask for the same in their own structure. None of them is satisfied by a mitigation that was promised in the assessment and never implemented.

A register also gives the office something the individual assessments cannot: exposure across the whole program. Which risks recur, which controls are relied on everywhere, which commitments are overdue. That is what a privacy management program under the BC and Alberta statutes is meant to show, and what an honest readiness score depends on.

07Approval and freeze

An assessment is evidence only from the moment it is approved, and only if what was approved cannot quietly change afterwards. The program therefore needs a review workflow with a named approver (the head or delegate in most Canadian regimes, the controller with the DPO's advice under the GDPR) that moves the assessment into effect, and a freeze: from approval, the document is read-only, and any change goes forward as a new version through re-assessment rather than as an edit. A frozen, versioned assessment is what lets you answer the only question that matters in a complaint: what did you know, and what had you decided, on the day the collection began.

08Re-assessment triggers

Every regime attaches the duty to change as well as to creation: Ontario requires the assessment to be updated before a significant change in the purpose or manner of collection, use or disclosure; Nova Scotia's new Act reaches a substantial change to an activity; Alberta's POPA covers a substantially changed practice, program, project or service; the GDPR requires a review at least when the risk represented by the processing changes. The failure mode is the same everywhere: the program changes, nobody connects the change to the assessment, and the assessment on file describes a program that no longer exists.

The fix is to bind the trigger to the subject record. When a program's recorded purpose, categories, recipients or vendors change, the reassessment date should move forward automatically and appear on someone's list, with the previous version intact for comparison. A calendar reminder set at approval does not survive the person who set it.

09Regulator readiness

Most regimes give the regulator a way in: Ontario's Commissioner can require an institution to provide an assessment; federal institutions provide assessments to the Treasury Board Secretariat and the Privacy Commissioner and publish summaries; Alberta public bodies must submit an assessment to the Commissioner where any of five factors applies (highly sensitive information, a significant share of the population served, data matching, a common or integrated program, or innovative technology); GDPR controllers consult the supervisory authority under Article 36, which has eight weeks to respond and may add six; EU institutions consult the EDPS under Article 40 on the same clocks.

Readiness means producing three things on request without assembling them: a summary in the regulator's expected form, the full assessment with its documents, and the record of approvals and activity. If the summary is a document you write when asked, the request will take weeks; if the assessment generates it, the request takes an afternoon.

10AI and automated decisions

Automated decision-making and AI systems are now assessed under their own instruments beside the PIA: the federal Directive on Automated Decision-Making and its Algorithmic Impact Assessment, Ontario's Enhancing Digital Security and Trust Act, Quebec's disclosure duties, the EU AI Act's fundamental-rights impact assessment, and the UK's algorithmic transparency standard. The regimes differ, but two program properties are common to all of them: a register of the AI systems in use, and an impact assessment that runs on the same engine as the PIA so that the two describe the same system, the same data and the same risks. The algorithmic impact assessments guide covers each regime; the point here is that a PIA program that cannot see the AI systems is already incomplete.

A readiness checklist

• The trigger and the prescribed contents for your regime are written into your procedure and reviewed against the statute each year.
• Every program that handles personal information has a subject record with an owner, categories, retention and vendors, updated by the assessment itself.
• A threshold screener decides the depth of assessment, and its determination is stored for every project, including those screened out.
• The template covers the union of prescribed contents above and is versioned when the regulation changes.
• Program experts answer their own sections in the assessment, and the record shows who answered what.
• Risks live in a register with harm-to-individuals determinations, controls, and commitments tracked to completion.
• A named approver moves the assessment into effect, after which it is frozen and versioned.
• A change to the program's purpose, data or recipients pulls the reassessment date forward automatically.
• The summary, the assessment, its documents and its approval history can be exported on request.
• AI and automated-decision systems are registered and assessed on the same engine as the PIA.

How AccessPoint runs it

AccessPoint's assessment engine is the same in every jurisdiction; the packs supply the regime's template, contents and terminology. The ten properties above map to documented behaviour:

Related reading

Score your own program with the PIA program readiness check, then go to the regime guide that binds you: Ontario, Canada, British Columbia, Alberta, Nova Scotia, the GDPR, the United Kingdom, or the EU institutions. For AI systems, the algorithmic impact assessments guide covers each regime. See how the engine runs on the privacy impact assessments capability page, or book a demo on your own template.

Sources

• Freedom of Information and Protection of Privacy Act, R.S.O. 1990, c. F.31, s. 38(3)–(6) (Ontario e-Laws; accessed September 2026)
• Directive on Privacy Practices, Treasury Board of Canada Secretariat, including Appendix C, Standard on Privacy Impact Assessment (effective October 9, 2024)
• Freedom of Information and Protection of Privacy Act, R.S.B.C. 1996, c. 165, s. 69(5)–(5.4) and s. 36.2 (BC Laws; accessed September 2026)
• Privacy impact assessments under the Protection of Privacy Act, Office of the Information and Privacy Commissioner of Alberta (accessed September 2026)
• Bill 150, Freedom of Information and Protection of Privacy Act, Nova Scotia House of Assembly, third reading, s. 53 (effective April 1, 2027)
• Regulation (EU) 2016/679 (GDPR), Articles 30, 35 and 36 (EUR-Lex)
• Article 29 Working Party, Guidelines on Data Protection Impact Assessment (WP248 rev.01), as endorsed by the European Data Protection Board
• UK GDPR, Article 35 and Data Protection Act 2018, s. 64 (legislation.gov.uk)
• Regulation (EU) 2018/1725, Articles 39 and 40, and the EDPS list of processing operations subject to a DPIA

Last reviewed: September 2026. Regime details are summarized from the linked guides, each of which quotes the provision; rely on the official text and your own counsel. This is general information for privacy practitioners, not legal advice.