IM-008 — Privacy Impact Assessment Procedures

Working Instruction

Functional Area: Information Management · IM-008

Document Owner: Director of Technology

Effective: May 31, 2026 Last Reviewed: —

Quick reference

What this guide covers

This guide applies to all Division information systems that collect, use, disclose, or store personal information, including data derived from personal information such as analytics, risk scores, or behavioural profiles. That includes systems classified as Core, Common, or Innovative under A.P. 312, electronic surveillance systems under A.P. 505, and vendor-managed systems assessed under A.P. 322.

When you need a PIA

A.P. 323 §9 defines when a PIA is required and when it must be submitted to the Office of the Information and Privacy Commissioner (OIPC). The short version: most Division PIAs need to be submitted, because virtually all Division systems handle personal information about minors, which M-Reg 143/2025 (Protection of Privacy (Ministerial) Regulation, Alta Reg 143/2025) deems high-sensitivity by default.

The PIA program also operates alongside acquisition-stage triggers in A.P. 312: Core Systems require PIAs, the Director of Technology may require PIAs for Common Systems, biometric and emotional AI systems require PIAs regardless of classification, and adaptive learning systems require PIAs prior to deployment. Either a statutory trigger or an acquisition trigger is sufficient to require a PIA.

If you’re not sure whether a PIA is needed, check with the Access and Privacy Coordinator. Default to "yes" when handling personal information about students. The high-sensitivity threshold under M-Reg 143/2025 s. 1 means most student-facing systems require both a PIA and submission to the OIPC.

Working through a PIA

A PIA moves through five phases. They’re sequential but not rigid; Phases 2 and 3 often blur together, and Phases 4 and 5 happen in close succession.

Phase 1: Triage and scoping

The Director of Technology and the Access and Privacy Coordinator confirm a PIA is required, identify the system being assessed, name the System Owner, and decide which appendices of the OIPC template apply. Most PIAs need only the main sections (A through H). Three appendices are conditional:

• Appendix A (Data Matching): applies when the project links personal information between two or more public bodies’ databases. Uncommon at Grasslands but possible (e.g., shared analytics with Alberta Education).

• Appendix B (Common or Integrated Program or Service): applies when the project is a CIPS as defined in POPA s. 1(d). Uncommon but plausible for shared services with other divisions.

• Appendix C (Use of Automated Systems or Other Forms of Innovative Technology): applies whenever AI or innovative technology generates content, decisions, or recommendations. Increasingly common; triggers an Algorithm Impact Assessment.

Phase 1 produces a short scoping memo: project name, project number (assigned from the Grasslands project register under A.P. 312), System Owner, applicable appendices, and a rough effort estimate. The scoping memo is what the Director of Technology takes into Phase 2 with the System Owner.

Phase 2: Joint intake

The Director of Technology and the System Owner (joined by the Access and Privacy Coordinator for legal authority and consent questions) work through every section of the OIPC template. The conversation typically covers project basics, personal information inventory, information flow, legal authority, access and correction, retention, safeguards, service providers, and risk inputs. Plan for around 80 minutes of structured conversation, plus follow-up where the System Owner needs to research vendor-specific details.

This phase produces a PIA Working Document: a markdown file in the relevant project folder, named PIA_WORKING_<project_number>_<short_name>.md. The Working Document holds the substance of every answer in Grasslands format before it’s projected into the OIPC template. It’s the single source of truth for the PIA throughout preparation.

If the System Owner can’t answer something on the spot (vendor configuration, sub-processor lists, retention specifics) that’s fine. The Working Document tracks open items so they can be picked up in Phase 3.

Phase 3: Gap-fill

The System Owner closes out the open items from Phase 2: gathering vendor contracts, confirming retention configurations, requesting clarification from sub-processors, pulling internal evidence (training records, access tables, audit log samples). The Director of Technology and Access and Privacy Coordinator stay engaged for evidence the System Owner can’t source alone.

This phase also assembles the supporting artifacts the PIA will need:

Phase 4: Production and review

The Director of Technology populates the OIPC template (the actual Word document, whose structure must not be modified) using the substance from the Working Document. The Access and Privacy Coordinator reviews privacy compliance and legislative accuracy. The Director of Technology reviews technical and security sections.

For PIAs that include an Appendix C (automated systems / AIA), the Access and Privacy Coordinator is required to sign off on the AIA before the PIA proceeds to submission.

Phase 5: Cover letter and submission

The Access and Privacy Coordinator prepares the OIPC cover letter on Division letterhead and obtains the signature. Under the standing delegation in CG-003, the Access and Privacy Coordinator typically signs as delegate of the head of the public body. The PIA package (populated OIPC template plus all attachments plus signed cover letter) is submitted to the OIPC at the email address published on the OIPC website.

