Evaluación de riesgos de privacidad para ISO 27701 y GDPR

La reunión del lunes por la mañana le resultaba familiar a María, la Directora de Seguridad de la Información de una empresa de tecnología sanitaria en rápido crecimiento.

El Director General quería un panel sencillo que mostrara la exposición al riesgo de GDPR antes de que la empresa lanzara su plataforma de analítica de pacientes impulsada por IA. El nuevo Responsable de Privacidad, David, tenía un Registro de Actividades de Tratamiento, o RoPA, con 50 pestañas. Ingeniería había protegido el entorno en la nube. Producto estaba listo para liberar la funcionalidad. El proveedor describía su cadena de subencargados del tratamiento como “de nivel empresarial”.

Pero una pregunta detuvo la reunión.

“¿Cuál es nuestro riesgo real y podemos demostrar a los clientes empresariales que lo tenemos bajo control?”

El RoPA mostraba qué trataba la empresa. El registro de riesgos de seguridad mostraba riesgos de infraestructura. Algunas EIPD estaban en documentos separados. Las revisiones de proveedores estaban en carpetas de compras. Nadie podía mostrar una única cadena de decisión trazable desde la actividad de tratamiento hasta el riesgo de privacidad, la decisión sobre la EIPD, el plan de tratamiento, la correspondencia con controles, la aprobación del riesgo residual y la fecha de revisión.

Esa es la brecha que afrontan muchas organizaciones al avanzar hacia ISO/IEC 27701:2025 y la responsabilidad proactiva conforme a GDPR. Disponen de avisos de privacidad, cuestionarios a proveedores, entradas de RoPA, mapas de datos, plantillas de EIPD y controles ISO/IEC 27001:2022. Lo que a menudo les falta es la capa operativa que los conecta.

Un Sistema de Gestión de la Información de Privacidad maduro, o PIMS, no trata la evaluación de riesgos de privacidad como un documento jurídico accesorio. La trata como un flujo de trabajo repetible de decisión: identificar el tratamiento, realizar una evaluación preliminar del riesgo, decidir si se necesita una EIPD, seleccionar controles, asignar responsables, aprobar el riesgo residual, supervisar desencadenantes y conservar evidencias.

Ahí es donde los paquetes de políticas de Clarysec, Zenith Blueprint y Zenith Controls ayudan a los equipos a pasar de hojas de cálculo desconectadas a un motor defendible de gestión de riesgos de privacidad.

La evaluación de riesgos de privacidad es la capa operativa que falta

La responsabilidad proactiva de GDPR se reduce a menudo a “tener documentación”. La documentación importa, pero Article 5(2) va más allá. El responsable del tratamiento es responsable del cumplimiento de los principios de Article 5(1) y debe poder demostrarlo, incluidos licitud, lealtad, transparencia, limitación de la finalidad, minimización de datos, exactitud, limitación del plazo de conservación, integridad y confidencialidad.

Eso exige algo más que un RoPA. La organización debe poder explicar por qué una actividad de tratamiento es aceptable, qué riesgos genera para las personas, qué controles reducen esos riesgos, quién es el responsable de la decisión y cuándo debe revisarse.

ISO/IEC 27701:2025 refuerza esta expectativa al integrar la gobernanza de la privacidad en un PIMS gestionado. En la práctica, la evaluación de riesgos de privacidad debe conectar seis objetos operativos:

1. El inventario de tratamientos de datos personales o RoPA.
2. La documentación de la base jurídica y la finalidad.
3. La evaluación preliminar de riesgos de privacidad y la decisión sobre la EIPD.
4. El tratamiento de riesgos y la selección de controles.
5. La gobernanza de proveedores, encargados del tratamiento y subencargados del tratamiento.
6. Las evidencias conservadas en el SGSI y el PIMS.

Clarysec hace explícita esa conexión. En la política Enterprise Privacy Risk Assessment and DPIA Policy, el desencadenante se produce antes de que comience el tratamiento:

[Ambos] El Propietario del proceso / Propietario de la organización DEBE iniciar la evaluación preliminar de riesgos de privacidad en REG04 antes de que comience un tratamiento nuevo o modificado materialmente de datos personales registrado en REG02.

La misma disciplina previa aparece en la política Enterprise PII Processing Inventory and Lawful Basis Policy:

[Ambos] El Propietario del proceso / Propietario de la organización DEBE iniciar la evaluación preliminar de riesgos de privacidad y EIPD en REG04 antes de que avance un tratamiento nuevo o modificado materialmente de datos personales.

