Plan de transición a ISO/IEC 27701:2025 para un PIMS basado en GDPR

La pregunta del consejo de administración que revela una deficiencia de evidencias de privacidad

Anya, la CISO de una FinTech en rápida expansión, miraba fijamente la agenda de la reunión del consejo de administración. Entre las previsiones de ingresos y la expansión de mercado aparecía el punto que había ocupado toda su semana: cumplimiento de GDPR y preparación para ISO/IEC 27701:2025.

La empresa tenía un programa GDPR. Había un Delegado de Protección de Datos (DPO), avisos de privacidad, contratos de encargo de tratamiento, una plantilla de EIPD y un proceso para solicitudes de los interesados. El equipo comercial ya había comunicado a clientes corporativos que la empresa avanzaba hacia un Sistema de Gestión de la Privacidad de la Información ISO/IEC 27701:2025, o PIMS. Producto estaba preparando una funcionalidad de analítica asistida por IA que trataría el comportamiento de usuarios de clientes, tickets de soporte, metadatos de facturación y actividad de cuentas. Un cliente importante de la UE había solicitado evidencias de que las obligaciones como responsable del tratamiento y como encargado del tratamiento se gestionaban por separado.

La verdad incómoda no era que faltara documentación de privacidad. El problema eran las evidencias.

El registro de actividades de tratamiento no mostraba de forma consistente la base jurídica, la conservación, las dependencias de subencargados del tratamiento, las transferencias internacionales ni si la empresa actuaba como responsable del tratamiento o como encargado del tratamiento para cada finalidad. Las revisiones de proveedores se centraban en la seguridad, pero no lo suficiente en las instrucciones de privacidad, la supresión, el apoyo ante violaciones de seguridad, los derechos de auditoría y las obligaciones trasladadas contractualmente a subencargados del tratamiento. Ingeniería realizaba revisiones de seguridad, pero la privacidad desde el diseño no siempre se activaba cuando una funcionalidad cambiaba la finalidad del tratamiento. La auditoría interna evaluaba GDPR a alto nivel, pero no siempre podía trazar una obligación hasta un propietario, un control, un registro, una prueba y una decisión de revisión por la dirección.

Ese es el verdadero reto de la transición a ISO/IEC 27701:2025. No es solo un proyecto de certificación. Es una prueba de madurez: ¿puede su organización operar la privacidad como un sistema gestionado y no como una carpeta de documentos legales?

Para las organizaciones impulsadas por GDPR, la respuesta es ampliar el Sistema de Gestión de la Seguridad de la Información ISO/IEC 27001:2022 hacia un sistema de gestión de la privacidad que integre el alcance del PIMS, los registros de actividades de tratamiento, la evaluación de riesgos de privacidad, las EIPD, la gobernanza de proveedores, la gestión de violaciones de seguridad, el mapeo de controles, la auditoría interna y la mejora continua.

Por qué el cumplimiento GDPR fragmentado se rompe bajo presión de auditoría

Muchas organizaciones tratan el cumplimiento de privacidad como una línea de trabajo separada de la seguridad de la información. Legal gestiona contratos. TI gestiona el cifrado. Compras gestiona proveedores. El DPO responde a las solicitudes de acceso de los interesados. Los equipos de producto lanzan funcionalidades. Seguridad gestiona incidentes. Cada función puede estar realizando un trabajo útil, pero sin un modelo operativo único, las evidencias de privacidad se fragmentan.

Esto genera cuatro problemas recurrentes.

Primero, los equipos duplican esfuerzos. Las evaluaciones de riesgos de seguridad y privacidad pueden usar métodos, puntuaciones y propietarios distintos.

Segundo, aparecen deficiencias en servicios de terceros, configuraciones de nube, canalizaciones de analítica, herramientas de soporte y nuevos proyectos de desarrollo porque nadie tiene una visión completa de los flujos de PII.

Tercero, el aseguramiento ante el consejo de administración y los clientes se vuelve difícil. Una colección de políticas desconectadas no demuestra que las obligaciones de privacidad estén implantadas, supervisadas y mejoradas.

