Introduction

Purpose of this guidance

Public bodies[1] in Alberta are required to comply with the Protection of Privacy Act (POPA) and its associated regulations the Protection of Privacy (Ministerial) Regulation (M-Regulation) and the Protection of Privacy Regulation (Regulation). POPA governs the collection, use, disclosure and management of personal information[2] in the custody or control of public bodies. They are also required to provide access to individuals who request access to their own personal information in accordance with the Access to Information Act.

This guidance is designed to help public bodies meet their obligations under POPA and ATIA, as described, when engaging the services of a service provider to perform services on behalf of the public body that involves the service provider collecting, using, disclosing or managing personal information on the public body’s behalf. For example, a public body may want to use a new application to support one of their programs and the program involves the collection, use or disclosure of personal information. This could involve contracting an information technology service provider to provide support for the application, hosting the application remotely and providing back-up services for the records. Another example would be a public body hiring a records management company to store paper records containing personal information at an off-site storage facility with support services until the end of the records retention period.

Any service provider that is, or may be, planning to provide services to public bodies will also benefit from this guidance as it will have a better understanding about public bodies’ duties under these laws.

This guidance is not intended for public bodies who are entering into contracts with other public bodies in the development of a common or integrated program or service.

What is a “service provider”?

A service provider is any organization or body that is external to the public body and that provides services to the public body under a contract.

Where, as part of providing services to the public body, the service provider will have access to or collect, use or disclose personal information on behalf of the public body under a contract, the service provider becomes an “employee” of the public body for the purposes of POPA and is bound as an employee to adhere to the public body’s requirements under POPA as they relate to these activities.

Similarly, ATIA also applies to public bodies. If a service provider under a contract for services is tasked with providing access to personal information on behalf of the public body, it will be an “employee” of that public body for that purpose and subject to the ATIA requirements regarding access to the personal information. For most service provider contracts, the service provider’s only task in regard to access or correction requests under ATIA will be to cooperate with the public body in responding to these requests.

Why is it important to read this guidance?

The role of service providers has grown disproportionately in the past few decades due to the development of cloud services, software as a service and other mainly technology driven developments. According to a recent survey, 80% of organizations suffered a data breach in 2022 caused by a third party. In recognition that most organizations use service providers as part of their operations, many modern privacy laws contain obligations that hold service providers directly accountable for compliance under these laws including for breach reporting.

When public bodies enter into a contract with a service provider, they remain accountable for any collection, use or disclosure and management of information carried out on their behalf by the service provider. This guidance will assist public bodies to develop policies and procedures for contracting with service providers that align with their privacy obligations under POPA and, as applicable, under ATIA. This guidance should not be used in isolation but rather in conjunction with other policies and procedures (e.g., procurement, information classification, cybersecurity).

Explanatory note

Any reference to “POPA” that follows includes the right of access under the ATIA to one’s own personal information, unless the service provider is providing access and correction services on behalf of the public body, which will be explained.

Back to top of the page

Public bodies’ governance and accountability

To meet the requirements of POPA, a public body must have a governance framework in place to facilitate compliance. This includes having appropriate policies and procedures in place when contracting service providers.

Roles and Responsibilities

The head of the Public Body holds ultimate responsibility for decisions and compliance. The head may delegate others to have the authority to make decisions on behalf of the head (e.g. Privacy Officer), including entering into contracts with service providers.

As indicated, a service provider under a contract relationship with a public body is defined as an employee under POPA s. 1(h):

“employee”, in relation to a public body, includes a person who performs a service for the public body as an appointee, volunteer or student or under a contract or agency relationship with the public body;

While a contracted service provider is not an employee in the labor relations sense, it is included in the POPA definition of employee. This ensures it is bound by the Act. Because the types of services will vary, the public body will need to look at each situation and be sure to clearly articulate which privacy requirements must be met. Public bodies must ensure they, and by extension their service providers, are complying with POPA.

