Pre-completed PIA template aligned with the TBS Directive on Privacy Impact Assessment for Canadian federal government departments deploying AccessPoint

Last updated: April 01, 2026 by Steve

GC Privacy Impact Assessment

This page provides a pre-completed Privacy Impact Assessment (PIA) template aligned with the Treasury Board of Canada Secretariat (TBS) Directive on Privacy Impact Assessment. It documents the personal information flows, privacy risks, and technical safeguards built into AccessPoint.

This template is intended to assist Canadian federal government departments in completing their own PIA for AccessPoint. It covers the technical and architectural sections — the deploying institution must complete the institutional details, retention schedules, and sign-off sections.

For the full technical architecture, see the Technical Architecture page. For ITSG-33 security control mapping, see the GC Security Controls Reference page.

How to Use This Document

This PIA is prepared by the software publisher (Realizer Services Inc.) to assist deploying institutions. The deploying institution must:

  • Complete the Institutional Overview with their own organizational details
  • Review and validate all sections against their specific deployment configuration
  • Add institution-specific policies (retention schedules, breach response procedures, ISAs)
  • Obtain approval from their ATIP Coordinator and Senior Official for Privacy
  • Submit the completed PIA to TBS and the Office of the Privacy Commissioner (OPC)

Program Description

Purpose

AccessPoint is a subject access request (SAR) management solution that helps government institutions process access to information and privacy requests in compliance with the Access to Information Act (ATIA) and the Privacy Act. It manages the full lifecycle of requests from intake through assignment, document collection, review, redaction, and response packaging.

Business Process

  1. Intake — A Subject Access Officer (SAO) creates a request record based on a formal ATIA or Privacy Act request
  2. Assignment — The SAO assigns custodian assignments to records holders. Custodians receive sanitized instructions without requestor PII.
  3. Document Collection — Custodians and contributors upload responsive documents from desktops, SharePoint, OneDrive, or Outlook
  4. Review and Redaction — The SAO reviews documents, classifies relevance, applies exemptions, and redacts content
  5. Response Packaging — The SAO assembles the response package (merged PDF or ZIP) with a table of contents and manifest
  6. Closure — The request is closed, the response is sent, and the retention clock begins

Individuals Affected

Class of Individuals Relationship to Program
Requestors Members of the public who submit ATIA or Privacy Act requests. Their personal information (name, address, contact details) is collected for request management and correspondence.
Institution Employees (SAOs, Administrators) Staff who process requests. Their names and actions are recorded in the audit trail. They have access to requestor PII as required by their role.
Custodians and Contributors Staff who collect and submit documents. They work from sanitized instructions and do not have access to requestor PII.
Third Parties Individuals whose personal information may appear in documents under review. This PI is managed under the exemption review process (e.g., s.19 of the ATIA).
Authority Section Relevance
Access to Information Act s.4 Right of access to government records
Access to Information Act s.6 Request submission requirements (name, address)
Access to Information Act s.9 Obligation to respond within statutory timelines
Access to Information Act s.19 Exemption for personal information
Privacy Act s.4 Authority to collect PI related to an operating program
Privacy Act s.5 Requirement to inform individuals of purpose of collection
Privacy Act s.7 Use limited to purpose of collection or consistent use
Privacy Act s.8(2)(m) Consistent use — processing requestor PI to administer ATIA requests

Personal Information Inventory

Personal Information Collected and Processed

Data Element Sensitivity Source Purpose Stored In
Requestor full name Medium Requestor (via intake) Identify requestor, correspondence Azure SQL
Requestor email address Medium Requestor Email correspondence Azure SQL
Requestor mailing address Medium Requestor Mail response delivery Azure SQL
Requestor phone number Low-Medium Requestor Telephone correspondence Azure SQL
Requestor organization Low Requestor Statistical reporting Azure SQL
Request description Medium Requestor Define scope of search Azure SQL
Employee names (all roles) Low Entra ID User identification, audit Azure SQL
Employee email addresses Low Entra ID Notifications, people picker Azure SQL
Audit trail (user actions) Low-Medium System-generated Accountability, compliance Azure SQL
Documents under review Potentially High Institution records ATIA response preparation Azure Blob Storage
Redacted document versions Medium System-generated Response packaging Azure Blob Storage
Attestation records Medium Custodians Formal sign-off on completeness Azure SQL