After submission, the PIA file number assigned by the OIPC (when it arrives) is added to the PIA inventory record alongside the Grasslands project number.

The Working Document

The Working Document is the central artifact during preparation. It lives in the project folder for the duration of the PIA (alongside other project artifacts) and stays there until the PIA is submitted. After submission, the Working Document moves to the privacy archive location maintained by the Access and Privacy Coordinator.

The Working Document follows a fixed structure: one section per OIPC template section (A through H plus appendices), plus metadata at the top (project number, System Owner, scoping decisions, current status). Every PIA uses the same structure, which makes it easy to scan, easy to resume after a break, and easy to amend later if the system changes.

When a PIA is amended (see “Amendments” below), the original Working Document gets loaded back up, the deltas get worked through, and a new amendment package gets produced. The Working Document carries the system’s privacy story across its full lifecycle.

Verifying the template version

The OIPC publishes updates to the POPA PIA Template from time to time. Before opening a new PIA, the Access and Privacy Coordinator verifies that the most current version of the template is in use. This is also done when starting an amendment, since the template in force when the original PIA was submitted may no longer be current.

The current template is published on the OIPC website. Navigate from the OIPC home page (oipc.ab.ca) to the POPA section, then to the Privacy Impact Assessment page, where the template is available for download. The template document itself shows a release date in its footer and on the OIPC publication page.

If the OIPC has published a newer version than the one currently in the Division’s reference library, the new version is downloaded and used for all PIAs going forward. The Access and Privacy Coordinator maintains a verified internal copy as a backup in case the OIPC site is temporarily unavailable when a PIA needs to start.

Supporting artifacts

Each PIA produces or attaches a set of supporting artifacts beyond the OIPC template body itself.

Information Flow Diagram (Attachment 4): hard requirement

Every PIA must include an Information Flow Diagram. The OIPC will not review a PIA submitted without one. The diagram traces flows of specific personal information elements between entities with directional arrows; it is not a network diagram or business process diagram.

The Division uses Gane-Sarson notation for IFDs: external entities (rectangles), processes (rounded rectangles), data stores (open-ended rectangles), and labelled data flows (arrows with the specific PI elements named on each arrow). The diagram is generated as an SVG and rendered to PDF for submission.

IM-012A risk register and OIPC H1 projection

The internal risk assessment runs through IM-012A using the Division’s standard risk methodology. When the PIA Starter Set is loaded, IM-012A populates the OIPC’s 17 standard privacy risks (H1), the 11 cloud computing risks (H2), and the 13 automated systems risks (Appendix C, if applicable).

For each OIPC risk, the IM-012A output supplies the mitigation measures and policy reference that get written into the OIPC template’s H1, H2, and Appendix C tables. The full IM-012A register attaches to the submission as supporting evidence and is referenced from the H1 table where useful for context.

Cover letter (Appendix D)

The cover letter is the only Division-branded document inside the OIPC submission package. It uses Division letterhead, follows the form requirements in the OIPC template, and is signed by the head of the public body or delegate. Under CG-003, the Access and Privacy Coordinator typically signs as delegate.

Internal Decision Record (internal only)

The Internal Decision Record is a companion document that does not go to the OIPC. It captures the Division’s internal decisions about the system: Student Safety considerations, Recommendations on conditions of approval or restrictions on use, parent notification language, staff training requirements. It travels with the PIA package internally and supports Senior Administration approval where required.

Vendor contract (Attachment 10)

When a service provider is involved, the current signed contract attaches to the submission. The contract must demonstrate that POPA-required clauses are in place, including the Division’s retention of control over personal information. AP-322 and IM-007 frame what the contract needs to contain. Phase 3 includes a contract review against this requirement.

Submitting to the OIPC

Once the PIA is reviewed internally and the cover letter is signed, the package is submitted to the OIPC at the submission address published on the OIPC website. The submission includes the populated OIPC template, the cover letter, and all attachments. The OIPC will issue a file number on receipt; that file number gets recorded in the PIA inventory.

For PIAs that don’t require submission (those triggered solely by the “significant harm” criterion), the package is filed internally by the Access and Privacy Coordinator. The OIPC may still request these PIAs under POPA s. 27(1)(j), so they’re held in submission-ready condition.

OIPC requests under POPA s. 27(1)(j)

The OIPC may request a copy of any Division PIA at any time. The Division must respond within 30 business days. The Access and Privacy Coordinator coordinates the response. The PIA inventory and the Working Document archive together make this straightforward; every PIA is held in submission-ready condition regardless of whether it was originally submitted.