Public bodies are accountable for any information handled on their behalf by their service providers. Therefore, they must ensure any collection, use and disclosure is legally authorized under POPA. Having a contract in place with the appropriate terms and conditions provides the public body with assurance that it is able to maintain control of the information. Roles and responsibilities should be clear, including what activities are authorized and which ones are prohibited. Public bodies will need to ensure they are able to meet their obligations under POPA.

Privacy Management Program and Service Providers

Public bodies are required to have a Privacy Management Program (PMP) inclusive of policies and procedures for service provider procurement, contracting, and management including oversight and auditing. Public bodies must develop their procurement processes to meet POPA. The processes must ensure the public body is choosing a service provider who will be able to support the public body’s legal obligations under POPA. For more information on PMPs please see the OIPC’s Guidance for Public Bodies in Developing Privacy Management Programs.

Back to top of the page

Pre-contract/Planning Phase

Public bodies should plan out their procurement strategy including spending some time thinking about what services are needed and how they will align with business needs, including compliance with POPA. This up-front planning will most likely save public bodies money in the long run and may even prevent the public body from experiencing a privacy or security breach.

Determining Scope of Services Involving Personal Information

Public bodies should identify:

• the business purpose for the activity and what service the public body is looking for.
• how the service fits into public body’s operations.
• the personal information that the service provider will collect, use or disclose on behalf of the public body to perform the service.
• its legal authority for this collection, use or disclosure of the personal information.

Determining Service Level Expectations

Determine the classification of personal information that the service provider will collect, use or disclose on behalf of the public body. This is necessary to establish the measures the service provider will need to implement to carry out the service for the public body in compliance with POPA.

Assessing the Privacy Posture of a Potential Service Provider

Before engaging a service provider, a public body may wish to examine the privacy posture of a potential service provider to assess whether it has in place privacy practices that will support the public body’s duties under POPA if the public body were to contract with the service provider for the services. The following are some areas a public body may wish to examine prior to considering whether to retain the services of a particular service provider (where this is permitted). Note that these considerations are not exhaustive but rather some key considerations.

• Does the service provider have a privacy policy? Often service providers will have a privacy policy on their website or in their marketing material. Public bodies can review these to see if at first glance they appear to have operationalized privacy practices in what appears to be a reasonable manner as part of their business, and references a privacy law to which they are subject. Service providers with transparent privacy policies that are easy to understand may enhance trust in their ability to protect the personal information that they will have access to in performing the services.
• Does the service provider have a privacy officer listed? Public bodies can contact the privacy officer with privacy questions they might have regarding the services and their privacy practices.
• Does the website:
  • describe what personal information is collected, used or disclosed for the service and does this appear reasonable based on the service provided;
  • describe any secondary uses of personal information, such as for improving products or services or marketing, or training artificial intelligence, which may not be permitted in some circumstances;
  • mention selling personal information, which is prohibited under POPA but may be permitted under other privacy laws;
  • mention the use of other third parties that help them provide the service (e.g. cloud providers, apps that link to the main service), which can create risks when subcontractors are part of the service.
• Does the service provider express a commitment concerning protecting the confidentiality, availability, and integrity of personal information in its custody or control? Does it provide any details as to how it does this?
• Does the service provider describe having security certifications?
• Does the service provider indicate where the personal information used in its services is processed and stored? Data stored in other jurisdictions may be subject to laws in those jurisdictions. In certain jurisdictions, access to information, including personal information, may be accessible by government or law enforcement in these jurisdictions.
• Has the service provider suffered a breach or been involved in court cases concerning its personal information processing or handling practices?

Conducting a Privacy Impact Assessment (PIA)

Before contracting with a service provider, public bodies should assess whether in contracting with a particular service provider, they will be in compliance with POPA. Completing a PIA is a useful tool to assist in assessing compliance.