Personal Information NOT Collected

AccessPoint does not collect or process: Social Insurance Numbers, financial information, health records (as structured data), biometric data, criminal record information, device identifiers, IP addresses, browsing behavior, location data, or cookies/tracking identifiers.

Sensitive Personal Information in Documents

Documents collected during the ATIA process may contain any category of personal information, including sensitive PI about third parties. AccessPoint does not analyze or index document content — it stores, previews, and facilitates redaction. The classification and exemption of PI within documents is performed by trained SAOs.

Personal Information Flow Analysis

Collection

Principle Assessment
Authority PI collected under the ATIA (s.6) and the Privacy Act (s.4)
Necessity Only PI necessary to process the request is collected: requestor identity, contact information, and request details
Direct collection PI is collected directly from the requestor and entered into AccessPoint by SAO staff
Limiting collection The system does not collect PI beyond what is required. Fields are configurable by the institution.

Use

Principle Assessment
Purpose limitation Requestor PI used solely for processing the ATIA/Privacy Act request
Role-based access Only Administrator, SAO, and Reviewer roles can view requestor PII. Custodians and Contributors never see requestor PI — enforced at the API level.
No automated decision-making No AI, profiling, or algorithmic processing of PI. All decisions are made by trained staff.
Statistical reporting Reports produce aggregate statistics only — they do not expose individual requestor PI.

Disclosure

Disclosure Details
To the requestor Response package provided under ATIA s.7
Internal — SAO/Reviewer Requestor PI disclosed to authorized staff for processing. Role-controlled.
Internal — Custodians/Contributors No disclosure. Sanitized instructions only. PII stripped by server-side middleware.
Email notifications Custodian/Contributor templates do not contain requestor PI. SAO templates may include request number but not requestor identity.
Teams notifications Contain only notification type, request number, and assignment/task name. No requestor PI.
Publisher (Realizer Services) Receives only tenant ID (license validation) and notification metadata (recipient user ID, notification type, request number). No requestor PI transmitted.
Microsoft Sub-processor under the institution's Microsoft Cloud Agreement. Data processed within the institution's Azure tenant.

Retention and Disposal

Principle Assessment
Retention management Built-in Retention Review feature with configurable periods per request type
Purge mechanism Permanently deletes request records, documents, assignments, tasks, attestations, and audit history. Logged in the RetentionPurgeLog table.
Backup retention Azure SQL automated backups retain data for 7-35 days depending on tier. Configurable LTR.

Privacy Risk Assessment

Risk Likelihood Impact Mitigation Residual Risk
Unauthorized access to requestor PII Low Medium Six-tier RBAC with server-side enforcement. Custodians/Contributors architecturally excluded from PII. Entra ID MFA. Low
PI breach via document exposure Low-Medium Medium-High Encryption at rest (TDE, AES-256). Role-based authorization. Redaction tools for PI removal before response. Low-Medium
PI in notifications Very Low Low Custodian/Contributor templates auto-strip PII. Teams notifications contain only notification type and request number. Very Low
PI transmission to publisher Very Low Low Publisher receives only tenant ID and notification metadata. No PI, documents, or request details transmitted. Very Low
PI outside Canadian jurisdiction Config-dependent Medium Data stored in institution's Azure subscription in the region they select (Canada Central/East recommended). Institution to assess
Inadequate retention/disposal Low-Medium Medium Built-in Retention Review with configurable periods and purge logging. Low (with proper config)
Insider threat Low Medium Comprehensive audit trail with user attribution. Role-based access limits exposure. Low

Risk Area Scores

Per the TBS standardized framework:

Risk Area Score Rationale
Type of program or activity 2 Administration of program/activity (ATIA administration)
Type of personal information 3 Contact information and potentially sensitive records in documents
Program partners 2 Microsoft (sub-processor), Realizer (no PI access)
Duration of the program 4 Long-term/ongoing statutory obligation
Program population 3 External individuals exercising statutory rights
PI transmission 2 Encrypted cloud infrastructure within Canadian jurisdiction
Technology and privacy 2 Standard web application — no AI, surveillance, or biometrics
Potential impact on individual 2-3 Possible embarrassment or reputational harm if requestor identity disclosed

