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.