POPA requires public bodies to complete PIAs in certain circumstances. The OIPC has developed a tool to help public bodies determine if they are required to prepare a PIA and if the PIA must be submitted to the OIPC for review (see POPA Privacy Impact Assessment Submission Assessment Tool). Whenever a public body submits a PIA to the OIPC, it must do so using the OIPC PIA template. Even if a PIA is not required to be prepared, when contracting with a service provider, a PIA will help a public body determine whether, in contracting the service, it will be compliance with POPA.

Completing a PIA will give public bodies confidence that when entering into a service provider relationship, they will be positioned to meet their obligations under POPA by identifying and mitigating any risks to privacy determined through the PIA process.

The public body may already have a PIA on a similar service. If so, consider reviewing that PIA to see what safeguards were put in place for the initiative. This may help with the writing of the new PIA. Be aware that PIAs are a point-in-time document and as technology evolves, the risks change too. Therefore, what was appropriate a few years ago may not be adequate today due to changes to legislation, products or services offered by service providers, technological risks, or other factors.

Complying with the Tendering Process

Depending on the size and complexity of a project, as well as the contract value, public bodies may be required to solicit proposals for services (open competition, selective tendering, limited tendering). Public bodies should Include requirements that will support POPA compliance in the Request for Proposal (RFP) and in the evaluation criteria used to choose the preferred service provider. It will be important to identify any mandatory requirements that must be met and to mitigate any risks to an acceptable level. Prepare to have individuals on the evaluation committee who have sufficient knowledge of access to information, privacy and security.

Back to top of the page

Contract

Once the public body has gathered information on the service and the service provider, the applicable privacy assessment has been completed, and the tendering process is complete if applicable, the public body will need to draft the contract for the service provider that will incorporate the requirements of POPA that the service provider will need to comply with for delivery of the service. The key areas that need to be addressed in any contract with a service provider wherein the service provider will collect, use, disclose, manage or have access to personal information are as follows.

Control and Accountability

Maintaining control means stipulating in the contract that the public body at all times retains “control” over the information that will be in the custody of the service provider for the services. This is essential to ensuring that the personal information remains subject to POPA and that the public body is able to exercise its control over how this information is used and managed by the service provider.

The contract must set out the roles and responsibilities of the parties as it relates to the personal information while in the custody of the service provider. The public body must ensure these roles and responsibilities support its ability to meet POPA requirements. There are risks to storing data outside of Canada, or with service providers from certain countries, due to other countries having laws that may permit access for government activities, such as national defence, or for law enforcement. The contract should clarify how the service provider would notify the public body of any requests it receives to produce personal information it has in its custody.

Last, the contract should specify how the public body will maintain oversight of the service provider’s duties to ensure it complies with both contractual requirements and POPA and include the right of the public body to audit for compliance.

Legal Authorities for Collection, Use or Disclosure

The contract must define what the service provider can and cannot do with the personal information. Any collection, use or disclosure the service provider carries out on behalf of the public body must be legally authorized under POPA[3]. The contract provisions must clarify what activity is authorized as it relates to the personal information and what activity is prohibited and specify measures that must be taken by the service provider to ensure downstream compliance by its employees or subcontractors. Public bodies may also decide to contractually restrict service providers’ ability to subcontract altogether. Public bodies must also ensure that the contract allows them to meet all of POPA’s requirements, including for accuracy and security (more on this below) and completion of PIAs as may be required by the public body.

Requests for Access or Correction

The contract must also address requests for access to (as set out in ATIA) or correction of personal information (as set out in POPA). If the contractor is involved in this activity (i.e., by providing access or correction services on behalf of the public body), the contract should specify this and ensure the access or correction process that the contractor must follow is laid out in the contract. Who will interact with the OIPC regarding any reviews of these requests must also be clarified in the contract. While it might seem preferable that a contractor undertake these activities, there are risks of non-compliance due to the rigor in the access and correction processes laid out in the Acts with oversight by the Commissioner. Given this, a public body should generally maintain responsibility for processing access and correction requests for personal information in the custody of a contractor. In most cases, the role of a service provider as it relates to this activity will be cooperation with the public body to facilitate the public body’s response to these requests, which should be set out in the contract as a duty of cooperation by the service provider.

