POPA PIA Template Completion Guide

Section 26 of the Protection of Privacy Act (POPA) requires a public body to prepare a privacy impact assessment (PIA) in prescribed circumstances and, if required by the regulations, submit the PIA to the Information and Privacy Commissioner in accordance with the regulations. In addition, as part of the Commissioner’s responsibility to monitor how POPA is administered to ensure that its purposes are achieved, the Commissioner may, as described in section 27(1)(j) of POPA, request a copy of a public body’s PIA.

Section 7(1) of the Protection of Privacy Act (Ministerial) Regulation (M-Regulation) lists the circumstances in which a public body must prepare and submit a PIA to the Commissioner.

This POPA PIA Template Completion Guide (“Completion Guide”) is a companion document to the POPA PIA Template. The aim of this Completion Guide is to assist public bodies in completing the POPA PIA Template. This Completion Guide provides explanation or clarification, where necessary, for each question asked in the POPA PIA Template and describes what is expected of the public body in each question. We recommend that you complete the POPA PIA Template while consulting this PIA Completion Guide.
The term “project” when used in this document means any administrative practice, program or service, or a change to any existing administrative practice, program or service that a public body plans to implement, which will involve the collection, use or disclosure of personal information and which includes one or more of the factors listed in section 7(5)(a) to (e) of the M-Regulation.

If a public body is unsure whether it is required to complete a PIA or complete and submit a PIA to the Information and Privacy Commissioner, the public body should consider using the PIA Submission Assessment Tool to make that determination.

Please note that sections in the POPA PIA Template with an asterisk (*) are mandatory and must be completed. Any PIA that does not complete the mandatory sections, will be deemed incomplete and will not be accepted for review by the OIPC.

If you encounter issues while using the completion guide or have questions, please contact us.

Note: Public bodies should not submit this completion guide to the OIPC as part of their PIA submission.

Given that section 26(1) of POPA requires a public body to prepare a PIA in prescribed circumstances and, if required by the regulations, submit it to the Commissioner in accordance with the regulations, the head of a public body is legally required to sign off on POPA PIAs. However, 55(1) of POPA authorizes the head of a public body to delegate to any person any power, duty or function of the head under the Act, except the power to delegate under this section. Section 55(2) requires that a delegation under subsection (1) be in writing and may contain any conditions or restrictions the head of the public body considers appropriate. To this end, the Designate of a public body may sign off on the public body’s PIA if that Designate has been delegated such a power. A copy of the delegation of power should be included with the PIA.

A. General Information about the public body or bodies, existing PIAs, and the project *

Questions in this section are asked as a legislative requirement and to enable the OIPC in processing the PIA file.

Question 1

Section 26 of POPA requires a public body to prepare a PIA in the circumstances listed in section 7 of the M-Regulation, when a project involves the collection, use or disclosure of personal information. If a public body is not collecting, using or disclosing personal information as part of its project, there is no requirement under POPA to submit a PIA to the Commissioner for the project.

Question 2

The legislation is clear on when a public body is required to prepare a PIA, and only in the prescribed circumstances as listed in the POPA PIA template is a public body required under POPA to submit a PIA to the OIPC. Please note that the list of highly sensitive information identified under section 1 of the M-Regulation is not an exhaustive list. Other personal information may be of high sensitivity.

In this question, if only the last checkbox (the loss of, unauthorized access to or unauthorized disclosure of the personal information could result in significant harm) is selected, the public body may not be required to submit a PIA to the Commissioner. Nonetheless, the OIPC recommends that public bodies use the POPA PIA template while preparing PIAs under section 7(1)(a) of the M-Regulation as the Commissioner may request copies of those PIAs under section 27(1)(j) of POPA. Using the template will ensure that the public bodies complete their PIAs in alignment with the PIA requirements under POPA and the M-Regulation of which the PIA template is based on.

Question 3
When submitting a PIA to the OIPC as required under section 26 of POPA, the OIPC needs to know certain information about the public body including who the head of the public body is at the time the PIA is submitted. This is because under POPA the head has specified duties including for protection of personal information (section 10(1)).

Question 4
Section 7(4)(b) of the M-Regulation allows for two or more public bodies to submit a PIA for a common or integrated program or service, hence the need to know if the PIA is for such a project.

Question 5
No additional explanation needed.

Question 6
No additional explanation needed.

Question 7
Sometimes, a new PIA is related to a PIA which has already been submitted to the OIPC and is still under review. In such cases, it is important that the OIPC is aware of this PIA to ensure the recent PIA is not reviewed in isolation from the related PIA. There are also times where information in an existing PIA is referenced in a new PIA. It is also important to know if such a PIA exists or has been previously reviewed by the OIPC.

Question 8

A PIA amendment addresses privacy and security risks associated with changes to an existing project that impacts the collection, use and/or disclosure of personal information. A PIA amendment focuses on areas that have changed in an existing project, and how the public body has identified and addressed privacy and security risks associated with the change. An amendment to a previously submitted PIA requires that the updated or new PIA is reviewed in consultation with the previously submitted PIA.