Cuarto, las expectativas regulatorias modernas están convergiendo. GDPR exige responsabilidad proactiva y evidencias. NIS2 exige gobernanza, gestión de riesgos, gestión de incidentes, control de acceso, gestión de activos y seguridad de la cadena de suministro. DORA exige que las entidades financieras gestionen el riesgo de las TIC, los incidentes, las pruebas de resiliencia, los contratos con terceros y las estrategias de salida. Un programa de privacidad aislado no puede soportarlas todas de forma eficiente.

El enfoque más sólido es construir la transición a ISO/IEC 27701:2025 sobre el SGSI ISO/IEC 27001:2022. ISO/IEC 27001:2022 proporciona la estructura del sistema de gestión para el contexto, las partes interesadas, el alcance, la evaluación de riesgos, el tratamiento de riesgos, los objetivos, la planificación operacional, la auditoría interna, la revisión por la dirección, la acción correctiva y la mejora continua. ISO/IEC 27002:2022 proporciona la base de controles para obligaciones legales, inventario de activos, relaciones con proveedores, servicios en la nube, control de acceso, registro de eventos, supervisión, supresión, enmascaramiento y privacidad y protección de PII.

La transición debe responder a cinco preguntas:

1. ¿Cuál es el alcance del PIMS, incluidos los roles de responsable del tratamiento, encargado del tratamiento, corresponsable del tratamiento y subencargado del tratamiento?
2. ¿Qué actividades de tratamiento, categorías de datos, finalidades, bases jurídicas, destinatarios, transferencias y reglas de conservación están dentro del alcance?
3. ¿Qué riesgos de privacidad requieren EIPD, tratamiento, aprobación y aceptación del riesgo residual?
4. ¿Qué políticas, controles, contratos, salvaguardas técnicas y registros demuestran la responsabilidad proactiva en GDPR?
5. ¿Cómo confirmarán la auditoría interna y la revisión por la dirección que el PIMS está operando y mejorando?

Fase 1: aprobar el alcance del PIMS antes de reescribir políticas

Un plan de transición a ISO/IEC 27701:2025 sólido no comienza reescribiendo todas las políticas de privacidad. Comienza con gobernanza y alcance.

El alcance existente del SGSI es el punto de partida, pero el alcance del PIMS debe identificar explícitamente el tratamiento de PII, las unidades de negocio, los servicios, los sistemas, las regiones, los entornos en la nube, los proveedores y los roles de privacidad. El consejo de administración o la alta dirección deben comprender por qué importa la transición, especialmente cuando clientes, reguladores u obligaciones sectoriales como DORA dependen de evidencias demostrables de privacidad y resiliencia.

La Política del Sistema de Gestión de la Privacidad de la Información de Clarysec [Política PIMS] hace obligatoria la aprobación del alcance:

[Ambos] La alta dirección DEBE aprobar el alcance del PIMS en REG01 antes de la implantación inicial del PIMS y dentro de los 30 días posteriores a cualquier cambio material.

Para los programas de transición que utilizan la numeración de cláusulas de la biblioteca de políticas de Clarysec, esta es la expectativa principal de la cláusula 4.1.1. Es importante porque el alcance de privacidad implícito es una de las debilidades de auditoría más comunes. Si una línea de producto, jurisdicción, rol de tratamiento, proveedor, región de nube o proceso de negocio cambia de forma material, el alcance del PIMS no debe quedar sujeto a interpretación.

La misma política también convierte la transición en un programa gestionado:

[Ambos] El Responsable de Privacidad / Responsable del PIMS DEBE registrar el plan de implantación del PIMS en REG12 antes del despliegue del PIMS o de un cambio importante del PIMS.

REG12 no es carga administrativa. Es el cuadro de mando de la transición. Debe mostrar qué cambia, por qué importa, quién es responsable, qué evidencias se requieren, qué riesgos siguen abiertos y cuándo se verificará la preparación.

Fase 2: construir un inventario de transición basado en registros

Para los sistemas de gestión de privacidad basados en GDPR, el primer entregable práctico debe ser un inventario de evidencias, no una reescritura de políticas. Clarysec utiliza un enfoque basado en registros porque los registros convierten la intención de privacidad en evidencias auditables.