Esto evita un patrón de fallo habitual: el producto se lanza, el RoPA se actualiza más tarde, la pregunta sobre la EIPD llega demasiado tarde y el registro de riesgos nunca recibe el escenario de privacidad.

Para los responsables del tratamiento, esto respalda la disciplina de la base jurídica de GDPR Article 6, la protección de datos desde el diseño y por defecto de Article 25, la seguridad del tratamiento de Article 32 y la responsabilidad proactiva de Article 5. Para los encargados del tratamiento, respalda las instrucciones documentadas, el aseguramiento frente al cliente, los límites contractuales y la transparencia sobre subencargados del tratamiento.

Empiece por la realidad del tratamiento, no por una plantilla en blanco

Una evaluación de riesgos de privacidad falla cuando empieza con un formulario vacío y sin contexto operativo. La primera pregunta no debería ser “¿Necesitamos una EIPD?”. Debería ser “¿Qué tratamiento está cambiando realmente?”.

Para una organización SaaS, fintech o de tecnología sanitaria, el cambio puede implicar:

• Una nueva categoría de datos, como datos de uso conductual, datos de salud, señales biométricas o metadatos de pago.
• Una nueva finalidad, como puntuación de fraude, analítica de pacientes, soporte asistido por IA, predicción de abandono o personalización.
• Un nuevo destinatario, encargado del tratamiento o subencargado del tratamiento.
• Un nuevo flujo de trabajo de soporte o una nueva ruta de acceso transfronterizo.
• Un nuevo período de conservación.
• Un nuevo modelo, algoritmo o recomendación automatizada.
• Un nuevo grupo de interesados, como menores, empleados, pacientes o personas financieramente vulnerables.

Las definiciones de GDPR son amplias. Los datos personales incluyen identificadores, identificadores en línea, datos de localización y factores vinculados a la identidad. El tratamiento incluye recogida, almacenamiento, consulta, uso, comunicación, limitación, supresión y destrucción. Una brecha de seguridad de datos personales incluye la destrucción, pérdida, alteración, comunicación no autorizada o acceso accidental o ilícito.

Esto significa que un flujo de trabajo de riesgos de privacidad debe capturar más que si la base de datos está cifrada. Debe capturar por qué existe el tratamiento, si la finalidad es compatible, si la base jurídica es válida, si intervienen categorías especiales de datos, si las personas pueden comprender el tratamiento y si las salvaguardas son proporcionadas.

Para equipos más pequeños, la política para pymes Data Protection and Privacy Policy proporciona el punto de partida en la cláusula 5.2.1:

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.

Ese registro no es burocracia. Es el modelo de entrada para la evaluación de riesgos de privacidad. Sin categorías de datos, finalidad, base jurídica y períodos de conservación, la evaluación no puede valorar de forma fiable la limitación de la finalidad, la minimización de datos, la limitación del plazo de conservación, la transparencia o la lealtad.

La misma política para pymes también convierte la revisión de riesgos en una obligación recurrente en la cláusula 7.1.1:

El Coordinador de Privacidad debe evaluar los riesgos de privacidad anualmente y durante cambios importantes en los sistemas.

Para empresas, la cadencia de gobernanza es más exigente. La política Enterprise Data Protection and Privacy Policy establece:

Los registros de riesgos de privacidad deberán mantenerse dentro del SGSI y revisarse al menos trimestralmente por el Delegado de Protección de Datos (DPO) y el CISO.

Aquí es donde la integración entre ISO/IEC 27701:2025 e ISO/IEC 27001:2022 se vuelve práctica. Los riesgos de privacidad no quedan enterrados en carpetas jurídicas. Se revisan junto con riesgos de seguridad, riesgos de proveedores, incidentes, hallazgos de auditoría, planes de tratamiento e informes a la dirección.

El flujo de trabajo de Clarysec de REG02 a REG04

El proceso de evaluación de riesgos de privacidad más eficaz es lo bastante sencillo para los responsables de negocio y lo bastante riguroso para los auditores. El modelo de Clarysec usa REG02 como inventario de tratamientos de datos personales y REG04 como registro de evaluación de riesgos de privacidad y EIPD.

La Privacy Risk Assessment and DPIA Policy define la evidencia mínima necesaria antes de cerrar REG04:

[Ambos] El Responsable de Privacidad / Responsable del PIMS DEBE asegurarse de que cada evaluación REG04 registre la calificación del riesgo, la decisión de tratamiento, el responsable, la fecha límite, el riesgo residual, el estado de aprobación y la fecha de revisión antes del cierre.

Esa frase es la columna vertebral operativa. Una evaluación de riesgos de privacidad no se cierra porque alguien escriba “riesgo bajo” en un cuadro de comentarios. Se cierra cuando el registro incluye la calificación, la decisión de tratamiento, el responsable, la fecha límite, el riesgo residual, el estado de aprobación y la fecha de revisión.

Para pymes, la misma disciplina se escala de forma proporcional. La política para pymes Risk Management Policy establece:

Cada entrada de riesgo debe incluir: descripción, probabilidad, impacto, puntuación, propietario y plan de tratamiento.

El principio es proporcionalidad, no informalidad. Las organizaciones más pequeñas pueden usar un registro más simple, pero cada riesgo sigue necesitando descripción, puntuación, propietario y plan de tratamiento.

Use el motor de riesgos de ISO/IEC 27001:2022 para la privacidad

El riesgo de privacidad no debe vivir fuera del método de gestión de riesgos de la organización. ISO/IEC 27001:2022 ya proporciona el motor del sistema de gestión: contexto, partes interesadas, alcance, liderazgo, evaluación de riesgos, tratamiento, control operacional, información documentada, evaluación del desempeño y mejora continua.

Las cláusulas 4.1 a 4.4 exigen que la organización comprenda las cuestiones internas y externas, los requisitos de las partes interesadas, el alcance del SGSI y los procesos del SGSI. Para privacidad, las partes interesadas incluyen clientes, interesados, empleados, reguladores, encargados del tratamiento, subencargados del tratamiento, autoridades de control, supervisores del sector financiero cuando proceda y clientes contractuales.

La cláusula 6.1.2 exige un proceso de evaluación de riesgos de seguridad de la información. La cláusula 6.1.3 exige el tratamiento de riesgos de seguridad de la información, incluida la selección de controles, la elaboración de una Declaración de Aplicabilidad, la formulación de un plan de tratamiento de riesgos y la obtención de la aprobación del Propietario del riesgo sobre el plan y los riesgos residuales. Las cláusulas 8.2 y 8.3 exigen realizar evaluaciones y tratamientos de riesgos de seguridad de la información a intervalos planificados o cuando se produzcan cambios significativos, conservando los resultados documentados.

La política Enterprise Risk Management Policy de Clarysec se alinea con esa estructura en la cláusula 5.1:

Se deberá mantener un proceso formal de gestión de riesgos de acuerdo con ISO/IEC 27005 e ISO 31000, que abarque identificación, análisis, evaluación, tratamiento, supervisión y comunicación del riesgo.

Para privacidad, los criterios de riesgo deben incluir el impacto sobre las personas, no solo el impacto en la organización. Una pérdida financiera baja puede seguir siendo un impacto de privacidad alto si el tratamiento incluye categorías especiales de datos, personas vulnerables, elaboración de perfiles, opacidad, conservación ilícita, imposibilidad de ejercer derechos o daños no materiales.

Zenith Blueprint: An Auditor’s 30-Step Roadmap de Clarysec lo explica en la fase de Gestión de riesgos, paso 10:

Al definir el impacto, conviene relacionar los niveles con la escala concreta de su organización. Por ejemplo, “impacto financiero mayor = pérdida > 100.000 $” (ajústelo a su contexto). Considere también el impacto regulatorio: por ejemplo, una brecha de seguridad de datos personales podría ser automáticamente “Mayor” o “Severa” debido a las sanciones de GDPR y los requisitos de notificación, incluso si la pérdida financiera directa no está clara.

Esta orientación es especialmente importante para analítica de IA, datos de salud, elaboración de perfiles financieros, monitorización de empleados y puntuación de clientes. El daño puede ser legal, reputacional, discriminatorio, operativo, contractual o personal.

Un ejemplo práctico: analítica de pacientes con IA

Volvamos a María y David. Su plataforma de tecnología sanitaria tratará datos de salud de categorías especiales conforme a GDPR Article 9. Usará historial de pacientes, datos de citas, notas clínicas y salidas del modelo para generar información de riesgo.

Utilizando Zenith Blueprint, empiezan por el paso 9, identificando activos, amenazas y vulnerabilidades:

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 (alta sensibilidad)”.

El mismo paso añade la perspectiva de privacidad:

