Modello di PIA precompilato, allineato alla Direttiva sulla valutazione d'impatto sulla privacy del TBS, per i dipartimenti del governo federale canadese che implementano AccessPoint

Last updated: July 12, 2026 by Steve

Valutazione dell'impatto sulla privacy del GC

Questa pagina è un riepilogo pubblico della valutazione d'impatto sulla privacy (PIA) predisposta dall'editore del software (Realizer Services Inc.) per AccessPoint, in conformità alla Direttiva sulla valutazione d'impatto sulla privacy del Segretariato del Consiglio del Tesoro del Canada (TBS). Documenta il patrimonio informativo di dati personali, i flussi informativi, i rischi per la privacy e le misure di salvaguardia integrate nel prodotto.

La PIA dell'editore copre le sezioni tecniche e architetturali ed è pensata per aiutare le istituzioni federali canadesi a completare la propria PIA. L'istituzione che effettua l'implementazione completa i dettagli istituzionali (panoramica istituzionale, piani di conservazione, accordi di condivisione delle informazioni e approvazione finale) e invia la PIA completata al TBS e all'Ufficio del Commissario per la privacy (OPC). La PIA completa è disponibile su richiesta per i clienti — vedere la nota finale.

Per l'architettura tecnica completa, vedere la pagina Architettura tecnica. Per la mappatura dei controlli di sicurezza ITSG-33, vedere la pagina Riferimento controlli di sicurezza GC.

Finalità e ambito di applicazione

AccessPoint è una piattaforma di gestione dell'accesso all'informazione e della privacy che aiuta le istituzioni governative ad amministrare i programmi di accesso e privacy in conformità all'Access to Information Act (ATIA), alla Privacy Act e ai regimi provinciali/internazionali equivalenti. La sua funzione principale è la gestione delle richieste di accesso ai dati personali/di accesso all'informazione — l'intero ciclo di vita, dall'acquisizione della richiesta all'assegnazione, alla raccolta dei documenti, alla revisione, alla redazione e alla predisposizione del pacchetto di risposta.

Oltre alla gestione delle richieste, AccessPoint supporta anche l'intero programma di privacy: valutazioni d'impatto sulla privacy (PIA/AIA/valutazioni di sicurezza), gestione degli incidenti e delle violazioni della privacy (compresi i flussi di lavoro per la notifica delle violazioni), reclami e ricorsi, un registro dei rischi per la privacy e un registro degli impegni, e il registro delle attività di trattamento (ROPA). Questi moduli trattano ulteriori categorie di dati personali e sono coperti dalle stesse misure di salvaguardia, dagli stessi ruoli, dal medesimo registro di audit e dalle medesime garanzie di residenza dei dati del nucleo di gestione delle richieste.

Processo operativo: acquisizione della richiesta (un SAO crea la richiesta) → assegnazione (i Custodian ricevono istruzioni sanificate prive di PII del richiedente) → raccolta dei documenti → revisione e redazione → predisposizione del pacchetto di risposta → chiusura (inizia a decorrere il termine di conservazione).

Persone interessate: i richiedenti; i dipendenti dell'istituzione (SAO, Administrator) le cui azioni sono registrate nel registro di audit; i Custodian e i Contributor (che non hanno accesso alla PII del richiedente); i terzi la cui PII può comparire nei documenti in esame; gli interessati descritti a livello di categoria nei ROPA e nelle valutazioni; le persone coinvolte in un incidente di privacy; i reclamanti e le parti del reclamo; e i contatti di consultazione.