El alcance del PIMS en REG01 se conecta con las actividades de tratamiento en REG02, la aplicabilidad de los controles en REG03, la evaluación preliminar de riesgos de privacidad y EIPD en REG04, y la planificación de la implantación en REG12.

La Política de Protección de Datos y Privacidad - pyme de Clarysec [Política de Privacidad para pymes] establece la línea base:

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.

Para entornos más grandes, la Política de Protección de Datos y Privacidad [P17 Política de Protección de Datos y Privacidad] eleva la expectativa de gobernanza:

La organización debe mantener un Marco de Gobernanza de la Privacidad formal integrado en el Sistema de Gestión de la Seguridad de la Información (SGSI) para aplicar esta política.

Esa integración es el principio de transición. Un registro de actividades de tratamiento sin tratamiento de riesgos es una hoja de cálculo. Una EIPD sin propiedad del control es un memorando legal. Un contrato de encargo de tratamiento con un proveedor sin supervisión es un expediente contractual archivado. El trabajo de transición a ISO/IEC 27701:2025 debe incorporar estos artefactos a un único PIMS gobernado.

Este inventario también sirve de apoyo a un Perfil Actual y un Perfil Objetivo al estilo del NIST Cybersecurity Framework 2.0. El Perfil Actual documenta los procesos, controles y evidencias de privacidad existentes. El Perfil Objetivo define el PIMS deseado alineado con ISO/IEC 27701:2025. La brecha entre ambos se convierte en el backlog de transición.

Fase 3: mapear la responsabilidad proactiva de GDPR en el PIMS

La responsabilidad proactiva de GDPR es la columna vertebral de las evidencias de privacidad. GDPR se aplica al tratamiento en el contexto de un establecimiento en la UE y también puede aplicarse a responsables del tratamiento o encargados del tratamiento no establecidos en la UE que ofrezcan bienes o servicios a personas en la UE o supervisen su comportamiento. Define los datos personales de forma amplia, incluidos identificadores directos e indirectos. Distingue entre responsables del tratamiento y encargados del tratamiento, y 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.

Para la planificación de la transición, el punto importante es que GDPR no se satisface diciendo “tenemos controles de seguridad”. Article 5 exige un tratamiento lícito, leal y transparente, limitación de la finalidad, minimización de datos, exactitud, limitación del plazo de conservación, integridad y confidencialidad, y responsabilidad proactiva demostrable. Article 6 exige una base jurídica. Article 9 añade condiciones más estrictas para categorías especiales de datos personales. Article 25 exige protección de datos desde el diseño y por defecto. Article 28 exige gobernanza de encargados del tratamiento. Article 32 exige seguridad del tratamiento.

La Política de Cumplimiento Legal y Normativo - pyme de Clarysec [Política de Cumplimiento Legal y Normativo para pymes] ofrece a las organizaciones más pequeñas un punto de partida sencillo:

El DG debe mantener un Registro de Cumplimiento sencillo y estructurado que enumere:

La Política de Cumplimiento Legal y Normativo corporativa [P37 Política de Cumplimiento Legal y Normativo] es más explícita:

Todas las obligaciones legales y reglamentarias deben mapearse a políticas, controles y propietarios específicos dentro del Sistema de Gestión de la Seguridad de la Información (SGSI).

Esa frase marca la diferencia entre un cumplimiento GDPR informal y una gestión de privacidad preparada para auditorías. Toda obligación GDPR material debe mapearse a una política, un control, un propietario, un campo de registro y una fuente de evidencias.

Las evidencias de responsable del tratamiento y encargado del tratamiento deben separarse. Un responsable del tratamiento debe demostrar base jurídica, transparencia, gestión de derechos, decisiones sobre finalidades y conservación. Un encargado del tratamiento debe demostrar el tratamiento conforme a instrucciones documentadas, la gobernanza de subencargados del tratamiento, la asistencia al responsable del tratamiento, las medidas de seguridad, el apoyo a la notificación de violaciones de seguridad y la devolución o supresión al finalizar el servicio. Si la organización actúa en ambos roles, un único modelo genérico de evidencias no es suficiente.

Fase 4: usar la SoA como puente de controles de privacidad