Overall risk level: Moderate — standard for an administrative program processing PI of external individuals. Mitigated by strong technical controls.

Technical and Administrative Safeguards

Authentication and Access Control

Safeguard Implementation
Authentication Microsoft Entra ID with JWT bearer tokens. No local user accounts.
Multi-factor authentication Enforced by the institution's Entra ID Conditional Access policies
Role-based access control Six roles enforced server-side on all API endpoints
PII filtering Server-side middleware strips requestor PI for Custodian, Contributor, and Reader roles
Session management Token-based, lifetime governed by Entra ID policies

Encryption

Layer Implementation
In transit TLS 1.3 minimum on all connections
At rest — database Azure SQL TDE with Microsoft-managed keys
At rest — documents Azure Blob Storage AES-256 encryption. CMK available.
At rest — secrets Azure Key Vault with managed identity access

Monitoring and Audit

Safeguard Implementation
Application audit trail All actions recorded with user ID, timestamp, field, old/new values
Retention purge log All purge operations logged with user attribution
Application monitoring Azure Application Insights — HTTP requests, exceptions, dependencies
Log Analytics Centralized log storage with KQL query for security investigations

For the complete technical architecture including network security, dependency inventory, and disaster recovery, see the Technical Architecture page.

Third-Party Services and Data Sharing

Service Role PI Received Data Location
Microsoft Azure Sub-processor (IaaS) All application data Institution's Azure region
Microsoft 365 Processor (communications) Email/Teams notification content Institution's M365 tenant
Realizer Services Publisher (no PI role) Tenant ID + notification metadata only Publisher's Azure (Canada)
Syncfusion Embedded library (not a service) None — processing occurs within App Service Institution's App Service

Key point: No requestor PI, document content, or request details are transmitted to Realizer Services or any external party. All document processing (conversion, redaction) occurs within the institution's own App Service.

Applicable Personal Information Banks

PIB Registration Number Description
Access to Information Act and Privacy Act Requests PSU 901 Records related to ATIP requests
Employee Personnel Records PSE 901 Employee names and roles in audit trail

Institutions should confirm applicable PIBs and whether new PIBs are required for their specific deployment.

Data Flow Diagrams

High-Level Architecture

Requestor                  Institution Staff              Azure Subscription
                           (SharePoint / Teams)           (Institution-controlled)
                                   │
                                   │ Entra ID JWT
                                   ▼
                          ┌────────────────────┐
                          │  SPFx Web Part /    │
                          │  Teams Personal App │
                          └────────┬───────────┘
                                   │ HTTPS (TLS 1.3)
                                   ▼
                          ┌────────────────────┐
                          │  ASP.NET Core API   │
                          │  (App Service)      │
                          │  - PII Filter MW    │
                          │  - Role Auth MW     │
                          │  - Audit Logging    │
                          └──┬──────┬──────┬───┘
                             │      │      │
                    ┌────────┘      │      └────────┐
                    ▼               ▼               ▼
            ┌──────────────┐ ┌───────────┐ ┌──────────────┐
            │  Azure SQL   │ │   Blob    │ │  Key Vault   │
            │  Database    │ │  Storage  │ │  (Secrets)   │
            │  (TDE)       │ │ (AES-256) │ │              │
            └──────────────┘ └───────────┘ └──────────────┘

Notification Data Flow

Event (e.g., assignment created)
        │
        ▼
  API Notification Service
        │
        ├── PII Filter: strips requestor PI for Custodian/Contributor templates
        │
        ├──► Email: Graph Mail.Send → Institution's shared mailbox → Recipient
        │    (via managed identity or institution's app registration)
        │
        └──► Teams: API → Realizer Platform → Graph TeamsActivity.Send → Recipient
             (sends: user ID, notification type, request number — NO requestor PI)

Document Processing Flow

User uploads document
        │
        ▼
  API stores in Azure Blob Storage (encrypted at rest)
        │
        ▼
  On preview/export: Syncfusion converts to PDF (within App Service)
        │
        ▼
  SAO applies redactions (within App Service)
        │
        ▼
  Response package generated → stored in Blob Storage → downloaded by SAO

All document processing occurs within the institution's App Service. No document content is transmitted to external services.

←
Previous GC Security Controls Reference
Next User Guide
→