An Alberta privacy impact assessment (PIA) asks for vendor details in Section G (service providers), safeguards in Section F, information flows in Section D and cloud risks in Section H2 of the Office of the Information and Privacy Commissioner's (OIPC) template. The public body completes and files the PIA; the vendor supplies the facts. This page pre-fills those fields for ATOM Signatures with only facts we can state, and marks every other field as yours to complete.
This is not legal advice. The PIA belongs to the public body, which is accountable for it under Alberta's Protection of Privacy Act (POPA). Statements about ATOM Signatures below are made by the vendor, are limited to what is listed here, and do not replace a contract. For your own assessment, consult your privacy office or a lawyer.
What vendor information does an Alberta PIA need?
On March 26, 2026, the OIPC launched a new PIA template and a completion guide that align with the requirements of the Protection of Privacy Act "and its regulations, which came into effect in 2025". It states that any public body required to submit a PIA to the OIPC under POPA must use the template. The template cites section 26 of the Act and section 7 of the Protection of Privacy (Ministerial) Regulation, and the completion guide says that sections marked with an asterisk are mandatory.
Sections A to H are mandatory, as are the cover letter and the submission checklist (Appendices D and E). A vendor's facts feed mainly four of them:
- D. Identify Personal Information Involved and your Authority to Collect, Use or Disclose the Information: the information flows, and the information flow diagram.
- F. Protection of Information: administrative, physical and technical safeguards, access control and audit logs.
- G. Service Providers: who the vendor is, what it does, and the contract.
- H. Project Risk Assessment and Mitigation, part H2 (Risks Associated with Cloud Computing).
Two details of the template matter before you ask any vendor for anything. First, its section G tells the reader that, under section 1(h) of POPA, a person who performs a service under a contract may be an "employee" of the public body, and that the public body is ultimately accountable for its employees. Second, it marks the contract as a hard requirement: "PIA submissions that do not indicate that there is a contract or agreement in place with third-party service providers will not be reviewed." The template is available from the OIPC's POPA PIA template page.
Section G: how do I describe ATOM as a service provider?
Legend: Pre-filled means a fact ATOM states. Public body means your organization completes the field. Ask ATOM means the information is not published on this page; request it from ATOM Solutions.
The template's table has four columns. Here is a pre-filled row for ATOM Signatures:
| Template column | Entry for ATOM Signatures |
|---|---|
| Name of third party | Pre-filled: ATOM Solutions (product: ATOM Signatures). |
| Relationship with the Public Body | Public body: state the relationship (the template's own example is "Service Provider"). |
| Description of services provided | Pre-filled: a Microsoft Outlook add-in and a web console that apply the organization's email signatures. It reads the Microsoft 365 directory through Microsoft Graph in application mode, read-only (User.Read.All and GroupMember.Read.All). It reads no email content and relays no email. |
| Type of agreement or contract that establishes a service provider relationship | Public body: name the agreement and attach it to the submission. |
Section G then asks six questions. The ones about the contract depend on your agreement, not on the product:
| Section G question (abridged) | Entry |
|---|---|
| 1. Does the public body use service providers that will have access to personal information or will collect, use or disclose it on its behalf? | Public body: decide, from the directory fields that your signature templates use. Whatever ATOM reads must also appear in your Section D flow diagram and legal authority table. |
| 2. Is there a contractual agreement that addresses the public body's duties under POPA and the privacy and security of personal information? | Public body, with ATOM: the agreement is the one you sign. |
| 3. Will the service provider process access to information requests on behalf of the public body? | Public body: to be completed. |
| 4. Does the agreement clarify that the public body maintains control of any information the provider accesses, collects or uses? (copy of the agreement: Attachment 10) | Public body, with ATOM: to be completed. |
| 5. Does the agreement identify each party's responsibilities for the privacy and security of personal information? | Public body, with ATOM: to be completed. |
| 6. Which sections of the agreement address ongoing training for the provider's employees who have access to personal information? | Public body, with ATOM: cite the sections of the agreement; ask ATOM about the training of its own staff. |
Section D: what flows between Microsoft 365 and ATOM?
Section D asks for a diagram and a table of information flows, with the parties, the purpose and the legal authority for each. The template says that without the diagram "the PIA will be deemed incomplete and will not be reviewed." The vendor can describe the technical path; the purpose and the legal authority are the public body's.
| Template column or item (abridged) | Entry for the directory flow |
|---|---|
| Description of the information flow | Pre-filled: ATOM reads directory information from the public body's Microsoft 365 tenant through Microsoft Graph, in application mode, read-only. Nothing is read from email content. |
| How the information flows between parties and systems | Pre-filled: Microsoft 365 (Microsoft Graph) to ATOM Signatures, over the two read-only permissions above. No email is relayed through ATOM's servers. |
| Stakeholders involved | Public body: add the administrators and users in your organization. |
| Purpose for collection, use and/or disclosure | Public body: to be completed. |
| Legal authority (cite the specific sections of POPA) | Public body: to be completed. |
| Personal information involved | Public body: list the directory fields that your own signature templates use, and no others. |
Section F: which safeguards can the vendor describe?
Section F asks the public body to describe administrative, physical and technical safeguards, and, for an electronic information system, an access-control policy (who approves and revokes access, and a table of roles and permissions) and whether the system keeps audit logs of access to personal information. The template marks the safeguards as a hard requirement.
| Template field (OIPC wording) | Entry for ATOM Signatures |
|---|---|
| "Describe the physical safeguards in place to protect the information involved in the project." | Pre-filled, on the location of the information: ATOM Signatures is hosted in Quebec. Backup copies are encrypted and kept in Toronto, Ontario. Other physical safeguards: Ask ATOM. See the privacy policy for the sub-processors that may handle information and where. |
| "Describe the technical safeguards in place to protect the information involved in the project." | Pre-filled: directory access through Microsoft Graph is read-only (User.Read.All and GroupMember.Read.All). No email content is read. Other technical safeguards, including encryption in transit and at rest: Ask ATOM. |
| "Describe the administrative safeguards in place to protect the information involved in the project." | Ask ATOM. |
| "Describe the process for approving access to personal information within the information system." and the matching process for revoking access, with the table of positions, roles and permissions | Public body for its own users; Ask ATOM for the vendor's own staff. |
| "Does the system capture and maintain audit logs of access to personal information?" and the table of audit log data elements | Ask ATOM. |
| Section E, Access, Correction, Accuracy, Retention, Disposition: "Has the public body established and implemented a record retention and disposition policy for personal information involved in this project?" | Public body for its own policy; Ask ATOM for what the vendor keeps and for how long. |
Section H2: what does the cloud risk table need from a vendor?
Part H2 lists risks specific to cloud computing, and for each the public body writes a mitigation and a policy reference. Several names come straight from the template: inadequate segregation and isolation in a multi-tenant environment, insufficient contracts, a governance structure that is not robust, lack of clarity on notifying the public body of a breach, vendor lock-in and lock-out, unauthorized access to personal information by foreign governments or states, broken authentication and authorization, and weak or missing encryption in transit and at rest.
The only facts this page states for the mitigation column are the ones above: read-only directory access, no email content read, no relay, hosting in Quebec, and encrypted backups in Toronto. For each other risk, ask ATOM for its written answer and attach it. If foreign access is a concern for your assessment, our guides on email data sovereignty and Canadian data hosting explain why where data sits and who controls the provider are two separate questions.
What does this sheet not do?
- It does not complete your PIA. The public body prepares it, signs the cover letter and answers for it.
- It does not certify compliance. It states what the product does and where it is hosted; whether that meets POPA for your project is your assessment.
- It does not replace the contract. The template says a PIA without evidence of a contract with the provider will not be reviewed.
- It does not cover your whole project. Appendices A to C, the privacy management program, retention and the public body's own risks are yours.
To see where a signature tool sits against the alternatives, compare email signature software in Canada, and read how an architecture without email routing works and what makes a signature solution Canadian.
Frequently asked questions
Who completes an Alberta PIA, the public body or the vendor?
The public body. The OIPC's template is addressed to the public body, which must use it when POPA requires it to submit a PIA to the OIPC. Section G records the vendor's role and the contract; the vendor supplies facts but does not file or sign the PIA.
What does ATOM Signatures read in our Microsoft 365 tenant?
Directory information, through Microsoft Graph in application mode and read-only, with the permissions User.Read.All and GroupMember.Read.All. ATOM reads no email content and relays no email.
Where is ATOM Signatures hosted?
In Quebec. Backup copies are encrypted and kept in Toronto, Ontario. Sub-processors that may handle information outside Quebec or Canada are listed in the privacy policy.
Does a PIA need a contract with the vendor?
According to the OIPC template, yes: if the public body engages third-party service providers, it is a hard requirement, and submissions that do not indicate that a contract or agreement is in place will not be reviewed. The template also asks for a copy of the agreement as Attachment 10.
Is this page legal advice or an OIPC document?
Neither. It is a drafting aid written by the vendor, with links to the OIPC's template and guide. This is not legal advice; the PIA and its conclusions are the public body's.
See what ATOM Signatures reads before you file. ATOM Signatures costs CA$1 per user per month, plus taxes, with a 14-day free trial.
Sources
- OIPC Alberta — new PIA template and guide under the Protection of Privacy Act, March 26, 2026: oipc.ab.ca
- OIPC Alberta — POPA PIA template (Word document, 2026): oipc.ab.ca/popa/pia/template
- OIPC Alberta — POPA PIA template completion guide: oipc.ab.ca
Template and guide consulted on November 3, 2026. ATOM Signatures facts are stated by the vendor. This is not legal advice.