Modelo de PIA pré-preenchido, alinhado com a Diretiva do TBS sobre Avaliação de Impacto na Privacidade, para departamentos do governo federal canadiano que implementam o AccessPoint
Last updated: July 12, 2026 by Steve
Avaliação de Impacto na Privacidade do GC
Esta página é um resumo público da Avaliação de Impacto na Privacidade (PIA) preparada pelo editor do software (Realizer Services Inc.) para o AccessPoint, alinhada com a Directive on Privacy Impact Assessment do Treasury Board of Canada Secretariat (TBS). Documenta os acervos de informações pessoais, os fluxos de informação, os riscos de privacidade e as salvaguardas incorporadas no produto.
A PIA do editor cobre as secções técnicas e arquiteturais, e destina-se a ajudar as instituições federais canadianas a concluir a sua própria PIA. A instituição que realiza a implantação completa os detalhes institucionais (visão geral institucional, cronogramas de retenção, acordos de partilha de informação e aprovação final) e submete a PIA concluída ao TBS e ao Office of the Privacy Commissioner (OPC). A PIA completa está disponível para os clientes mediante solicitação — consulte a nota final.
Para a arquitetura técnica completa, consulte a página de Arquitetura Técnica. Para o mapeamento de controlos de segurança ITSG-33, consulte a página de Referência de Controlos de Segurança do GC.
Objetivo e Âmbito
O AccessPoint é uma plataforma de gestão de acesso à informação e privacidade que ajuda as instituições governamentais a administrar programas de acesso e privacidade em conformidade com o Access to Information Act (ATIA), o Privacy Act e regimes provinciais/internacionais equivalentes. A sua função principal é a gestão de pedidos de acesso do titular / acesso à informação — o ciclo de vida completo, desde a receção até à atribuição, recolha de documentos, revisão, redação e preparação do pacote de resposta.
Para além da gestão de pedidos, o AccessPoint também apoia o programa de privacidade circundante: Avaliações de Impacto na Privacidade (avaliações PIA/AIA/Segurança), gestão de incidentes e violações de privacidade (incluindo fluxos de trabalho de notificação de violações), reclamações e recursos, um registo de riscos de privacidade e registo de compromissos, e registos de processamento (ROPA). Estes módulos processam categorias adicionais de informações pessoais e estão cobertos pelas mesmas salvaguardas, funções, livro-razão de auditoria e garantias de residência de dados que o núcleo de gestão de pedidos.
Processo de negócio: receção (um SAO cria o pedido) → atribuição (os custodians recebem instruções desidentificadas, sem PII do requerente) → recolha de documentos → revisão e redação → preparação do pacote de resposta → encerramento (o prazo de retenção começa a contar).
Indivíduos afetados: requerentes; funcionários da instituição (SAOs, Administrators) cujas ações são registadas no registo de auditoria; custodians e contributors (que não têm acesso ao PII do requerente); terceiros cujos DP podem constar de documentos em revisão; titulares de dados descritos ao nível de categoria no ROPA e nas avaliações; indivíduos afetados por um incidente de privacidade; reclamantes e partes na reclamação; e contactos de consulta.
Autoridade legal: a recolha e a utilização assentam principalmente no ATIA (ss.4, 6, 9, 19) e no Privacy Act (ss.4, 5, 7, 8(2)(m), e o direito de acesso do indivíduo).
Inventário de Informações Pessoais
Informações Pessoais Recolhidas e Processadas
| Elemento de Dados | Sensibilidade | Fonte | Finalidade | Armazenado Em |
|---|---|---|---|---|
| Nome completo do requerente | Média | Requerente (via receção) | Identificar o requerente, correspondência | Azure SQL |
| Endereço de email do requerente | Média | Requerente | Correspondência por email | Azure SQL |
| Morada postal do requerente | Média | Requerente | Envio postal da resposta | Azure SQL |
| Número de telefone do requerente | Baixa-Média | Requerente | Correspondência telefónica | Azure SQL |
| Organização do requerente | Baixa | Requerente | Relatórios estatísticos | Azure SQL |
| Descrição do pedido | Média | Requerente | Definir o âmbito da pesquisa | Azure SQL |
| Nome do sujeito | Média-Alta | Requerente (via receção) | Identificar o sujeito do pedido (pode diferir do requerente) | Azure SQL |
| Data de nascimento do sujeito | Alta | Requerente (via receção) | Verificação de identidade para pedidos de privacidade | Azure SQL |
| Nomes, emails e IDs de objeto Entra dos funcionários | Baixa | Entra ID | Identificação de utilizadores, notificações, autenticação, auditoria | Azure SQL |
| Registo de auditoria (ações dos utilizadores) | Baixa-Média | Gerado pelo sistema | Responsabilização, conformidade | Azure SQL |
| Documentos em revisão | Potencialmente Alta | Registos da instituição | Preparação da resposta ATIA | Azure Blob Storage |
| Versões redigidas dos documentos | Média | Gerado pelo sistema | Preparação do pacote de resposta | Azure Blob Storage |
| Registos de atestação e assinaturas eletrónicas (nome digitado) | Baixa-Média | Custodians | Aprovação formal de completude | Azure SQL |
| Endereços IP e cadeias de user agent (atestação, acesso a documentos) | Baixa-Média | Capturado pelo sistema | Auditoria forense do contexto de assinatura/acesso | Azure SQL |
| Comunicações com o requerente | Média | Pessoal SAO | Registos de correspondência (direção, método, data, notas) | Azure SQL |
| Registos de delegação | Baixa-Média | SAO/Administrator | Delegação de responsabilidade do oficial | Azure SQL |
| Registos de consulta e diretório de contactos | Baixa-Média | Pessoal SAO | Consulta interdepartamental ou externa | Azure SQL |
| Diretório de contactos do requerente | Média | Requerente / pessoal de receção | Identidade de requerente reutilizável; o pedido associa-se a um contacto em vez de armazenar PII diretamente | Azure SQL |
| Detalhes de DP afetados por incidente | Potencialmente Alta | Pessoal de Privacidade/ATIP | Factos do incidente, categorias de DP afetados, avaliação de danos, acompanhamento de notificação de violações | Azure SQL |
| Partes da reclamação e correspondência | Média | Pessoal de Privacidade/ATIP | Identidade do reclamante/parte e gestão da reclamação | Azure SQL |
| Categorias de registos de processamento (ROPA) | Baixa-Média | Pessoal de Privacidade | Descrições do Artigo 30.º do GDPR por categoria de titular de dados/destinatário — não registos individuais | Azure SQL |
| Respostas ao questionário de avaliação | Baixa-Média | Pessoal de Privacidade / delegados | Conteúdo PIA/AIA/Segurança; pode descrever DP tratados por um programa | Azure SQL |
| Registos capturados do Microsoft 365 (opcional) | Potencialmente Alta | Os próprios dados M365 do custodian | Email, calendário, OneNote, conversas do Teams ou interações do Copilot capturados pelo custodian como registo responsivo | Azure Blob Storage (PDFs convertidos) |
| Livro-razão de auditoria em cadeia de hash | Baixa-Média | Gerado pelo sistema | Livro-razão à prova de adulteração e só de inserção, de ações em todos os módulos | Azure SQL |
Informações Pessoais NÃO Recolhidas
O AccessPoint não recolhe nem processa: números de segurança social; informações financeiras (contas bancárias, cartões de crédito); registos de saúde ou médicos como dados estruturados (podem constar de documentos em revisão); dados biométricos; informações de registo criminal; dados de localização; ou cookies/identificadores de rastreamento.
Nota: os endereços IP e as cadeias de user agent são capturados apenas em contextos limitados (assinatura de atestação e registo de acesso a documentos) para fins de auditoria forense, conforme indicado acima. O comportamento geral de navegação e a impressão digital de dispositivos não são recolhidos.
Informações Pessoais Sensíveis em Documentos
Os documentos recolhidos durante o processo ATIA podem conter qualquer categoria de informações pessoais, incluindo DP sensíveis sobre terceiros. O AccessPoint não analisa nem indexa o conteúdo dos documentos — armazena-o, pré-visualiza-o e facilita a sua redação. A classificação e a isenção de DP dentro dos documentos são realizadas por SAOs qualificados, utilizando as ferramentas de revisão integradas.
Captura de registos do Microsoft 365 (opcional, controlada por comutador de funcionalidade): um custodian pode capturar os seus próprios registos do Microsoft 365 — email do Outlook, calendário do Outlook, OneNote, conversas do Teams, Microsoft Lists ou histórico de interações do Copilot — como registo responsivo. A captura utiliza sempre a identidade delegada do próprio utilizador com sessão iniciada e tem âmbito limitado aos dados desse utilizador (a obtenção de dados do Copilot é apenas de aplicação, uma vez que não existe permissão Graph delegada, mas tem sempre âmbito, do lado do servidor, limitado ao próprio ID de objeto Entra do utilizador com sessão iniciada — nunca a todo o tenant). O conteúdo capturado é convertido em PDF e entra no fluxo de trabalho normal de revisão/redação. A captura de calendário exclui, por predefinição, os itens marcados como Privado/Pessoal/Confidencial.
Análise do Fluxo de Informações Pessoais
| Etapa | Resumo |
|---|---|
| Recolha | Os DP são recolhidos ao abrigo do ATIA, art. 6 (a submissão do pedido requer nome e morada) e do Privacy Act, art. 4 (recolha relacionada com um programa operacional). Apenas os DP necessários para processar o pedido são recolhidos, diretamente do requerente e inseridos pelo pessoal SAO. Os campos são configuráveis pela instituição. |
| Utilização | Os DP do requerente são utilizados exclusivamente para processar o pedido ao abrigo do ATIA/Privacy Act. Apenas as funções Administrator, SAO e Reviewer podem visualizar o PII do requerente — Custodians e Contributors nunca o veem (aplicado do lado do servidor por middleware de filtro de PII). Não ocorre tomada de decisão automatizada, definição de perfis ou processamento algorítmico; todas as decisões são tomadas por pessoal qualificado. Os relatórios estatísticos são apenas agregados. |
| Divulgação | O pacote de resposta é fornecido ao requerente (ATIA, art. 7). A divulgação interna ao pessoal SAO/Reviewer é controlada por função; os Custodians/Contributors recebem apenas instruções desidentificadas. As notificações por email e Teams a custodians/contributors não contêm DP do requerente. O editor recebe apenas o ID do tenant (validação de licença), metadados de notificação (ID de utilizador do destinatário, tipo de atividade, nome de exibição do ator, número do pedido, texto de pré-visualização/tópico, referência ao registo relacionado) e relatórios de instalação de pacotes de configuração — sem DP do requerente. A Microsoft processa dados como subprocessador dentro do próprio tenant da instituição. |
| Retenção e eliminação | Uma funcionalidade integrada de Revisão de Retenção aplica períodos de retenção configuráveis por tipo de pedido. A purga elimina permanentemente registos de pedidos, documentos, atribuições, tarefas, atestações e histórico de auditoria, e é registada na tabela RetentionPurgeLog. As cópias de segurança automáticas do Azure SQL retêm os dados durante 7 a 35 dias, consoante o nível (retenção a longo prazo configurável). |
| Exatidão | Os DP do requerente são inseridos a partir do formulário de pedido original; os DP dos funcionários provêm do Entra ID e são atualizados a cada início de sessão. Os DP são armazenados tal como inseridos — o sistema não transforma, infere ou deriva DP adicionais. |
O percurso de notificação ilustra o controlo de "nenhum DP do requerente para o editor":
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)
Avaliação de Riscos de Privacidade
| Risco | Probabilidade | Impacto | Mitigação | Risco Residual |
|---|---|---|---|---|
| Acesso não autorizado ao PII do requerente | Baixa | Médio | RBAC de seis níveis com aplicação do lado do servidor; Custodians/Contributors excluídos arquiteturalmente do PII; MFA do Entra ID; verificações de função em cada pedido. | Baixo |
| Violação de DP por exposição de documentos | Baixa-Média | Médio-Alto | Encriptação em repouso (TDE, AES-256); autorização baseada em funções; sem acesso público a documentos; as ferramentas de redação removem os DP antes da preparação do pacote de resposta. | Baixo-Médio |
| DP em notificações | Muito Baixa | Baixo | Os modelos de Custodian/Contributor removem automaticamente o PII; as notificações SAO incluem o número do pedido, mas não a identidade do requerente; as notificações Teams contêm apenas o tipo de notificação, o número do pedido e o nome da tarefa/atribuição. | Muito Baixo |
| Transmissão de DP ao editor | Muito Baixa | Baixo | O editor recebe apenas o ID do tenant (licença) e metadados de notificação — sem DP, documentos ou detalhes de pedidos — e não tem acesso permanente aos recursos Azure da instituição. | Muito Baixo |
| DP fora da jurisdição canadiana | Dependente da configuração | Médio | Os dados são armazenados na subscrição Azure da instituição, na região que esta selecionar (recomenda-se Canada Central/East); o Microsoft Cloud Agreement aborda a residência de dados. | A avaliar pela instituição |
| Retenção/eliminação inadequada | Baixa-Média | Médio | Revisão de Retenção integrada com períodos configuráveis e registo de purgas; a instituição alinha os cronogramas com as autoridades de disposição da Library and Archives Canada. | Baixo (com configuração adequada) |
| Ameaça interna (utilização indevida por utilizador autorizado) | Baixa | Médio | Registo de auditoria abrangente com atribuição de utilizador e carimbos temporais; o acesso baseado em funções limita a exposição; os Administrators controlam as atribuições de funções. | Baixo |
Pontuações por Área de Risco
De acordo com o framework padronizado do TBS:
| Área de Risco | Pontuação | Justificação |
|---|---|---|
| Tipo de programa ou atividade | 2 | Administração de programa/atividade (administração do ATIA) |
| Tipo de informações pessoais | 3 | Informações de contacto e registos potencialmente sensíveis em documentos |
| Parceiros do programa | 2 | Microsoft (subprocessador); Realizer (sem acesso a DP) |
| Duração do programa | 4 | Obrigação legal de longo prazo/contínua |
| População do programa | 3 | Indivíduos externos que exercem direitos legais |
| Transmissão de informações pessoais | 2 | Infraestrutura cloud encriptada dentro da jurisdição canadiana |
| Tecnologia e privacidade | 2 | Aplicação web padrão — sem IA, vigilância ou biometria |
| Impacto potencial no indivíduo | 2-3 | Possível constrangimento ou dano reputacional se a identidade do requerente for divulgada |
Nível de risco global: Moderado — padrão para um programa administrativo que processa DP de indivíduos externos, mitigado por controlos técnicos fortes (encriptação, RBAC, filtragem de PII, soberania de dados).
Salvaguardas Técnicas e Administrativas
Autenticação e Controlo de Acesso
| Salvaguarda | Implementação |
|---|---|
| Autenticação | Microsoft Entra ID com tokens bearer JWT. Sem contas de utilizador ou palavras-passe locais. |
| Autenticação multifator | Aplicada pelas políticas de Conditional Access do Entra ID da instituição. |
| Continuous Access Evaluation | Suportada — a validação de tokens ocorre em cada pedido à API. |
| Controlo de acesso baseado em funções | Seis funções aplicadas do lado do servidor em todos os endpoints da API. |
| Filtragem de PII | Middleware do lado do servidor que remove os DP do requerente das respostas para as funções Custodian, Contributor e Reader; não pode ser contornado pelo cliente. |
| Gestão de sessões | Baseada em tokens; duração regida pelas políticas do Entra ID. |
| Bootstrap do primeiro utilizador | O primeiro utilizador recebe as funções Administrator e SAO. Não existem credenciais predefinidas ou partilhadas. |
Encriptação
| Camada | Implementação |
|---|---|
| Em trânsito | TLS 1.3 no mínimo na front door do App Service; TLS 1.2+ no Azure SQL e Blob Storage; FTPS desativado. |
| Em repouso — base de dados | Azure SQL Transparent Data Encryption (TDE) com chaves geridas pela Microsoft. |
| Em repouso — documentos | Encriptação AES-256 do Azure Blob Storage; chaves geridas pelo cliente (CMK) disponíveis. |
| Em repouso — segredos | Azure Key Vault, acedido via identidade gerida. |
Segurança de Rede
| Salvaguarda | Implementação |
|---|---|
| Apenas HTTPS | Todo o tráfego HTTP é rejeitado; HTTP/2 ativado. |
| CORS | Restrito ao domínio SharePoint da instituição. |
| Limitação de taxa | 600 pedidos/minuto por utilizador autenticado. |
| Cabeçalhos de segurança | X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy, Content-Security-Policy. |
| Plano de gestão | Autenticação básica SCM/FTP desativada; gestão apenas via Portal Azure com Entra ID + MFA. |
Monitorização e Auditoria
| Salvaguarda | Implementação |
|---|---|
| Registo de auditoria da aplicação | Todas as ações de criação/atualização/eliminação são registadas com ID de utilizador, carimbo temporal, campo alterado e valores antigo/novo. |
| Livro-razão de auditoria à prova de adulteração | Um livro-razão em cadeia de hash (SHA-256) e só de inserção regista ações em todos os módulos; a integridade é verificável do lado do servidor, e é possível exportar um pacote de provas pronto para tribunal relativo a um pedido. |
| Registo de acesso a documentos | Os eventos de pré-visualização e transferência são registados com ID de utilizador, carimbo temporal, endereço IP e user agent. Só de inserção. |
| Registo de purga de retenção | Todas as operações de purga são registadas com atribuição de utilizador. |
| Monitorização da aplicação | O Azure Application Insights captura pedidos HTTP, exceções e chamadas de dependência (retenção de 90 dias). |
| Regras de alerta | Alertas de métricas configuráveis para erros HTTP 5xx e latência elevada. |
| Log Analytics | Armazenamento centralizado de registos com capacidade de consulta KQL para investigações de segurança. |
Salvaguardas Administrativas
Os Administrators atribuem funções através de Definições; as alterações de função têm efeito imediato. Uma Application Access Policy restringe o Mail.Send apenas à caixa de correio partilhada designada. As alterações de configuração são aplicadas através de pacotes de configuração com controlo de versão e registo de auditoria de instalação. A formação do pessoal, a política de utilização aceitável e os procedimentos de resposta a violações são especificados pela instituição.
Serviços de Terceiros e Partilha de Dados
| Serviço | Função | DP Recebidos | Localização dos Dados |
|---|---|---|---|
| Microsoft Azure | Subprocessador (IaaS: App Service, SQL, Blob, Key Vault, Application Insights) | Todos os dados da aplicação | Região Azure da instituição |
| Microsoft 365 | Processador (Graph Mail.Send, feed de atividades Teams) e, opcionalmente, uma fonte de registos capturados pelo custodian |
Conteúdo de notificações por email/Teams; para captura opcional, o próprio conteúdo M365 desse custodian | Tenant M365 da instituição |
| Realizer Services (Editor) | Editor do software — sem função de processador para DP do cliente | Nenhum — apenas ID do tenant + metadados de notificação + relatórios de instalação de pacotes de configuração | Azure do editor (Canadá) |
| Syncfusion | Biblioteca incorporada (não é um serviço) | Nenhum — a conversão ocorre dentro do App Service da instituição | App Service da instituição |
Ponto-chave: nenhum DP do requerente, conteúdo de documento ou detalhe de pedido é transmitido à Realizer Services ou a qualquer parte externa. Todo o processamento de documentos (conversão, redação) ocorre dentro do próprio App Service da instituição.
Bancos de Informações Pessoais Aplicáveis
| PIB | Número de Registo | Descrição |
|---|---|---|
| Access to Information Act and Privacy Act Requests | PSU 901 | Registos relacionados com pedidos ATIP |
| Employee Personnel Records | PSE 901 | Nomes e funções dos funcionários no registo de auditoria |
As instituições devem confirmar os PIBs aplicáveis e se são necessários novos PIBs para a sua implantação específica.
Disponibilidade da PIA Completa
A Avaliação de Impacto na Privacidade completa — incluindo o inventário completo de informações pessoais, a análise detalhada de recolha/utilização/divulgação/retenção/exatidão, as autoridades legais e os diagramas de fluxo de dados — está disponível para clientes e potenciais clientes mediante solicitação. As instituições que realizam a implantação utilizam-na como base técnica e arquitetural para a sua própria PIA, completando a visão geral institucional, os cronogramas de retenção, os acordos de partilha de informação e a aprovação final antes de submeter ao TBS e ao Office of the Privacy Commissioner.