Safeguards and Retention

The contract must set out the specific security requirements that the contractor must meet, which must, at minimum, align with those of the public body and the requirements in POPA and its regulations. In addition, the contract should include wording that requires the service provider to cooperate with the public body for the preparation of PIAs or STRAs, or if the public body is under investigation by a regulatory authority.

The contract must also specify what the public body expects the service provider to do whenever it experiences a breach of personal information it holds on behalf of the public body, including timelines. This helps to ensure the public body can meet its requirements concerning breaches including for notification as required by POPA and its regulations.

The contract must also establish retention periods for the information stored by the service provider and establish a process for the service provider to certify to the public body when personal information has been destroyed at the end of its retention.

Complaint Handling

The contract must also address how any complaints alleging unauthorized access, collection, use or disclosure by the contractor (or their employees or subcontractors) will be handled. For the same reason as indicated for access and correction requests, it is recommended that public bodies maintain responsibility for complaints management. Additionally, managing complaints provides insight into the personal information handling practices of the service provider and provides the public body with the opportunity to address any issues that arise through this process.

Termination

In addition to the foregoing, the contract must outline clear outcomes in the event the service provider ceases to operate or the contract terminates. Public bodies must be able to terminate the contract and retrieve the records from the service provider with assurance that no records are retained by the service provider. Additionally, the contract should address compatibility between the service provider’s system of storing personal information and that of the public body’s. This is important, since the public body must be able to import the personal information into a new information system, or to archive it as dictated by applicable retention periods. The contract must include clear expectations around data format, applicable timelines and security arrangements. This will ensure the data can be moved across different information systems with minimal integration issues and it will be readable by the public body.

For more specific details to consider in a contract, please see the Appendix – Service Provider Contract Privacy Checklist.

Back to top of the page

Oversight

The public body should develop processes that ensure their service providers are meeting the contractual obligations. The frequency of these reviews may be informed by policies of the public body, which may be part of the public body’s Privacy Management Program. When auditing a service provider to verify adherence to contract terms, the public body should have defined processes to ensure the details of the audit are clearly documented and retained and there are distinct steps on how to escalate issues of non-compliance. There may be similar processes for audits conducted on a reactive basis, such as when an incident occurs.

The OIPC may request information from a public body due to a complaint or a request for review under ATIA or POPA. The Commissioner may also conduct investigations. The public body and by extension, the service provider, may be required to provide information to the Commissioner to conduct the review or investigation. Where a service provider is involved, they will be part of the review or investigation and must cooperate. That said, as an employee of the public body, any non-compliance by a service provider with POPA is non-compliance by the public body. Investigations may result in Orders or in the event of an offence, charges and fines.

Back to top of the page

Conclusion

Public bodies collect, use and disclose personal information in order to provide public services to Albertans. When entering into a contract with a service provider, public bodies remain accountable for this information and must have appropriate policies and procedures to ensure, in the use of service providers, they will meet their obligations under POPA.

Public bodies must ensure that contracts entered into with service providers contain clauses that will ensure the service provider, and its employees or subcontractors, comply with the public body’s duties under POPA. Having an accountability framework such as a PMP with appropriate policies and procedures regarding contracting with service providers will help guide those who are part of the processes involved in retaining the services of a service provider, including for procurement, contracting and, managing contracts to ensure legal obligations are met.

This guidance is meant to support the public body in developing policies and procedures for acquiring and managing service providers that will facilitate compliance with POPA and in contracting and oversight.

We welcome any feedback concerning this guidance. Please send the same to generalinfo@oipc.ab.ca.

Appendix – Service Provider Contract Privacy Checklist