Un error común en la transición es crear una hoja de cálculo independiente de controles del PIMS mientras se deja intacta la Declaración de Aplicabilidad del SGSI. Eso crea dos universos de control en competencia.

ISO/IEC 27001:2022 exige que las decisiones de tratamiento de riesgos se reflejen en la Declaración de Aplicabilidad. La Política de gestión de riesgos de Clarysec [Política de gestión de riesgos] establece:

Una Declaración de Aplicabilidad (SoA) debe reflejar todas las decisiones de tratamiento y debe actualizarse siempre que se modifique la cobertura del control.

Para la transición a ISO/IEC 27701:2025, la SoA se convierte en el puente entre el SGSI y el PIMS. Si una EIPD o un tratamiento de riesgos de privacidad añade cifrado, enmascaramiento de datos, controles de supresión, mecanismos de consentimiento, diligencia debida de encargados del tratamiento, restricciones de acceso o supervisión del flujo de trabajo de DSAR, la SoA y REG03 deben reflejar la decisión.

Zenith Blueprint: hoja de ruta de 30 pasos para auditores [Zenith Blueprint] lo refuerza en el paso 6:

✓ Controles adicionales: ¿Hay controles fuera del Anexo A que podría incluir? ISO 27001
permite añadir otros controles en la SoA. Por ejemplo, quizá desee incluir
el cumplimiento con NIST CSF o controles de privacidad específicos de ISO 27701.

No fuerce las obligaciones de privacidad dentro de controles que no encajan. Añada controles específicos de privacidad cuando sea necesario, pero gobiérnelos mediante el mismo modelo de tratamiento de riesgos, propiedad, estado de implantación, evidencias y auditoría.

Los controles ISO/IEC 27002:2022 que anclan la transición

En Zenith Controls: guía de cumplimiento cruzado [Zenith Controls], dos controles ISO/IEC 27002:2022 son centrales para la transición a ISO/IEC 27701:2025: 5.31 Requisitos legales, estatutarios, reglamentarios y contractuales, y 5.34 Privacidad y protección de PII.

El control 5.31 es el núcleo de cumplimiento. Da soporte a la identificación, documentación, propiedad y revisión de requisitos legales, reglamentarios, estatutarios y contractuales. Se conecta de forma natural con la responsabilidad proactiva de GDPR, la gobernanza NIS2, las obligaciones de gestión del riesgo de las TIC de DORA, las cláusulas de privacidad de clientes y los compromisos de tratamiento en la nube.

El control 5.34 es el ancla operativa de privacidad. Zenith Controls explica claramente la dependencia:

Un inventario de activos de información (5.9) debe incluir los repositorios de datos PII (bases de datos de clientes, expedientes de RR. HH.). Esto sustenta 5.34 al garantizar que la organización sabe qué PII tiene y dónde, que es el primer paso para protegerla.

La matriz de correspondencia de controles debe utilizarse como una lista de verificación práctica de diseño.

Aquí es donde la privacidad se vuelve operativa. Para cada actividad de tratamiento de alto riesgo, pregunte: qué activos contienen PII, cómo se clasifica, quién puede acceder a ella, dónde se transfiere, qué servicios en la nube la tratan, qué regla de conservación aplica, qué supervisión detecta usos indebidos y qué evidencias demuestran que esos controles operan.

Ejemplo de flujo de trabajo: incorporación de una funcionalidad de analítica asistida por IA

Volvamos a la FinTech de Anya. El equipo de producto quiere lanzar una funcionalidad de analítica asistida por IA que trata identificadores de usuario, actividad de cuentas, metadatos de soporte, metadatos de facturación y señales de comportamiento. Algunos clientes corporativos pueden usar los resultados para monitorización de empleados, lo que incrementa el riesgo de privacidad.

Un flujo de trabajo de transición del PIMS debe gestionar el lanzamiento como un evento de privacidad controlado.

Paso 1: actualizar REG02 con roles y finalidades del tratamiento

El Propietario del proceso crea o actualiza el registro de actividades de tratamiento. Los campos obligatorios incluyen finalidad, categorías de datos, categorías de interesados, base jurídica o instrucción del encargado del tratamiento, período de conservación, sistemas, proveedores, destinatarios, transferencias y contexto del rol.