Question 9
Some public bodies have their own filing convention for their internal use. Providing this number ensures the OIPC, in addition to the OIPC’s file number, references this number in its communication with the public body.

Question 10

This informs the OIPC whether the project under consideration has been implemented or not.

Question 11
This question aims to inform the public body which sections of the appendices to the POPA PIA template are relevant to their project as well as relevant resource expertise needed to assist the public body in completing the technical aspect of the PIA. The question also informs the OIPC what to consider regarding legislative requirements during the PIA review process as different projects may have unique compliance privacy and security issues to consider.

For projects that involve automated systems, section 7(3) of the M-Regulation states that a PIA must provide a level of detail commensurate with the complexity of the practice, program, project or service the PIA relates to. As such, the public body is required to also complete an Algorithm Impact Assessment (AIA). AIA is a tool used for identifying and addressing the risks and impacts of automated decision-making systems. Typically comprising of a set of questionnaires, the tool can be used to determine the impact level of an automated decision-making system including biases, human rights violations, ethical violations, marginalization and accessibility issues. The OIPC is in the process of developing an AIA tool. Once completed, it will be published on the https://oipc.ab.ca and a link to it will be added to the POPA PIA Template and this document. In the interim, the OIPC recommends that where a project involves automated systems, public bodies consult industry standard algorithm impact assessment guidelines in preparing and submitting their AIAs with their PIAs.

Back to top of the page

B. Details About the Project*

Question 12
This information assists the OIPC in understanding the project, its business rationale and the purpose or objective it intends to achieve for the public body. This question also informs the OIPC on why the collection, use and/or disclosure of personal information is required by the public body to meet the needs of the project. It is imperative that the public body provides sufficient detail on the project. In addition, in this question, the public body is required to provide technical information about the project under consideration. For instance, if the public body is a police agency implementing a body worn camera (BWC), the public body is expected to describe each body worn camera unit, its associated features and IT infrastructure that operates the BWC. Also, information on BWC storage media, how information is transferred from the camera to the IT network, where information is stored and who is responsible for managing the information, etc. must be provided. In other words, the entire lifecycle of the personal information involved must be addressed in all aspects of the project. The public body should also consider attaching technical details of the project as necessary.

Question 13

An electronic information system has specific technical requirements, such as logging and auditing, access controls, that need to be considered and assessed to ensure the access and privacy rights of Albertans are upheld, which is why we need this information.

Question 14

Other stakeholders’ involvement in a project may determine who is collecting, using or disclosing personal information in the project and as a result shed some light on how the public body ought to consider the legal authority for each stakeholder to collect, use and/or disclose personal information involved in the project.

Back to top of the page

C. Information About Your Privacy Management Program (PMP)*

Question 15

Section 25(1) of POPA requires a public body to establish and implement a PMP and make it public or provide a copy of the PMP upon request pursuant to section 25(5). These requirements will come into effect on June 11, 2026. The public body’s policies and procedures must comply with the requirements of POPA and its regulations. The OIPC is working on issuing a POPA PMP Guideline which will be available on the OIPC website to assist public bodies in meeting their PMP obligations under POPA.

Not having a PMP leaves a gap in the completion of the PIA. This could potentially lead to non-compliance. It is important to provide the OIPC PMP file number of the public body’s most current PMP where applicable, as by doing so it saves the public body time and effort by referencing the already submitted PMP and avoids duplication. Also from a PIA review standpoint, it is relevant to review the PIA to assess the public body’s compliance with applicable legislation.

Back to top of the page

D. Identify Personal Information Involved and your Authority to Collect, Use or Disclose the Information*

Question 16

This question ensures that the public body identifies the personal information that it intends to collect, use or disclose in the project. In doing so, the public body would have to start thinking about its legal authority to collect, use or disclose personal information and whether those authorities align with sections 4, 12 and 13 of POPA, respectively. In addition, the public body is required to consider the limitation principle under sections 12(4) and 13(4) of POPA. Under section 12(4) the public body needs to explain how the use of personal information in the project is only to the extent necessary to enable the public body to carry out its identified purposes in a reasonable manner. Similarly, under section 13(4) of POPA, the public body needs to explain how the public body public disclosure of personal information is only to the extent necessary to enable the public body to carry out its identified purposes in a reasonable manner. Personal information means recorded information about an identifiable individual. Some examples of personal information include an individual’s name, home or business address, home or business email address, race, gender identity, fingerprints and financial history. For a complete listing of what is considered personal information, please see section 1(q) of POPA.

Question 17
Section 5 of POPA provides for the manner of collection of personal information. It is important that the collection of personal information for this project meets the requirements of section 5 of POPA. In this question, the public body needs to consider and explain how section 5(2) of POPA is complied with in this project if personal information is collected directly from the individuals who are the subjects of the information, including when and how a collection notice is provided to those individuals. In particular, the public body needs to explain whether section 5(2) of POPA applies to its project and how the public body complies with it.