Base giuridica: la raccolta e l'utilizzo si fondano principalmente sull'ATIA (ss.4, 6, 9, 19) e sulla Privacy Act (ss.4, 5, 7, 8(2)(m), e il diritto di accesso dell'interessato).

Inventario delle informazioni personali

Informazioni personali raccolte e trattate

Elemento di dati Sensibilità Fonte Finalità Archiviato in
Nome completo del richiedente Medio Richiedente (tramite acquisizione della richiesta) Identificazione del richiedente, corrispondenza Azure SQL
Indirizzo email del richiedente Medio Richiedente Corrispondenza via email Azure SQL
Indirizzo postale del richiedente Medio Richiedente Invio della risposta per posta Azure SQL
Numero di telefono del richiedente Basso-Medio Richiedente Corrispondenza telefonica Azure SQL
Organizzazione del richiedente Basso Richiedente Rendicontazione statistica Azure SQL
Descrizione della richiesta Medio Richiedente Definizione dell'ambito della ricerca Azure SQL
Nome del soggetto Medio-Alto Richiedente (tramite acquisizione della richiesta) Identificazione del soggetto della richiesta (può differire dal richiedente) Azure SQL
Data di nascita del soggetto Alto Richiedente (tramite acquisizione della richiesta) Verifica dell'identità per le richieste in materia di privacy Azure SQL
Nomi, email e ID oggetto Entra dei dipendenti Basso Entra ID Identificazione dell'utente, notifiche, autenticazione, audit Azure SQL
Registro di audit (azioni dell'utente) Basso-Medio Generato dal sistema Responsabilizzazione, conformità Azure SQL
Documenti in esame Potenzialmente alto Documenti dell'istituzione Predisposizione della risposta ai sensi dell'ATIA Azure Blob Storage
Versioni redatte dei documenti Medio Generato dal sistema Predisposizione del pacchetto di risposta Azure Blob Storage
Registrazioni di attestazione e firme elettroniche (nome digitato) Basso-Medio Custodian Approvazione formale della completezza Azure SQL
Indirizzi IP e stringhe user agent (attestazione, accesso ai documenti) Basso-Medio Rilevato dal sistema Audit forense del contesto di firma/accesso Azure SQL
Comunicazioni con il richiedente Medio Personale SAO Registrazioni della corrispondenza (direzione, metodo, data, note) Azure SQL
Registrazioni di delega Basso-Medio SAO/Administrator Delega di responsabilità del funzionario Azure SQL
Registrazioni delle consultazioni e rubrica dei contatti Basso-Medio Personale SAO Consultazione interdipartimentale o esterna Azure SQL
Rubrica dei contatti dei richiedenti Medio Richiedente / personale addetto all'acquisizione Identità riutilizzabile del richiedente; la richiesta si collega a un contatto anziché memorizzare la PII direttamente Azure SQL
Dettagli delle informazioni personali coinvolte nell'incidente Potenzialmente alto Personale privacy/ATIP Fatti dell'incidente, categorie di informazioni personali coinvolte, valutazione del danno, monitoraggio della notifica della violazione Azure SQL
Parti del reclamo e corrispondenza Medio Personale privacy/ATIP Identità del reclamante/della parte e gestione del reclamo Azure SQL
Categorie dei registri delle attività di trattamento (ROPA) Basso-Medio Personale privacy Descrizioni ai sensi del GDPR Article 30 per categoria di interessato/destinatario — non per singola registrazione Azure SQL
Risposte al questionario di valutazione Basso-Medio Personale privacy / delegati Contenuti PIA/AIA/di sicurezza; possono descrivere le informazioni personali trattate da un programma Azure SQL
Registrazioni acquisite da Microsoft 365 (opt-in) Potenzialmente alto I dati M365 personali del Custodian Email, calendario, OneNote, chat di Teams o interazioni Copilot acquisiti dal Custodian come documento pertinente Azure Blob Storage (PDF convertiti)
Registro di audit concatenato tramite hash Basso-Medio Generato dal sistema Registro a prova di manomissione e a sola aggiunta delle azioni in tutti i moduli Azure SQL

Informazioni personali NON raccolte

AccessPoint non raccoglie né tratta: numeri di previdenza sociale (Social Insurance Number); informazioni finanziarie (conti bancari, carte di credito); cartelle sanitarie o mediche come dati strutturati (possono comparire nei documenti in esame); dati biometrici; informazioni sui precedenti penali; dati di geolocalizzazione; o cookie/identificatori di tracciamento.

Nota: gli indirizzi IP e le stringhe user agent vengono rilevati solo in contesti limitati (firma dell'attestazione e registrazione degli accessi ai documenti) per finalità di audit forense, come indicato sopra. Il comportamento di navigazione generale e il device fingerprinting non vengono raccolti.

Informazioni personali sensibili nei documenti

I documenti raccolti durante il processo ATIA possono contenere qualsiasi categoria di informazioni personali, comprese informazioni personali sensibili relative a terzi. AccessPoint non analizza né indicizza il contenuto dei documenti: li archivia, ne consente l'anteprima e agevola la redazione. La classificazione e l'esenzione delle informazioni personali all'interno dei documenti sono effettuate da SAO formati, utilizzando gli strumenti di revisione integrati.

Acquisizione di registrazioni Microsoft 365 (opt-in, subordinata a un feature toggle): un Custodian può acquisire le proprie registrazioni Microsoft 365 — email di Outlook, calendario di Outlook, OneNote, chat di Teams, Microsoft Lists o cronologia delle interazioni Copilot — come documento pertinente. L'acquisizione utilizza sempre l'identità delegata dell'utente che ha effettuato l'accesso ed è limitata ai dati personali di tale utente (il recupero da Copilot avviene in modalità solo app, poiché non esiste un permesso Graph delegato, ma è sempre limitato lato server all'ID oggetto Entra dell'utente che ha effettuato l'accesso — mai esteso all'intero tenant). Il contenuto acquisito viene convertito in PDF ed entra nel normale flusso di revisione/redazione. L'acquisizione del calendario esclude per impostazione predefinita gli elementi contrassegnati come Privato/Personale/Riservato.

Analisi del flusso delle informazioni personali

Fase Sintesi
Raccolta Le informazioni personali sono raccolte ai sensi dell'ATIA s.6 (la presentazione della richiesta richiede nome e indirizzo) e della Privacy Act s.4 (raccolta connessa a un programma operativo). Vengono raccolte solo le informazioni personali necessarie per elaborare la richiesta, direttamente dal richiedente e inserite dal personale SAO. I campi sono configurabili dall'istituzione.
Utilizzo La PII del richiedente è utilizzata esclusivamente per elaborare la richiesta ai sensi dell'ATIA/Privacy Act. Solo i ruoli Administrator, SAO e Reviewer possono visualizzare la PII del richiedente — Custodian e Contributor non la vedono mai (applicato lato server dal middleware di filtro PII). Non avviene alcun processo decisionale automatizzato, profilazione o elaborazione algoritmica; tutte le decisioni sono prese da personale formato. I report statistici sono solo aggregati.
Comunicazione Il pacchetto di risposta viene fornito al richiedente (ATIA s.7). La comunicazione interna al personale SAO/Reviewer è controllata in base al ruolo; i Custodian/Contributor ricevono solo istruzioni sanificate. Le notifiche via email e Teams a Custodian/Contributor non contengono alcuna PII del richiedente. L'editore riceve solo l'ID del tenant (convalida della licenza), i metadati delle notifiche (ID utente destinatario, tipo di attività, nome visualizzato dell'autore, numero della richiesta, testo di anteprima/oggetto, riferimento al record correlato) e i report di installazione dei pacchetti di configurazione — nessuna PII del richiedente. Microsoft tratta i dati come sub-responsabile del trattamento all'interno del tenant dell'istituzione.
Conservazione e smaltimento Una funzionalità integrata di revisione della conservazione applica periodi di conservazione configurabili per ciascun tipo di richiesta. L'eliminazione definitiva rimuove in modo permanente le registrazioni delle richieste, i documenti, le assegnazioni, i compiti, le attestazioni e la cronologia di audit, ed è registrata nella tabella RetentionPurgeLog. I backup automatici di Azure SQL conservano i dati per 7-35 giorni a seconda del livello (conservazione a lungo termine configurabile).
Accuratezza La PII del richiedente viene inserita a partire dal modulo di richiesta originale; la PII dei dipendenti proviene da Entra ID e viene aggiornata a ogni accesso. La PII viene memorizzata così come inserita: il sistema non trasforma, deduce o deriva ulteriore PII.

Il percorso delle notifiche illustra il controllo "nessuna PII del richiedente trasmessa all'editore":

Event (e.g., assignment created)
        │
        ▼
  API Notification Dispatch 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 API → Graph TeamsActivity.Send → Recipient
             (sends: user ID, activity type, actor name, request number, preview text — NO requestor PI)

Valutazione dei rischi per la privacy

Rischio Probabilità Impatto Mitigazione Rischio residuo
Accesso non autorizzato alla PII del richiedente Basso Medio RBAC a sei livelli con applicazione lato server; Custodian/Contributor esclusi a livello architetturale dalla PII; MFA di Entra ID; verifica dei ruoli a ogni richiesta. Basso
Violazione della PII tramite esposizione di documenti Basso-Medio Medio-Alto Crittografia dei dati inattivi (TDE, AES-256); autorizzazione basata sui ruoli; nessun accesso pubblico ai documenti; gli strumenti di redazione rimuovono la PII prima della predisposizione del pacchetto di risposta. Basso-Medio
PII nelle notifiche Molto basso Basso I modelli per Custodian/Contributor rimuovono automaticamente la PII; le notifiche ai SAO includono il numero della richiesta ma non l'identità del richiedente; le notifiche Teams riportano solo il tipo di notifica, il numero della richiesta e il nome del compito/assegnazione. Molto basso
Trasmissione di PII all'editore Molto basso Basso L'editore riceve solo l'ID del tenant (licenza) e i metadati delle notifiche — nessuna PII, documento o dettaglio della richiesta — e non dispone di accesso permanente alle risorse Azure dell'istituzione. Molto basso
PII al di fuori della giurisdizione canadese Dipende dalla configurazione Medio I dati sono archiviati nell'abbonamento Azure dell'istituzione, nella regione selezionata (si raccomandano Canada Central/East); il Microsoft Cloud Agreement disciplina la residenza dei dati. Da valutare a cura dell'istituzione
Conservazione/smaltimento inadeguati Basso-Medio Medio Revisione della conservazione integrata con periodi configurabili e registrazione delle eliminazioni; l'istituzione allinea i piani agli orientamenti in materia di scarto di Library and Archives Canada (Biblioteca e Archivi del Canada). Basso (con una configurazione adeguata)
Minaccia interna (uso improprio da parte di utenti autorizzati) Basso Medio Registro di audit completo con attribuzione dell'utente e marche temporali; l'accesso basato sui ruoli limita l'esposizione; gli Administrator controllano le assegnazioni dei ruoli. Basso

Punteggi per area di rischio

Secondo il quadro standardizzato del TBS:

Area di rischio Punteggio Motivazione
Tipo di programma o attività 2 Amministrazione di programma/attività (amministrazione ATIA)
Tipo di informazioni personali 3 Informazioni di contatto e registrazioni potenzialmente sensibili nei documenti
Partner del programma 2 Microsoft (sub-responsabile del trattamento); Realizer (nessun accesso alla PII)
Durata del programma 4 Obbligo di legge a lungo termine/continuativo
Popolazione del programma 3 Persone esterne che esercitano diritti di legge
Trasmissione delle informazioni personali 2 Infrastruttura cloud crittografata all'interno della giurisdizione canadese
Tecnologia e privacy 2 Applicazione web standard — nessuna IA, sorveglianza o dato biometrico
Potenziale impatto sull'interessato 2-3 Possibile imbarazzo o danno reputazionale in caso di divulgazione dell'identità del richiedente

Livello di rischio complessivo: Moderato — standard per un programma amministrativo che tratta informazioni personali di persone esterne, mitigato da solidi controlli tecnici (crittografia, RBAC, filtro PII, sovranità dei dati).

Misure di salvaguardia tecniche e amministrative

Autenticazione e controllo degli accessi

Misura di salvaguardia Implementazione
Autenticazione Microsoft Entra ID con token JWT bearer. Nessun account utente locale o password.
Autenticazione a più fattori Applicata dai criteri di accesso condizionale di Entra ID dell'istituzione.
Valutazione dell'accesso continuo Supportata — la convalida del token avviene a ogni richiesta API.
Controllo degli accessi basato sui ruoli Sei ruoli applicati lato server su tutti gli endpoint API.
Filtro PII Un middleware lato server rimuove la PII del richiedente dalle risposte per i ruoli Custodian, Contributor e Reader; non può essere aggirato dal client.
Gestione delle sessioni Basata su token; la durata è disciplinata dai criteri di Entra ID.
Bootstrap del primo utente Al primo utente vengono assegnati i ruoli Administrator e SAO. Non esistono credenziali predefinite o condivise.

Crittografia

Livello Implementazione
In transito TLS 1.3 minimo al punto di ingresso di App Service; TLS 1.2+ su Azure SQL e Blob Storage; FTPS disabilitato.
A riposo — database Transparent Data Encryption (TDE) di Azure SQL con chiavi gestite da Microsoft.
A riposo — documenti Crittografia AES-256 di Azure Blob Storage; disponibili chiavi gestite dal cliente (CMK).
A riposo — segreti Azure Key Vault, con accesso tramite identità gestita.

Sicurezza di rete

Misura di salvaguardia Implementazione
Solo HTTPS Tutto il traffico HTTP viene rifiutato; HTTP/2 abilitato.
CORS Limitato al dominio SharePoint dell'istituzione.
Limitazione della velocità 600 richieste al minuto per utente autenticato.
Intestazioni di sicurezza X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy, Content-Security-Policy.
Piano di gestione Autenticazione di base SCM/FTP disabilitata; gestione tramite Portale Azure solo con Entra ID + MFA.

Monitoraggio e audit

Misura di salvaguardia Implementazione
Registro di audit dell'applicazione Tutte le azioni di creazione/modifica/eliminazione vengono registrate con ID utente, marca temporale, campo modificato e valori precedenti/nuovi.
Registro di audit a prova di manomissione Un registro concatenato tramite hash (SHA-256) e a sola aggiunta registra le azioni in tutti i moduli; l'integrità è verificabile lato server ed è possibile esportare, per una richiesta, un pacchetto di prove idoneo in sede giudiziaria.
Registro degli accessi ai documenti Gli eventi di anteprima e download vengono registrati con ID utente, marca temporale, indirizzo IP e user agent. Solo inserimento.
Registro delle eliminazioni per conservazione Tutte le operazioni di eliminazione definitiva vengono registrate con attribuzione all'utente.
Monitoraggio dell'applicazione Azure Application Insights rileva le richieste HTTP, le eccezioni e le chiamate alle dipendenze (conservazione di 90 giorni).
Regole di avviso Avvisi sulle metriche configurabili per errori HTTP 5xx e latenza elevata.
Log Analytics Archiviazione centralizzata dei log con possibilità di query KQL per le indagini di sicurezza.

Misure di salvaguardia amministrative

Gli Administrator assegnano i ruoli tramite Impostazioni; le modifiche ai ruoli hanno effetto immediato. Un criterio di accesso alle applicazioni limita Mail.Send esclusivamente alla cassetta postale condivisa designata. Le modifiche alla configurazione vengono applicate tramite pacchetti di configurazione versionati, con registrazione di audit delle installazioni. La formazione del personale, la politica di utilizzo accettabile e le procedure di risposta alle violazioni sono definite dall'istituzione.

Servizi di terze parti e condivisione dei dati

Servizio Ruolo PII ricevuta Ubicazione dei dati
Microsoft Azure Sub-responsabile del trattamento (IaaS: App Service, SQL, Blob, Key Vault, Application Insights) Tutti i dati dell'applicazione Regione Azure dell'istituzione
Microsoft 365 Responsabile del trattamento (Graph Mail.Send, feed di attività di Teams) e, facoltativamente, fonte di registrazioni acquisite dal Custodian Contenuto delle notifiche email/Teams; per l'acquisizione opt-in, i contenuti M365 personali di tale Custodian Tenant M365 dell'istituzione
Realizer Services (Editore) Editore del software — nessun ruolo di responsabile del trattamento per la PII dei clienti Nessuno — solo ID del tenant + metadati delle notifiche + report di installazione dei pacchetti di configurazione Azure dell'editore (Canada)
Syncfusion Libreria integrata (non un servizio) Nessuno — la conversione avviene all'interno dell'App Service dell'istituzione App Service dell'istituzione

Punto chiave: nessuna PII del richiedente, contenuto di documenti o dettaglio della richiesta viene trasmesso a Realizer Services o a terzi. Tutto il trattamento dei documenti (conversione, redazione) avviene all'interno dell'App Service dell'istituzione stessa.

Banche di dati personali (PIB) applicabili

PIB Numero di registrazione Descrizione
Access to Information Act and Privacy Act Requests PSU 901 Documenti relativi alle richieste ATIP
Employee Personnel Records PSE 901 Nomi e ruoli dei dipendenti nel registro di audit

Le istituzioni dovrebbero verificare quali PIB siano applicabili e se per la propria implementazione specifica siano necessari nuovi PIB.

Disponibilità della PIA completa

La valutazione d'impatto sulla privacy completa — comprensiva dell'inventario completo delle informazioni personali, dell'analisi dettagliata di raccolta/utilizzo/comunicazione/conservazione/accuratezza, delle basi giuridiche e dei diagrammi di flusso dei dati — è disponibile su richiesta per i clienti e i potenziali clienti. Le istituzioni che effettuano l'implementazione la utilizzano come base tecnica e architetturale per la propria PIA, completando la panoramica istituzionale, i piani di conservazione, gli accordi di condivisione delle informazioni e l'approvazione finale, prima dell'invio al TBS e all'Ufficio del Commissario per la privacy.