Ontario's mandatory privacy impact assessments: what FIPPA section 38 requires, and what changes for municipalities in 2027
The ten things the written assessment must contain, the two duties that outlast it, the January 1, 2027 extension to MFIPPA, and where each element lives in AccessPoint — for privacy officers, FOI coordinators, and the program managers who now need a PIA before they can collect a name.
Since July 1, 2025, the head of every institution under Ontario's Freedom of Information and Protection of Privacy Act must ensure a written privacy impact assessment exists before personal information is collected, keep it updated before any significant change of purpose, and hand it to the Information and Privacy Commissioner on request. On January 1, 2027, the identical duty arrives for municipalities and local boards under MFIPPA, alongside mandatory breach reporting and Commissioner review of information practices.
Ontario had a privacy impact assessment methodology long before it had a mandate: the IPC's Planning for Success guide has shaped provincial PIAs since 2015, and the Ontario Public Service ran PIAs as policy. What Bill 194 did was move the assessment from good practice into the statute, give it a prescribed table of contents, and attach it to the one event every program shares — the moment personal information is first collected. This guide sets out exactly what the Act now says, what it implies for programs that already exist, what municipalities inherit in 2027, and how each requirement maps to a working assessment in AccessPoint.
Who, when, and what triggers it
Bill 194, the Strengthening Cyber Security and Building Trust in the Public Sector Act, 2024, received Royal Assent in November 2024. Its second schedule amended FIPPA in stages: whistleblower protections came into force on January 29, 2025, and the privacy impact assessment and breach-reporting provisions on July 1, 2025. The assessment duty sits in section 38, the collection section, and it reads in full:
"Unless the regulations provide otherwise, before collecting personal information, the head of an institution shall ensure that a written assessment is prepared that contains the following information respecting any personal information that the institution intends to collect."
Three features of that sentence decide how a program should read it. The duty belongs to the head, which in practice means the delegated privacy function must be able to prove the assessment existed and was approved. The trigger is collecting personal information, not launching a project: a new form, a new integration that pulls information from another institution, or a new use of a vendor platform each counts if it collects. And the escape hatch is a regulation: the general regulation under FIPPA, Regulation 460, contains no PIA provisions as consolidated, so as of this writing there is no exemption to rely on and no prescribed additional content beyond the statutory list.
The ten things the assessment must contain
Section 38(3) lists the contents. The table gives each paragraph in plain terms, with the question a reviewer will ask about it and the place it lives in an AccessPoint assessment.
| s. 38(3) | What the assessment must state | Where it lives in AccessPoint |
|---|---|---|
| 1 | The purpose of the collection, use and disclosure, and why the personal information is necessary to achieve it | The subject's processing purpose on its record of processing, and the template's purpose and necessity questions |
| 2 | The legal authority for the intended collection, use and disclosure | The template's governing legal authority (read-only on every assessment) plus the authority question; the Ontario pack carries FIPPA's own section references |
| 3 | Each type of personal information to be collected, and how each type will be used or disclosed | The personal-information inventory, captured as a typed table question whose rows populate the subject's categories of personal data |
| 4 | The sources of the personal information | The data-source inventory on the subject and the template's source questions |
| 5 | The position titles of the officers, employees, consultants or agents who will have access | A template question answered by the program area, delegated to it as a section assignment so the people who know answer it |
| 6 | Any limitations or restrictions on collection, use or disclosure | The template's limits questions and the commitments register, where a restriction becomes a tracked undertaking |
| 7 | The retention period, consistent with subsection 40(1) | The retention period on the subject's record of processing, bound from the answer so the register and the assessment cannot disagree |
| 8 | The administrative, technical and physical safeguards, and a summary of the risks to individuals if the information is stolen, lost or misused | Controls linked from the controls library with their designation, and the risk register scored on likelihood and impact with the harm-to-individuals lens |
| 9 | The steps to prevent or reduce the likelihood of theft, loss or unauthorized use or disclosure, and to mitigate harm if it occurs | Mitigation tasks on each risk and the commitments card, each with an owner and a completion date |
| 10 | Anything else a regulation prescribes | Template sections are pack-maintained; a prescribed addition ships as a template version, not a rebuild |
Two paragraphs catch institutions out. Paragraph 5 asks for position titles, not a statement that "authorized staff" will have access; the program area has to name the roles, which is why the question is best delegated to it rather than answered by the privacy office. Paragraph 8 asks for two things in one breath: the safeguards, and a summary of the risks to individuals if those safeguards fail. An assessment that lists controls without saying what happens to people when the controls fail does not meet the paragraph.
Two duties that outlast the document
Implementation. Subsection 38(4) requires the head to ensure the paragraph 9 steps are actually implemented before collection begins or, where that is not possible, within a reasonable time after. An assessment whose mitigations are still "planned" a year after go-live is evidence against the institution, not for it.
Update before a change of purpose. Subsection 38(5) requires the assessment to be updated before any significant change to the purpose for which the assessed information is used or disclosed, with any additional steps implemented. This is the provision that turns a document into a program: someone has to notice that a purpose is changing, and the assessment has to be reopened before the change, not after the complaint.
Copy to the Commissioner. Subsection 38(6) requires the head to provide the Commissioner, on request, with access to or a copy of any assessment prepared or updated under the section. The Commissioner does not need a complaint to ask. Institutions should assume the request will come without warning and that the assessment will be read by someone who knows what section 38(3) says.
Municipalities and local boards: January 1, 2027
MFIPPA did not change in July 2025. It changes on January 1, 2027, when Schedule 11 of the Plan to Protect Ontario Act (Budget Measures), 2026 (S.O. 2026, c. 2) adds subsections 28(3) to (6) to the municipal Act. The wording is the same as FIPPA's, paragraph for paragraph, including the update duty and the copy-to-Commissioner duty. Three companion provisions arrive on the same day: a new section 30.1 requiring the head to report thefts, losses and unauthorized uses or disclosures of personal information to the Commissioner, a new section 38.1 giving the Commissioner power to review an institution's information practices, and a new section 45.1 protecting whistleblowers. The access-side changes in the same schedule, including the move to business days, took effect earlier, on July 1, 2026, and are covered in the Ontario FOI in transition guide.
For a municipality, the practical meaning is that any program that will collect personal information after January 1, 2027 needs its assessment finished, approved and implemented before that date if collection starts then, and any program already collecting needs a schedule for assessment before its purpose next changes. Eighteen months looked like a long runway in the spring of 2026. It is not, for a clerk's office that also runs the access program.
The methodology has not changed. The stakes have.
Nothing in section 38 replaces the IPC's Planning for Success: Privacy Impact Assessment Guide; it is still the province's methodology and the Commissioner's reference point for what a complete assessment looks like. What the statute adds is a minimum table of contents and a legal consequence for not having one. In January 2026 the IPC and the Ontario Human Rights Commission published joint principles for the responsible use of artificial intelligence by public-sector institutions — valid and reliable, safe, privacy protective, human rights affirming, transparent, accountable — and stated that the principles will ground their assessment of institutions' AI adoption. An AI system that processes personal information is a collection like any other, and its assessment should say so in section 38(3) terms.
The AI provisions of the Enhancing Digital Security and Trust Act, 2024 (Schedule 1 of the same Bill 194) apply to prescribed public sector entities in prescribed circumstances and still await their regulations; the regulations that took effect on July 1, 2026 cover cyber security for hospitals, colleges and universities (O. Reg. 51/26) and school boards' handling of children's information (O. Reg. 52/26). Ministries and provincial agencies are separately bound by the Responsible Use of AI Directive. None of that displaces the PIA: for any AI system that touches personal information, the assessment under section 38 is the instrument that already exists.
Building the program, not the document
- Inventory the collections. The trigger is collection, so the starting point is a list of every program, system and form that collects personal information, with its owner. Rank by sensitivity and volume; that is your assessment schedule for existing programs.
- Put a threshold screener in front of the intake. Most changes do not need a full assessment. A short screener that asks whether personal information is collected, whether the purpose is new, and whether a vendor or another institution is involved sends the right cases to a full assessment and records the reasoning for the rest.
- Delegate the parts only the program knows. Position titles with access, sources, retention practice and the real safeguards come from the program area. Send those sections to the people who run the program and keep the privacy analysis with the office.
- Score the risks and register the commitments. Paragraphs 8 and 9 are a risk register in disguise: each risk to individuals, its likelihood and impact, the safeguards that address it, and the steps still owed. Give every step an owner and a date, because subsection 38(4) will ask whether it was done.
- Approve, freeze, and re-assess. An approved assessment should not be editable; changes go forward through a new version on the same subject. Watch the purpose: when it changes, subsection 38(5) requires the update before the change, and the office needs a trigger it does not have to remember.
- Be ready for the Commissioner. Keep the approved assessment, its risk register, its evidence and its approval trail exportable as one package. The request under subsection 38(6) will not come with a lead time.
How AccessPoint runs it
AccessPoint's assessment engine was built for this shape of obligation, and its Ontario jurisdiction packs carry the province's templates. The provincial FIPPA and municipal MFIPPA packs each ship a PIA template built on the IPC's methodology, with the governing legal authority attached, so a new assessment starts from Ontario's questions rather than a blank form; the PHIPA pack carries its own health-sector template. Every template is versioned and pack-maintained, which is how a prescribed addition under paragraph 10 arrives without anyone rebuilding a questionnaire.
Threshold screener
A template can carry a preliminary screener; a "screened out" result produces a lightweight compliance record, and everything else instantiates the full section set.
Typed questions that populate the register
The personal-information inventory is a table question; retention, categories of personal data and the transfer flag are bound to the subject's record of processing on approval, so the assessment and the register cannot drift apart. Templates with a flow narrative carry an information-flow diagram question.
Section delegation
Any section can be assigned to a program expert who sees only that section, answers with autosave, logs hours and submits; the coordinator approves or requests changes.
Risks, controls and commitments
The risk register scores likelihood and impact with a harm-to-individuals determination, links controls from the controls library with a designation of mandatory, recommended, implemented or not applicable, and tracks every undertaking on the commitments card.
AI drafting, human decisions
With AI Assist deployed, unanswered questions can be drafted from the assessment's own documents and the organization profile, accepted or dismissed one by one, with a consistency check across the set. Nothing is recorded without a person's decision.
Review, freeze, re-assess
A configurable review moves the assessment to In Effect; from then it is read-only, and change goes forward through Re-assess on the same subject. When a subject's recorded purpose changes, the platform pulls the reassessment date forward and surfaces it on My Day — subsection 38(5) with a trigger attached.
Compliance profile
Each subject shows the requirements its jurisdiction pack evaluates: a required assessment reads as met exactly while one is In Effect, a mandatory control while it is linked as implemented, and before-production items stay visible until the system is deployed.
The Commissioner's copy
The closure tab generates the regulator summary as a document, in English or French, alongside the executive and publication summaries; the assessment's documents, activity trail and approvals export as one package.
Reporting
Assessment throughput, outstanding commitments and the new PIA findings report answer the questions a deputy or a council asks, and Report Studio answers the ones specific to your program.
All of it runs inside your own Microsoft 365 and Azure tenant, beside the FIPPA or MFIPPA access requests, breach incidents and complaints the same office handles.
A readiness checklist
- Confirm which Act binds you: FIPPA now, MFIPPA from January 1, 2027, PHIPA for health information custodians.
- Inventory every collection of personal information and its owner; rank by sensitivity.
- Adopt a template that covers all ten paragraphs of section 38(3), with position titles and the risk summary called out explicitly.
- Stand up a screener so routine changes are recorded without a full assessment.
- Delegate program-area sections to the program area; keep the privacy analysis with the office.
- Track every paragraph 9 step to completion with an owner and a date.
- Freeze approved assessments and define the purpose-change trigger that reopens them.
- Rehearse a Commissioner request: can you produce the assessment, its approvals and its evidence in a day?
- Municipalities: schedule the existing-program assessments to finish before January 1, 2027, and align the breach-reporting procedure to new section 30.1 on the same date.
Sources
- Freedom of Information and Protection of Privacy Act, R.S.O. 1990, c. F.31, s. 38(3)–(6) (as amended by 2024, c. 24, Sched. 2, s. 4, in force July 1, 2025) — Ontario e-Laws (accessed September 4, 2026).
- Municipal Freedom of Information and Protection of Privacy Act, R.S.O. 1990, c. M.56, ss. 28(3)–(6), 30.1, 38.1, 45.1 (as amended by 2026, c. 2, Sched. 11, in force January 1, 2027) — Ontario e-Laws (accessed September 4, 2026).
- Bill 97, Plan to Protect Ontario Act (Budget Measures), 2026 — Legislative Assembly of Ontario (Royal Assent received; S.O. 2026, c. 2).
- R.R.O. 1990, Reg. 460 (General) under FIPPA — Ontario e-Laws (no privacy impact assessment provisions as consolidated, September 2026).
- Enhancing Digital Security and Trust Act, 2024, S.O. 2024, c. 24, Sched. 1, ss. 5–8 — Ontario e-Laws; Enhancing Digital Security and Trust Act (O. Reg. 51/26 and O. Reg. 52/26, effective July 1, 2026) — Government of Ontario (accessed September 4, 2026).
- Planning for Success: Privacy Impact Assessment Guide — Information and Privacy Commissioner of Ontario.
- AI Governance Reimagined: Ontario's New Joint Principles for the Responsible Use of Artificial Intelligence — Lerners LLP, on the IPC and OHRC joint principles of January 2026.
- Ontario's new public sector cybersecurity and AI law now in force — Dentons, January 31, 2025 (Bill 194 in-force dates).
Related reading on this site: AccessPoint for Ontario FIPPA institutions, AccessPoint for Ontario municipalities, privacy impact assessment software, the Ontario FOI in transition guide, the companion guide on Nova Scotia's privacy assessments, or book a demo to see an Ontario PIA run end to end.
Ontario PIA Questions
Are privacy impact assessments mandatory in Ontario?
Yes, for provincial institutions since July 1, 2025. Section 38(3) of the Freedom of Information and Protection of Privacy Act, added by Bill 194, requires the head of an institution to ensure a written assessment is prepared before personal information is collected, unless a regulation provides otherwise. Municipalities and local boards follow on January 1, 2027, when the same text is added to section 28 of the Municipal Freedom of Information and Protection of Privacy Act.
What must an Ontario PIA contain?
Ten things, listed in FIPPA section 38(3): the purpose and why the information is necessary; the legal authority for collection, use and disclosure; the types of personal information and how each will be used or disclosed; the sources; the position titles of everyone who will have access; any limits on collection, use or disclosure; the retention period; the safeguards and a summary of the risks to individuals if the information is lost, stolen or misused; the steps to prevent that and to mitigate harm if it happens; and anything a regulation prescribes.
Do municipalities need PIAs under MFIPPA?
From January 1, 2027. The Plan to Protect Ontario Act (Budget Measures), 2026 adds subsections 28(3) to (6) to MFIPPA with wording identical to FIPPA's, and on the same date adds mandatory breach reporting to the Commissioner, Commissioner review of information practices, and whistleblower protection.
Does an existing program need a PIA?
The statutory trigger is a collection, not a project: the assessment must exist before personal information is collected, and must be updated before any significant change to the purpose for which information already assessed is used or disclosed. Collections that began before July 1, 2025 are not expressly grandfathered in the text, so most institutions are assessing existing high-risk programs on a risk-ranked schedule rather than waiting for a purpose change to force the question.
Can the Information and Privacy Commissioner ask to see a PIA?
Yes. Section 38(6) requires the head to provide the Commissioner, on request, with access to or a copy of any assessment prepared or updated under the section. A PIA that cannot be produced on request is a compliance finding waiting to happen.