Gobernanza de EIPD para ISO 27001, NIS2 y DORA
Son las 17:40 de un jueves y a María, directora de seguridad de la información de una fintech en rápido crecimiento, le piden aprobar una versión antes del cierre del trimestre.
El equipo de Producto lo presenta como un avance decisivo: una funcionalidad de autenticación de pagos basada en biometría y analítica del comportamiento que hará más fluido el acceso de los clientes y reducirá el fraude. Ingeniería afirma que no se está creando ninguna nueva base de datos principal. Ventas indica que un cliente financiero regulado está esperando. El responsable de la liberación ya ha marcado el ticket como cambio estándar.
Entonces el Delegado de Protección de Datos (DPO) formula tres preguntas.
¿La funcionalidad combinará datos biométricos o de comportamiento con atributos de cuenta? ¿Recibirá un subencargado en la nube telemetría o señales de autenticación? ¿Alguien ha evaluado si el cambio genera un alto riesgo para las personas?
La sala queda en silencio.
María tiene un Registro de Riesgos de ISO/IEC 27001:2022. Legal tiene un registro de actividades de tratamiento del RGPD de la UE. Compras tiene un cuestionario de proveedores. El equipo de nube tiene una revisión de seguridad del proveedor. El responsable de cambios tiene un ticket. El Consejo de Administración acaba de recibir una sesión informativa sobre las expectativas de responsabilidad proactiva de NIS2 y resiliencia operativa de DORA.
Ninguno de esos registros cuenta por sí solo la historia completa.
Este es el problema de la gobernanza de las EIPD en 2026. Las Evaluaciones de Impacto relativas a la Protección de Datos no pueden permanecer en una carpeta de privacidad a la espera de una autoridad reguladora. Deben convertirse en registros de decisión que conecten los Articles 25, 30, 32, 35 y 36 del RGPD de la UE con evidencias de riesgo de ISO/IEC 27001:2022, medidas de gestión de riesgos de ciberseguridad de NIS2, gobernanza de cambios TIC de DORA, aseguramiento de proveedores y responsabilidad proactiva a nivel del Consejo de Administración.
Las organizaciones que tienen dificultades no suelen estar ignorando el cumplimiento. Están realizando por separado la revisión de privacidad, la revisión de seguridad, la revisión de la nube y la revisión de cambios. Las organizaciones que tienen éxito crean un único flujo de trabajo de gobernanza trazable en el que los desencadenantes de EIPD, la evaluación de riesgos, la diligencia debida de proveedores, el mapeo de controles, las pruebas y la aprobación del riesgo residual forman una única cadena de evidencias.
Por qué las EIPD aisladas fallan en 2026
El RGPD de la UE introdujo la EIPD como mecanismo formal para evaluar tratamientos que probablemente entrañen un alto riesgo para las personas. En muchas empresas se convirtió en una tarea legal o de privacidad: un formulario que se cumplimenta cuando un proyecto parece sensible.
Ese modelo ya no es defendible.
Un cambio en el tratamiento de datos personales rara vez es solo un evento de privacidad. También es:
- Un evento de riesgo de seguridad de la información conforme a ISO/IEC 27001:2022.
- Un evento de gobernanza de la seguridad conforme a NIS2 si se ven afectados redes y sistemas de información, proveedores o controles de seguridad.
- Un evento de cambio TIC y resiliencia conforme a DORA para entidades financieras y proveedores de servicios TIC relevantes.
- Un evento de riesgo de proveedores y nube cuando intervienen encargados del tratamiento, subencargados, interfaces de programación de aplicaciones, SDK o servicios alojados.
Cuando esas evaluaciones se realizan por separado, las brechas se vuelven peligrosas. Un equipo de privacidad puede aprobar una EIPD sin comprender las vulnerabilidades de un SDK biométrico. Un equipo de TI puede liberar un cambio sin advertir que implica datos de categorías especiales o monitorización del comportamiento. Un equipo de seguridad puede revisar un servicio en la nube sin conectarlo con los riesgos específicos para los derechos y libertades identificados en la EIPD.
La respuesta no es más documentación. La respuesta es una gobernanza integrada.
Una EIPD debe tratarse como el desencadenante que inicia un flujo de trabajo coordinado de riesgos entre privacidad, seguridad, nube, proveedores, ingeniería, legal y dirección.
La base del RGPD de la UE: la gobernanza de EIPD empieza con el conocimiento del tratamiento
Una EIPD no puede ser fiable si la organización no puede explicar qué trata, por qué lo trata, quién lo recibe y durante cuánto tiempo se conserva.
La responsabilidad proactiva del RGPD de la UE exige más que una declaración de intenciones. Article 5 establece principios básicos como licitud, lealtad, transparencia, limitación de la finalidad, minimización de datos, exactitud, limitación del plazo de conservación, integridad y confidencialidad. También exige que el responsable del tratamiento pueda demostrar el cumplimiento. Article 25 exige privacidad desde el diseño y por defecto. Article 30 exige registros de actividades de tratamiento. Article 32 exige seguridad del tratamiento. Article 35 exige una EIPD cuando es probable que el tratamiento entrañe alto riesgo. Article 36 exige consulta previa cuando persiste un alto riesgo sin mitigación suficiente.
Para organizaciones SaaS, fintech, en la nube y de servicios gestionados, esto significa que todo cambio material debe someterse a una evaluación preliminar de impacto en privacidad. El desencadenante no es que un proyecto esté etiquetado como “privacidad”. El desencadenante es si el cambio afecta a datos personales, finalidad del tratamiento, base jurídica, destinatarios, conservación, derechos de acceso, proveedores, ubicaciones en la nube o riesgo residual.
La Política de Protección de Datos y Privacidad - pyme de Clarysec lo convierte en un requisito operativo:
“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 plazos de conservación”
De la sección “Requisitos de gobernanza”, cláusula de política 5.2.1.
La misma política para pymes incorpora la privacidad en la entrega:
“La privacidad desde el diseño y por defecto debe aplicarse en todos los nuevos sistemas y servicios”
De la sección “Requisitos de gobernanza”, cláusula de política 5.3.1.
Para entornos empresariales, la Política de Protección de Datos y Privacidad de Clarysec hace explícita la puerta de control de la EIPD:
“Todos los cambios significativos en sistemas o procesos que impliquen información de identificación personal (PII) deberán requerir una Evaluación de Impacto relativa a la Protección de Datos (DPIA) documentada, revisada por el Delegado de Protección de Datos (DPO).”
De la sección “Requisitos de gobernanza”, cláusula de política 5.6.
Esa cláusula es el puente entre la responsabilidad proactiva del RGPD de la UE y el control operativo. Traslada la EIPD de una consideración legal tardía a la gobernanza de proyectos y a la aprobación de cambios.
Conectar la EIPD con las evidencias de riesgo de ISO/IEC 27001:2022
ISO/IEC 27001:2022 proporciona la estructura de sistema de gestión que necesita la gobernanza de EIPD.
Las cláusulas 4.1 a 4.4 exigen que la organización comprenda su contexto, las partes interesadas, los requisitos, el alcance del SGSI y los procesos que interactúan. Las leyes de privacidad, los contratos con clientes, las obligaciones NIS2, los requisitos DORA, las obligaciones de los encargados del tratamiento y las dependencias de proveedores forman parte de ese contexto.
Las cláusulas 5.1 a 5.3 exigen liderazgo, alineación de políticas, recursos, roles y responsabilidades. Aquí es donde fallan muchas EIPD. Un DPO puede identificar alto riesgo, pero sin Propietarios del Riesgo, reglas de escalado y criterios de aceptación respaldados por la dirección, la EIPD se convierte en un documento en lugar de una decisión.
Las cláusulas 6.1.1 a 6.1.3 exigen planificación basada en riesgos, un proceso documentado de evaluación de riesgos de seguridad de la información, criterios de aceptación del riesgo, Propietarios del Riesgo, planificación del tratamiento, selección de controles, una Declaración de Aplicabilidad y la aprobación del riesgo residual. Esa es la estructura que debe utilizar una EIPD.
Una EIPD puede identificar daños como riesgo de elaboración de perfiles, divulgación no autorizada, uso secundario ilícito, fraude de identidad, discriminación o conservación excesiva. El SGSI traduce esos daños en escenarios de riesgo, análisis de probabilidad e impacto, acciones de tratamiento, controles del Anexo A y aprobaciones de riesgo residual.
La Política de gestión de riesgos - pyme de Clarysec define la disciplina mínima:
“Cada entrada de riesgo debe incluir: descripción, probabilidad, impacto, puntuación, propietario y Plan de Tratamiento de Riesgos.”
De la sección “Requisitos de gobernanza”, cláusula de política 5.1.2.
Para entornos empresariales, la Política de gestión de riesgos de Clarysec conecta la planificación del tratamiento con las evidencias de ISO/IEC 27001:2022:
“El Responsable de Riesgos deberá garantizar que los tratamientos sean realistas, estén acotados en el tiempo y estén mapeados con controles del Anexo A de ISO/IEC 27001.”
De la sección “Requisitos de implementación de la política”, cláusula de política 6.4.2.
El Zenith Blueprint: hoja de ruta de 30 pasos para auditores, fase de gestión de riesgos, paso 13, Planificación del Tratamiento de Riesgos y Declaración de Aplicabilidad, explica claramente la función de la SoA:
“La SoA es, en la práctica, un documento puente: vincula su evaluación/tratamiento de riesgos con los controles reales que tiene.”
Ese es el modelo de EIPD preparado para auditoría. Un hallazgo de EIPD no debe terminar con “riesgo aceptado”. Debe mapearse con el Registro de Riesgos, el Plan de Tratamiento de Riesgos, la Declaración de Aplicabilidad, la revisión del proveedor, la diligencia debida de la nube, el ticket de cambio, las evidencias de prueba y la decisión de la dirección.
Un registro de decisión, múltiples resultados de cumplimiento
Un flujo de trabajo maduro de gobernanza de EIPD no duplica cada regulación. Recopila evidencias una vez y las reutiliza de forma inteligente.
| Pregunta de gobernanza de EIPD | Evidencia creada | Evidencia de ISO/IEC 27001:2022 | Valor para la responsabilidad proactiva del RGPD de la UE | Valor para NIS2 o DORA |
|---|---|---|---|---|
| ¿Qué tratamiento está cambiando? | Actualización del registro de tratamiento y entrada de EIPD | Evidencia de alcance, contexto, activos y procesos | Apoya los registros de actividades de tratamiento y la privacidad desde el diseño | Demuestra conocimiento del riesgo operativo |
| ¿Qué podría causar daño a las personas? | Escenario de riesgo de privacidad y evaluación de impacto | Resultado de la evaluación de riesgos y Propietario del Riesgo | Apoya el razonamiento de la EIPD y la responsabilidad proactiva | Se alinea con la gobernanza de ciberseguridad basada en riesgos |
| ¿Qué controles reducen el riesgo? | Salvaguardas, medidas técnicas y organizativas (MTO) y Plan de Tratamiento de Riesgos | SoA, Plan de Tratamiento de Riesgos y estado de implantación del Anexo A | Apoya la seguridad del tratamiento y la privacidad por defecto | Apoya las medidas de ciberseguridad y de riesgo TIC |
| ¿Quién más trata o accede a los datos? | Revisión de proveedor, encargado del tratamiento y nube | Evidencias de controles de proveedores y nube | Apoya la supervisión de encargados del tratamiento y la gobernanza de transferencias | Apoya la cadena de suministro y el riesgo TIC de terceros |
| ¿Qué cambió en producción? | Registro de cambio, evidencias de prueba y aprobación | Evidencias de gestión de cambios y control operativo | Demuestra que los controles se consideraron antes de la liberación | Apoya las expectativas de riesgo de cambio y resiliencia |
| ¿Quién aceptó el riesgo residual? | Aprobación del DPO, Propietario del Riesgo y dirección | Aceptación del riesgo residual y entrada para la revisión por la dirección | Demuestra toma de decisiones responsable | Apoya la supervisión del Consejo de Administración u órgano de dirección |
Esta cadena de evidencias se alinea directamente con la cláusula 8.1 de ISO/IEC 27001:2022, que exige procesos operativos planificados y controlados, evidencias documentadas, control de los cambios planificados y revisión de los cambios no previstos. La cláusula 8.2 exige evaluaciones de riesgos a intervalos planificados o cuando se propongan o se produzcan cambios significativos. La cláusula 8.3 exige la implantación del Plan de Tratamiento de Riesgos. La cláusula 9 convierte después las evidencias en aseguramiento mediante supervisión, medición, auditoría interna y revisión por la dirección.
La Política de Protección de Datos y Privacidad - pyme hace explícito el momento de la evaluación:
“El Coordinador de Privacidad debe evaluar los riesgos de privacidad anualmente y durante cambios importantes en los sistemas”
De la sección “Tratamiento de riesgos y excepciones”, cláusula de política 7.1.1.
Si un cambio importante que afecta a datos personales no activa la evaluación preliminar de EIPD y la reevaluación del SGSI, el proceso de gobernanza está incompleto.
NIS2: la gobernanza de EIPD se convierte en responsabilidad de la dirección
NIS2 incrementa la presión de gobernanza sobre las organizaciones de sectores esenciales e importantes. Se aplica a muchas entidades públicas y privadas de sectores enumerados que cumplen los umbrales de tamaño pertinentes, y puede aplicarse con independencia del tamaño en casos específicos como servicios de confianza, DNS, registros TLD, servicios públicos de comunicaciones electrónicas, proveedores únicos de servicios esenciales o entidades con funciones de riesgo sistémico.
Para la gobernanza de EIPD, el punto clave no es solo el alcance. Es la responsabilidad de la dirección.
NIS2 Article 20 exige que los órganos de dirección de las entidades esenciales e importantes aprueben las medidas de gestión de riesgos de ciberseguridad, supervisen su implantación y sigan formación. Article 21 exige medidas técnicas, operativas y organizativas adecuadas y proporcionadas basadas en la exposición al riesgo, el tamaño, la probabilidad, la severidad, el impacto social y económico, el estado de la técnica y las normas pertinentes.
Article 21(2) incluye ámbitos que se solapan con frecuencia con los resultados de una EIPD, entre ellos:
- Análisis de riesgos y políticas de seguridad de los sistemas de información.
- Gestión de incidentes.
- Continuidad del negocio y gestión de crisis.
- Seguridad de la cadena de suministro.
- Seguridad en la adquisición, desarrollo y mantenimiento de redes y sistemas de información.
- Gestión y divulgación de vulnerabilidades.
- Políticas para evaluar la eficacia de las medidas de gestión de riesgos de ciberseguridad.
- Higiene cibernética y formación.
- Criptografía y cifrado.
- Seguridad de Recursos Humanos, control de acceso y gestión de activos.
- Autenticación multifactor, autenticación continua, comunicaciones seguras y comunicaciones de emergencia seguras.
Por tanto, una EIPD para una nueva actividad de tratamiento biométrico, de analítica del comportamiento o basada en la nube debe plantear preguntas relevantes para NIS2. ¿Depende el tratamiento de un nuevo proveedor? ¿Introduce una nueva interfaz de programación de aplicaciones, SDK, flujo de identidad o modelo de acceso? ¿Cambia el impacto de los incidentes? ¿Requiere cifrado, registro de eventos reforzado, comprobaciones de desarrollo seguro o aprobación de la dirección?
La pregunta práctica de gestión es sencilla: ¿puede la organización demostrar que un cambio con impacto en privacidad se consideró como parte de la gestión de riesgos de ciberseguridad antes de su implantación?
Esa prueba debe ser visible en la entrada de EIPD, el registro de tratamiento actualizado, el Registro de Riesgos, el Plan de Tratamiento de Riesgos, la Declaración de Aplicabilidad, la diligencia debida de proveedores, las evidencias de pruebas de seguridad, la aprobación del cambio y la aceptación del riesgo residual.
DORA: las evidencias de cambio TIC y de terceros son inevitables
DORA es aplicable desde el 17 de enero de 2025 y crea un marco uniforme de la UE para la gestión del riesgo TIC, la notificación de incidentes graves relacionados con las TIC, las pruebas de resiliencia operativa digital, el intercambio de información sobre ciberamenazas y vulnerabilidades, la gestión del riesgo de terceros TIC y la supervisión de proveedores terceros críticos de servicios TIC.
Para las entidades financieras, DORA actúa generalmente como acto jurídico sectorial específico de la Unión para las obligaciones de gestión del riesgo TIC y notificación de incidentes, mientras que NIS2 sigue siendo relevante para la coordinación más amplia del ecosistema y para entidades no cubiertas por DORA.
La gobernanza de EIPD importa bajo DORA porque el tratamiento de datos personales suele residir dentro de sistemas TIC, servicios de terceros, entornos en la nube y flujos de trabajo operativos.
DORA Article 5 exige marcos internos de gobernanza y control para la gestión del riesgo TIC, con responsabilidad del órgano de dirección. Article 6 exige un marco documentado de gestión del riesgo TIC integrado en la gestión global del riesgo. Articles 8 a 14 cubren la identificación de activos y dependencias, protección y prevención, detección, continuidad, copia de seguridad, recuperación, lecciones aprendidas y comunicaciones de crisis.
DORA Article 28 exige que las entidades financieras gestionen el riesgo de terceros TIC como parte integrante de la gestión del riesgo TIC y sigan siendo responsables cuando utilicen servicios TIC. Exige registros de contratos de servicios TIC, evaluaciones precontractuales, diligencia debida, evaluación del riesgo de concentración, planificación de auditorías e inspecciones, derechos de terminación y estrategias de salida. Article 30 exige contratos escritos con descripciones claras del servicio, ubicaciones de los datos, protecciones de confidencialidad, integridad y disponibilidad, recuperación y devolución de datos, asistencia en incidentes, cooperación con autoridades, derechos de terminación y salvaguardas adicionales para funciones críticas o importantes.
Para una EIPD, esto cambia la pregunta sobre proveedores. “¿Tenemos un contrato de encargo de tratamiento?” no es suficiente. La pregunta adecuada es: ¿podemos demostrar que la dependencia TIC, la ubicación de los datos, la subcontratación, los estándares de seguridad, la resiliencia, los derechos de auditoría, el soporte ante incidentes y la estrategia de salida se evaluaron antes de aprobar el tratamiento?
La Política de Uso de la Nube de Clarysec hace explícito este control previo a la activación:
“Todo uso de la nube debe someterse a diligencia debida basada en riesgos antes de su activación, incluida la evaluación del proveedor, la validación del cumplimiento legal y las revisiones de validación de controles.”
De la sección “Requisitos de gobernanza”, cláusula de política 5.2.
Una EIPD no debe aprobar un nuevo encargado de analítica, proveedor de identidad, SDK biométrico o plataforma de telemetría en la nube salvo que la diligencia debida de la nube, la validación legal y la validación de controles estén completas o se hayan registrado explícitamente como acciones de tratamiento.
Los anclajes de ISO/IEC 27002:2022: privacidad, proyectos y cambios
La Zenith Controls: guía de cumplimiento transversal de Clarysec trata los controles de ISO/IEC 27002:2022 como anclajes de cumplimiento transversal. Para la gobernanza de EIPD, tres controles son especialmente importantes.
| Control de ISO/IEC 27002:2022 | Por qué importa para la gobernanza de EIPD | Valor de cumplimiento transversal |
|---|---|---|
| 5.34 Privacidad y protección de la PII | Exige conocimiento y protección de los datos personales a lo largo de su ciclo de vida | Apoya la responsabilidad proactiva del RGPD de la UE, el Anexo A de ISO/IEC 27001:2022, las medidas de riesgo NIS2 y las expectativas de protección de datos de DORA |
| 5.8 Seguridad de la información en la gestión de proyectos | Incorpora el análisis de impacto de seguridad y privacidad al diseño del proyecto | Apoya la privacidad desde el diseño, el desarrollo seguro y las medidas de adquisición y desarrollo de NIS2 |
| 8.32 Gestión de cambios | Garantiza que los cambios se evalúen, autoricen, prueben, implanten y revisen | Apoya el control operativo ISO, la gobernanza de cambios TIC de DORA y la trazabilidad de auditoría |
La entrada de Zenith Controls para 5.34, Privacidad y protección de la PII, la clasifica como preventiva, asociada a confidencialidad, integridad y disponibilidad, alineada con los conceptos de ciberseguridad Identificar y Proteger, y vinculada a la protección de la información y a capacidades legales y de cumplimiento.
El Zenith Blueprint, fase Controles en acción, paso 23, expone el punto práctico:
“La base de este control es el conocimiento de los datos. La organización debe saber qué PII recopila, dónde reside, por qué se está tratando y quién puede acceder a ella.”
La entrada de Zenith Controls para 5.8, Seguridad de la información en la gestión de proyectos, la clasifica como preventiva, asociada a confidencialidad, integridad y disponibilidad, alineada con Identificar y Proteger, y ubicada en dominios de gobernanza, ecosistema y protección.
El Zenith Blueprint, fase Controles en acción, paso 22, afirma:
“El objetivo de este control no es sobrecargar los proyectos con burocracia. Es garantizar que la seguridad se trate como un insumo de diseño, no como una fase de pruebas.”
La privacidad debe tratarse del mismo modo. Una EIPD después de la puesta en producción suele ser un informe de daños. Una EIPD durante el diseño es prevención de riesgos.
La entrada de Zenith Controls para 8.32, Gestión de cambios, la clasifica como preventiva, asociada a confidencialidad, integridad y disponibilidad, alineada con Proteger, y vinculada a capacidades de seguridad de aplicaciones y seguridad de sistemas y redes.
El Zenith Blueprint, fase Controles en acción, paso 21, es directo:
“El cambio es inevitable, pero en ciberseguridad, el cambio no controlado es peligroso.”
La Política de gestión de cambios - pyme de Clarysec recoge el desencadenante:
“Si un cambio implica datos sensibles, derechos de acceso a sistemas o integraciones externas, se requiere una revisión del impacto en la seguridad. El responsable de seguridad o cumplimiento designado debe evaluar si el cambio introduce riesgos adicionales y recomendar salvaguardas adicionales.”
De la sección “Tratamiento de riesgos y excepciones”, cláusula de política 7.5.1.
Para entornos empresariales, la Política de gestión de cambios de Clarysec establece la expectativa del CAB:
“Evaluar los cambios por riesgos de seguridad y cumplimiento antes de la aprobación del Comité Asesor de Cambios.”
De la sección “Roles y responsabilidades”, cláusula de política 4.6.1.
Ejemplo práctico: aprobación de una funcionalidad de analítica biométrica
María no necesita tres proyectos de gobernanza separados. Necesita una única entrada integrada de proyecto y un flujo de trabajo de riesgos.
El equipo de producto propone autenticación biométrica de pagos con analítica del comportamiento. La funcionalidad recopila plantillas biométricas, metadatos de dispositivos, atributos de cuenta, direcciones IP, eventos de autenticación y señales de fraude. Utiliza un proveedor de analítica en la nube y un SDK biométrico de un tercero. Los equipos de éxito del cliente recibirán acceso agregado a un panel.
El ticket de cambio debe activar una evaluación preliminar de EIPD y una evaluación de riesgos antes de la asignación de recursos o la aprobación del CAB.
| Campo de entrada | Respuesta de ejemplo |
|---|---|
| Datos personales implicados | Plantilla biométrica, ID de usuario, dirección IP, metadatos del dispositivo, rol de cuenta, eventos de autenticación |
| Finalidad del tratamiento | Autenticación de pagos, detección de fraude y analítica de éxito del cliente |
| Base jurídica que confirmar | Necesidad contractual, intereses legítimos o consentimiento explícito, sujeto a revisión del DPO |
| Nuevo proveedor o servicio en la nube | Proveedor de SDK biométrico y encargado de analítica en la nube en región de la UE |
| Datos sensibles o de categorías especiales | Los datos biométricos requieren revisión de alto riesgo cuando se utilizan para identificación unívoca |
| Cambio del modelo de acceso | El equipo de éxito del cliente recibe acceso agregado a un panel |
| Cambio de conservación | Registros de eventos conservados durante 180 días; plantillas biométricas conservadas conforme a las condiciones del servicio |
| EIPD requerida | Sí; el tratamiento biométrico, la monitorización y la nueva dependencia de proveedor requieren revisión |
La evaluación integrada debe producir después un único expediente de riesgos.
| Sección de evaluación | Marco principal | Preguntas que responder | Evidencia o resultado |
|---|---|---|---|
| Descripción del tratamiento | RGPD de la UE Article 35 | ¿Qué datos se tratan, por qué, por quién y durante cuánto tiempo? | Flujo de datos, actualización del RoPA, entrada de EIPD |
| Necesidad y proporcionalidad | RGPD de la UE Article 35 | ¿Es necesario el tratamiento y es el enfoque viable menos intrusivo? | Revisión y justificación del DPO |
| Riesgo para las personas | RGPD de la UE Article 35 | ¿Podrían las personas sufrir robo de identidad, discriminación, elaboración de perfiles, exclusión o perjuicio financiero? | Análisis de riesgos de EIPD y entrada en el Registro de Riesgos ISO |
| Evaluación de riesgos de seguridad | ISO/IEC 27001:2022 cláusula 6.1.2 | ¿Qué amenazas de confidencialidad, integridad y disponibilidad existen? | Entradas del Registro de Riesgos con probabilidad, impacto, propietario y tratamiento |
| Análisis de impacto NIS2 | NIS2 Article 21 | ¿El cambio afecta a proveedores, desarrollo seguro, control de acceso, gestión de incidentes o continuidad? | Evaluación de proveedor, lista de verificación de desarrollo seguro, evidencias de dirección |
| Análisis de resiliencia DORA | DORA Articles 8, 9, 24 y 30 | ¿Se trata de un cambio TIC que afecta a la resiliencia, las pruebas o las obligaciones contractuales? | Registro de cambio, plan de pruebas, revisión contractual y evidencias de salida |
| Tratamiento de riesgos y controles | ISO/IEC 27001:2022 cláusula 6.1.3 | ¿Qué MTO y controles del Anexo A reducen el riesgo? | Plan de Tratamiento de Riesgos y Declaración de Aplicabilidad actualizada |
Las entradas de riesgo de ejemplo podrían ser las siguientes:
| Escenario de riesgo | Probabilidad | Impacto | Ejemplos de tratamiento | Mapeo de controles |
|---|---|---|---|---|
| Recopilación excesiva más allá de la finalidad declarada | Media | Alto | Revisión de minimización de datos, aprobación del esquema de eventos, límite de conservación | 5.34, 5.31, 8.10 |
| Acceso no autorizado al panel biométrico o de comportamiento | Media | Alto | Acceso basado en roles, MFA, registro de eventos, revisión trimestral de accesos | 5.15, 5.18, 8.15, 8.16 |
| Una configuración incorrecta del encargado en la nube expone telemetría | Baja | Alto | Diligencia debida de la nube, cifrado, configuración de referencia, supervisión | 5.23, 8.9, 8.24, 8.16 |
| Una vulnerabilidad del SDK biométrico compromete datos de autenticación | Media | Alto | Diligencia debida de proveedores, revisión de desarrollo seguro, pruebas de seguridad | 5.21, 8.25, 8.28, 8.29 |
| La elaboración de perfiles genera un impacto injusto en clientes | Media | Alto | Revisión del DPO, redacción de transparencia, gestión de oposición cuando proceda | 5.34, 5.8 |
Antes de la liberación, el registro de cambio debe contener la finalización de la EIPD o un Plan de Tratamiento de Riesgos aprobado por el DPO, el registro de tratamiento actualizado, la diligencia debida de proveedores y nube, la revisión del impacto en la seguridad, los resultados de las pruebas, el plan de reversión, el plan de supervisión y la aprobación del riesgo residual.
Después de la liberación, el propietario debe verificar registros, alertas, roles de acceso, paneles, reglas de conservación y flujos de trabajo de eliminación. Esto cierra el ciclo de cambio planificado conforme a la cláusula 8.1 de ISO/IEC 27001:2022 y apoya la disciplina de resiliencia operativa propia de DORA.
Qué preguntarán los auditores
Una EIPD unificada ofrece a distintos auditores una pista de evidencias coherente.
| Perspectiva del auditor | Foco probable de auditoría | Evidencias que deben existir |
|---|---|---|
| Auditor de ISO/IEC 27001:2022 | Si los cambios significativos activaron evaluación de riesgos, tratamiento, actualizaciones de la SoA y control operativo | Entrada de EIPD, Registro de Riesgos, Plan de Tratamiento de Riesgos, notas de SoA, registro de cambio, pista de auditoría interna |
| Revisor de privacidad del RGPD de la UE | Si el tratamiento de alto riesgo se evaluó antes del despliegue y las salvaguardas se documentaron | EIPD, registro de tratamiento, análisis de base jurídica, revisión del DPO, evidencias de transparencia y conservación |
| Auditor orientado a NIS2 | Si las medidas de riesgo aprobadas por la dirección cubren políticas de seguridad, cadena de suministro, gestión de incidentes, continuidad, acceso, cifrado y gestión de vulnerabilidades | Registros del Consejo de Administración o de revisión por la dirección, mapeo de controles, revisión de proveedores, vínculo con incidentes y continuidad |
| Auditor orientado a DORA | Si el cambio TIC, la dependencia de terceros, la resiliencia, las pruebas y las evidencias contractuales están integradas en la gobernanza del riesgo TIC | Evaluación del riesgo TIC, registro de proveedores, cláusulas contractuales, evidencias de pruebas, plan de salida, evidencias de soporte ante incidentes |
| Evaluador de NIST CSF | Si los resultados de gobernanza, riesgo, activos, proveedores, protección, detección, respuesta y recuperación están conectados | Perfil actual y objetivo, plan de brechas, Inventario de Activos, registros de riesgo de proveedores, evidencias de supervisión y respuesta |
| Auditor de COBIT 2019 o ISACA | Si la habilitación de cambios, la gestión de riesgos, los servicios de seguridad y las prácticas de aseguramiento están controlados | Registros del CAB, análisis de impacto, aprobaciones, pruebas, segregación de funciones, revisión posterior al cambio |
NIST CSF 2.0 es útil como capa de comunicación porque su función GOVERN sitúa la estrategia, las expectativas, la política, los roles, la supervisión y la gestión de riesgos de la cadena de suministro en el centro. COBIT 2019 añade aseguramiento de procesos, especialmente en torno a la habilitación estructurada de cambios, el análisis de impacto, las aprobaciones, las pruebas y la evaluación posterior al cambio.
Una autoridad reguladora del RGPD de la UE puede empezar por los derechos y libertades de las personas. Un auditor ISO puede empezar por la evaluación de riesgos documentada y la implantación de controles. Un revisor DORA puede empezar por la dependencia TIC y la resiliencia. Un revisor NIS2 puede empezar por la supervisión de la dirección y las medidas de ciberseguridad proporcionadas.
La misma cadena de evidencias de la EIPD debe satisfacerlos a todos.
Las decisiones de EIPD deben resistir los incidentes
Una EIPD no es solo un artefacto de aprobación previa a la liberación. Debe mejorar la preparación ante violaciones de seguridad de datos personales e incidentes.
El RGPD de la UE define una violación de la seguridad de los datos personales como una violación de seguridad que ocasiona la destrucción, pérdida o alteración accidental o ilícita de datos personales, o la comunicación o acceso no autorizados a dichos datos. NIS2 exige la notificación de incidentes significativos sin dilación indebida, incluida una alerta temprana en un plazo de 24 horas, una notificación en un plazo de 72 horas y un informe final a más tardar un mes después de la notificación del incidente. DORA exige que las entidades financieras detecten, gestionen, registren, clasifiquen, escalen y notifiquen incidentes graves relacionados con las TIC mediante informes iniciales, intermedios y finales, con notificación al cliente cuando se vean afectados sus intereses financieros.
Si la EIPD registró flujos de datos, encargados del tratamiento, controles de acceso, conservación, registro de eventos, cifrado, seudonimización y responsabilidades de gestión de incidentes, el equipo de respuesta a incidentes puede responder antes a preguntas críticas. ¿Qué datos personales estuvieron implicados? ¿Qué sistemas y proveedores se vieron afectados? ¿Qué personas o clientes pueden verse impactados? ¿Había cifrado implantado? ¿Qué registros están disponibles? ¿Qué plazos de notificación aplican? ¿Qué comunicaciones a clientes o autoridades reguladoras son necesarias?
Por eso la gobernanza de EIPD debe conectarse con los controles de incidentes de ISO/IEC 27001:2022, los controles de continuidad del negocio y los controles de preparación TIC, así como con las expectativas del ciclo de vida de incidentes de NIS2 y DORA.
Fallos comunes de gobernanza de EIPD
Los fallos suelen deberse a flujos de trabajo desconectados, no a falta de esfuerzo.
| Fallo | Por qué genera riesgo | Mejor práctica |
|---|---|---|
| Registro de tratamiento actualizado después de la puesta en producción | El registro se convierte en un inventario histórico en lugar de un control de diseño | Actualizar el RoPA antes de la aprobación |
| Ausencia de evaluación preliminar de EIPD en la entrada de cambios | El riesgo de privacidad se descubre demasiado tarde | Añadir preguntas obligatorias sobre datos personales, proveedor, acceso y conservación |
| Los riesgos de EIPD permanecen en una carpeta de privacidad | El tratamiento de seguridad y la aprobación del riesgo residual no son trazables | Convertir los hallazgos de EIPD en entradas del Registro de Riesgos del SGSI |
| Las revisiones de proveedores se centran solo en cuestionarios | Pueden omitirse finalidad del tratamiento, ubicación de datos, subencargados, derechos de auditoría y salida | Combinar diligencia debida de seguridad, privacidad, legal y resiliencia |
| La SoA carece de justificación de privacidad y nube | Los auditores ven controles, pero no la lógica de riesgo | Mapear controles con hallazgos de EIPD y obligaciones del RGPD de la UE, NIS2 y DORA |
| El riesgo residual se acepta informalmente | La responsabilidad de la dirección no es demostrable | Registrar la aprobación del DPO, el Propietario del Riesgo y la dirección con condiciones |
Lista de verificación de gobernanza de EIPD
Utilice esta lista de verificación para integrar las EIPD en el SGSI, la preparación para NIS2 y la gobernanza de cambios TIC de DORA.
| Actividad de gobernanza | Propietario | Evidencia mínima |
|---|---|---|
| Evaluación preliminar de EIPD integrada en la entrada de proyectos y cambios | Responsable de cambios y DPO | Formulario de entrada, decisión de activación y justificación |
| Registro de tratamiento actualizado antes de la aprobación | Coordinador de Privacidad o DPO | Finalidad, base jurídica, categorías de datos, conservación y destinatarios |
| Riesgos de privacidad traducidos a riesgos del SGSI | Responsable de Riesgos y propietario del sistema | Entradas de riesgo con probabilidad, impacto, propietario y Plan de Tratamiento de Riesgos |
| Controles mapeados con la SoA | Responsable del SGSI | Controles aplicables del Anexo A, justificación y estado de implantación |
| Diligencia debida de proveedores y nube completada | Compras, seguridad y legal | Evaluación del proveedor, cláusulas contractuales, ubicación de datos y evidencias de salida |
| Pruebas de seguridad y privacidad completadas | Ingeniería y seguridad | Resultados de las pruebas, revisión de acceso, validación del registro de eventos y evidencias de vulnerabilidad |
| Riesgo residual aceptado | Propietario del Riesgo, DPO y dirección cuando sea necesario | Registro de aprobación, condiciones y fecha de revisión |
| Revisión posterior al cambio realizada | Propietario del cambio y propietario del servicio | Notas de revisión, incidentes, métricas y acciones correctivas |
Esto no es burocracia. Es responsabilidad operativa. Ayuda al Director de Seguridad de la Información a demostrar que se consideró la seguridad, al DPO a demostrar que se evaluó el riesgo de privacidad, al Responsable de Cumplimiento a demostrar que los controles se mapean entre marcos y al propietario de negocio a demostrar que la innovación se gobernó de forma responsable.
Cómo ayuda Clarysec
El enfoque de Clarysec está diseñado para organizaciones que afrontan obligaciones superpuestas en 2026 y evidencias fragmentadas.
El conjunto de herramientas de políticas proporciona el lenguaje de gobernanza. La Política de Protección de Datos y Privacidad define cuándo se requieren EIPD y quién las revisa. La Política de gestión de riesgos define cómo deben estructurarse y mapearse las entradas de riesgo. La Política de gestión de cambios garantiza que los impactos de privacidad y seguridad se evalúen antes de la aprobación. La Política de Uso de la Nube exige diligencia debida antes de la activación en la nube.
El Zenith Blueprint proporciona la hoja de ruta de implantación. El paso 13 convierte el tratamiento de riesgos y la Declaración de Aplicabilidad en un puente de cumplimiento transversal. El paso 22 integra la seguridad en la gestión de proyectos. El paso 21 hace que el cambio sea intencional, justificado y auditable. El paso 23 convierte la protección de PII en un control de ciclo de vida basado en conocimiento de los datos, uso lícito, restricción de acceso, supervisión de proveedores y procesos operativos de privacidad.
La guía Zenith Controls proporciona la brújula de cumplimiento transversal. Para la gobernanza de EIPD, los controles 5.34, 5.8 y 8.32 de ISO/IEC 27002:2022 conectan la protección de la privacidad, la gobernanza de proyectos y el control de cambios con la responsabilidad proactiva del RGPD de la UE, las medidas de ciberseguridad de NIS2, la gobernanza del riesgo TIC de DORA, los resultados de NIST CSF y el aseguramiento de COBIT 2019.
Si su organización se está preparando para revisiones de responsabilidad proactiva del RGPD de la UE, certificación ISO/IEC 27001:2022, preparación para NIS2 o resiliencia operativa DORA, empiece por integrar los desencadenantes de EIPD en la entrada de proyectos y cambios. Vincule los hallazgos de EIPD con el Registro de Riesgos. Mapee los tratamientos en la SoA. Valide proveedores y servicios en la nube antes de la activación. Conserve un único registro de decisión que la dirección, los auditores y las autoridades reguladoras puedan seguir.
La mejor EIPD no es la que se redacta después de que una autoridad reguladora la solicite. Es la que dio forma al sistema antes de que clientes, auditores o incidentes lo pusieran a prueba.
Revise su proceso actual de EIPD frente al conjunto de herramientas de políticas de Clarysec, utilice el Zenith Blueprint para crear trazabilidad preparada para auditorías y use Zenith Controls para mapear un marco de controles único entre el RGPD de la UE, ISO/IEC 27001:2022, NIS2, DORA, NIST CSF y COBIT 2019. Luego convierta su próximo cambio con impacto en privacidad en una decisión de liberación gobernada y respaldada por evidencias, en lugar de una carrera de cumplimiento de última hora.
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