Asegúrese de que los activos de datos personales estén marcados (por relevancia para GDPR) y de que los activos de servicios críticos estén identificados (por posible aplicabilidad de NIS2 si opera en un sector regulado).

El equipo de María identifica la plataforma de analítica de pacientes con IA, la base de datos de pacientes, el almacén de datos, la canalización de entrenamiento del modelo, el panel clínico, el almacenamiento en la nube, el proveedor de identidad, los registros de auditoría, la plataforma de tickets de soporte y la herramienta analítica de terceros. Cada activo recibe un propietario, ubicación, clasificación y relación con datos personales.

Después definen escenarios de riesgo. Uno es el acceso no autorizado a historiales de salud. Otro es la divulgación accidental mediante exportaciones analíticas. Un tercero es el sesgo del modelo de IA causado por datos de entrenamiento sesgados, que genera puntuaciones de riesgo de pacientes injustas o discriminatorias.

El paso 11 de Zenith Blueprint explica el papel del registro de riesgos:

El Registro de Riesgos suele ser una hoja de cálculo (nuestra plantilla “Risk Register and SoA Builder.xlsx” tiene una hoja dedicada para ello). Sirve como registro maestro de riesgos.

Una entrada de riesgo de privacidad para el escenario de sesgo del modelo de IA podría tener este aspecto:

Esta entrada hace lo que la antigua hoja de cálculo no podía hacer. Conecta una actividad de tratamiento con un activo, una amenaza, una vulnerabilidad, un riesgo para las personas, un propietario, una puntuación, un plan de tratamiento y una pista de evidencias.

Como el tratamiento es de alto riesgo e implica categorías especiales de datos, la EIPD no es una consideración posterior separada. Se convierte en la fase de evaluación más exhaustiva para un riesgo ya registrado en el sistema. La política Enterprise Data Protection and Privacy Policy establece:

Todos los cambios significativos en sistemas o procesos que impliquen información personal (PII) deberán requerir una Evaluación de Impacto relativa a la Protección de Datos (EIPD) documentada, revisada por el Delegado de Protección de Datos (DPO).

Para alto riesgo residual del responsable del tratamiento, la Privacy Risk Assessment and DPIA Policy añade:

[Responsable del tratamiento] La Alta Dirección DEBE aprobar la aceptación de alto riesgo residual de privacidad en REG04 antes de que el tratamiento de alto riesgo por parte del responsable comience o continúe.

La decisión de lanzamiento ahora tiene trazabilidad: qué cambió, qué se evaluó, qué riesgos se identificaron, qué controles se seleccionaron, quién es responsable del tratamiento del riesgo, quién aprobó el riesgo residual y cuándo se revisará la decisión.

De los riesgos a los controles con Zenith Controls

La evaluación de riesgos de privacidad solo importa si conduce a decisiones de control. Zenith Controls: The Cross-Compliance Guide de Clarysec es la guía de cumplimiento transversal que asigna controles ISO/IEC 27001:2022 e ISO/IEC 27002:2022 a requisitos relacionados de distintos marcos. No es un conjunto separado de controles. Ayuda a los equipos a comprender cómo las evidencias de control respaldan múltiples obligaciones.

Para la evaluación de riesgos de privacidad, Zenith Controls destaca tres controles centrales de ISO/IEC 27002:2022:

El control 5.34 también respalda GDPR Article 25 y Article 32, NIS2 Article 21 sobre medidas de gestión de riesgos de ciberseguridad, las expectativas de gestión del riesgo de las TIC de DORA y resultados de NIST CSF 2.0 como GV.OC-03 para obligaciones legales, regulatorias, contractuales, de privacidad y de libertades civiles, además de PR.DS-01 para la protección de datos en reposo.

El paso 13 de Zenith Blueprint conecta estas decisiones con la Declaración de Aplicabilidad:

Referencie normativas de forma cruzada: si determinados controles se implementan específicamente para cumplir con GDPR, NIS2 o DORA, puede indicarlo en el Registro de Riesgos (como parte de la justificación del impacto del riesgo) o en las notas de la SoA.

Así es como un hallazgo de privacidad se convierte en una decisión de control del SGSI y del PIMS, no solo en un comentario jurídico.

El riesgo de proveedores y encargados del tratamiento debe evaluarse antes de la aprobación

