Gobernanza del acceso a datos personales para ISO 27701:2025 y GDPR
La pregunta del auditor externo quedó suspendida en el aire, engañosamente sencilla.
“¿Puede mostrarme el registro de revisión de accesos relativo al acceso de su equipo de soporte a datos personales en producción durante el último trimestre?”
Para Anya, CISO de Medtelligence, un proveedor SaaS de tecnología sanitaria en rápido crecimiento, ese fue el momento decisivo. Medtelligence actúa como encargado del tratamiento de datos personales para hospitales y gestiona datos sensibles de pacientes en una plataforma en la nube. La empresa contaba con autenticación robusta, roles definidos y un equipo de ingeniería maduro. Pero el auditor no preguntaba si existía una página de inicio de sesión. Pedía pruebas de que el acceso a los datos personales se gobernaba de forma sostenida en el tiempo.
Quería ver quién podía acceder a datos personales en producción, por qué tenía ese acceso, cuándo se había aprobado, si seguía siendo necesario, si la actividad de soporte quedaba registrada y si se habían retirado los permisos innecesarios.
Anya abrió la consola de IAM. Había ingenieros de soporte, administradores de bases de datos, una cuenta de servicio de integración, un proveedor de servicios gestionados, dos roles de emergencia break-glass y un antiguo contratista que seguía presente en un grupo porque el ticket de baja se había cerrado antes de eliminar el derecho de acceso. Recursos Humanos indicaba que la persona había salido seis semanas antes. La hoja de cálculo de revisión de accesos decía “pendiente”. El SIEM tenía registros, pero nadie había mapeado qué eventos demostraban el acceso a datos personales.
Aquí es donde la gobernanza de la privacidad se vuelve real.
Conforme al GDPR, los datos personales deben tratarse con integridad y confidencialidad, protegidos frente al tratamiento no autorizado o ilícito y frente a la pérdida, destrucción o daño accidental mediante medidas técnicas y organizativas adecuadas. El GDPR también establece de forma expresa la responsabilidad proactiva: el responsable del tratamiento debe poder demostrar el cumplimiento. ISO/IEC 27701:2025 convierte esa responsabilidad proactiva en un Sistema de Gestión de la Información de Privacidad, o PIMS, donde el acceso a datos personales deja de ser una cuestión técnica secundaria. Pasa a ser un ciclo de vida gobernado que abarca roles, encargados del tratamiento, plataformas en la nube, empleados, administradores privilegiados, registros, revisiones, contratos y evidencias.
La brecha en muchas organizaciones no es que carezcan de control de acceso. La brecha es que no pueden demostrar de forma consistente la gobernanza del acceso a datos personales en ISO/IEC 27701:2025, GDPR, ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIS2, DORA, NIST CSF 2.0 y COBIT 2019.
La gobernanza del acceso a datos personales no es solo IAM
Un programa tradicional de IAM pregunta: “¿Pueden los usuarios correctos acceder a los sistemas correctos?”
Un PIMS maduro conforme a ISO/IEC 27701:2025 plantea preguntas más exigentes:
- ¿Qué sistemas tratan datos personales?
- ¿Qué roles requieren acceso a qué categorías de datos personales?
- ¿Actúa la organización como responsable del tratamiento, encargado del tratamiento, corresponsable del tratamiento o subencargado del tratamiento?
- ¿Está el acceso limitado por la finalidad, una necesidad de negocio documentada y el mínimo privilegio?
- ¿Se registran y revisan las acciones privilegiadas?
- ¿Puede la organización demostrar que el acceso de encargados y subencargados del tratamiento está controlado contractualmente?
- ¿Se incluyen en las evidencias las rutas de soporte en la nube, el aislamiento entre tenants, las exportaciones y las acciones administrativas?
- ¿Se revisan las decisiones de acceso después de la incorporación, un cambio de rol, un incidente, la baja y los cambios materiales del sistema?
Por eso la seguridad de los datos personales y la gobernanza del control de acceso son un puente natural entre ISO/IEC 27701:2025 y GDPR. El GDPR proporciona el marco jurídico de responsabilidad proactiva. ISO/IEC 27701:2025 operacionaliza la gestión de la privacidad para responsables y encargados del tratamiento. ISO/IEC 27001:2022 aporta el motor de gestión de riesgos del SGSI. ISO/IEC 27002:2022 proporciona la arquitectura de controles, incluida la privacidad y protección de datos personales, el control de acceso, los derechos de acceso, el registro de eventos, los servicios en la nube, las relaciones con proveedores, la clasificación, la supresión, el enmascaramiento y la criptografía.
Zenith Blueprint: An Auditor’s 30-Step Roadmap de Clarysec sitúa esto en la fase de controles en acción. En el paso 23, que cubre los controles organizativos 5.19 a 5.37, describe el control 5.34 de ISO/IEC 27002:2022, Privacidad y protección de datos personales, como una cuestión de confianza, no solo como una cuestión de datos:
La información de identificación personal no es simplemente otro tipo de dato; es una representación profundamente sensible de la confianza. Nombres, direcciones, documentos de identidad, historiales médicos, datos financieros: estos datos cuentan una historia sobre personas reales.
El mismo pasaje establece la base práctica: la protección de la privacidad empieza con el conocimiento de los datos. Una organización debe saber qué datos personales recopila, dónde residen, por qué se tratan y quién puede acceder a ellos.
La presión de cumplimiento que hay detrás del control de acceso a datos personales
La gobernanza del acceso a datos personales ya no es una cuestión de un único marco. Organizaciones como Medtelligence operan en la intersección de la regulación de privacidad, la legislación de ciberseguridad, la resiliencia operativa, el aseguramiento ante clientes y la certificación de seguridad.
El Article 5 del GDPR exige que los datos personales se traten conforme a los principios de licitud, lealtad, transparencia, limitación de la finalidad, minimización de datos, exactitud, limitación del plazo de conservación, integridad y confidencialidad. El Article 5(2) introduce la responsabilidad proactiva: el responsable del tratamiento es responsable del cumplimiento y debe poder demostrarlo. El Article 32 exige después medidas técnicas y organizativas adecuadas para la seguridad del tratamiento.
El Article 21 de NIS2 exige a las entidades esenciales e importantes adoptar medidas técnicas, operativas y organizativas de gestión de riesgos de ciberseguridad que sean adecuadas y proporcionadas. Sus ámbitos mínimos incluyen análisis de riesgos, políticas de seguridad, gestión de incidentes, continuidad del negocio, seguridad de la cadena de suministro, adquisición y desarrollo seguros, evaluación de la eficacia, higiene cibernética y formación, criptografía, seguridad de Recursos Humanos, control de acceso, gestión de activos y, cuando proceda, autenticación multifactor o continua y comunicaciones seguras. El Article 20 también atribuye a los órganos de dirección la responsabilidad de aprobar y supervisar las medidas de gestión de riesgos de ciberseguridad.
DORA se aplica desde el 17 de enero de 2025 a un amplio conjunto de entidades financieras y crea un régimen sectorial específico de resiliencia operativa. Cubre la gestión del riesgo de las TIC, la notificación de incidentes graves relacionados con las TIC, las pruebas de resiliencia operativa digital, el intercambio de información, el riesgo de terceros de TIC y los acuerdos contractuales con proveedores terceros de servicios de TIC. Para las entidades financieras y los proveedores de servicios de TIC que las apoyan, el control de acceso no es solo una cuestión de privacidad. Forma parte de la resiliencia operativa.
ISO/IEC 27001:2022 integra estas obligaciones en un sistema de gestión basado en riesgos. Las cláusulas 6.1.1 a 6.1.3 exigen a las organizaciones abordar riesgos y oportunidades, definir un proceso de evaluación de riesgos de seguridad de la información, identificar riesgos para la confidencialidad, integridad y disponibilidad, evaluar los riesgos, seleccionar opciones de tratamiento, determinar controles, comparar los controles seleccionados con el Anexo A, documentar la Declaración de Aplicabilidad, obtener la aprobación del propietario del riesgo y aceptar los riesgos residuales. Las cláusulas 8.2 y 8.3 exigen realizar evaluaciones de riesgos a intervalos planificados o tras cambios significativos, así como implementar el plan de tratamiento de riesgos con resultados documentados.
Para la gobernanza de datos personales, esto significa que el control de acceso no es un ajuste aislado de IAM. Es una decisión de tratamiento de riesgos. Un rol que puede exportar registros de nómina, datos de pacientes, detalles de pago, documentos de identidad, datos de ubicación o transcripciones de soporte al cliente debe estar justificado en el Registro de Riesgos, reflejado en la Declaración de Aplicabilidad, aplicado en IAM, registrado en producción, revisado periódicamente y retirado cuando deje de ser necesario.
El modelo de control de Clarysec: de la promesa de privacidad a la evidencia
Clarysec trata la gobernanza del acceso a datos personales como una cadena de evidencias. La cadena comienza con el inventario de datos y la definición de roles, continúa con la aprobación y la aplicación del acceso, y termina con la supervisión, la revisión, la revocación y registros preparados para auditoría.
En Zenith Controls: The Cross-Compliance Guide, el tema se sitúa principalmente alrededor de tres controles de ISO/IEC 27002:2022:
| Control de ISO/IEC 27002:2022 | Interpretación de Clarysec para la gobernanza de datos personales | Atributos del control en Zenith Controls |
|---|---|---|
| 5.34 Privacidad y protección de datos personales | Identificar los datos personales, protegerlos durante todo su ciclo de vida y alinear el tratamiento con las obligaciones legales y de privacidad | Preventivo, Confidencialidad, Integridad, Disponibilidad, Identificar, Proteger, Protección de la información, Legal y Cumplimiento |
| 5.15 Control de acceso | Establecer reglas de control de acceso basadas en requisitos de negocio y seguridad, incluido el mínimo privilegio y el acceso basado en roles | Preventivo, Confidencialidad, Integridad, Disponibilidad, Proteger, gestión de identidades y accesos |
| 5.18 Derechos de acceso | Conceder, revisar, ajustar y revocar derechos de acceso mediante un ciclo de vida trazable | Preventivo, Confidencialidad, Integridad, Disponibilidad, Proteger, gestión de identidades y accesos |
Los auditores rara vez aceptan “usamos IAM” como evidencia. Esperan ver cómo las decisiones de IAM se vinculan con obligaciones de privacidad, propiedad del sistema, clasificación de datos, necesidad de negocio, tratamiento de riesgos, frecuencia de revisión de accesos, alcance del registro de eventos y contratos con proveedores.
La PII Security and Access Control Policy de Clarysec establece la configuración de referencia en lenguaje de PIMS:
[Ambos] El propietario del sistema / propietario de la aplicación DEBE restringir el acceso a datos personales a roles aprobados y usuarios autorizados registrados o trazables en REG02 o REG12 antes de habilitar el acceso.
De la sección “4.2 Configuración de referencia de control de acceso”, cláusula de política 4.2.1.
La etiqueta “[Ambos]” significa que el control se aplica tanto si la organización actúa como responsable del tratamiento de datos personales como si actúa como encargado del tratamiento. Esa distinción importa. Los responsables del tratamiento suelen fallar al definir reglas de acceso basadas en la finalidad. Los encargados del tratamiento suelen fallar al demostrar que el acceso está limitado a instrucciones del cliente, rutas de soporte aprobadas y personal contractualmente autorizado.
La misma política eleva el nivel de exigencia para datos personales sensibles o de alto impacto:
[Ambos] El propietario del sistema / propietario de la aplicación DEBE revisar el acceso de usuarios a sistemas que traten datos personales de alto impacto o sensibles al menos trimestralmente y registrar el resultado de la revisión en REG12.
De la sección “4.2 Configuración de referencia de control de acceso”, cláusula de política 4.2.3.
Aquí es donde un PIMS se vuelve auditable. La revisión de accesos no es simplemente un correo electrónico de un responsable. Es un registro en REG12, vinculado a un sistema, una categoría de datos, un rol, un propietario, un resultado de revisión y una acción de remediación.
Base de políticas: mínimo privilegio, necesidad de negocio y denegación por defecto
La gobernanza eficaz empieza con reglas exigibles. Antes de que Anya pudiera mostrar al auditor un registro de revisión de accesos, debía demostrar que el requisito de realizar revisiones de acceso estaba formalmente establecido.
La Access Control Policy - SME de Clarysec para pymes establece el principio:
Esta política aplica el principio de mínimo privilegio y exige que el acceso se limite a lo mínimo necesario para desempeñar las responsabilidades del puesto.
De la sección “Finalidad”, cláusula de política 1.3.
La Data Protection and Privacy Policy - SME para pymes vincula el acceso con la necesidad de negocio:
El acceso de usuarios a datos personales debe limitarse a roles con una necesidad de negocio documentada.
De la sección “Requisitos de gobernanza”, cláusula de política 5.3.2.
Para organizaciones de mayor tamaño, la Data Protection and Privacy Policy empresarial expresa la expectativa de control como un requisito del sistema:
Todos los sistemas deben aplicar por defecto el acceso de mínimo privilegio.
De la sección “Requisitos de implementación de la política”, cláusula de política 6.3.1.
La distinción es importante. Una empresa más pequeña puede necesitar un registro ligero pero explícito de la necesidad de negocio. Una organización empresarial necesita aplicación a nivel de sistema, revisión periódica, segregación de funciones, gobernanza del acceso privilegiado y evidencias conservadas para auditoría interna, aseguramiento ante clientes, requerimientos de autoridades reguladoras e investigación de brechas de seguridad.
El ciclo de vida del acceso a datos personales: aprobación, uso, revisión y revocación
El fallo más común en el acceso a datos personales no es la aprobación inicial. Es la persistencia del acceso.
Zenith Blueprint, en la fase de controles en acción, paso 22, explica así el control 5.18 de ISO/IEC 27002:2022, Derechos de acceso:
El control 5.18 asegura que los derechos de acceso no solo se concedan adecuadamente, sino que también se revisen, ajusten y revoquen de forma controlada y trazable.
Después describe escenarios habituales: una nueva incorporación recibe acceso, cambia de rol y conserva permisos antiguos; un antiguo administrador abandona la organización pero un token sigue activo; la cuenta de un contratista vence sobre el papel, pero no en IAM. Estas son precisamente las debilidades que se convierten en incidentes de seguridad del GDPR cuando intervienen datos personales.
La User Account and Privilege Management Policy - SME de Clarysec para pymes establece una periodicidad de referencia:
Debe realizarse una revisión de todas las cuentas de usuario y privilegios cada seis meses.
De la sección “Requisitos de implementación de la política”, cláusula de política 6.4.1.
Para entornos empresariales, la User Account and Privilege Management Policy ajusta la cadencia operativa:
Seguridad de TI debe realizar revisiones trimestrales de todas las cuentas de usuario y privilegios asociados en colaboración con los responsables de departamento.
De la sección “Requisitos de implementación de la política”, cláusula de política 6.5.1.
Un ciclo de vida práctico del acceso a datos personales debe incluir:
- Clasificar el sistema y las categorías de datos personales.
- Definir roles aprobados y la necesidad de negocio documentada.
- Mapear los roles con las finalidades del tratamiento.
- Aprobar el acceso antes de habilitarlo.
- Aplicar el mínimo privilegio, la segregación de funciones y autenticación robusta.
- Registrar la autenticación, el acceso, la exportación, la configuración y las acciones privilegiadas.
- Revisar el acceso con una periodicidad basada en el riesgo.
- Retirar el acceso ante cambio de rol, cese, cierre del proyecto, vencimiento contractual o instrucción del cliente.
- Conservar las evidencias en el registro del PIMS y en la pista de auditoría.
Esto no es burocracia. Es la forma en que una organización demuestra que el acceso a datos personales está controlado desde el diseño, por defecto y mediante evidencias.
Ejemplo práctico: la revisión trimestral de accesos a datos personales
La auditoría de Anya tuvo éxito cuando desplazó la conversación de las declaraciones de política a las evidencias.
Primero, citó la PII Security and Access Control Policy, cláusula 4.2.3, que exigía la revisión trimestral del acceso a datos personales de alto impacto o sensibles y el registro del resultado de la revisión en REG12.
A continuación, guio al auditor por el trimestre anterior:
- TI generó una lista de todos los usuarios, grupos, roles privilegiados, cuentas de servicio, cuentas de proveedores, roles break-glass y permisos de soporte para la base de datos de producción que contenía datos de pacientes.
- La lista se envió al propietario de la aplicación, el responsable de Éxito del Cliente, que era titular de la necesidad operativa del equipo de soporte.
- El propietario de la aplicación revisó la lista línea por línea frente al rol actual, la responsabilidad de soporte al cliente y la finalidad del tratamiento.
- Dos agentes de soporte que habían cambiado de equipo fueron marcados para revocación.
- Se creó un ticket en el sistema de gestión de servicios de TI, vinculado a la revisión de accesos, con un acuerdo de nivel de servicio asignado, y se cerró después de la revocación.
- REG12 se actualizó con el registro de revisión, el aprobador, las excepciones, el ticket de remediación, las evidencias de cierre y la siguiente fecha de revisión.
El resultado fue una cadena de evidencias de ciclo cerrado. Anya no se limitó a afirmar que Medtelligence usaba mínimo privilegio. Mostró el requisito de política, el propietario responsable, la lista de accesos, la decisión de revisión, la acción correctiva y la revocación completada.
Esa es la diferencia entre control de acceso y gobernanza del acceso.
Acceso de proveedores y encargados del tratamiento: el punto ciego en las auditorías de PIMS
Muchos riesgos de acceso no autorizado entran a través de soporte, externalización, socios de integración, proveedores de servicios gestionados y subencargados del tratamiento. Un encargado del tratamiento puede tener acceso remoto a datos de producción de clientes. Un proveedor de servicios en la nube puede proporcionar rutas de acceso de soporte. Un subencargado del tratamiento puede mantener un índice de búsqueda que contenga identificadores de clientes. Un proveedor de servicios de seguridad gestionados puede acceder a registros que contienen datos personales.
Conforme al GDPR, los responsables del tratamiento deben utilizar encargados del tratamiento que ofrezcan garantías suficientes. Conforme a ISO/IEC 27701:2025, la gobernanza de encargados y subencargados del tratamiento debe operacionalizarse mediante instrucciones documentadas, controles contractuales, aseguramiento y supervisión. ISO/IEC 27002:2022 lo respalda mediante controles de relaciones con proveedores, incluidos 5.19 Seguridad de la información en las relaciones con proveedores, 5.20 Tratamiento de la seguridad de la información en los acuerdos con proveedores y 5.21 Gestión de la seguridad de la información en la cadena de suministro de TIC.
Zenith Blueprint, en la fase de controles en acción, paso 23, resume áreas de evidencia de acuerdos con proveedores, incluidas:
✓ Responsabilidades de control de acceso, por ejemplo quién puede acceder a sus datos, cómo se gestionan las credenciales y qué supervisión existe;
También incluye obligaciones de confidencialidad, medidas técnicas y organizativas, plazos de notificación de incidentes, derechos de auditoría, controles sobre subcontratistas y desactivación de cuentas al final del contrato.
La Processor, Subprocessor and Third-Party Privacy Management Policy de Clarysec convierte esto en evidencias del PIMS del lado del responsable del tratamiento:
[Responsable del tratamiento] El responsable de privacidad / responsable del PIMS DEBE verificar que los campos de control contractual del encargado del tratamiento en REG08 aborden el alcance, la duración y la finalidad del tratamiento, las categorías de datos personales, las categorías de interesados, la confidencialidad, la seguridad, la autorización de subencargados del tratamiento, la asistencia, la auditoría o el aseguramiento, la devolución, la supresión y la terminación antes de la aprobación.
De la sección “4.3 Controles contractuales e instrucciones documentadas”, cláusula de política 4.3.2.
El acceso de proveedores también se controla directamente en las políticas de proveedores de Clarysec para pymes y empresas. La Third-Party and Supplier Security Policy - SME para pymes establece:
A los proveedores solo se les debe conceder acceso a los sistemas y datos mínimos necesarios para desempeñar su función.
De la sección “Requisitos de implementación de la política”, cláusula de política 6.2.1.
La Third party and supplier security policy empresarial añade RBAC, revisión y mínimo privilegio:
El personal de proveedores debe estar sujeto a control de acceso basado en roles (RBAC), revisiones periódicas de derechos de acceso y aplicación del mínimo privilegio.
De la sección “Requisitos de implementación de la política”, cláusula de política 6.3.1.
Si el acceso de proveedores puede alcanzar datos personales, pertenece al PIMS. Debe aparecer en controles contractuales, aprobaciones de acceso, grupos de IAM, alcance del registro de eventos, registros de revisión, registros de baja, procedimientos de respuesta a incidentes y evidencias de auditoría.
Acceso a datos personales en la nube: responsabilidad compartida no equivale a responsabilidad proactiva compartida
La gobernanza del acceso a datos personales en la nube es un ámbito en el que las organizaciones suelen sobrestimar al proveedor y subestimar sus propias responsabilidades. El proveedor de servicios en la nube puede proteger la infraestructura, pero el cliente sigue gobernando identidades, roles, configuración del tenant, acceso de soporte, registros, ajustes de configuración del cifrado, permisos de exportación y preparación para la respuesta a incidentes.
Zenith Blueprint, en la fase de controles en acción, paso 23, lo expresa con claridad en su guía sobre servicios en la nube:
Los proveedores de servicios en la nube protegen la infraestructura, pero usted sigue siendo responsable de sus datos, sus configuraciones, sus políticas de acceso y su preparación para la respuesta a incidentes.
También advierte:
En la nube, la visibilidad es parcial salvo que se diseñe deliberadamente. Es necesario configurar el registro de eventos, aplicar el cifrado, definir roles de identidad y supervisar la actividad mediante herramientas nativas o integraciones de terceros. Eso no es una tarea de infraestructura; es un requisito del SGSI.
La Cloud Usage Policy de Clarysec convierte esto en un requisito de acceso empresarial:
Todos los servicios en la nube deben aplicar control de acceso basado en identidades alineado con el principio de mínimo privilegio.
De la sección “Requisitos de implementación de la política”, cláusula de política 6.2.1.
Para organizaciones que actúan como encargados del tratamiento en entornos en la nube, la Cloud PII Processor Policy de Clarysec define una obligación de revisión del PIMS más específica:
[Encargado del tratamiento] El responsable de seguridad de la información DEBE revisar el acceso privilegiado a la nube, el acceso de soporte, el acceso a datos personales de clientes y la cobertura de registro de eventos en REG12 al menos trimestralmente.
De la sección “4.2 Configuración de la nube, aislamiento entre tenants, acceso y registro de eventos”, cláusula de política 4.2.4.
Esta cláusula es especialmente relevante para empresas SaaS, plataformas alojadas en la nube, servicios de datos gestionados y encargados del tratamiento B2B.
| Área de acceso a datos personales en la nube | Qué verificar | Evidencia típica |
|---|---|---|
| Acceso privilegiado a la nube | Los roles de administración están aprobados, limitados, supervisados y revisados | Exportación de IAM, aprobación de acceso privilegiado, registro de revisión |
| Acceso de soporte | El personal de soporte solo puede acceder a datos personales de clientes mediante flujos aprobados | Registros de acceso de soporte, vinculación con tickets, registro de instrucción del cliente |
| Acceso a datos personales de clientes | El acceso se mapea con tenant, rol, finalidad y necesidad de negocio | Registro REG12, matriz de roles, aprobación del propietario del sistema |
| Cobertura de registro de eventos | Se capturan eventos de autenticación, acceso, exportación, acciones privilegiadas y configuración | Alcance del registro de eventos, consulta SIEM, registro de pista de auditoría |
La gobernanza del acceso a datos personales en la nube no está completa salvo que los registros nativos de la nube, las políticas de IAM, las cuentas de servicio, los roles privilegiados, las herramientas de soporte al cliente, las claves API y las funciones de exportación de datos se revisen de forma conjunta.
Registro y supervisión: la memoria de la gobernanza de datos personales
Un programa de control de acceso del PIMS sin registros es una promesa sin memoria.
La PII Security and Access Control Policy exige definir el alcance del registro de eventos antes del uso en producción o de un cambio material:
[Ambos] El propietario del sistema / propietario de la aplicación DEBE definir en REG12 el alcance de registro de eventos de datos personales para eventos de autenticación, eventos de acceso, acciones privilegiadas, actividad de exportación de datos personales y cambios materiales de configuración antes del uso en producción o de un cambio material.
De la sección “4.6 Registro y supervisión”, cláusula de política 4.6.1.
La Logging and Monitoring Policy - SME para pymes explicita el contenido de los registros de acceso:
Registros de acceso: acceso a archivos (especialmente a datos sensibles o personales), cambios de permisos, uso de recursos compartidos.
De la sección “Requisitos de gobernanza”, cláusula de política 5.4.3.
La Logging and Monitoring Policy empresarial se centra en la utilidad para auditorías:
El Registro de Pista de Auditoría del SGSI debe registrar la disponibilidad de datos de registro para auditorías, investigaciones y revisiones regulatorias.
De la sección “Requisitos de gobernanza”, cláusula de política 5.4.
Esto es crítico porque las evidencias de privacidad suelen tener que responder a preguntas basadas en eventos:
- ¿Quién accedió a los datos personales?
- ¿Estaba autorizado el acceso?
- ¿Estaba el acceso vinculado a un ticket de soporte, una solicitud legal, una tarea operativa o una instrucción del cliente?
- ¿Se exportaron, copiaron, alteraron o suprimieron datos?
- ¿Se utilizó acceso privilegiado?
- ¿Se cambiaron permisos antes o después del acceso?
- ¿Indicaba la actividad un incidente de seguridad o una brecha de datos personales?
Los registros no son solo para el SOC. Son evidencias del PIMS, evidencias de aseguramiento ante clientes, evidencias de aseguramiento del encargado del tratamiento y evidencias de respuesta a incidentes.
Mapeo de cumplimiento cruzado: un modelo de acceso, múltiples perspectivas
Una debilidad en las revisiones de acceso a datos personales nunca es un único hallazgo. Puede convertirse en un problema de responsabilidad proactiva del GDPR, una debilidad del PIMS de ISO/IEC 27701:2025, una no conformidad de ISO/IEC 27001:2022, un fallo de gobernanza de NIS2, una preocupación de resiliencia de DORA, una deficiencia de gobernanza de NIST CSF 2.0 o un problema de madurez de procesos de COBIT 2019.
| Perspectiva del marco | Qué es probable que pregunte el auditor | Anclaje de evidencias de Clarysec |
|---|---|---|
| GDPR | ¿Puede demostrar integridad, confidencialidad, responsabilidad proactiva y protección frente al tratamiento no autorizado? | Matriz de roles de datos personales, revisión de accesos REG12, alcance del registro de eventos, pista de investigación de brechas de seguridad |
| ISO/IEC 27701:2025 | ¿Están incorporadas al PIMS las obligaciones de acceso del responsable y del encargado del tratamiento? | Etiquetas de rol del PIMS, PII Security and Access Control Policy, controles de encargados en REG08 |
| ISO/IEC 27001:2022 | ¿Se ha evaluado, tratado, incluido en la SoA, operado y evaluado el riesgo de acceso a datos personales? | Evaluación de riesgos, plan de tratamiento de riesgos, SoA, registros de implementación de control de acceso |
| NIS2 | ¿La dirección gobierna el control de acceso, la seguridad de Recursos Humanos, la gestión de activos, la seguridad de proveedores, la formación y la gestión de incidentes? | Evidencias de aprobación del Consejo de Administración, controles de acceso de proveedores, registros de formación, procedimiento de respuesta a incidentes |
| DORA | ¿Los controles de acceso a TIC, los riesgos de terceros de TIC, el registro de eventos, la auditoría, las pruebas y la remediación forman parte de la resiliencia operativa? | Marco de riesgo de las TIC, revisiones de acceso en la nube, informe de auditoría interna, herramienta de seguimiento de remediación |
| NIST CSF 2.0 | ¿Las obligaciones de privacidad y ciberseguridad se gobiernan, dotan de recursos, comunican y revisan? | Registro de gobernanza, registros de revisión de políticas, mapeo de apetito de riesgo, líneas de riesgo de proveedores |
| COBIT 2019 | ¿Se controla la gobernanza del acceso como un proceso de gestión repetible, con responsabilidad proactiva y métricas? | RACI, KPI de proceso, periodicidad de revisión, informes de excepciones, acciones correctivas |
Una matriz de correspondencia de controles más detallada muestra cómo un único proceso de gobernanza del acceso a datos personales respalda múltiples requisitos:
| Requisito de control | ISO/IEC 27001:2022 e ISO/IEC 27002:2022 | GDPR | NIS2 | DORA |
|---|---|---|---|---|
| Revisión periódica de accesos a datos personales | Cláusulas 8.1, 9.1 de ISO/IEC 27001:2022, Anexo A 5.18 Derechos de acceso | Article 5(1)(f), Article 32 | Article 21(2)(i) | Article 6, Article 9 |
| Registro de eventos de acceso a datos personales | Anexo A 8.15 Registro de eventos, Anexo A 8.16 Actividades de supervisión | Article 32 | Article 21(2)(b), Article 21(2)(i) | Article 10 |
| Gobernanza del acceso de proveedores | Anexo A 5.19, 5.20, 5.21 | Article 28 | Article 21(3) | Article 28, Article 30 |
| Gobernanza de acceso y configuración en la nube | Anexo A 5.23 Seguridad de la información para el uso de servicios en la nube, Anexo A 8.3 Restricción del acceso a la información | Article 32 | Article 21(2)(e), Article 21(2)(i) | Article 6, Article 9, Article 28 |
| Selección de controles y evidencias basadas en riesgos | Cláusulas 6.1.1, 6.1.2, 6.1.3, 8.2, 8.3 | Article 5(2), Article 24 | Article 20, Article 21 | Article 5, Article 6 |
El valor de Zenith Controls es que los equipos pueden mapear estas perspectivas con las mismas evidencias de control, en lugar de mantener silos de cumplimiento separados.
Ejecute un sprint de evidencias de acceso a datos personales de 45 minutos
Una forma útil de comprobar la preparación es elegir un sistema de alto impacto, como una plataforma de soporte al cliente, un sistema de Recursos Humanos, un portal de pagos, un portal de pacientes, un lago de datos o una base de datos de producción SaaS, y ejecutar un sprint de evidencias focalizado.
Paso 1: Defina el contexto de tratamiento de datos personales
Registre en REG12:
- Nombre y propietario del sistema
- Categorías de datos personales
- Categorías de interesados
- Rol de responsable o encargado del tratamiento
- Finalidad del tratamiento
- Indicador de datos personales sensibles o de alto impacto
- Dependencias de nube, proveedores y subencargados del tratamiento
Si el sistema implica a un encargado del tratamiento, verifique los campos de control contractual de REG08 mediante la Processor, Subprocessor and Third-Party Privacy Management Policy. La aprobación debe cubrir alcance, duración y finalidad del tratamiento, categorías de datos personales, categorías de interesados, confidencialidad, seguridad, autorización de subencargados del tratamiento, asistencia, auditoría o aseguramiento, devolución, supresión y terminación.
Paso 2: Extraiga la lista de accesos
Exporte todos los usuarios, grupos, roles privilegiados, cuentas de servicio, roles de soporte, cuentas break-glass, claves API y cuentas de proveedores. Compare cada derecho de acceso con los roles aprobados.
| Estado del acceso | Significado | Acción inmediata |
|---|---|---|
| Aprobado y necesario | El acceso se mapea con rol, finalidad y necesidad de negocio | Conservar y registrar evidencias |
| Aprobado pero excesivo | El usuario tiene más acceso del necesario | Reducir permisos y documentar el cambio |
| Necesidad de negocio desconocida | No existe finalidad o aprobación clara | Suspender o escalar para validación del propietario |
| Cuenta huérfana | La cuenta no está vinculada a un usuario o propietario activo | Deshabilitar e investigar |
| Acceso de proveedor o subencargado del tratamiento | Una parte externa puede alcanzar datos personales | Verificar contrato, aprobación, registro de eventos y revisión |
| Acceso privilegiado o de emergencia | Existe acceso elevado | Confirmar aprobación, MFA, supervisión y revisión posterior al uso |
| Cuenta de servicio que requiere validación | Una cuenta no humana tiene acceso a datos personales | Confirmar propietario, finalidad, rotación de secretos y registro de eventos |
Paso 3: Confirme el mínimo privilegio y la alineación con la finalidad
Use la configuración de referencia de la PII Security and Access Control Policy: el acceso debe restringirse a roles aprobados y usuarios autorizados registrados o trazables en REG02 o REG12 antes de habilitarlo. Si un usuario no puede trazarse hasta un rol, una finalidad y una aprobación, el hallazgo no es “falta documentación”. El hallazgo es “acceso a datos personales no demostrablemente autorizado”.
Paso 4: Verifique el alcance del registro de eventos
Confirme que los registros capturan autenticación, eventos de acceso, acciones privilegiadas, actividad de exportación de datos personales y cambios materiales de configuración. Después confirme dónde se almacenan los registros, cuánto tiempo se conservan, quién puede acceder a ellos y si están registrados en el Registro de Pista de Auditoría del SGSI para auditorías, investigaciones y revisiones regulatorias.
Paso 5: Cierre el ciclo
Para cada excepción, registre el propietario del riesgo, la acción inmediata de contención, la remediación permanente, la fecha objetivo, las evidencias requeridas, la decisión sobre el riesgo residual y si se necesita una evaluación de la brecha de seguridad.
Este único ejercicio suele revelar la madurez real de la gobernanza del acceso a datos personales. Las organizaciones sólidas pueden responder con rapidez. Las organizaciones débiles descubren que la política de privacidad, la configuración de IAM, los contratos con encargados del tratamiento, el registro de eventos en la nube y las evidencias de auditoría están desconectados.
Hallazgos de auditoría comunes en la gobernanza del acceso a datos personales
La mayoría de los hallazgos son previsibles. Surgen cuando privacidad, seguridad, legal, TI y proveedores controlan cada uno una parte de la historia, pero nadie es propietario del ciclo de vida completo del acceso a datos personales.
Los hallazgos comunes incluyen:
- Los sistemas que tratan datos personales no están completamente listados en el inventario del PIMS.
- Los roles de acceso están definidos técnicamente, pero no mapeados con finalidades de tratamiento.
- Los datos personales sensibles son accesibles mediante grupos operativos amplios.
- Las revisiones trimestrales cubren a los empleados, pero no cuentas de servicio, claves API o usuarios de proveedores.
- El acceso de soporte en la nube es posible, pero no se revisa como acceso a datos personales.
- Existen registros, pero no demuestran acceso a datos personales, exportación o actividad privilegiada.
- Los contratos con encargados del tratamiento incluyen cláusulas genéricas de confidencialidad, pero no controles específicos de acceso, auditoría, subencargados del tratamiento, devolución, supresión o terminación.
- Antiguos empleados o contratistas conservan acceso mediante grupos compartidos o tokens no gestionados.
- El acceso al almacén de datos es más amplio que el acceso a la aplicación de origen.
- Existen cuentas break-glass sin revisión posterior al uso.
- La suplantación por soporte al cliente no se registra con contexto de ticket.
- La Declaración de Aplicabilidad incluye controles de acceso, pero las evidencias no muestran una implementación específica para datos personales.
Cada uno de estos hallazgos puede convertirse en un problema de responsabilidad proactiva del GDPR, una cuestión de aseguramiento ante clientes, una debilidad de gobernanza de NIS2 o DORA, o una no conformidad de ISO/IEC 27001:2022, según el alcance.
Cómo se ve un buen modelo
Un modelo operativo maduro no depende de limpiezas trimestrales heroicas. Integra la gobernanza del acceso a datos personales en las operaciones normales.
Primero, la organización tiene conocimiento de los datos. Sabe dónde existen datos personales, por qué se tratan, qué rol del PIMS aplica y qué sistemas, proveedores, servicios en la nube, registros, copias de seguridad y exportaciones están dentro del alcance.
Segundo, el acceso está basado en roles y alineado con la finalidad. Los permisos se definen por roles aprobados, necesidad de negocio documentada, finalidad del tratamiento y mínimo privilegio.
Tercero, los controles se aplican técnicamente. IAM, RBAC, gestión de accesos privilegiados (PAM), MFA, acceso condicional, controles de tenant, cifrado y segregación de entornos aplican las expectativas de la política.
Cuarto, la supervisión es deliberada. La organización puede reconstruir autenticación, acceso, exportación, acciones privilegiadas, acceso de soporte y cambios de configuración que afecten a datos personales.
Quinto, las revisiones se basan en riesgos y están documentadas. Los datos personales de alto impacto reciben revisión al menos trimestral. Se incluye el acceso de proveedores y de soporte en la nube. Las excepciones se supervisan hasta su cierre.
Sexto, las evidencias son reutilizables. Los mismos registros respaldan la responsabilidad proactiva del GDPR, el funcionamiento del PIMS de ISO/IEC 27701:2025, el tratamiento de riesgos de ISO/IEC 27001:2022, las medidas de gestión de riesgos de NIS2, la gobernanza del riesgo de las TIC de DORA, los resultados GOVERN de NIST CSF 2.0 y el aseguramiento de gestión de COBIT 2019.
Esta es la diferencia entre el control de acceso como ajuste y la gobernanza del acceso como sistema.
Convierta el acceso a datos personales en evidencias preparadas para auditorías
Si su próxima auditoría, revisión de cliente o requerimiento de una autoridad reguladora comenzara mañana con “muéstreme quién puede acceder a datos personales”, ¿su equipo produciría evidencias en minutos o empezaría a conciliar hojas de cálculo?
Clarysec puede ayudarle a cerrar esa brecha.
Empiece con la PII Security and Access Control Policy, alinee las obligaciones de encargados del tratamiento y de nube mediante la Processor, Subprocessor and Third-Party Privacy Management Policy y la Cloud PII Processor Policy, y después use Zenith Blueprint: An Auditor’s 30-Step Roadmap para implementar los controles en la secuencia adecuada. Por último, use Zenith Controls: The Cross-Compliance Guide para mapear las evidencias de acceso a datos personales en ISO/IEC 27701:2025, GDPR, ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIS2, DORA, NIST CSF 2.0 y COBIT 2019.
El siguiente paso práctico más rápido es sencillo: seleccione un sistema de datos personales de alto impacto, complete REG12, exporte la lista de accesos, verifique el alcance del registro de eventos y ejecute una revisión con formato trimestral. En una sola sesión sabrá si su gobernanza del acceso a datos personales está preparada para auditorías o solo preparada en la política.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