Question 18
While there are legal authorities for public bodies in POPA to use or disclose personal information, there are situations where a public body may rely on individuals’ consent to use or disclose their personal information. Such consent must meet the prescribed requirements of section 2 of the Protection of Privacy Regulation (“the Regulation”). That is, the consent process for the project needs to clearly explain whether consent is obtained electronically or manually. Where consent is collected electronically, the public body should state how individuals give their consent. While a consent form is the implementation of the above consent requirements, public bodies need to have policies and procedures in place to collect and manage consent.

Question 19
There are circumstances where personal information can be collected indirectly, which means the collection comes from a source that is not the person whom the information is about. If that is the case in this project, this question gives the public body the opportunity to describe why, and how personal information is collected indirectly.

Question 20 – An information flow diagram is not the same as a business flow or a network diagram. An information flow diagram identifies the flow of specific pieces of information from one entity to another and when the entities involved are collecting, using or disclosing the information in question. It has arrows indicating the direction of flow of information between the entities. In some cases, information flow could be bi-directional between two entities. The information flows help in identifying the legal authority for collecting, using or disclosing personal information by each entity involved in the flow of the information. A network diagram depicts an IT network infrastructure or network segment and its associated components which may include, servers, routers, firewalls, databases, etc. A business flow diagram is a step-by-step process on how a specific business task is accomplished.

Question 21
No additional explanation needed.

Back to top of the page

E. Access, Correction, Accuracy, Retention, Disposition*

Question 22

This question is asked to remind a public body to ensure it takes steps to make individuals aware of their rights to request access to their personal information that is in the custody or under the control of the public body. Usually, public bodies should be transparent by making their access to information request processes public, with specific contact information of a person or business unit that handles access to information requests. In certain circumstances, public bodies should make proactive disclosure to minimize the number of access requests they get.

Question 23
While this may be addressed as part of the PMP, public bodies are required to have access request policies in place to ensure that Albertans can exercise their rights to access their information. Such a policy governs how a public body implements its access to personal information processes to ensure consistency in processing such requests.

Question 24

This question is asked to ensure a public body has established a process to make individuals aware of their right to request correction to their personal information involved in the project. Usually, public bodies should be transparent by making their correction to personal information request processes public with specific contact information of a person or business unit that handles correction requests.

Question 25

While this may be addressed as part of the PMP, public bodies are required to have correction request policies in place that govern how Albertans can exercise their rights to correct their personal information and to ensure consistency in processing such requests.

Question 26

Public bodies have an obligation to make every reasonable effort to ensure that information about individuals that the public body relies on to make decisions that affect those individuals is accurate and complete.

Question 27

It is important to understand how the public body complies with section 6(b) of POPA for this project by ensuring that there exists a retention and disposition policy for information used in this project to govern how long personal information must be retained.

Question 28

Implementing record retention and disposition policies into information systems ensures that information that has reached its retention period is automatically flagged by the system for disposition instead of it being a manual process that is prone to inconsistencies and human errors resulting in information being retained past its retention period. Information held longer than its retention period poses a risk of loss, unauthorized access, or unauthorized disclosure.

Back to top of the page

F. Protection of Information*

Question 29
Information security classification means assigning security levels to information that are based on the sensitivity of the information in question. Classifying the information based on the public body’s information classification standard assists the public body to protect the information by implementing security controls that are proportionate to the classification levels of the information. Each public body is required to implement an information security classification system to assist the public body to classify information that it collects, uses or discloses as required under section 2(1) of the M-Regulation. Public bodies must meet this requirement before submitting their PIAs to the Commissioner for review.