Muchos fallos de privacidad empiezan en la gobernanza de proveedores. Un encargado del tratamiento añade un nuevo subencargado del tratamiento. Un proveedor de soporte obtiene acceso al entorno de producción. Una plataforma analítica almacena datos de eventos en una nueva región. Compras firma el contrato antes de que privacidad vea el riesgo.

La política Enterprise Processor, Subprocessor and Third-Party Privacy Management Policy de Clarysec lo evita conectando la revisión del proveedor, REG04 y el registro de terceros:

[Ambos] El Responsable de Privacidad / Responsable del PIMS DEBE activar la evaluación preliminar de riesgos de privacidad y EIPD en REG04 para relaciones de alto riesgo con encargados del tratamiento y cambios materiales de privacidad de terceros antes de la aprobación, con la referencia REG04 registrada en REG08.

Para pymes, la Third-Party and Supplier Security Policy establece el requisito de revisión previa a la contratación:

Antes de la contratación, cada proveedor debe revisarse para identificar riesgos potenciales. Esta revisión debe incluir:

El mensaje operativo es claro. El riesgo de proveedores se evalúa antes de la aprobación, no después de la firma.

Esto también respalda NIS2 y DORA. NIS2 Article 21 exige seguridad de la cadena de suministro como parte de las medidas de gestión de riesgos de ciberseguridad. DORA Articles 28 to 30 exigen que las entidades financieras gestionen el riesgo de terceros TIC, realicen evaluaciones precontractuales, mantengan salvaguardas contractuales, comprendan el riesgo de subcontratación, supervisen dependencias y planifiquen salidas para funciones esenciales o importantes.

Si un proveedor trata datos personales o da soporte a un tratamiento crítico para la privacidad, el registro de riesgo de privacidad debe mostrar el proveedor, el rol de tratamiento, la ubicación de los datos, la dependencia de subencargados del tratamiento, las salvaguardas contractuales, los compromisos sobre incidentes, las reglas de conservación, el enfoque de supervisión y el plan de salida.

Un flujo de trabajo, muchos resultados de cumplimiento

La ventaja de un flujo de trabajo PIMS integrado es que las mismas evidencias respaldan múltiples marcos sin duplicar trabajo.

NIST CSF 2.0 es especialmente útil para la comunicación con la dirección. Su función GOVERN cubre contexto organizativo, estrategia de gestión de riesgos, política, roles, supervisión y riesgo de la cadena de suministro. Sus Perfiles Organizativos ayudan a traducir resultados actuales y objetivo en un plan de acción priorizado, como un registro de riesgos o un plan de acción e hitos.

Para organizaciones sujetas a NIS2, DORA o normas sectoriales, las evidencias de riesgos de privacidad también respaldan la gobernanza de la ciberseguridad, la supervisión de proveedores, la preparación frente a incidentes y los informes de resiliencia.

El tratamiento de riesgos de privacidad va más allá del cifrado

El cifrado es importante, pero no puede corregir una base jurídica inválida, una recogida excesiva, una elaboración de perfiles no comunicada, un tratamiento desleal, una conservación ilícita o un encargado del tratamiento que actúa fuera de las instrucciones.

La política para pymes Data Protection and Privacy Policy establece:

Deben implementarse controles para reducir los riesgos identificados, incluidos cifrado, anonimización, eliminación segura y restricciones de acceso.

Son buenos ejemplos, pero el tratamiento debe ajustarse al escenario. Un plan de tratamiento de riesgos de privacidad puede incluir acotar la finalidad del tratamiento, eliminar categorías de datos innecesarias, agregar o seudonimizar datos, actualizar avisos, cambiar la base jurídica cuando proceda, limitar la conservación, restringir el acceso, añadir registro de eventos, actualizar contratos, completar una EIPD, retrasar el lanzamiento o rechazar un tratamiento que siga siendo inaceptable.

La política Enterprise Risk Management Policy refuerza la planificación del tratamiento para riesgos por encima de la tolerancia:

Todos los riesgos clasificados por encima del nivel de tolerancia deberán contar con un Plan de Tratamiento de Riesgos asociado que especifique:

En la práctica, esto significa que el alto riesgo de privacidad no puede aceptarse por silencio. Debe tratarse, transferirse cuando proceda, evitarse o aceptarse formalmente por el responsable con la autoridad adecuada.

Los desencadenantes de revisión mantienen viva la evaluación