Si la empresa es encargada del tratamiento para la analítica de clientes, REG02 debe mostrar el tratamiento conforme a instrucciones del cliente. Si también utiliza datos agregados para mejorar su propio producto, esa finalidad separada puede convertirla en responsable del tratamiento para el tratamiento secundario. El registro no debe difuminar los roles.

Paso 2: completar la evaluación preliminar REG04

La Política de evaluación de riesgos de privacidad y EIPD de Clarysec [Política de evaluación de riesgos de privacidad y EIPD] exige:

[Ambos] El Propietario del proceso / Propietario de negocio DEBE completar la evaluación preliminar REG04 de referencia para todas las actividades de tratamiento REG02 activas dentro del alcance en un plazo de 30 días hábiles desde la aprobación del alcance del PIMS o la ampliación del alcance.

La evaluación preliminar debe identificar supervisión, elaboración de perfiles, categorías especiales, personas vulnerables, nueva tecnología, tratamiento a gran escala, transferencias transfronterizas o cambio de finalidad. Si se cumplen los umbrales, se activa una EIPD.

Paso 3: realizar la EIPD y definir el tratamiento

La P17 Política de Protección de Datos y Privacidad exige:

Todos los cambios significativos en sistemas o procesos que impliquen información personal (PII) deben 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).

En la biblioteca de Clarysec, esto está vinculado a la cláusula 5.6. La EIPD debe evaluar riesgos como recopilación excesiva, finalidad poco clara, reidentificación, acceso no autorizado de administradores del cliente, conservación poco clara y exposición a subencargados del tratamiento. Los tratamientos pueden incluir minimización a nivel de campo, seudonimización, controles de configuración del cliente, valores de conservación por defecto, registro de auditoría más sólido, actualizaciones del contrato de encargo de tratamiento, avisos de producto y restricciones al entrenamiento de modelos.

Paso 4: actualizar REG03 y la SoA

La Política PIMS exige:

[Ambos] El Responsable de Privacidad / Responsable del PIMS DEBE mantener REG03 con controles incluidos, controles excluidos, estado de implantación y justificación anualmente y dentro de los 30 días posteriores a cada cambio de tratamiento de riesgos de privacidad.

Si la EIPD añade enmascaramiento para analítica no productiva, registro de eventos para acceso de administradores, controles de supresión, cláusulas de proveedores o salvaguardas de configuración del cliente, REG03 y la SoA deben actualizarse.

Paso 5: demostrar la privacidad desde el diseño

La Política de Privacidad para pymes recoge el principio de forma clara:

La privacidad desde el diseño y por defecto debe aplicarse en todos los sistemas y servicios nuevos.

Las evidencias deben incluir la EIPD, la revisión de arquitectura, la decisión de minimización de datos, el modelo de acceso, la configuración de registro de eventos, el ajuste de conservación, los resultados de las pruebas, la aprobación de la liberación y la revisión posterior al lanzamiento. Esto convierte el lanzamiento de la funcionalidad en evidencias PIMS reutilizables.

Gobernanza de la privacidad de proveedores en un entorno DORA y NIS2

La gobernanza de la privacidad de proveedores es donde muchas transiciones fallan. GDPR Article 28 exige que los responsables del tratamiento utilicen encargados del tratamiento que ofrezcan garantías suficientes y que incorporen las obligaciones de los encargados del tratamiento en contratos escritos. DORA Articles 28 to 30 exigen que las entidades financieras gestionen el riesgo de terceros de TIC, mantengan registros de acuerdos contractuales, realicen diligencia debida, incluyan derechos de auditoría y cláusulas de salida, gestionen la subcontratación y aborden funciones esenciales o importantes. NIS2 Article 21 exige medidas de seguridad de la cadena de suministro, incluida la consideración de vulnerabilidades de proveedores, prácticas de ciberseguridad y procedimientos de desarrollo seguro.