Public bodies can use this checklist whenever they seek to enter into a contract with a service provider who performs a service on behalf of the public body and in doing so has access to personal information subject to the Protection of Privacy Act:

Download the checklist here  [DOCX]  [PDF]

References

Ontario IPC Guidance: Privacy and Access in Public Sector Contracting with Third Party Service Providers

Treasury Board of Canada Secretariat Guidance Document: Taking Privacy into Account Before Making Contracting Decisions

Government of Alberta, Contractor’s Guide to the Freedom of Information and Protection of Privacy Act

Footnotes

[1] (t) “public body” means
(i) a department, branch or office of the Government of Alberta,
(ii) an agency, board, commission, corporation, office or other body designated as a public body in the regulations,
(iii) the Executive Council Office,
(iv) the office of a member of the Executive Council,
(v) the Legislative Assembly Office,
(vi) the office of the Auditor General, the Ombudsman, the Chief Electoral Officer, the Ethics Commissioner, the Information and Privacy Commissioner, the Child and Youth Advocate or the Public Interest Commissioner, or
(vii) a local public body,
but does not include
(viii) the office of the Speaker of the Legislative Assembly and the office of a Member of the Legislative Assembly, or
(ix) the Court of Appeal, the Court of King’s Bench or the Court of Justice;

The full definition of a public body can be found in the ATIA at Alberta King’s Printer.

[2] Bolded terms can be found in the Glossary.

[3] Often, service providers that provide services nationally or internationally reference legislation that does not apply to Alberta’s public sector, such as PIPEDA, the GDPR or the public sector privacy laws of other jurisdictions. These laws differ from POPA and compliance with these laws does not ensure compliance with POPA.

Back to top of the page

 

Glossary

Term	POPA Ref	Definition
Common or Integrated Program or Service	1(d)	(d) “common or integrated program or service”, in relation to a public body, means a program or service planned, administered, delivered, managed, monitored or evaluated by (i) the public body working collaboratively with one or more other public bodies, or (ii) another public body working on behalf of (A) the public body, or (B) the public body and one or more other public bodies;
Data derived from Personal Information	1(e)	“data derived from personal information” means data created by data matching, and that identifies any individual whose personal information was used in the data matching;
Employee	1(h)	“employee”, in relation to a public body, includes a person who performs a service for the public body as an appointee, volunteer or student or under a contract or agency relationship with the public body;
Head of the Public Body	1(i)	“head”, in relation to a public body, means a head as defined in the Access to Information Act
Information		for the purpose of this document, “information” is used to refer to any records in the control of the public body including personal information, data derived from personal information, non-personal information, and other business records.
Non-Personal Data	1(n)	“non personal data” means data, including data derived from personal information, that has been generated, modified or anonymized so that it does not identify any individual, and includes synthetic data and any other type of non personal data identified in the regulations;
Personal Information	1(q)	recorded information about an identifiable individual, including the individual’s name, home or business address, home or business telephone number, home or business email address, or other contact information, except where the individual has provided the information on behalf of the individual’s employer or principal in the individual’s capacity as an employee or agent, the individual’s race, national or ethnic origin, colour or religious or political beliefs or associations, the individual’s age, gender identity, sex, sexual orientation, marital status or family status, an identifying number, symbol or other particular assigned to the individual, the individual’s fingerprints, other biometric information, blood type, genetic information or inheritable characteristics, information about the individual’s health and health care history, including information about the individual’s physical or mental health, information about the individual’s educational, financial, employment or criminal history, including criminal records where a pardon has been given, anyone else’s opinions about the individual, and the individual’s personal views or opinions, except if they are about someone else;
Privacy Management Program	1(t)	“privacy management program” means a privacy management program established and implemented under section 25
Record	1(v)	“record” means a record as defined in the Access to Information Act;

April 2026

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 has developed guidance 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 doing so 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.

For more information on PMPs please see the OIPC’s Guidance for Public Bodies in Developing Privacy Management Programs.

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