Una evaluación de riesgos de privacidad que nunca se revisa se convierte en evidencia desactualizada. Las cláusulas 8.2 y 8.3 de ISO/IEC 27001:2022 exigen evaluación y tratamiento de riesgos a intervalos planificados o cuando se produzcan cambios significativos. La responsabilidad proactiva de GDPR exige decisiones vigentes. ISO/IEC 27701:2025 depende de la supervisión y la mejora continua.

Una evaluación REG04 debe reabrirse cuando cambia la finalidad, se añaden nuevas categorías de datos, intervienen categorías especiales de datos, cambia la base jurídica, cambia un encargado del tratamiento o subencargado del tratamiento, el almacenamiento se traslada a una nueva región, cambian los períodos de conservación, cambia la lógica de elaboración de perfiles, ocurre una brecha de seguridad o un cuasi incidente, cambian los contratos con clientes o se aplica una nueva obligación de NIS2, DORA o sectorial.

Los procesos de incidentes deben retroalimentar el flujo de trabajo de riesgos de privacidad. NIS2 Article 23 establece una notificación por fases de incidentes significativos. DORA Articles 17 to 20 exigen registro, clasificación, escalado, comunicación, análisis de causa raíz y mejora de incidentes relacionados con las TIC. También pueden activarse obligaciones de brecha de seguridad de datos personales de GDPR. Si un incidente revela controles de acceso débiles, conservación excesiva, notificación poco clara por parte de proveedores o instrucciones deficientes del cliente, REG04 debe actualizarse.

Qué esperarán ver los auditores

Un flujo de trabajo sólido de riesgos de privacidad debe resistir múltiples perspectivas de aseguramiento.

La política Enterprise Data Protection and Privacy Policy también exige actividad de auditoría interna:

Se deberá realizar una auditoría interna de cumplimiento de privacidad anualmente o ante cambios organizativos o regulatorios importantes. El alcance de la auditoría deberá incluir:

Esto crea un ciclo de retroalimentación para la dirección. ¿Están completos los registros REG02? ¿Son oportunas las evaluaciones preliminares REG04? ¿Se realizan las EIPD cuando corresponde? ¿Se aprueban los altos riesgos residuales? ¿Se capturan los cambios de proveedores? ¿Se cierran los planes de tratamiento? ¿Los avisos están alineados con el tratamiento real?

Lista de verificación para su próxima reunión sobre cambios de privacidad

Use esta lista de verificación antes de que una nueva actividad de tratamiento, funcionalidad de producto, proveedor, modelo o flujo de soporte entre en producción.

Esta lista de verificación no sustituye a la política. Es una forma práctica de operacionalizar la política en reuniones de producto, compras, ingeniería, cumplimiento, legal y dirección.

Convierta la responsabilidad proactiva en privacidad en un sistema operativo

ISO/IEC 27701:2025 y la responsabilidad proactiva conforme a GDPR requieren algo más que documentos. Requieren un sistema operativo que conecte registros de tratamiento, base jurídica, riesgo de privacidad, decisiones sobre EIPD, proveedores, controles, responsables, aprobaciones y evidencias.

Empiece por la fase de Gestión de riesgos de Zenith Blueprint, especialmente los pasos 9 a 13. Use Risk Register and SoA Builder para conectar activos, amenazas, vulnerabilidades, riesgos de privacidad, decisiones de tratamiento y referencias de control. Después use Zenith Controls para correlacionar la protección de datos personales, el Inventario de Activos y la seguridad de proveedores con las expectativas de aseguramiento de GDPR, ISO/IEC 27001:2022, NIS2, DORA, NIST CSF 2.0 y COBIT 19.

Alinee las políticas operativas que hacen exigible el flujo de trabajo: Privacy Risk Assessment and DPIA Policy, PII Processing Inventory and Lawful Basis Policy, Processor, Subprocessor and Third-Party Privacy Management Policy, Risk Management Policy y Data Protection and Privacy Policy. Los equipos más pequeños también pueden usar las políticas para pymes de Clarysec, mientras que las organizaciones más grandes pueden estructurar la gobernanza mediante políticas Enterprise.

Si su equipo está lanzando un nuevo tratamiento, cambiando proveedores, preparándose para ISO/IEC 27701:2025 o intentando que las evidencias de responsabilidad proactiva de GDPR sean repetibles, empiece con una actividad de tratamiento en producción. Abra REG02, ejecute la evaluación preliminar REG04, asigne los riesgos a controles, designe responsables del tratamiento de riesgos y revise el riesgo residual con el decisor adecuado.

Ese único flujo de trabajo es donde la gobernanza de la privacidad se vuelve operativa.