El control 5.19 de ISO/IEC 27002:2022, Seguridad de la información en las relaciones con proveedores, es el ancla operativa. Zenith Controls mapea esta área a acuerdos con proveedores, seguridad de la cadena de suministro de TIC, transferencia de información, supervisión del cumplimiento, uso aceptable, obligaciones de encargados del tratamiento en GDPR, ciberseguridad de la cadena de suministro en NIS2, riesgo de terceros de TIC en DORA, gobernanza de proveedores en NIST y gestión de proveedores en COBIT.

Para las entidades financieras reguladas por DORA, estas evidencias deben conectarse con registros de terceros de TIC y evaluaciones de funciones esenciales o importantes. Para entidades NIS2, los mismos registros de proveedores dan soporte a la gestión de riesgos de la cadena de suministro. Para NIST CSF 2.0, la gobernanza de proveedores se alinea con la función GOVERN, especialmente con los resultados de gestión de riesgos de la cadena de suministro. Para COBIT 2019, la gobernanza de proveedores se alinea con objetivos como APO10 Gestionar proveedores y controles operativos relacionados con proveedores de DSS.

La preparación ante incidentes y violaciones de seguridad debe integrarse

Los planes de transición de privacidad suelen centrarse demasiado en la documentación y demasiado poco en la gestión de violaciones de seguridad. Eso es peligroso porque GDPR, NIS2 y DORA esperan procesos de incidentes disciplinados, aunque los umbrales y los plazos de notificación difieran.

GDPR exige evaluar si un evento de seguridad causó una violación de la seguridad de los datos personales y si se requiere notificación a la autoridad de control o a las personas afectadas. NIS2 establece notificación por fases para incidentes significativos, incluido un aviso temprano en 24 horas, una notificación en 72 horas y un informe final en un mes. DORA exige que las entidades financieras detecten, gestionen, clasifiquen, registren, notifiquen, respondan y aprendan de incidentes relacionados con las TIC, con notificación por fases para incidentes graves.

NIST CSF 2.0 apoya este ciclo mediante los resultados Detect, Respond, Recover y Govern. El equipo de transición debe garantizar que las decisiones sobre violaciones de privacidad estén integradas en el flujo de trabajo de incidentes de seguridad, no gestionadas como una reflexión legal desconectada.

Una hoja de ruta, muchos resultados de cumplimiento

La transición a ISO/IEC 27701:2025 gana valor cuando reduce el trabajo de cumplimiento duplicado. Zenith Blueprint, paso 14, recomienda hacer referencias cruzadas entre GDPR, NIS2 y DORA para que las organizaciones puedan demostrar que el tratamiento de riesgos y los controles satisfacen múltiples obligaciones:

Para cada regulación, si procede, puede crear una tabla de mapeo sencilla (podría ser un
anexo en un informe) que enumere los requisitos clave de seguridad de la regulación y los
controles/políticas correspondientes en su SGSI.

Para la planificación de la transición de privacidad, el mapeo debe ser práctico y basado en evidencias.

En Zenith Controls, el control 5.31 de ISO/IEC 27002:2022 da soporte a la trazabilidad legal y normativa en la responsabilidad proactiva de GDPR, las obligaciones de cumplimiento de DORA, las expectativas de gobernanza de NIS2, NIST CSF 2.0 GV.OC-03 y la supervisión de cumplimiento externo de COBIT. El control 5.34 da soporte a GDPR Articles 25 and 32, la protección del ciclo de vida de PII, las expectativas de tratamiento de PII en la nube y los controles de seguridad conscientes de la privacidad.

El resultado no es un modelo simplista de “un control equivale a una ley”. Es un modelo de evidencias defendible en el que un conjunto de controles bien diseñado soporta múltiples necesidades de aseguramiento.

Cómo probarán los auditores la transición

Un plan de transición sólido anticipa las técnicas de auditoría.

Un auditor de sistemas de gestión ISO comenzará por el alcance, las partes interesadas, los requisitos legales, los riesgos, los objetivos, los controles operativos, las auditorías internas, las revisiones por la dirección, las no conformidades y la mejora. Verificará si el alcance del PIMS está aprobado, si las obligaciones de privacidad están incluidas en el Registro de Cumplimiento, si los controles están justificados en la SoA y si las evidencias de implantación coinciden con el alcance declarado.