Amendments

A PIA is amended when the underlying system, practice, program, or service undergoes a substantial change affecting the collection, use, or disclosure of personal information: new data types, a new vendor or sub-processor, a new storage jurisdiction, a new automated decision capability, or a material change in how personal information is used.

The amendment workflow is the same five-phase shape as a new PIA, but starts from the existing Working Document rather than blank. Phase 1 confirms what changed and which sections of the template are affected; Phase 2 walks through only the affected sections with the System Owner; Phases 3 through 5 produce and submit the amendment package.

Amendments use the original project number with an appended suffix indicating amendment number: for example, <project_number>-A1, <project_number>-A2. The OIPC template’s Section A.Q8 marks the submission as an amendment and references the original PIA file number.

For older PIAs that were prepared under the former FOIP Act (the Freedom of Information and Protection of Privacy Act, repealed and replaced by POPA effective June 11, 2025), the amendment workflow effectively migrates them onto the new template. The amendment is prepared using the OIPC POPA PIA Template, which supersedes the FOIP-era format.

When a PIA concludes with non-approval

Sometimes a PIA leads to a decision not to proceed with the system, or to proceed only with significant restrictions that the requester finds unworkable. The Internal Decision Record captures this outcome: the rationale, the privacy or risk concerns that drove it, the alternatives considered, and the communication back to the requester.

A non-approval doesn’t mean the PIA work is wasted. The completed PIA, the Internal Decision Record, and the rationale all get retained in the privacy archive. If the system is reconsidered later (perhaps after vendor changes or contract renegotiation) the prior PIA work provides the starting point.

Backfilling PIAs for stable systems

The Division does not proactively reissue FOIP-era PIAs under the new OIPC template. Existing PIAs remain on file as historical records. They’re migrated onto the new template only when an amendment is triggered (per the "Amendments" section above) or when Senior Administration directs a backfill.

A direction from Senior Administration to backfill a PIA for a stable, unchanged system is treated as a from-scratch new PIA rather than an amendment, since there is no in-template original to amend from.

After approval

The completed PIA goes into the system documentation file. If the PIA identifies new personal information collection, the PIB directory is updated accordingly. If a new vendor is identified, the vendor inventory is updated per IM-007. The Working Document moves to the privacy archive.

The Access and Privacy Coordinator maintains the PIA inventory: a record of all completed PIAs with the following metadata: system name, Grasslands project number, PIA completion date, System Owner, system classification (Core/Common/Innovative), OIPC submission status (submitted / not required / not submitted), OIPC file number (if assigned), amendment history, and date of last review.

PIA records are retained per IM-009 – Records Retention Schedule.

When PIAs get reviewed

PIAs aren’t one-and-done. They’re reviewed and updated when any of these happen:

• A material change to how the system handles personal information

• A change in vendor or sub-processor

• A system reclassification under A.P. 312

• A privacy or security incident involving the system (see IM-022 for the RROSH assessment that accompanies incident response)

• Direction from Senior Administration or the Access and Privacy Coordinator

• A change in the OIPC POPA PIA Template that materially affects how the PIA would be answered

PIAs for Core Systems are reviewed at minimum every two years, aligned with the vendor reassessment cycle under A.P. 322.

If a review turns up material changes, the PIA goes through the amendment workflow.

Operational tooling

The following operational artifacts referenced throughout this guide are maintained as live records in Division tooling rather than as appendices to this document. The placeholder links below will be replaced with the real destinations once those tools are stood up.

• PIA inventory: the live register of all completed PIAs maintained by the Access and Privacy Coordinator. One row per PIA, capturing system name, Grasslands project number, PIA completion date, System Owner, system classification, OIPC submission status, OIPC file number (if assigned), amendment history, and date of last review.
• Working Document archive: the location where completed PIA Working Documents move after submission. Used to support OIPC s. 27(1)(j) requests, amendments, and PIA reviews.
• PIA cover letter template: standard Division-letterhead cover letter for OIPC submissions, with the form requirements per the OIPC template's Appendix D structure. Signed by the Access and Privacy Coordinator under the standing CG-003 delegation.

When this gets updated

This document is reviewed annually by the Director of Technology and Access and Privacy Coordinator, or earlier if there are changes to POPA or M-Reg 143/2025 PIA requirements, changes to the OIPC POPA PIA Template, changes to A.P. 323 §9, or changes to IM-012 risk assessment methodology. If something is out of date or unclear, reach out to the Director of Technology.

Document history