Plantilla de PIA precompletada alineada con la Directiva del TBS sobre la Evaluación de Impacto en la Privacidad para los departamentos del gobierno federal canadiense que implementan AccessPoint
Last updated: July 12, 2026 by Steve
Evaluación de Impacto en la Privacidad de GC
Esta página es un resumen público de la Evaluación de Impacto en la Privacidad (PIA) preparada por el editor del software (Realizer Services Inc.) para AccessPoint, alineada con la Directiva sobre la Evaluación de Impacto en la Privacidad de la Secretaría del Consejo del Tesoro de Canadá (TBS). Documenta los conjuntos de información personal, los flujos de información, los riesgos de privacidad y las salvaguardas incorporadas en el producto.
La PIA del editor cubre las secciones técnicas y de arquitectura, y está pensada para ayudar a las instituciones federales canadienses a completar su propia PIA. La institución que realiza la implementación completa los detalles institucionales (descripción general institucional, calendarios de retención, acuerdos de intercambio de información y aprobación final) y presenta la PIA completa al TBS y a la Oficina del Comisionado de Privacidad (OPC). La PIA completa está disponible para los clientes que la soliciten; consulte la nota final.
Para conocer la arquitectura técnica completa, consulte la página Arquitectura técnica. Para la asignación de controles de seguridad ITSG-33, consulte la página Referencia de controles de seguridad de GC.
Propósito y alcance
AccessPoint es una plataforma de gestión de acceso a la información y privacidad que ayuda a las instituciones gubernamentales a administrar programas de acceso y privacidad en cumplimiento con la Access to Information Act (ATIA), la Privacy Act y regímenes provinciales/internacionales equivalentes. Su función principal es la gestión de solicitudes de acceso del interesado / acceso a la información: el ciclo de vida completo, desde la recepción hasta la asignación, la recopilación de documentos, la revisión, la redacción y el empaquetado de la respuesta.
Más allá de la gestión de solicitudes, AccessPoint también respalda el programa de privacidad en su conjunto: Evaluaciones de Impacto en la Privacidad (evaluaciones PIA/AIA/de seguridad), gestión de incidentes y vulneraciones de privacidad (incluidos los flujos de trabajo de notificación de vulneraciones), quejas y apelaciones, un registro de riesgos de privacidad y un registro de compromisos, y registros de actividades de tratamiento (ROPA). Estos módulos procesan categorías adicionales de información personal y están cubiertos por las mismas salvaguardas, roles, libro mayor de auditoría y garantías de residencia de datos que el núcleo de gestión de solicitudes.
Proceso operativo: recepción (un SAO crea la solicitud) → asignación (los custodios reciben instrucciones depuradas sin información personal del solicitante) → recopilación de documentos → revisión y redacción → empaquetado de la respuesta → cierre (comienza el plazo de retención).
Personas afectadas: solicitantes; empleados de la institución (SAO, administradores) cuyas acciones quedan registradas en el registro de auditoría; custodios y colaboradores (que no tienen acceso a la información personal del solicitante); terceros cuya información personal pueda aparecer en los documentos en revisión; interesados descritos a nivel de categoría en el ROPA y en las evaluaciones; personas afectadas por un incidente de privacidad; reclamantes y partes de la queja; y contactos de consulta.
Fundamento jurídico: la recopilación y el uso se basan principalmente en la ATIA (arts. 4, 6, 9, 19) y en la Privacy Act (arts. 4, 5, 7, 8(2)(m), y el derecho de acceso del individuo).
Inventario de información personal
Información personal recopilada y procesada
| Elemento de datos | Sensibilidad | Origen | Finalidad | Almacenado en |
|---|---|---|---|---|
| Nombre completo del solicitante | Media | Solicitante (mediante recepción) | Identificar al solicitante, correspondencia | Azure SQL |
| Dirección de correo electrónico del solicitante | Media | Solicitante | Correspondencia por correo electrónico | Azure SQL |
| Dirección postal del solicitante | Media | Solicitante | Entrega de la respuesta por correo | Azure SQL |
| Número de teléfono del solicitante | Baja-Media | Solicitante | Correspondencia telefónica | Azure SQL |
| Organización del solicitante | Baja | Solicitante | Informes estadísticos | Azure SQL |
| Descripción de la solicitud | Media | Solicitante | Definir el alcance de la búsqueda | Azure SQL |
| Nombre del interesado | Media-Alta | Solicitante (mediante recepción) | Identificar al interesado de la solicitud (puede diferir del solicitante) | Azure SQL |
| Fecha de nacimiento del interesado | Alta | Solicitante (mediante recepción) | Verificación de identidad para solicitudes de privacidad | Azure SQL |
| Nombres, correos electrónicos e ID de objeto de Entra de empleados | Baja | Entra ID | Identificación de usuarios, notificaciones, autenticación, auditoría | Azure SQL |
| Registro de auditoría (acciones de usuarios) | Baja-Media | Generado por el sistema | Rendición de cuentas, cumplimiento | Azure SQL |
| Documentos en revisión | Potencialmente alta | Registros de la institución | Preparación de la respuesta según la ATIA | Azure Blob Storage |
| Versiones redactadas de documentos | Media | Generado por el sistema | Empaquetado de la respuesta | Azure Blob Storage |
| Registros de certificación y firmas electrónicas (nombre escrito) | Baja-Media | Custodios | Aprobación formal de integridad | Azure SQL |
| Direcciones IP y cadenas de user agent (certificación, acceso a documentos) | Baja-Media | Capturado por el sistema | Auditoría forense del contexto de firma/acceso | Azure SQL |
| Comunicaciones con el solicitante | Media | Personal del SAO | Registros de correspondencia (dirección, método, fecha, notas) | Azure SQL |
| Registros de delegación | Baja-Media | SAO/Administrador | Delegación de responsabilidad del funcionario | Azure SQL |
| Registros de consulta y directorio de contactos | Baja-Media | Personal del SAO | Consulta interdepartamental o externa | Azure SQL |
| Directorio de contactos del solicitante | Media | Solicitante / personal de recepción | Identidad reutilizable del solicitante; la solicitud se vincula a un contacto en lugar de almacenar la información personal en línea | Azure SQL |
| Detalles de la información personal afectada por un incidente | Potencialmente alta | Personal de privacidad/ATIP | Hechos del incidente, categorías de información personal afectada, evaluación de daños, seguimiento de la notificación de vulneraciones | Azure SQL |
| Partes de la queja y correspondencia | Media | Personal de privacidad/ATIP | Identidad del reclamante/parte y gestión de la queja | Azure SQL |
| Categorías de registros de actividades de tratamiento (ROPA) | Baja-Media | Personal de privacidad | Descripciones del artículo 30 del GDPR por categoría de interesado/destinatario, no por registro individual | Azure SQL |
| Respuestas del cuestionario de evaluación | Baja-Media | Personal de privacidad / delegados | Contenido de la PIA/AIA/evaluación de seguridad; puede describir información personal gestionada por un programa | Azure SQL |
| Registros capturados de Microsoft 365 (opcional) | Potencialmente alta | Los propios datos de M365 del custodio | Correo electrónico, calendario, OneNote, chats de Teams o interacciones con Copilot capturados por el custodio como registro pertinente | Azure Blob Storage (PDF convertidos) |
| Libro mayor de auditoría encadenado por hash | Baja-Media | Generado por el sistema | Libro mayor de solo adición, a prueba de alteraciones, de las acciones en todos los módulos | Azure SQL |
Información personal NO recopilada
AccessPoint no recopila ni procesa: números de seguro social; información financiera (cuentas bancarias, tarjetas de crédito); registros de salud o médicos como datos estructurados (pueden aparecer en documentos en revisión); datos biométricos; información de antecedentes penales; datos de ubicación; ni cookies o identificadores de seguimiento.
Nota: las direcciones IP y las cadenas de user agent se capturan únicamente en contextos limitados (firma de certificaciones y registro de acceso a documentos) con fines de auditoría forense, como se indica arriba. No se recopila el comportamiento general de navegación ni la huella digital del dispositivo.
Información personal sensible en documentos
Los documentos recopilados durante el proceso de la ATIA pueden contener cualquier categoría de información personal, incluida información personal sensible sobre terceros. AccessPoint no analiza ni indiza el contenido de los documentos: los almacena, permite obtener una vista previa y facilita la redacción. La clasificación y las exenciones de la información personal dentro de los documentos las realiza personal del SAO capacitado mediante las herramientas de revisión integradas.
Captura de registros de Microsoft 365 (opcional, controlada por un conmutador de funciones): un custodio puede capturar sus propios registros de Microsoft 365 (correo electrónico de Outlook, calendario de Outlook, OneNote, chats de Teams, Microsoft Lists o historial de interacciones con Copilot) como registro pertinente. La captura siempre utiliza la identidad delegada propia del usuario que inició sesión y se limita a los datos propios de ese usuario (la recuperación de Copilot es solo de aplicación, ya que no existe un permiso delegado de Graph para ello, pero siempre se limita, del lado del servidor, al ID de objeto de Entra propio del usuario que inició sesión, nunca a todo el inquilino). El contenido capturado se convierte a PDF e ingresa al flujo de trabajo normal de revisión/redacción. La captura de calendario excluye, de forma predeterminada, los elementos marcados como Privado/Personal/Confidencial.
Análisis del flujo de información personal
| Etapa | Resumen |
|---|---|
| Recopilación | La información personal se recopila conforme al art. 6 de la ATIA (la presentación de la solicitud requiere nombre y dirección) y al art. 4 de la Privacy Act (recopilación relacionada con un programa operativo). Solo se recopila la información personal necesaria para procesar la solicitud, directamente del solicitante e ingresada por el personal del SAO. Los campos son configurables por la institución. |
| Uso | La información personal del solicitante se utiliza únicamente para procesar la solicitud conforme a la ATIA/Privacy Act. Solo los roles de Administrador, SAO y Revisor pueden ver la información personal del solicitante: los custodios y colaboradores nunca la ven (aplicado del lado del servidor mediante middleware de filtrado de información personal). No se produce toma de decisiones automatizada, elaboración de perfiles ni procesamiento algorítmico; todas las decisiones las toma personal capacitado. Los informes estadísticos son únicamente agregados. |
| Divulgación | El paquete de respuesta se entrega al solicitante (art. 7 de la ATIA). La divulgación interna al personal del SAO/Revisor está controlada por roles; los custodios/colaboradores reciben únicamente instrucciones depuradas. Las notificaciones por correo electrónico y Teams a custodios/colaboradores no contienen información personal del solicitante. El editor recibe únicamente el ID del inquilino (validación de licencia), metadatos de notificación (ID de usuario destinatario, tipo de actividad, nombre visible del actor, número de solicitud, texto de vista previa/tema, referencia del registro relacionado) e informes de instalación de paquetes de configuración; ninguna información personal del solicitante. Microsoft procesa los datos como subencargado dentro del propio inquilino de la institución. |
| Retención y eliminación | Una función integrada de Revisión de retención aplica períodos de retención configurables según el tipo de solicitud. La depuración elimina de forma permanente los registros de solicitudes, documentos, asignaciones, tareas, certificaciones e historial de auditoría, y queda registrada en la tabla RetentionPurgeLog. Las copias de seguridad automatizadas de Azure SQL conservan los datos entre 7 y 35 días, según el nivel (retención a largo plazo configurable). |
| Exactitud | La información personal del solicitante se ingresa a partir del formulario de solicitud original; la información personal de los empleados proviene de Entra ID y se actualiza en cada inicio de sesión. La información personal se almacena tal como se ingresa; el sistema no transforma, infiere ni deriva información personal adicional. |
La ruta de notificación ilustra el control de "ninguna información personal del solicitante para el 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)
Evaluación de riesgos de privacidad
| Riesgo | Probabilidad | Impacto | Mitigación | Riesgo residual |
|---|---|---|---|---|
| Acceso no autorizado a la información personal del solicitante | Baja | Media | RBAC de seis niveles con aplicación del lado del servidor; los custodios/colaboradores quedan excluidos arquitectónicamente de la información personal; MFA de Entra ID; verificaciones de rol en cada solicitud. | Baja |
| Vulneración de información personal mediante exposición de documentos | Baja-Media | Media-Alta | Cifrado en reposo (TDE, AES-256); autorización basada en roles; sin acceso público a documentos; las herramientas de redacción eliminan la información personal antes del empaquetado de la respuesta. | Baja-Media |
| Información personal en notificaciones | Muy baja | Baja | Las plantillas de custodios/colaboradores eliminan automáticamente la información personal; las notificaciones al SAO incluyen el número de solicitud, pero no la identidad del solicitante; las notificaciones de Teams contienen solo el tipo de notificación, el número de solicitud y el nombre de la tarea/asignación. | Muy baja |
| Transmisión de información personal al editor | Muy baja | Baja | El editor recibe únicamente el ID del inquilino (licencia) y metadatos de notificación, sin información personal, documentos ni detalles de la solicitud, y no tiene acceso permanente a los recursos de Azure de la institución. | Muy baja |
| Información personal fuera de la jurisdicción canadiense | Depende de la configuración | Media | Los datos se almacenan en la suscripción de Azure de la institución, en la región que esta seleccione (se recomienda Canada Central/East); el Microsoft Cloud Agreement aborda la residencia de datos. | A evaluar por la institución |
| Retención/eliminación inadecuada | Baja-Media | Media | Revisión de retención integrada con períodos configurables y registro de depuración; la institución alinea los calendarios con las autoridades de disposición de Library and Archives Canada. | Baja (con la configuración adecuada) |
| Amenaza interna (uso indebido por parte de un usuario autorizado) | Baja | Media | Registro de auditoría integral con atribución de usuario y marcas de tiempo; el acceso basado en roles limita la exposición; los administradores controlan la asignación de roles. | Baja |
Puntuaciones por área de riesgo
Según el marco estandarizado del TBS:
| Área de riesgo | Puntuación | Justificación |
|---|---|---|
| Tipo de programa o actividad | 2 | Administración de un programa/actividad (administración de la ATIA) |
| Tipo de información personal | 3 | Información de contacto y registros potencialmente sensibles en los documentos |
| Socios del programa | 2 | Microsoft (subencargado); Realizer (sin acceso a información personal) |
| Duración del programa | 4 | Obligación estatutaria continua/a largo plazo |
| Población del programa | 3 | Personas externas que ejercen derechos estatutarios |
| Transmisión de información personal | 2 | Infraestructura en la nube cifrada dentro de la jurisdicción canadiense |
| Tecnología y privacidad | 2 | Aplicación web estándar, sin IA, vigilancia ni biometría |
| Impacto potencial sobre la persona | 2-3 | Posible vergüenza o daño a la reputación si se divulga la identidad del solicitante |
Nivel de riesgo general: moderado. Es el nivel estándar para un programa administrativo que procesa información personal de personas externas, mitigado por controles técnicos sólidos (cifrado, RBAC, filtrado de información personal, soberanía de datos).
Salvaguardas técnicas y administrativas
Autenticación y control de acceso
| Salvaguarda | Implementación |
|---|---|
| Autenticación | Microsoft Entra ID con tokens portadores JWT. Sin cuentas de usuario ni contraseñas locales. |
| Autenticación multifactor | Aplicada mediante las políticas de acceso condicional de Entra ID de la institución. |
| Evaluación continua de acceso | Compatible; la validación del token se realiza en cada solicitud a la API. |
| Control de acceso basado en roles | Seis roles aplicados del lado del servidor en todos los puntos de conexión de la API. |
| Filtrado de información personal | Un middleware del lado del servidor elimina los campos de información personal del solicitante de las respuestas para los roles de Custodio, Colaborador y Lector; el cliente no puede eludirlo. |
| Gestión de sesiones | Basada en tokens; la duración la rige la política de Entra ID. |
| Configuración inicial del primer usuario | Al primer usuario se le otorgan los roles de Administrador y SAO. No existen credenciales predeterminadas ni compartidas. |
Cifrado
| Capa | Implementación |
|---|---|
| En tránsito | TLS 1.3 como mínimo en la puerta de enlace del App Service; TLS 1.2+ en Azure SQL y Blob Storage; FTPS deshabilitado. |
| En reposo — base de datos | Cifrado transparente de datos (TDE) de Azure SQL con claves administradas por Microsoft. |
| En reposo — documentos | Cifrado AES-256 de Azure Blob Storage; claves administradas por el cliente (CMK) disponibles. |
| En reposo — secretos | Azure Key Vault, con acceso mediante identidad administrada. |
Seguridad de red
| Salvaguarda | Implementación |
|---|---|
| Solo HTTPS | Se rechaza todo el tráfico HTTP; HTTP/2 habilitado. |
| CORS | Restringido al dominio de SharePoint de la institución. |
| Limitación de velocidad | 600 solicitudes por minuto por usuario autenticado. |
| Encabezados de seguridad | X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy, Content-Security-Policy. |
| Plano de administración | Autenticación básica de SCM/FTP deshabilitada; administración mediante Azure Portal solo con Entra ID + MFA. |
Monitoreo y auditoría
| Salvaguarda | Implementación |
|---|---|
| Registro de auditoría de la aplicación | Todas las acciones de creación/actualización/eliminación se registran con el ID de usuario, la marca de tiempo, el campo modificado y los valores anteriores/nuevos. |
| Libro mayor de auditoría a prueba de alteraciones | Un libro mayor de solo adición, encadenado por hash (SHA-256), registra las acciones en todos los módulos; la integridad se puede verificar del lado del servidor y se puede exportar un paquete de evidencia listo para uso judicial ante una solicitud. |
| Registro de acceso a documentos | Los eventos de vista previa y descarga se registran con el ID de usuario, la marca de tiempo, la dirección IP y el user agent. Solo inserción. |
| Registro de depuración de retención | Todas las operaciones de depuración se registran con atribución de usuario. |
| Monitoreo de la aplicación | Azure Application Insights captura solicitudes HTTP, excepciones y llamadas de dependencia (retención de 90 días). |
| Reglas de alertas | Alertas de métricas configurables para errores HTTP 5xx y latencia alta. |
| Log Analytics | Almacenamiento centralizado de registros con capacidad de consulta KQL para investigaciones de seguridad. |
Salvaguardas administrativas
Los administradores asignan roles a través de Configuración; los cambios de rol surten efecto de inmediato. Una política de acceso de aplicaciones restringe Mail.Send únicamente al buzón compartido designado. Los cambios de configuración se aplican mediante paquetes de configuración con versión y registro de auditoría de instalación. La capacitación del personal, la política de uso aceptable y los procedimientos de respuesta a vulneraciones los define la institución.
Servicios de terceros e intercambio de datos
| Servicio | Rol | Información personal recibida | Ubicación de los datos |
|---|---|---|---|
| Microsoft Azure | Subencargado (IaaS: App Service, SQL, Blob, Key Vault, Application Insights) | Todos los datos de la aplicación | Región de Azure de la institución |
| Microsoft 365 | Encargado (Graph Mail.Send, fuente de actividad de Teams) y, opcionalmente, fuente de registros capturados por el custodio |
Contenido de notificaciones por correo electrónico/Teams; para la captura opcional, el propio contenido de M365 de ese custodio | Inquilino de M365 de la institución |
| Realizer Services (editor) | Editor del software; sin rol de encargado respecto de la información personal del cliente | Ninguna: solo ID del inquilino + metadatos de notificación + informes de instalación de paquetes de configuración | Azure del editor (Canadá) |
| Syncfusion | Biblioteca incorporada (no un servicio) | Ninguna: la conversión ocurre dentro del App Service de la institución | App Service de la institución |
Punto clave: ninguna información personal del solicitante, contenido de documentos ni detalle de la solicitud se transmite a Realizer Services ni a ningún tercero externo. Todo el procesamiento de documentos (conversión, redacción) ocurre dentro del propio App Service de la institución.
Bancos de información personal aplicables
| BIP | Número de registro | Descripción |
|---|---|---|
| Solicitudes conforme a la Access to Information Act y a la Privacy Act | PSU 901 | Registros relacionados con solicitudes de ATIP |
| Registros de personal de empleados | PSE 901 | Nombres y roles de empleados en el registro de auditoría |
Las instituciones deben confirmar los BIP aplicables y si se requieren nuevos BIP para su implementación específica.
Disponibilidad de la PIA completa
La Evaluación de Impacto en la Privacidad completa (incluido el inventario completo de información personal, el análisis detallado de recopilación/uso/divulgación/retención/exactitud, los fundamentos jurídicos y los diagramas de flujo de datos) está disponible para clientes y clientes potenciales que la soliciten. Las instituciones que realizan la implementación la utilizan como base técnica y de arquitectura para su propia PIA, completando la descripción general institucional, los calendarios de retención, los acuerdos de intercambio de información y la aprobación final antes de presentarla al TBS y a la Oficina del Comisionado de Privacidad.