Un auditor de privacidad muestreará registros de actividades de tratamiento, EIPD, DSAR, decisiones sobre violaciones de seguridad, contratos con encargados del tratamiento, controles de conservación e incorporación de proyectos. No aceptará intención de política cuando falten evidencias operativas.

Un evaluador alineado con NIST buscará gobernanza, obligaciones legales y contractuales, perfiles objetivo, riesgo de proveedores, supervisión, respuesta y evidencias de recuperación.

Un auditor COBIT 2019 se centrará en la supervisión del consejo de administración, los informes de cumplimiento, la gobernanza de proveedores, los roles y responsabilidades, y si el riesgo de privacidad se gestiona a lo largo del ciclo de vida de la información.

La Política de seguimiento, auditoría y mejora del PIMS de Clarysec [Política de seguimiento, auditoría y mejora del PIMS] hace obligatorio el programa de auditoría:

[Todos] El Revisor de Auditoría Interna / Cumplimiento DEBE preparar un programa de auditoría interna del PIMS basado en riesgos en REG12 anualmente antes del primer ciclo de auditoría del PIMS planificado.

La Política de Auditoría y Supervisión del Cumplimiento [Política de Auditoría y Supervisión del Cumplimiento] aplica la misma disciplina a nivel del SGSI:

Se debe desarrollar y aprobar anualmente un Plan de Auditoría basado en riesgos, teniendo en cuenta:

Para organizaciones más pequeñas, la Política de Auditoría y Supervisión del Cumplimiento - pyme [Política de Auditoría y Supervisión del Cumplimiento para pymes] mantiene enfocada la planificación de auditoría:

El plan debe identificar los sistemas y políticas clave que se revisarán, con foco en:

Durante la transición, la primera auditoría interna no debe probarlo todo. Debe probar los riesgos de transición más altos: registros de actividades de tratamiento incompletos, criterios de activación de EIPD ausentes, cláusulas débiles de privacidad de proveedores, decisiones sobre violaciones de seguridad no probadas, roles poco claros de responsable del tratamiento y encargado del tratamiento, y discrepancias con la SoA.

Una hoja de ruta práctica de transición a ISO/IEC 27701:2025 en 90 días

Una hoja de ruta realista debe ser lo bastante breve para ejecutarse y lo bastante estructurada para generar evidencias.

El objetivo de 90 días no significa que todos los elementos de remediación estén cerrados. Significa que la dirección debe contar con un alcance aprobado, una línea base de evidencias creíble, un tratamiento de riesgos priorizado, resultados de auditoría enfocados y una decisión de la dirección sobre la preparación.

Hacer que la transición se base en evidencias

Las organizaciones que tienen éxito en la transición a ISO/IEC 27701:2025 no son las que tienen la política de privacidad más larga. Son las que pueden demostrar cómo las obligaciones de privacidad pasan de la ley al alcance, del alcance a los registros de actividades de tratamiento, de los registros de actividades de tratamiento a la evaluación de riesgos, de la evaluación de riesgos a los controles, de los controles a las evidencias y de las evidencias a la mejora.

Clarysec ayuda a los equipos a hacer práctica esa transición. Nuestro conjunto de políticas PIMS, mapeos de GDPR, registros de evidencias de responsable del tratamiento y encargado del tratamiento, flujos de trabajo de EIPD, plantillas de gobernanza de privacidad de proveedores, materiales de gestión de violaciones de seguridad, agendas de revisión por la dirección, Zenith Blueprint y Zenith Controls ofrecen a CISO, DPO, responsables de cumplimiento, auditores y propietarios de negocio una ruta estructurada desde la intención de privacidad hasta la operación preparada para auditorías.

Si su organización se está preparando para ISO/IEC 27701:2025, empiece esta semana con tres acciones: aprobar el alcance de transición del PIMS en REG01, completar REG02 para su servicio de mayor riesgo y ejecutar la primera evaluación preliminar REG04. Después, utilice Clarysec para convertir ese conjunto de evidencias en una hoja de ruta completa de transición del PIMS alineada con GDPR, lista para clientes, auditores, reguladores y el consejo de administración.