Protección de información de identificación personal (PII) lista para auditoría para GDPR, NIS2 y DORA
La alerta llegó a la bandeja de entrada de Sarah a las 22:00 de un martes.
Como CISO de una empresa fintech SaaS en fase de crecimiento, las alertas nocturnas no eran una novedad. Pero esta era distinta. Un desarrollador junior había expuesto una base de datos de preproducción en un punto de conexión público mientras probaba una nueva funcionalidad de analítica. La base de datos debía contener datos de prueba, pero una sincronización reciente de producción a preproducción la había llenado con PII real de clientes.
El incidente se contuvo con rapidez. Después llegó el segundo hallazgo. Una hoja de cálculo de migración llamada customer_users_final_v7.xlsx se había copiado desde el mismo conjunto de datos. Contenía nombres, correos electrónicos, permisos de rol, registros de uso, campos de país, notas de soporte y comentarios de texto libre que nunca deberían haber entrado en un flujo de trabajo de pruebas. Se había copiado a una unidad compartida, descargado por un desarrollador, adjuntado a un ticket y olvidado.
A medianoche, Sarah ya no gestionaba una configuración técnica incorrecta. Estaba gestionando un problema de auditoría.
La empresa ya estaba certificada conforme a ISO/IEC 27001:2022. El Consejo de Administración solicitaba aseguramiento de GDPR antes del lanzamiento en el mercado de la UE. Los clientes de servicios financieros enviaban cuestionarios de diligencia debida de DORA. Las relaciones con proveedores de nube y servicios gestionados planteaban preguntas sobre la cadena de suministro de NIS2. Legal podía explicar las obligaciones. Ingeniería podía señalar el cifrado. Producto tenía buenas intenciones de privacidad desde el diseño. La Declaración de Aplicabilidad mencionaba la privacidad y la protección de PII.
Pero nadie podía mostrar, en una única cadena trazable, qué PII existía, por qué se trataba, quién podía acceder a ella, dónde se enmascaraba, qué proveedores la tocaban, durante cuánto tiempo se conservaba y cómo se clasificaría un incidente con arreglo a GDPR, NIS2 o DORA.
Esa brecha explica exactamente por qué importan ISO/IEC 27701:2025 e ISO/IEC 29151:2022. No son simples etiquetas de privacidad. Ayudan a las organizaciones a convertir las promesas de privacidad en controles de protección de PII listos para auditoría. ISO/IEC 27701:2025 amplía un Sistema de Gestión de la Seguridad de la Información (SGSI) ISO/IEC 27001:2022 hacia la gestión de la información de privacidad. ISO/IEC 29151:2022 añade directrices prácticas para proteger la información de identificación personal durante todo su ciclo de vida.
El enfoque de Clarysec consiste en crear un único modelo operativo de privacidad y seguridad basado en evidencias, no silos de cumplimiento separados. Ese modelo combina Zenith Blueprint: hoja de ruta de 30 pasos para auditores Zenith Blueprint, Zenith Controls: la guía de cumplimiento transversal Zenith Controls y las políticas de Clarysec en un sistema único y trazable para GDPR, ISO/IEC 27001:2022, ISO/IEC 27701:2025, ISO/IEC 29151:2022, NIS2, DORA, un enfoque de aseguramiento NIST y las expectativas de gobernanza de COBIT 2019.
Por qué la protección de PII es ahora un asunto de auditoría a nivel del Consejo
La protección de PII solía tratarse como una responsabilidad del equipo de privacidad. Hoy es una cuestión de confianza, resiliencia y regulación a nivel del Consejo de Administración.
GDPR sigue siendo la referencia para la protección de datos personales en Europa y más allá. Define datos personales, tratamiento, responsable del tratamiento, encargado del tratamiento, destinatario, tercero, consentimiento y violación de la seguridad de los datos personales de formas que afectan a los contratos SaaS, las operaciones de soporte, la analítica, la telemetría de producto, la gestión de proveedores y la respuesta a incidentes. Sus principios exigen licitud, lealtad, transparencia, limitación de la finalidad, minimización de datos, exactitud, limitación del plazo de conservación, integridad, confidencialidad y responsabilidad proactiva. En términos de auditoría, GDPR no solo pregunta si los datos están cifrados. Pregunta si la organización puede demostrar por qué existen los datos y cómo se logra el cumplimiento.
NIS2 eleva el nivel de gobernanza de la ciberseguridad para entidades esenciales e importantes. Article 21 exige medidas de gestión de riesgos de ciberseguridad, incluido el análisis de riesgos, políticas de seguridad de los sistemas de información, gestión de incidentes, continuidad del negocio, seguridad de la cadena de suministro, desarrollo seguro, gestión de vulnerabilidades, evaluación de la eficacia de los controles, higiene cibernética, criptografía, seguridad de recursos humanos, control de acceso, gestión de activos, autenticación y comunicaciones seguras. Article 23 añade una notificación escalonada de incidentes, incluido un aviso temprano en un plazo de 24 horas, una notificación en un plazo de 72 horas y un informe final en el plazo de un mes desde la notificación.
DORA cambia la conversación para las entidades financieras y sus proveedores de TIC. Se aplica desde el 17 de enero de 2025 y crea un régimen armonizado de resiliencia operativa digital que cubre la gestión del riesgo de las TIC, la notificación de incidentes graves relacionados con las TIC, las pruebas de resiliencia, el riesgo asociado a terceros de TIC, los requisitos contractuales y la supervisión de proveedores terceros críticos de servicios de TIC. Para muchas entidades financieras, DORA funciona como el acto jurídico sectorial específico de la Unión cuando se solapan obligaciones equivalentes a NIS2. Para proveedores SaaS y de TIC que prestan servicio a instituciones financieras, la presión de DORA suele llegar a través de cláusulas contractuales, auditorías de clientes, requisitos de planificación de salida, obligaciones de soporte en incidentes y pruebas de resiliencia.
ISO/IEC 27001:2022 proporciona la columna vertebral del sistema de gestión. Exige contexto, partes interesadas, alcance, responsabilidad del liderazgo, políticas, roles, evaluación de riesgos, tratamiento de riesgos, Declaración de Aplicabilidad, auditoría interna, revisión por la dirección y mejora continua. El Anexo A incluye controles directamente relevantes para la protección de PII, incluidos 5.34 Privacidad y protección de PII, 5.18 Derechos de acceso, 8.11 Enmascaramiento de datos, 5.23 Seguridad de la información para el uso de servicios en la nube, 8.15 Registro de eventos, 8.33 Información de prueba, 8.24 Uso de la criptografía y 8.10 Eliminación de información.
El reto no es que las organizaciones no tengan controles. El problema es que los controles están fragmentados. Los registros de privacidad están en Legal. Las revisiones de acceso están en TI. Los scripts de enmascaramiento están en Ingeniería. Los contratos con proveedores están en Compras. Las evidencias viven en tickets, capturas de pantalla, hojas de cálculo y correo electrónico.
ISO/IEC 27701:2025 e ISO/IEC 29151:2022 ayudan a unificar esas evidencias en torno a la gestión de la información de privacidad y las prácticas de protección de PII. Clarysec convierte esa estructura en un modelo operativo.
Del SGSI al PIMS: la cadena integrada de controles de privacidad
Un SGSI ISO/IEC 27001:2022 responde a una pregunta central: ¿la seguridad de la información está gobernada, basada en riesgos, implementada, supervisada y mejorada?
Un Sistema de Gestión de la Información de Privacidad, o PIMS, amplía esa pregunta para los datos personales: ¿se gestionan dentro del mismo sistema las responsabilidades de privacidad, las actividades de tratamiento de PII, los riesgos de privacidad, las obligaciones de responsables y encargados del tratamiento, los derechos de los interesados y las evidencias de los controles de privacidad?
ISO/IEC 27701:2025 amplía el SGSI hacia la gobernanza de la privacidad. ISO/IEC 29151:2022 lo complementa con directrices prácticas de protección de PII, incluida la limitación de la recogida, la gestión de la divulgación, la aplicación de enmascaramiento o seudonimización, la protección de transferencias, la restricción del acceso y la alineación de los controles con el riesgo de privacidad.
| Capa | Pregunta principal | Evidencias de auditoría habituales |
|---|---|---|
| ISO/IEC 27001:2022 | ¿Existe un SGSI gobernado y basado en riesgos, con controles seleccionados y operativos? | Alcance, partes interesadas, evaluación de riesgos, plan de tratamiento, SoA, políticas, auditoría interna, revisión por la dirección |
| ISO/IEC 27701:2025 | ¿Se gobiernan dentro del sistema de gestión las responsabilidades de privacidad, los riesgos de privacidad y las actividades de tratamiento de PII? | Roles de privacidad, registro de actividades de tratamiento, procedimientos de responsable y encargado del tratamiento, evaluaciones de riesgos de privacidad, EIPD, proceso de solicitudes de los interesados |
| ISO/IEC 29151:2022 | ¿Se han implementado medidas prácticas de protección de PII durante todo el ciclo de vida de los datos? | Clasificación de PII, restricciones de acceso, enmascaramiento, seudonimización, controles de conservación, salvaguardas de transferencia, evidencias de incidentes |
| GDPR | ¿Puede la organización demostrar un tratamiento lícito, leal, transparente, minimizado, seguro y sujeto a responsabilidad proactiva? | Registros de base jurídica, avisos de privacidad, EIPD, proceso de gestión de violaciones de seguridad, contratos con encargados del tratamiento, gestión de derechos |
| NIS2 y DORA | ¿Puede la organización gobernar los riesgos de ciberseguridad y resiliencia, incluidos incidentes y proveedores? | Supervisión por la dirección, marco de riesgo de TIC, clasificación de incidentes, playbooks de notificación, registros de proveedores, derechos de auditoría, pruebas de continuidad |
Este modelo por capas evita el error más común en el cumplimiento de privacidad: tratar la PII como otro tipo más de datos sensibles. La PII conlleva obligaciones legales, éticas, operativas, contractuales y reputacionales. Requiere una cadena de controles que empieza con la concienciación y termina con evidencias.
Empiece por la conciencia sobre los datos, no por diagramas de cifrado
El fallo de privacidad más común que observa Clarysec es la falta de contexto. Una empresa no puede proteger la PII si no sabe qué PII tiene, dónde reside, qué finalidad cumple, durante cuánto tiempo se conserva o quién puede acceder a ella.
Zenith Blueprint inicia este trabajo en una fase temprana de gestión de riesgos. En el Paso 9, Identificación de activos, amenazas y vulnerabilidades, indica a las organizaciones que inventaríen los activos de información y marquen explícitamente los datos personales:
“Para cada activo, registre los detalles clave: nombre/descripción, propietario, ubicación y clasificación (sensibilidad). Por ejemplo, un activo podría ser ‘Base de datos de clientes – propiedad del Departamento de TI – alojada en AWS – contiene datos personales y financieros (sensibilidad alta)’.”
También añade: “Asegúrese de que los activos de datos personales estén marcados (por su relevancia para GDPR) y de que los activos de servicios críticos estén identificados (por la posible aplicabilidad de NIS2 si opera en un sector regulado).”
Esta es la base para la adopción de ISO/IEC 27701:2025 e ISO/IEC 29151:2022. La secuencia práctica es sencilla:
- Identificar sistemas, conjuntos de datos, repositorios, registros, informes, copias de seguridad, herramientas de soporte, entornos de desarrollo y proveedores que tratan PII.
- Asignar un propietario a cada activo de PII.
- Clasificar la PII por sensibilidad, finalidad de negocio, base jurídica, rol de tratamiento y requisito de conservación.
- Conectar cada activo de PII con amenazas, vulnerabilidades, escenarios de riesgo y obligaciones regulatorias.
- Seleccionar controles, asignar evidencias y supervisar su operación a lo largo del tiempo.
Las políticas de Clarysec hacen que esto sea ejecutable. La Política de Protección de Datos y Privacidad para pymes Política de Protección de Datos y Privacidad para pymes establece:
“El Coordinador de Privacidad debe mantener un registro de todas las actividades de tratamiento de datos personales, incluidas las categorías de datos, la finalidad, la base jurídica y los períodos de conservación”
De la sección ‘Requisitos de gobernanza’, cláusula de política 5.2.1.
Para organizaciones empresariales, la Política de Protección de Datos y Privacidad Política de Protección de Datos y Privacidad establece una regla estricta de minimización:
“Solo podrán recopilarse y tratarse los datos necesarios para una finalidad de negocio específica y legítima.”
De la sección ‘Requisitos de implementación de la política’, cláusula de política 6.2.1.
Estas cláusulas convierten la responsabilidad proactiva de GDPR en operaciones diarias. También respaldan la gestión de la información de privacidad y la protección de PII porque obligan a la organización a definir qué datos existen, por qué existen y si son necesarios.
Los tres controles que hacen real la protección de PII
Tres controles del Anexo A de ISO/IEC 27001:2022 suelen determinar si la protección de PII es defendible en auditoría: 5.34 Privacidad y protección de PII, 8.11 Enmascaramiento de datos y 5.18 Derechos de acceso.
5.34 Privacidad y protección de PII
El control 5.34 es el núcleo de gobernanza. En Zenith Controls, 5.34 se trata como un control preventivo que respalda la confidencialidad, la integridad y la disponibilidad, con conceptos de ciberseguridad de Identificar y Proteger y capacidades operativas de protección de la información y cumplimiento legal.
Zenith Controls deja clara la dependencia:
“Un inventario de activos de información (5.9) debe incluir los repositorios de datos PII (bases de datos de clientes, archivos de RR. HH.). Esto sustenta 5.34 al garantizar que la organización sabe qué PII tiene y dónde se encuentra, que es el primer paso para protegerla.”
El control 5.34 depende de 5.9 Inventario de información y otros activos asociados porque la PII no puede protegerse si no puede encontrarse. También se conecta con 5.23 Seguridad de la información para el uso de servicios en la nube, porque la mayor parte de la PII reside ahora en plataformas en la nube, herramientas SaaS, entornos de analítica y servicios gestionados.
Para tratamientos de alto riesgo, la Política de Protección de Datos y Privacidad empresarial exige:
“El modelado de amenazas y las Evaluaciones de Impacto relativas a la Protección de Datos (EIPD) son obligatorios para los sistemas de tratamiento de alto riesgo.”
De la sección ‘Requisitos de implementación de la política’, cláusula de política 6.3.4.
Esa cláusula es crítica. Convierte la privacidad en una actividad de diseño y de gestión de riesgos, no en una revisión legal de última hora.
8.11 Enmascaramiento de datos
El control 8.11 es la respuesta directa a la exposición de la base de datos de preproducción de Sarah. Zenith Controls describe 8.11 como un control preventivo de confidencialidad dentro de la protección de la información. Vincula 8.11 con 5.12 Clasificación de la información porque las decisiones de enmascaramiento dependen de la sensibilidad, con 5.34 porque el enmascaramiento respalda la protección de la privacidad, y con 8.33 Información de prueba porque los entornos de prueba no deben exponer PII real.
La Política de Enmascaramiento de Datos y Seudonimización Política de Enmascaramiento de Datos y Seudonimización explicita la regla:
“Los datos personales reales no deben utilizarse en entornos de desarrollo, prueba o preproducción. En su lugar deben utilizarse datos enmascarados o seudonimizados, que deben generarse a partir de plantillas de transformación preaprobadas.”
De la sección ‘Requisitos de implementación de la política’, cláusula de política 6.3.
Para pymes, la Política de Enmascaramiento de Datos y Seudonimización para pymes Política de Enmascaramiento de Datos y Seudonimización para pymes añade un requisito clave de seguridad y evidencias:
“El acceso a las claves debe estar cifrado, sujeto a control de acceso y registrado.”
De la sección ‘Requisitos de implementación de la política’, cláusula de política 6.2.1.3.
Esto importa porque la seudonimización solo reduce el riesgo cuando se controlan la lógica de transformación, las claves y las rutas de reidentificación.
5.18 Derechos de acceso
El control 5.18 es el núcleo operativo del mínimo privilegio. Zenith Controls lo trata como preventivo, vinculado a la confidencialidad, integridad y disponibilidad, y situado dentro de la gestión de identidades y accesos. Relaciona 5.18 con 5.15 Control de acceso, 5.16 Gestión de identidades y 8.2 Derechos de acceso privilegiado.
La Política de Clasificación y Etiquetado de Datos para pymes Política de Clasificación y Etiquetado de Datos para pymes establece:
“El acceso debe limitarse a usuarios específicamente autorizados con necesidad de conocer.”
De la sección ‘Requisitos de gobernanza’, cláusula de política 5.2.1.
La Política de Clasificación y Etiquetado de Datos empresarial Política de Clasificación y Etiquetado de Datos añade la configuración de referencia de clasificación:
“Todos los activos de información deben tener una clasificación claramente asignada en el momento de su creación o incorporación. En ausencia de una clasificación explícita, los activos deben considerarse ‘Confidencial’ por defecto hasta su revisión formal.”
De la sección ‘Requisitos de gobernanza’, cláusula de política 5.4.
En conjunto, estos controles forman la cadena práctica de protección de PII: conocer la PII, clasificarla, limitar el acceso, enmascararla cuando la identidad completa no sea necesaria, proteger las claves, registrar el acceso y conservar evidencias.
Construir trazabilidad mediante la Declaración de Aplicabilidad
Un sistema de gestión de la privacidad está listo para auditoría cuando puede demostrar trazabilidad. Zenith Blueprint, fase de gestión de riesgos, Paso 13, Planificación del tratamiento del riesgo y Declaración de Aplicabilidad, describe la Declaración de Aplicabilidad como un documento puente:
“La SoA es, en la práctica, un documento puente: vincula su evaluación/tratamiento de riesgos con los controles reales que tiene. Al completarla, también comprueba si se ha dejado algún control sin considerar.”
Ese concepto es central para la preparación de ISO/IEC 27701:2025, ISO/IEC 29151:2022, GDPR, NIS2 y DORA. Cada control de PII debe ser trazable desde el requisito hasta el riesgo, del riesgo al control, del control al propietario, del propietario a la evidencia y de la evidencia a la revisión.
| Elemento de trazabilidad | Ejemplo para PII de soporte al cliente | Evidencia esperada |
|---|---|---|
| Activo de PII | Plataforma de tickets de soporte con nombres de clientes, correos electrónicos, registros y adjuntos | Entrada del registro de activos, propietario, ubicación en la nube, clasificación |
| Finalidad del tratamiento | Soporte al cliente y diagnóstico del servicio | Registro de actividades de tratamiento, base jurídica, período de conservación |
| Escenario de riesgo | Un agente de soporte o desarrollador accede a datos excesivos de clientes | Entrada del registro de riesgos, probabilidad, impacto, propietario |
| Selección de controles | 5.34 Protección de PII, 5.18 Derechos de acceso, 8.11 Enmascaramiento, 8.15 Registro de eventos, 5.23 Gobernanza de la nube | SoA, política de acceso, estándar de enmascaramiento, configuración de registro |
| Evidencia operativa | Acceso basado en roles, exportaciones enmascaradas, revisión trimestral de accesos, alertas ante descargas masivas | Registros de revisión de accesos, alertas DLP, registros, evidencias de tickets |
| Mapeo regulatorio | Responsabilidad proactiva y seguridad de GDPR, gestión de riesgos de NIS2, requisitos de riesgo de TIC y proveedores de DORA | Matriz de cumplimiento, playbook de incidentes, registro de contratos de proveedores |
| Evidencia de revisión | Hallazgo de auditoría interna cerrado, acción de revisión por la dirección aceptada | Informe de auditoría, acción correctiva, actas de revisión por la dirección |
ISO/IEC 27005:2022 respalda este enfoque basado en riesgos al enfatizar los requisitos de las partes interesadas, criterios de riesgo comunes, propietarios del riesgo responsables, evaluación de riesgos repetible, tratamiento de riesgos, selección de controles, alineación de la Declaración de Aplicabilidad, aprobación del riesgo residual, supervisión y mejora continua. La protección de PII debe ser un ciclo vivo de riesgos, no un ejercicio puntual de documentación de GDPR.
Corregir la hoja de cálculo y la base de datos de preproducción de riesgo
El incidente de Sarah puede convertirse en un paquete de controles repetible si la remediación se gestiona de forma sistemática.
| Paso | Acción | Resultado de evidencia de Clarysec |
|---|---|---|
| 1 | Registrar la base de datos de preproducción y la hoja de cálculo como activos de PII | Entradas del inventario de activos con propietario, ubicación, clasificación, categorías de PII, finalidad y conservación |
| 2 | Actualizar la actividad de tratamiento | Entrada del registro que muestre categorías de datos, base jurídica, finalidad y período de conservación |
| 3 | Clasificar los archivos y conjuntos de datos | Clasificación Confidencial o superior aplicada por defecto hasta su revisión formal |
| 4 | Eliminar la PII real de entornos no productivos | Conjunto de datos enmascarado o seudonimizado generado a partir de plantillas de transformación aprobadas |
| 5 | Restringir y revisar el acceso | Permisos basados en la necesidad de conocer, acceso excesivo revocado, registro de revisión de accesos |
| 6 | Proteger la lógica de transformación y las claves | Acceso a claves cifrado, sujeto a control de acceso y registrado |
| 7 | Capturar evidencias de forma centralizada | Registro de activos, entrada de riesgo, revisión de accesos, prueba de eliminación, aprobación de enmascaramiento y cierre de ticket |
| 8 | Actualizar la SoA y el plan de tratamiento de riesgos | Escenario de riesgo vinculado con 5.34, 5.18, 8.11, 8.15, 8.10, 5.23 y controles de proveedores |
| 9 | Decidir si se requiere una EIPD | EIPD o justificación documentada para decisiones de tratamiento de alto riesgo |
| 10 | Registrar las lecciones aprendidas | Formación actualizada, reglas de desarrollo seguro, controles de exportación, supervisión DLP y directrices de datos de prueba |
La Política de Auditoría y Supervisión del Cumplimiento para pymes Política de Auditoría y Supervisión del Cumplimiento para pymes establece:
“Todas las evidencias deben almacenarse en una carpeta de auditoría centralizada.”
De la sección ‘Requisitos de implementación de la política’, cláusula de política 6.2.1.
La Política de Seguridad de la Información Política de Seguridad de la Información explicita la expectativa general de auditoría:
“Todos los controles implementados deberán ser auditables, estar respaldados por procedimientos documentados y contar con evidencias conservadas de su operación.”
De la sección ‘Requisitos de implementación de la política’, cláusula de política 6.6.1.
Esas dos cláusulas marcan la diferencia entre tener un control y poder demostrarlo.
Mapeo de cumplimiento transversal para un único conjunto de controles de PII
La protección de PII resulta más fácil de defender cuando se mapea frente a varios marcos antes de que lo pida el auditor.
| Tema de protección de PII | Relevancia para GDPR | Relevancia para ISO/IEC 27001:2022, ISO/IEC 27701:2025 e ISO/IEC 29151:2022 | Relevancia para NIS2 | Relevancia para DORA | Enfoque de auditoría NIST y COBIT 2019 |
|---|---|---|---|---|---|
| Inventario de PII y registro de actividades de tratamiento | Responsabilidad proactiva, base jurídica, limitación de la finalidad, limitación del plazo de conservación | Contexto del SGSI, 5.9 Inventario de activos, gestión de la información de privacidad, protección de PII | Gestión de activos y análisis de riesgos | Conocimiento de activos de TIC y dependencias de servicios | Evidencias de la función Identificar y gobernanza sobre activos de información |
| Derechos de acceso y mínimo privilegio | Integridad y confidencialidad, acceso limitado por rol | 5.15 Control de acceso, 5.16 Gestión de identidades, 5.18 Derechos de acceso, 8.2 Derechos de acceso privilegiado | Control de acceso, seguridad de recursos humanos, autenticación | Controles de riesgo de TIC y supervisión de acceso privilegiado | Aplicación de acceso, propiedad, responsabilidad y supervisión |
| Enmascaramiento y seudonimización | Minimización de datos, protección de datos desde el diseño, seguridad del tratamiento | 5.12 Clasificación, 5.34 Protección de PII, 8.11 Enmascaramiento de datos, 8.33 Información de prueba | Higiene cibernética y desarrollo seguro | Pruebas seguras, reducción de pérdida de datos, resiliencia operativa | Pruebas de salvaguardas técnicas y operación fiable del control |
| Clasificación y notificación de incidentes | Evaluación y notificación de violaciones de la seguridad de los datos personales | Planificación de incidentes, evaluación de eventos, respuesta, recopilación de evidencias | Aviso temprano de 24 horas, notificación de 72 horas, informe final | Clasificación y notificación de incidentes graves relacionados con las TIC | Criterios de escalado, registros de decisiones, causa raíz, remediación |
| Tratamiento por proveedores y en la nube | Obligaciones de encargados del tratamiento, transferencias, contratos | 5.21 Cadena de suministro de TIC, 5.23 Servicios en la nube, 5.31 Requisitos legales y contractuales | Seguridad de la cadena de suministro | Riesgo asociado a terceros de TIC, derechos de auditoría, salida y transición | Gobernanza de terceros, aseguramiento y responsabilidad de la dirección |
Aquí es donde Zenith Controls resulta especialmente útil. Para 5.34, mapea la protección de PII con el inventario de activos, el enmascaramiento de datos y la gobernanza de la nube. Para 8.11, mapea el enmascaramiento con la clasificación, la protección de la privacidad y la información de prueba. Para 5.18, mapea los derechos de acceso con el control de acceso, la gestión de identidades y el acceso privilegiado. Estas relaciones permiten a un equipo explicar no solo que existe un control, sino por qué existe y qué controles adyacentes deben operar con él.
Cómo distintos auditores prueban el mismo control de PII
Un único control, como 8.11 Enmascaramiento de datos, se examinará de forma distinta según el enfoque de auditoría.
| Tipo de auditor | Foco principal | Evidencias que esperará |
|---|---|---|
| Auditor de ISO/IEC 27001:2022 e ISO/IEC 27701:2025 | Integración del SGSI y PIMS, tratamiento de riesgos, exactitud de la SoA | Evaluación de riesgos, entrada de la SoA, política de enmascaramiento, registros de cambios, resultados de auditoría interna |
| Revisor de GDPR o de una autoridad de protección de datos | Protección de datos desde el diseño, minimización, responsabilidad proactiva | Registro de actividades de tratamiento, base jurídica, EIPD, evidencias de seudonimización, lógica de conservación |
| Evaluador centrado en NIS2 | Desarrollo seguro, prevención de incidentes, gobernanza | Procedimiento de desarrollo seguro, formación de desarrolladores, evidencias de remediación de incidentes, revisión de la eficacia del control |
| Cliente o auditor de DORA | Resiliencia operativa digital y riesgo asociado a terceros | Evidencias de pruebas de aplicaciones críticas, cláusulas contractuales con proveedores, obligaciones de soporte en incidentes, planificación de recuperación y salida |
| Revisor con enfoque NIST o COBIT 2019 | Diseño del control, operación, propiedad, supervisión | Propietario del control, métricas, repositorio de evidencias, informes a la dirección, acciones correctivas |
Un auditor de ISO/IEC 27001:2022 empieza por la lógica del sistema de gestión. ¿La PII está dentro del alcance? ¿Se han identificado los requisitos de las partes interesadas? ¿Se evalúan los riesgos de privacidad con criterios definidos? ¿Se seleccionan los controles mediante el tratamiento de riesgos? ¿La SoA es exacta? ¿Las auditorías internas y las revisiones por la dirección cubren los controles relacionados con PII?
Un revisor de privacidad empieza por la responsabilidad proactiva. ¿Qué datos personales se tratan? ¿Cuál es la base jurídica? ¿Se informa a los interesados? ¿El tratamiento se limita a una finalidad específica? ¿Se evalúan las actividades de alto riesgo? ¿Se gobiernan los encargados del tratamiento?
Un evaluador centrado en NIS2 empieza por la gobernanza y la gestión de riesgos de ciberseguridad. ¿La dirección aprueba y supervisa las medidas? ¿Están integradas la gestión de incidentes, la continuidad, la seguridad de proveedores, el control de acceso, la gestión de activos, el desarrollo seguro y la evaluación de la eficacia de los controles?
Un cliente o auditor de DORA pregunta si la gestión del riesgo de las TIC está documentada, gobernada por el Consejo, es proporcional y está respaldada por contratos. Si se trata PII en servicios que respaldan a entidades financieras, cabe esperar preguntas sobre asistencia en incidentes, ubicaciones de tratamiento de datos, recuperación, derechos de auditoría, niveles de servicio, terminación y salida.
Un revisor de COBIT 2019 o con enfoque ISACA prueba la alineación de la gobernanza. ¿Quién es propietario del riesgo de PII? ¿Qué órgano de gobernanza recibe informes? ¿Están asignadas las responsabilidades? ¿Se supervisan los proveedores? ¿Se registran las desviaciones? ¿Se usan métricas para la toma de decisiones? ¿Se acepta formalmente el riesgo residual?
Un único modelo de evidencias puede satisfacer todos estos enfoques, pero solo si el sistema de controles está diseñado para la trazabilidad desde el principio.
Hallazgos de auditoría habituales en programas de protección de PII
Las organizaciones que abordan la preparación para ISO/IEC 27701:2025 o ISO/IEC 29151:2022 sin un conjunto de herramientas integrado suelen encontrar los mismos hallazgos.
| Hallazgo | Por qué importa | Remediación de Clarysec |
|---|---|---|
| El inventario de PII excluye registros, copias de seguridad, exportaciones analíticas o adjuntos de soporte | La PII oculta no puede protegerse ni eliminarse de forma fiable | Ampliar el inventario de activos del Paso 9 y el registro de actividades de tratamiento para incluir todas las ubicaciones de PII |
| Los entornos de prueba usan datos de producción | La PII real se expone donde no es necesaria | Aplicar la política de enmascaramiento y las plantillas de transformación aprobadas |
| Las revisiones de acceso son genéricas y no se centran en repositorios de PII | El acceso excesivo permanece sin detectar | Mapear 5.18 Derechos de acceso con propietarios de activos de PII y evidencias de revisión periódica |
| La base jurídica está documentada, pero no vinculada a sistemas ni a conservación | No puede demostrarse la responsabilidad proactiva de GDPR | Añadir campos de base jurídica y conservación al registro de actividades de tratamiento y al inventario de activos |
| Los contratos con proveedores carecen de ubicación de datos, asistencia en incidentes, derechos de auditoría o disposiciones de salida | Persisten brechas de aseguramiento de proveedores frente a DORA, NIS2 y GDPR | Alinear la diligencia debida de proveedores y los contratos con la gobernanza de terceros de TIC y de la nube |
| Los playbooks de incidentes no distinguen incidentes de seguridad de violaciones de la seguridad de los datos personales | Pueden incumplirse los plazos de notificación | Crear árboles de clasificación para activadores de notificación de GDPR, NIS2 y DORA |
| Las evidencias están dispersas entre tickets, unidades, capturas de pantalla y correo electrónico | La preparación para auditorías falla incluso cuando los controles operan | Usar carpetas de auditoría centralizadas y estándares de nomenclatura de evidencias |
Estos hallazgos no son problemas de documentación. Son problemas de modelo operativo. ISO/IEC 27701:2025 e ISO/IEC 29151:2022 no los corregirán salvo que la gobernanza de la privacidad, los controles de seguridad y la gestión de evidencias se incorporen a los flujos de trabajo habituales.
Qué debe preguntar la dirección antes de la próxima auditoría
Antes de iniciar la preparación para ISO/IEC 27701:2025, la implementación de ISO/IEC 29151:2022 o una evaluación de cliente sobre GDPR, NIS2 o DORA, la dirección debe plantear diez preguntas directas:
- ¿Disponemos de un registro completo de actividades de tratamiento de PII, incluidas categorías de datos, finalidad, base jurídica y conservación?
- ¿Los activos de PII están marcados en el inventario de activos, incluidos registros, copias de seguridad, exportaciones, herramientas de analítica y adjuntos de soporte?
- ¿Las clasificaciones de datos se asignan en la creación o incorporación, con activos no revisados clasificados por defecto como Confidencial?
- ¿Podemos demostrar que el acceso a PII se limita a usuarios autorizados con necesidad de conocer?
- ¿Los entornos de desarrollo, prueba y preproducción utilizan datos enmascarados o seudonimizados en lugar de datos personales reales?
- ¿Las plantillas de enmascaramiento están aprobadas, las claves protegidas, el acceso sujeto a control de acceso y registrado?
- ¿La SoA conecta los riesgos de PII con controles y obligaciones regulatorias?
- ¿Se revisan los contratos de nube y proveedores respecto de ubicación de datos, seguridad, soporte en incidentes, derechos de auditoría, recuperación y salida?
- ¿Nuestro proceso de incidentes puede clasificar violaciones de la seguridad de los datos personales de GDPR, incidentes significativos de NIS2 e incidentes graves relacionados con las TIC de DORA?
- ¿Las evidencias se almacenan de forma centralizada y se conservan de manera que un auditor pueda seguirlas?
Si la respuesta a cualquiera de estas preguntas no está clara, la organización aún no está lista para auditoría.
Hacer demostrable la protección de PII
El incidente nocturno de Sarah podría haberse convertido en una carrera fragmentada de cumplimiento. En cambio, puede ser el punto de partida de un modelo operativo más sólido: un SGSI ISO/IEC 27001:2022 ampliado hacia la privacidad mediante ISO/IEC 27701:2025, reforzado con prácticas de ISO/IEC 29151:2022 y mapeado frente a GDPR, NIS2, DORA, un enfoque de aseguramiento NIST y las expectativas de gobernanza de COBIT 2019.
Ese es el verdadero valor de la protección de PII lista para auditoría. No depende de encontrar la hoja de cálculo correcta antes de que llegue el auditor. Depende de un sistema que ya sabe dónde está la PII, por qué existe, cómo se protege, quién rinde cuentas, qué proveedores participan y dónde residen las evidencias.
Empiece con Zenith Blueprint: hoja de ruta de 30 pasos para auditores Zenith Blueprint para estructurar su implementación. Use Zenith Controls: la guía de cumplimiento transversal Zenith Controls para mapear la protección de PII en ISO/IEC 27001:2022, GDPR, NIS2, DORA, un enfoque de aseguramiento NIST y las expectativas de gobernanza de COBIT 2019. Operacionalice el trabajo con las políticas de Clarysec, incluidas la Política de Protección de Datos y Privacidad Política de Protección de Datos y Privacidad, la Política de Enmascaramiento de Datos y Seudonimización Política de Enmascaramiento de Datos y Seudonimización, la Política de Clasificación y Etiquetado de Datos Política de Clasificación y Etiquetado de Datos, la Política de Auditoría y Supervisión del Cumplimiento para pymes Política de Auditoría y Supervisión del Cumplimiento para pymes y la Política de Seguridad de la Información Política de Seguridad de la Información.
Si se acerca su próxima auditoría de cliente, revisión de GDPR, proyecto de preparación para NIS2 o evaluación de proveedor de DORA, no espere a que una violación de seguridad revele las deficiencias. Descargue los paquetes de herramientas de Clarysec, solicite una demo o programe una evaluación de protección de PII y construya un programa de privacidad que no solo sea conforme, sino defendible.
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