Question 30
The “reasonable security arrangements” standard set out in section 10(1) of POPA are determined by the security classification of the personal information involved in the project. If the security classification is high, then the security measures, i.e., the administrative, technical and physical safeguards, must be correspondingly high. Whereas, if the security classification is low, then fewer measures may suffice to meet the standard. Section 6(2(b) of the M-Regulation requires public bodies having custody or control of a high volume of personal information or highly sensitive personal information to have documented safeguards. POPA does not stipulate a threshold for “high volume” or “significant percentage of the population”. The interpretation of this section of the M-Regulation is contextual in relation to the project. Although Section 1 of the M-Regulation deems certain personal information to be highly sensitive (biometric and financial information, and personal information of minors and seniors), this list is not an exhaustive or exclusive list. Other types of personal information may be deemed to be highly sensitive in specific contexts.

1. Administrative safeguards govern the implementation of other protective measures and ensures that such measures are implemented consistently during the life cycle of the project. Consistent implementation of protective measures reduces vulnerabilities usually caused by lack of good security governance.
2. No additional explanation needed.
3. The technical safeguards should directly protect the information involved in the project, not just the general technical safeguards implemented by the public body. For instance, access controls should be specific for the project and describe how such controls ensure only authorized individuals have the right level of access to information involved in the project. In addition, any security assessments results such as vulnerability assessment and penetration tests conducted specific to the project should be included as part of the public body’s PIA submission, as such results provide additional information on risks that were identified and how they were resolved as part of the project implementation.

Question 31
Continuous assessment and monitoring of safeguards assists the public body in ensuring that the safeguards are working as expected. For instance, employees should be required to take refresher trainings on privacy and security. Also, monitoring controls such as intrusion detection and prevention systems should be implemented.

Question 32
Section 6(1)(b) of the M-Regulation requires public bodies to establish policies and procedures that ensures they comply with the public body’s obligations under POPA such as responding to incidents (unauthorized access to, unauthorized disclosure of or loss of personal information). Section 6(1)(d) of the M-Regulation also requires public bodies to train their employees about the employee’s obligations under POPA. As part of that training, public bodies should make their employees aware of their obligations under POPA, which includes notifying the public body of incidents under section 10(2) of POPA.

Question 33
Access control policies ensure that access to the Electronic Information System (EIS) is consistently managed, including requests to access the EIS, account provisioning and revocation of account when an employee no longer needs access to the EIS. Through enforceable access control policies, a public body will be able to ensure that an employee only gains access to the information they require to perform their job functions.

If the project involves a high volume of personal information or highly sensitive personal information, a documented access control policy must be attached to the PIA submission. POPA does not stipulate a threshold for “high volume” or “significant percentage of the population”. The interpretation of this section of the M-Regulation is contextual in relation to the project. Although Section 1 of the M-Regulation deems certain personal information to be highly sensitive (biometric and financial information, and personal information of minors and seniors), this list is not an exhaustive or exclusive list. Other types of personal information may be deemed to be highly sensitive in specific contexts.

Question 34
Having an access requests process for the EIS ensures access requests are submitted by appropriate business heads for approval by the appropriate authority prior to processing and account provisioning. Each request should identify the permission level for employees requiring access and ensure the permission level gives the employee only the right access required for the specific job tasks.

Question 35
All access requests to the EIS must be approved by the appropriate level of management, to ensure that employees who access the EIS are authorized to do so.

Question 36
It is important to ensure that access to the EIS is revoked in a timely manner when employees no longer need such access, to prevent potential unauthorized access to personal information. It is also to ensure dormant accounts are removed from the system, as such accounts pose security risks.

Question 37
The access control table provides clarification on the access privileges of the users of the system including the kind of actions each user can take and what information the user can access, and how the permission limits users only to the information they need to perform their job tasks or functions. The public body’s information technology (IT) department plays a significant role in implementing access controls in systems and will be a good resource for assisting in completing this table.

Question 38
Logging and auditing policies ensure that information systems are built and implemented to capture audit logs of activities that are occurring within the system, including unauthorized activities listed under section 10(2) of POPA. Such a policy also ensures proactive auditing of information systems to detect and manage incidents defined under section 10(2) of POPA.

If the project involves a high volume of personal information or highly sensitive personal information, a documented auditing and logging policy must be attached to the PIA submission. POPA does not stipulate a threshold for “high volume” or “significant percentage of the population”. The interpretation of this section of the M-Regulation is contextual in relation to the project. Although Section 1 of the M-Regulation deems certain personal information to be highly sensitive (biometric and financial information, and personal information of minors and seniors), this list is not an exhaustive or exclusive list. Other types of personal information may be deemed to be highly sensitive in specific contexts.

Question 39
Being able to capture and maintain audit logs of personal information means that the public body can identify and investigate unauthorized access to, unauthorized disclosure of, or loss of personal information in order to meet its obligations under section 10(2) and (3) of POPA and sections 4(3), (4) and (5) of the M-Regulation.

Question 40
Proactive auditing is a way of monitoring access to an EIS to detect and respond to potential unauthorized access to, unauthorized disclosure of, or loss of personal information.

Question 41
No additional explanation needed.

Back to top of the page

G. Service Providers*

Question 42
Given that service providers, which includes corporations, are considered employees under section 1(h) of POPA, a public body is accountable for the service provider’s compliance with POPA. Therefore, it is important for the public body to consider privacy issues that may involve the service provider’s role in relation to any personal information it may collect, use, disclose or access as an “employee” of the public body.

Question 43
If a service provider will have access to personal information as part of providing its services to the public body or if it will collect, use or disclose personal information on behalf of the public body, the public body must ensure it complies with POPA as it relates to these activities. Therefore, the contract with the public body must address all related compliance issues such that through the implementation of the terms of the contract agreed to between the public body and the service provider, the public body has confidence that the service provider will comply with POPA in providing its services concerning any personal information involved in service delivery. A service provider must also protect the personal information it has in its custody, or that it is otherwise responsible for, according to the terms of the contract which must ensure compliance with section 10(1) of POPA, i.e., the security of the personal information must at minimum align with the public body’s security safeguards for this type of information. The agreement must also set out how the service provider interacts with the public body’s privacy management program. Without an agreement that addresses all these compliance related issues, there is a risk of non-compliance by the public body as a result of the activities of its service provider. Consequently, as part of the PIA review, any agreement entered into with a service provider must be reviewed by our office as part of the PIA review process. This is because the service provider agreement plays a central role in determining whether the service provider-employee is positioned within the terms of the contract to comply with POPA. Submitting a copy of the agreement with your PIA is a mandatory requirement.

Section 7(6) of the M-Regulation provides that where a public body is required under POPA or the Regulation, to enter into an agreement relating to the practice, program, project or service the PIA relates to, the portions of the agreement relating to the protection of privacy must be submitted to the Commissioner together with the PIA. Under section 1(1)(h) of POPA, an “employee” includes those providing a service to the public body “under contract.” The contract with the service provider would demonstrate the public body’s authority under POPA to share personal information with the service provider or otherwise permit it to collect, use or disclose personal information on its behalf. Therefore, it is an essential part of the PIA submission.

Question 44
A public body may delegate responding to access to information request responsibility to its service provider. However, the public body must ensure that its contractual agreement with the service provider adequately addresses access to information request processing and describe how the service will be provided to the public body.

Question 45
To ensure the public body is able to meet its obligations under POPA the public body must ensure it maintains control of the personal information involved in the project where this information is collected or accessible by the service provider. This is required to ensure the personal information remains subject to POPA and the Access to Information Act (ATIA) to preserve the rights of individuals concerning their personal information under these Acts. Failure to retain control of the personal information amounts to a disclosure, which is prohibited under POPA without authority for said disclosure. This means, that there is a high likelihood of a breach if a public body fails to retain control of personal information in an agreement and provides personal information to the service provider for the services. For this question, if the public body’s answer is yes, the public body must identify specific sections of its contract with the service provider that ensures the public body maintains control of the information for the project. Public bodies must meet this requirement before submitting their PIAs to the Commissioner for review.

Question 46
For this question, refer to the information set out in the commentary above for Question 43.

Question 47
Service providers are considered employees of the public body and should have appropriate training prior to accessing personal information and continue to have refresher training for the duration of their contract. Section 6(1)(d) of the M-Regulation.

Back to top of the page

H. Project Risk Assessment and Mitigation*

This section of the PIA template requires public bodies to identify the project’s privacy and security risks and associated administrative, technical and physical safeguards that address these risks. This completion guide provides some example descriptions of the types of risks identified in the POPA PIA Template risk table.

Question 48
Conducting security vulnerability assessments (VA) during the implementation of an information system that processes identifying information ensures exploitable security vulnerabilities or weaknesses are identified, prioritized and addressed in a timely manner. A penetration test (pentest) is performed to test if security controls are working as expected. VA and pentest are part of an overall risk management strategy and should be conducted periodically. Other security assessments can also be conducted and included in the PIA. Providing copies of these assessments with your PIA goes on to demonstrate the public body’s commitment to protect personal information pursuant to section 10 of POPA.

H1. General Risks (to be completed for all PIA submissions) *

Risk 1
E.g., personal information is collected by the public body and/or the information system is configured to accept personal information that does not relate directly to and is necessary for the project. Systems built for the global market have default configurations that allow for the collection of vast amounts of personal information. Such systems should be hardened by disabling data fields that are not required for specific project implementations to manage the risk of over collection.

Risk 2
E.g., information that was collected for this project is used for a purpose not directly related to the project, contrary to section 12 of POPA.

Risk 3
E.g., information that was collected for this project is disclosed contrary to section 13 of POPA. Personal information could be intercepted while in transit due to lack of appropriate security control, leading to unauthorized disclosure. There are also situations where the public body or its employees disclose personal information for secondary purposes without legal authority. Unauthorized disclosure could also be via insecure disposal of information processing media.

Risk 4
E.g., information collected for this project is accessed by unauthorized users or malicious software due to lack of reasonable safeguards, contrary to section 10(1) of POPA.

Risk 5
E.g., information collected for this project is lost as a result of human error or malicious software attacks, such as ransomware, which renders information inaccessible. This may lead to the inability of the public body to perform its business functions or respond to requests from individuals to access their information. Disgruntled employees can also deliberately destroy personal information. Also, changes to IT systems without proper IT change management process and lack of disaster recovery strategy could lead to loss of information.

Risk 6
E.g., A public body loses control of electronic and/or paper-based information as a result of insufficient or absence of contractual agreements with a third-party service provider. Loss of custody may involve the theft of paper records or a server that contains personal information in the public body’s premises.

Risk 7
E.g., information collected for this project is inadvertently or maliciously destroyed contrary to POPA and the policies of the public body, such that the public body is unable to respond to access to information requests or carry out its business functions. Lack of an enforceable record retention and disposition policy could also lead to unauthorized destruction.

Risk 8
E.g., information collected for this project is rendered inaccurate, or incomplete, contrary to section 6(a) of POPA. This may occur if employees are not adequately trained on good data entry practices or if system changes do not follow industry standard change management processes or information is not reasonably protected from unauthorized modification.

Risk 9
E.g., personal information collected for this project is retained contrary to section 6(b) of POPA or the project retention procedures as established by the public body (section 7(2)(f) of the M-Regulation). In some cases, this may be a consequence of the absence of a record retention policy or lack of enforcement of an existing record retention policy.

Risk 10
E.g., individuals’ information is collected for this project without providing proper notice at the time of collection, contrary to section 5(2) of POPA. Notice fails to align with the manner of collection and the requirement of POPA such as collecting personal information directly from individuals by telephone but providing notice via the public body’s website.

Risk 11
E.g., the public body fails to make individuals aware of their rights to request access to or correction of their personal information, and how to make such requests.

Risk 12
E.g., lack of or inadequate privacy breach management means that privacy breaches will not be consistently detected and managed. In addition, affected individuals of privacy breaches/incidents, the Commissioner and the Minister will not be notified in a timely manner as required under section 10(2) of POPA.

Risk 13
E.g. without assessing third parties’ controls, the public body is unable to attest whether the third party reasonably protects personal information in respect of the services provided to the public body in compliance with POPA and its regulations. As a result, the public body could fail to meet its obligations to protect personal information under section 10 of POPA.

Risk 14
E.g. personal information collected for this project for purposes under section 12 of POPA is being used for secondary purposes (e.g. to train artificial intelligence (AI) or by the third party for quality improvement purposes) without authority.

Risk 15
E.g., inadequate or absence of logging capabilities of systems limits the ability of the public body to identify and manage privacy breaches of personal information. In addition, it limits the Commissioner’s ability to investigate access to personal information violations including investigating potential offences under section 60 of POPA.

Risk 16
E.g., failure to have human oversight and validation measures for information systems could potentially lead to data accuracy and reliability issues.

Risk 17
Failing to conduct a security vulnerability assessment means that the public body may not be aware of exploitable security vulnerabilities that exists in its environment and as a result, would not take steps to address those security vulnerabilities in a timely manner thereby exposing personal information to potential compromise.

H2. Risks Associated with Cloud Computing

Risk 1
E.g. In a multitenant cloud environment, compromise of one environment could lead to the compromise of other environments due to inappropriate segregation and isolation of cloud resources. In addition, there could potentially be information leakage between environments leading to unauthorized disclosure of personal information.

Risk 2
E.g., lack of formalized contractual arrangements that specifically consider POPA requirements could lead to loss of custody and/or control of personal information stored in the cloud environment as well as gaps in security management and non-compliance with POPA.

Risk 3
E.g. the absence of clear and good governance on privacy and security of personal information could result in gaps in privacy and security management leading to non-compliance with POPA.

Risk 4
E.g., POPA requirements including privacy breach management is not addressed in the contractual agreement between the public body and the cloud provider, which could lead to non-compliance with section 10(2) of POPA.

Risk 5
E.g. a cloud provider goes out of business or declares bankruptcy, making it impossible for the public body to access personal information in the provider’s environment.

Risk 6
E.g., a cloud provider uses proprietary technologies, making it difficult for the public body to migrate services to another provider, locking-in the public body. A public body may want to change provider if the existing provider suffers multiple security incidents that have caused privacy breaches.

Risk 7
E.g., the USA PATRIOT Act and Cloud Act allow the US government to access personal information held by US-based companies in the US (USA PATRIOT Act) and anywhere in the world (Cloud Act).

Risk 8
E.g., a cloud provider uses personal information for their own purposes, such as de-identifying personal information and/or using the personal information for training their AI models.

Risk 9
E.g., the cloud provider sells personal information or fails to securely sanitize information processing media prior to re-use or disposition leading to unauthorized disclosure of the personal information.

Risk 10
E.g. lack of reasonable authentication and authorization controls such as failures to implement and enforce multifactor authentication could potentially lead to unauthorized access to personal information.

Risk 11
E.g. weak or lack of encryption could lead to unauthorized access to and disclosure of personal information in transit and at rest.

H3. Risks Associated with Research

Risk 1
E.g., the public body fails to assess whether non-identifying data can be used to accomplish the research purpose prior to disclosing individually identifying personal information or has not obtained the Commissioner’s approval for such disclosure as required under section 15(a) of POPA.

Risk 2
E.g., the public body fails to perform a public interest analysis prior to disclosing personal information for research or statistical purposes where the information is involved in data matching.

Risk 3
E.g. the public body fails to conduct an assessment of risk of harm prior to disclosing personal information for research or statistical purposes where the information is involved in data matching.

Risk 4
E.g., the public body has not approved conditions relating to security and confidentiality, the removal or destruction of individual identifiers and prohibition of subsequent use or disclosure of the information without express authorization of the public body.

Risk 5
E.g., a research agreement has not been signed prior to the public body disclosing personal information or the research agreement in place does not meet the requirements of section 15(d) of POPA and section 4 of the Regulation.

Back to top of the page

Appendix A. Data Matching

Only complete this section if the project involves data matching as defined under section 1(f) of POPA.

Question 1
No additional explanation needed.

Question 2
There are specific circumstances in which a public body may carry out data matching as listed in section 17(1) of POPA. Any prescribed purposes will be found in the regulation otherwise such a purpose does not exist.

Question 3
No additional explanation needed.

Question 4
Prior to collecting personal information from another public body for the purpose of data matching, a public body must first create a governance structure that clearly identifies the responsibilities and accountability of each public body involved in carrying out the data matching to ensure access and privacy rights of Albertans are protected. The governance structure must clearly identify the responsibilities and accountability of each public body as it relates to:

1. the custody and control of personal information,
2. the correction of errors or omissions in an individual’s personal information,
3. breach notifications, and
4. other duties imposed by the Act.

Public bodies must meet this requirement before submitting their PIAs to the Commissioner for review.

Question 5 – The data matching agreement is required to ensure clarity regarding the roles and responsibilities of each public body involved in the data matching project as well as legislative compliance. The minimum requirements of the agreement are as follows:

the agreement must:

1. identify

(i) the authority under which the public body will carry out data matching, and

(ii) the purpose for which the public body will carry out data matching,

1. identify each public body’s role and how each public body’s role relates to the purpose of the data matching to which the addendum relates,
2. describe how the personal information will be securely transmitted, matched or linked by the public bodies,
3. identify whether the data derived from the personal information used for data matching will be disclosed to the public body from whom the personal information was collected,
4. identify each public body’s responsibilities respecting reasonable security arrangements, including respecting administrative safeguards, physical safeguards and technical safeguards, for the protection of personal information against such risks as unauthorized access, collection, use, disclosure or destruction, and
5. establish a clear governance structure respecting the responsibilities and accountability of each public body.

Question 6

This question requires that a public body participating in data matching identifies collections, uses or disclosures of personal information that only apply to that public body. In doing so, the public body is required, by law, to have an addendum for the unique collections, uses or disclosures to accompany the join PIA submitted for the project.

Question 7
No additional explanation needed.

Question 8

Risk Assessment and Mitigation – Risks Associated with Data Matching.

This Completion Guide will provide some examples of the description of the types of risks identified in the Risk Assessment and Mitigation table for risks related to data matching.

Risk 1

E.g. section 7(2)(g) of the M-Regulation requires the establishment of a clear governance structure respecting the responsibilities and accountability of two public bodies involved in data matching if one public body is collecting personal information from another public body for the purpose of data matching.

Risk 2

E.g., this risk assessment is to ensure that section 17 of POPA is complied with, given that this section prohibits public bodies, except for the Office of Statistics and Information, from collecting personal information directly from an individual for the purpose of data matching.

Risk 3
E.g., section 6 of POPA requires a public body to make every reasonable effort to ensure that an individual’s personal information is accurate and complete before using such information to make a decision that directly affects that individual.

Risk 4
E.g., as required by section 6 of POPA, the quality of the source data will play a significant part in the quality of the resulting data from data matching, so it is important for public bodies to ensure that the quality of the source is validated prior to conducting the data matching.

Risk 5
E.g., data matching activities normally take place in a test environment. The resulting data is then migrated to the production environment. Therefore, the test environment security controls should be proportionate to the security classification of the data involved in data matching. Failure to implement reasonable and proportionate security arrangements to protect personal information within the public body’s data matching environment, exposes it to potential incidents under section 10 (2) of POPA especially given that a single test environment may be used for multiple projects and thus accessed by various users.

Risk 6
E.g. this is about validating the final product. The public body should ensure that the final product is the desired outcome, and that no data errors are in the resulting data set, or if errors are identified, that they are addressed. (section 6 of POPA).

Risk 7
E.g., this is about securely cleaning the test environment that was used for data matching by securely deleting personal information from that environment before it is used for other purposes or used by other users to prevent potential unauthorized access to personal information.

Back to top of the page

Appendix B. Common or Integrated Program or Service

Question 1
A common or integrated program or service must comply with specific requirements under POPA and the M-Regulation. It is therefore important for the public body to carefully consider those requirements prior to implementing new common or integrated program or service or making changes to an existing common or integrated program or service.

Question 2

Since common or integrated program or services requires each public body to identify its responsibilities and accountabilities identifying each public body assist in determining the areas of responsibility and accountability for each public body.

For question 2c, if the PIA is for a change in an existing common or integrated program or service, providing an existing PIA file number assists the OIPC in making reference to relevant information in that file during the review of the current PIA as the public body focuses on addressing privacy and security risks associated with the change. The public body may also choose to use the existing Microsoft Word copy of the existing PIA to identify areas that have changed by striking the outdated information and entering updated or new information in a different-colour text.

Question 3

This question is about making sure that there is a governance structure in place for the common or integrated program or services. This governance structure (a documented set of rules and processes that identify the roles, responsibilities and accountability for each public body participating in the integrated program or service), that clearly identifies responsibilities and accountabilities must be in place prior to the PIA being submitted to the Commissioner for review.

The governance structure must clearly identify the responsibilities and accountability of each public body as it relates to:

1. the custody and control of personal information,
2. the correction of errors or omissions in an individual’s personal information,
3. breach notifications, and
4. other duties imposed by the Act.

Question 4

This agreement is required to ensure each public body involved in a common or integrated program or service independently comply with POPA. The minimum requirements for such an agreement include:

1. identify the purpose of the common or integrated program or service,
2. identify each public body’s roles and responsibilities respecting the common or integrated program or service and how the roles and responsibilities of each public body relate to the purpose of the common or integrated program or service, identify each public body’s responsibilities under the Act,
3. establish rules respecting reasonable security arrangements, including respecting administrative safeguards, physical safeguards and technical safeguards, for the protection of personal information against such risks as unauthorized access, collection, use, disclosure or destruction, and
4. establish a clear governance structure respecting the responsibilities and accountability of each public body.

Question 5

This question requires that a public body participating in a common or integrated program or service identifies collections, uses or disclosures of personal information that only apply to that public body. In doing so, the public body is required, by law, to have an addendum PIA for the unique collections, uses or disclosures to accompany the joint PIA submitted for the project.

Question 6

Risk Assessment and Mitigation – Common or Integrated Program or Service Risks

This completion guide will provide some examples of the description of the types of risks identified in the Risk Assessment and Mitigation table for common or integrated program or service risks

Risk 1
E.g., governance structure including policies are not in place or are inadequate leading to inconsistencies in the management of the program that creates exploitable privacy and security vulnerabilities.

Risk 2
E.g., policies are not in place or are not clear on accountability for different aspects of the program including accountability for privacy.

Risk 3

E.g., the responsibilities of each public body involved in the common or integrated program including for privacy management are not clearly defined.

Risk 4

E.g., the information security classification for one or more public bodies do not align with the sensitivity of information, leading to gaps in the protection of personal information.

Risk 5
E.g., the public bodies involved fail to make individuals aware of how they can exercise their access and privacy rights under applicable POPA and ATIA.

Back to top of the page

Appendix C. Use of Automated Systems or Other Forms of Innovative Technology

Question 1

An Algorithm Impact Assessment (AIA), is a risk assessment or evaluation process that determines the impact of an automated system on individuals whose personal information is collected, used or disclosed in the use of automated systems such as artificial intelligence or other forms of innovative technology. Section 7(3) of the M-Regulation requires that a PIA contains a level of detail commensurate with the complexity of the practice, program, project or service the PIA relates to. As such, the public body is required to also complete an AIA. The OIPC is in the process of developing an AIA tool, which will be published on the OIPC website and a link included in the POPA PIA template and this document. In the interim, the OIPC recommends that where a project involves automated systems, public bodies consult industry standard algorithm impact assessment guidelines in preparing and submitting their AIAs with their PIAs.

Question 2

Risks Associated with the use of Automated Systems or other forms of innovative technology.

Risk 1
E.g. failure to maintain custody or control of personal information ingested by an automated system due to lack of controls to securely and automatically delete information from the automated system.

Risk 2
E.g. lack of or insufficient automated systems governance policies and procedures leads to inconsistent implementation and use of automated systems, resulting in automated systems-related vulnerabilities and privacy compliance issues.

Risk 3
E.g. automated systems such as artificial intelligence, are known to hallucinate by fabricating results or outputs. Lack of monitoring including lack of oversight of AI systems leads to failures to detect and address hallucination issues.

Risk 4
E.g. Using poor quality and unreliable training data leads to issues with automated systems results including hallucination. In addition, using training data that is not an accurate representation of the population where the automated systems will be deployed could potentially lead to inaccurate results and bias.

Risk 5
E.g. if inputs in automated systems are not validated and protected, such inputs can be manipulated prior to processing by the automated system. This makes input vulnerable to tampering and the automated system vulnerable to faulty results.

Risk 6
E.g., understanding whether the automated system model is static or dynamic, it may be difficult to implement the right monitoring mechanism for the models. For instance, while dynamic models continuously learn from new data sets in process, a static model is as good as its last update.

Risk 7
E.g., Underfitting an automated system model with its training data means that the automated system model is trained to be too broad in its generalization making the model prone to false positives when processing new data.

Risk 8
E.g., Overfitting an automated system model with its training data means that the automated system model is trained too closely aligned with its training data, leading to lack of generalization by the model and making the model prone to false negatives when it processes new data.

Risk 9
E.g., misconfiguration of an automated system is a security vulnerability that could be exploitable, leading potential to unauthorized access to or disclosure of personal information.

Risk 10
E.g., lack of processes for individuals to be made aware of and appeal decisions made by automated systems could infringe on individuals’ access and privacy rights.

Risk 11 – E.g., insufficient logging and auditing means that the activities of the automated system cannot be reasonably monitored to ensure it is working as expected or to detect potential compromise of the system.

Risk 12
E.g., lack of monitoring of the automated system based on established policies and processes means that issues with the functioning of the automated system cannot be detected and addressed in a timely manner.

Risk 13
E.g., without conducting a vulnerability assessment means that exploitable vulnerabilities associated with an automated system cannot be identified and addressed. A copy of the results of the assessment should form part of the PIA to demonstrate the public body’s commitment to protect personal information pursuant to section 10 of POPA.

Back to top of the page

Appendix D. PIA Cover Letter *

While the head of a public body may assign privacy responsibilities to other individuals within the public body, the head of the public body is ultimately accountable for meeting the public body’s obligations under POPA. To this end, the PIA must include a cover letter signed by the head of the public body.

Back to top of the page

Appendix E. PIA Submission Checklist *

This checklist is there to ensure the public body reviews its PIA and ensures all sections of the PIA have been considered, relevant sections completed, and all supporting document included in the PIA submission.

Back to top of the page

March 2026