Aplicabilidad de los controles ISO 27701 según los roles del RGPD de la UE

Son las 08:40 de un martes y María, CISO de una empresa SaaS de tecnología sanitaria en rápido crecimiento, observa cuatro correos de clientes que parecen casi idénticos, pero que significan cosas muy distintas.

Un cliente empresarial solicita evidencias de que la compañía puede actuar como encargada del tratamiento conforme al artículo 28 del RGPD de la UE. Un segundo cliente pregunta si la plataforma también actúa como responsable del tratamiento respecto de la telemetría y la analítica de producto. Un tercero solicita la lista actual de subencargados y prueba de que las cláusulas del contrato de encargo del tratamiento se trasladan contractualmente. Un cuarto cliente, una fintech que se prepara para revisiones de proveedores DORA, pregunta si los mismos controles de privacidad están correlacionados con la resiliencia operativa, la notificación de incidentes y el riesgo de terceros TIC.

La empresa de María no actúa de forma negligente. Cuenta con un SGSI alineado con ISO/IEC 27001:2022, políticas de privacidad, un registro de actividades de tratamiento, autenticación multifactor, cifrado, revisiones de acceso y formación sobre privacidad desde el diseño. Sin embargo, la solicitud expone la pregunta más difícil que auditores y clientes realmente comprueban:

¿Puede la empresa demostrar que los controles adecuados del PIMS de ISO 27701 aplican al rol correcto del RGPD de la UE, para la actividad de tratamiento correcta, con el propietario, las evidencias y la justificación adecuados?

Ahí es donde fallan muchos programas de privacidad. Tratan ISO 27701 como una lista de verificación, cuando los organismos de certificación, los auditores de clientes y los Delegados de Protección de Datos esperan una decisión razonada sobre la aplicabilidad de los controles. La respuesta no es “tenemos controles de privacidad”. La respuesta es “para esta actividad de tratamiento, somos responsables del tratamiento, encargados del tratamiento, corresponsables del tratamiento o subencargados, y estos son los motivos por los que estos controles aplican o no aplican”.

Por qué la aplicabilidad de los controles de ISO 27701 es la capa que falta en el PIMS

Los roles del RGPD de la UE se basan en la capacidad de decisión. Un responsable del tratamiento determina los fines y medios del tratamiento. Un encargado del tratamiento actúa por cuenta de un responsable. Los corresponsables determinan conjuntamente los fines y medios. Un subencargado es contratado por un encargado para tratar datos personales en un nivel posterior de la cadena.

En entornos SaaS reales, estos roles rara vez permanecen claros a nivel de empresa. La organización de María actúa como encargada del tratamiento cuando aloja datos de bienestar de clientes, como responsable del tratamiento para nóminas de empleados y contactos de marketing, como posible responsable respecto de la telemetría de producto según la finalidad y los términos contractuales, y como corresponsable en una campaña con marca compartida. Si un proveedor de servicios gestionados de mayor tamaño revende su plataforma, la empresa también puede convertirse en subencargada dentro de esa cadena.

La aplicabilidad de los controles de ISO 27701 es la disciplina que evita que esos roles se diluyan en declaraciones vagas. Plantea las siguientes preguntas:

• ¿Qué actividad de tratamiento está dentro del alcance?
• ¿Qué rol del RGPD de la UE desempeña la organización en esa actividad?
• ¿Qué controles del PIMS aplican debido a ese rol?
• ¿Qué controles se excluyen y por qué?
• ¿Qué evidencias demuestran la implantación?
• ¿Qué requisito legal, contractual, de riesgo o de alcance impulsa la decisión?

La Política del Sistema de Gestión de la Privacidad de la Información de Clarysec convierte la clasificación de roles en el punto de partida:

“[Ambos] El propietario del proceso / propietario del negocio DEBE clasificar el rol de PIMS de la organización para cada actividad de tratamiento de PII en REG02 antes de que comience la actividad de tratamiento.”

De la sección “Determinación del rol en el PIMS”, cláusula 4.2.1 de la política.

La misma política conecta esa decisión de rol con la aplicabilidad de los controles:

“[Ambos] El Responsable de Privacidad / Responsable del PIMS DEBE mantener REG03 con los controles incluidos, los controles excluidos, el estado de implantación y la justificación con periodicidad anual y en un plazo de 30 días tras cada cambio en el tratamiento de riesgos de privacidad.”

De la sección “Política de privacidad, objetivos y aplicabilidad de los controles”, cláusula 4.3.3 de la política.

REG02 responde qué tratamiento existe y qué rol aplica. REG03 responde qué controles aplican, qué se excluye, qué evidencias existen y por qué la decisión es defendible.

Construir el PIMS sobre la lógica de la Declaración de Aplicabilidad de ISO/IEC 27001:2022

Un PIMS basado en roles funciona mejor cuando se construye sobre un SGSI maduro. ISO/IEC 27001:2022 ya exige definición de alcance, análisis de partes interesadas, evaluación de riesgos, tratamiento de riesgos, selección de controles y una Declaración de Aplicabilidad. ISO 27701 extiende esa lógica de sistema de gestión a la privacidad.

La Política de Seguridad de la Información de Clarysec establece:

“El SGSI deberá incluir límites de alcance definidos, una metodología de evaluación de riesgos, objetivos medibles y controles documentados justificados en la Declaración de Aplicabilidad (SoA).”

De la sección “Requisitos de implantación de la política”, cláusula 6.1.2 de la política.

La Política de gestión de riesgos refuerza la misma disciplina de evidencias:

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

De la sección “Requisitos de gobierno”, cláusula 5.4 de la política.

Para la privacidad, REG03 se convierte en el registro de aplicabilidad de controles del PIMS que replica la disciplina de la SoA. No sustituye a la SoA de ISO/IEC 27001:2022. La enriquece añadiendo decisiones de privacidad específicas por rol del RGPD de la UE para responsables del tratamiento, encargados del tratamiento, corresponsables y subencargados.

La Política de Inventario de Tratamiento de PII y Base Jurídica hace explícita esa vinculación:

“[Ambos] El Responsable de Privacidad / Responsable del PIMS DEBE vincular las actividades de tratamiento REG02 aplicables con los registros de aplicabilidad de controles REG03 antes de la revisión de preparación para la certificación.”

De la sección “Operación del inventario de tratamientos”, cláusula 7.1.5 de la política.

Un auditor debería poder seleccionar una actividad de tratamiento en REG02, identificar el rol del RGPD de la UE, trazar los controles aplicables en REG03, revisar los controles relevantes de ISO/IEC 27001:2022 en la SoA e inspeccionar evidencias como un contrato de encargo del tratamiento, un registro de base jurídica, una revisión de acceso, una aprobación de subencargado, un procedimiento de incidentes o un registro de supresión.

El modelo de aplicabilidad de controles basado en roles

La forma más rápida de hacer utilizable ISO 27701 es decidir la aplicabilidad a nivel de actividad de tratamiento, no a nivel de empresa.

Un proveedor SaaS debe evitar decir “somos encargados del tratamiento”. Debe decir: “para los registros de usuarios cargados por clientes en la plataforma de producción, somos encargados del tratamiento. Para nóminas, somos responsables del tratamiento. Para analítica de producto, nuestro rol depende de si la analítica se usa solo para prestar servicios contratados o para nuestras finalidades independientes. Para el proveedor de tickets que da soporte a datos de clientes, el proveedor es un subencargado”.

Esta visión basada en roles se alinea con la responsabilidad proactiva del RGPD de la UE. Los responsables del tratamiento deben demostrar cumplimiento de principios como licitud, lealtad, transparencia, limitación de la finalidad, minimización, exactitud, limitación del plazo de conservación, integridad, confidencialidad y responsabilidad proactiva. Los encargados del tratamiento deben tratar solo conforme a instrucciones documentadas, implantar seguridad adecuada, asistir a los responsables, gestionar subencargados y respaldar la devolución o supresión.

El atajo peligroso consiste en asumir que todos los controles de privacidad aplican en todas partes. Normalmente, un encargado no determina la base jurídica para los datos de usuarios finales de clientes, pero debe probar que trata únicamente conforme a las instrucciones del cliente. Un responsable puede no necesitar la aprobación de subencargados por parte de clientes para tratamientos internos de RR. HH., pero debe realizar diligencia debida sobre el encargado que presta el servicio de nóminas.

Clasificar antes de aprobar el contrato o iniciar el tratamiento

El hallazgo más común en la preparación del PIMS es la clasificación tardía de roles. El contrato se firma, la plataforma está en producción, los proveedores están integrados y nadie ha decidido si la organización actúa como responsable del tratamiento, encargada del tratamiento, corresponsable o subencargada para cada flujo de datos.

Ese retraso crea problemas posteriores. Se usa el contrato de encargo del tratamiento incorrecto. No se comunican los subencargados. Se omiten EIPD. La conservación no está clara. El soporte al cliente no sabe qué plazo de notificación de violación de seguridad aplica. Compras trata a un proveedor con impacto en privacidad como “solo una herramienta”.

La Política de gestión de privacidad de encargados, subencargados y terceros aborda directamente el momento:

“[Ambos] El Responsable de Privacidad / Responsable del PIMS DEBE clasificar cada relación de privacidad con terceros como responsable del tratamiento, corresponsable del tratamiento, encargado del tratamiento, subencargado u otra relación con terceros en REG08 antes de la aprobación del contrato o antes de que comience el tratamiento de PII, lo que ocurra primero.”

De la sección “Identificación y clasificación de relaciones”, cláusula 4.1.3 de la política.

La clasificación de proveedores y relaciones con terceros en REG08 alimenta REG03. Si un proveedor es encargado del tratamiento, los controles aplicables incluyen términos del contrato de encargo del tratamiento, confidencialidad, medidas de seguridad, derechos de auditoría, asistencia con solicitudes de ejercicio de derechos, apoyo ante violaciones de seguridad, devolución o supresión y controles de subencargados. Si un proveedor es un responsable independiente, el foco cambia a base jurídica, gobierno de comunicaciones de datos personales, transferencias, transparencia y responsabilidad proactiva.

Para organizaciones más pequeñas, la Política de Seguridad de Terceros y Proveedores - SME exige que los equipos consideren:

“Exposición regulatoria (p. ej., rol de encargado del tratamiento conforme al RGPD de la UE, obligaciones del sector financiero conforme a DORA)”

De la sección “Requisitos de gobierno”, cláusula 5.2.4 de la política.

También establece un requisito claro antes de compartir datos:

“Las cláusulas del contrato de encargo del tratamiento o términos contractuales equivalentes deben acordarse antes de compartir cualquier dato personal o sensible.”

De la sección “Requisitos de implantación de la política”, cláusula 6.3.2 de la política.

Esa es la diferencia entre tener contratos con proveedores y tener un gobierno auditable de los roles de privacidad.

Relacionar controles con rol, riesgo, ley y contrato

Zenith Blueprint, fase de Gestión de riesgos, Paso 13: Planificación del Tratamiento de Riesgos y Declaración de Aplicabilidad, explica la lógica central de aplicabilidad. Los controles son aplicables por decisiones de tratamiento de riesgos, requisitos legales o contractuales, relevancia para el alcance y contexto organizativo. Las exclusiones necesitan razones claras, y los controles aplicables deben trazarse hasta un riesgo o requisito.

En el Paso 13, Zenith Blueprint establece:

“Asegura la alineación con tu registro de riesgos: cada control compensatorio que hayas escrito en el Plan de Tratamiento de Riesgos debe corresponderse con un control del Anexo A marcado como ‘Aplicable’. A la inversa, si un control está marcado como aplicable, deberías tener un riesgo o un requisito que lo impulse.”

Para ISO 27701, el mismo método aplica a los controles de privacidad. Un control puede ser aplicable porque:

1. El RGPD de la UE lo exige para el rol de la organización.
2. Lo exige un contrato de cliente, un contrato de encargo del tratamiento o un acuerdo de corresponsabilidad del tratamiento.
3. Lo exige un tratamiento de riesgos de privacidad.
4. El tratamiento incluye categorías especiales, datos de menores, monitorización a gran escala, elaboración de perfiles sensibles o datos personales de alto impacto.
5. El riesgo de proveedores, nube, subencargados o transferencias transfronterizas hace necesario el control.
6. El control respalda el alcance de certificación, la preparación para auditorías o los objetivos de privacidad aprobados.

La Política de Cumplimiento Legal y Normativo refuerza esta disciplina de mapeo:

“Cuando una regulación aplique a múltiples áreas (p. ej., el RGPD de la UE aplica a conservación, seguridad y privacidad), esto debe mapearse claramente en el Registro de Cumplimiento y en los materiales de formación.”

De la sección “Requisitos de gobierno”, cláusula 5.2.2 de la política.

La misma Política de Cumplimiento Legal y Normativo es explícita respecto a la integración con el SGSI empresarial:

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

De la sección “Requisitos de implantación de la política”, cláusula 6.2.1 de la política.

Por tanto, REG03 nunca debe ser una hoja de cálculo de privacidad aislada. Debe conectar actividades de tratamiento, obligaciones legales, tratamientos de riesgos, contratos, controles de ISO/IEC 27001:2022 y propietarios de evidencias.

Ejemplo práctico: un flujo de trabajo de soporte SaaS

Considera un flujo de trabajo de soporte en la plataforma SaaS de María. Los clientes envían tickets que pueden contener nombres, correos electrónicos, identificadores de cuenta, capturas de pantalla y, ocasionalmente, contexto de negocio sensible. Los agentes de soporte acceden a registros limitados. Un proveedor de tickets en la nube aloja los datos y utiliza sus propios subencargados.

Paso 1: Registrar la actividad en REG02

El Responsable de Privacidad registra:

• Nombre de la actividad: Gestión de tickets de soporte al cliente
• Categorías de PII: identificadores de usuario, datos de contacto, capturas de pantalla, metadatos de cuenta
• Interesados: administradores de clientes y usuarios finales
• Finalidad: soporte y resolución de incidencias del servicio
• Rol: encargado del tratamiento para PII de usuarios finales proporcionada por clientes; responsable del tratamiento para la gestión de contactos comerciales directos si se usan para comunicaciones de cuenta
• Conservación: período definido de conservación de soporte y auditoría
• Destinatarios: personal interno de soporte, proveedor de tickets, subencargados aprobados
• Clasificación de seguridad: confidencial, PII

La Política de Protección de Datos y Privacidad - SME respalda esta 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”

De la sección “Requisitos de gobierno”, cláusula 5.2.1 de la política.

Paso 2: Clasificar al proveedor en REG08

Si la empresa de María actúa como encargada del tratamiento para datos de clientes, el proveedor de tickets suele ser un subencargado para esos datos de clientes. REG08 debe capturar el tipo de relación, el estado contractual, las categorías de datos, las ubicaciones de los datos, los subencargados posteriores y las evidencias de aseguramiento.

Paso 3: Registrar la aplicabilidad en REG03

La Política de Protección de Datos y Privacidad empresarial añade un desencadenante de alto riesgo:

“El modelado de amenazas y las Evaluaciones de Impacto relativas a la Protección de Datos (EIPD) son obligatorios para sistemas de tratamiento de alto riesgo.”

De la sección “Requisitos de implantación de la política”, cláusula 6.3.4 de la política.

La Política de Protección de Datos y Privacidad - SME incorpora la expectativa de diseño:

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

De la sección “Requisitos de gobierno”, cláusula 5.3.1 de la política.

Paso 4: Alinear con los controles de ISO/IEC 27001:2022

Si la plataforma de soporte está dentro del alcance del SGSI, la SoA debe incluir controles de soporte de ISO/IEC 27002:2022 como relaciones con proveedores, acuerdos con proveedores, gestión de la cadena de suministro TIC, control de acceso, gestión de identidades, transferencia de información, servicios en la nube, gestión de incidentes, registro de eventos y supervisión, gestión de cambios, cumplimiento legal y protección de la privacidad.

Zenith Blueprint, fase de Gestión de riesgos, Paso 14: Políticas de Tratamiento de Riesgos y Referencias Cruzadas Regulatorias, recomienda referenciar de forma cruzada el RGPD de la UE, NIS2 y DORA frente a políticas y controles, especialmente para protección de datos personales, respuesta a incidentes, control de acceso, continuidad del negocio y riesgo de terceros TIC.

El resultado son evidencias reutilizables, no hojas de cálculo separadas para el RGPD de la UE, DORA, NIS2 y la certificación.

Qué aporta Zenith Controls a la aplicabilidad del PIMS

Zenith Controls es la guía de cumplimiento cruzado de Clarysec para entender las relaciones entre los controles de ISO/IEC 27001:2022 e ISO/IEC 27002:2022, los métodos de auditoría y otros marcos. No es un conjunto de controles separado. Para este tema, los controles centrales de ISO/IEC 27002:2022 son:

• 5.34 Privacidad y protección de PII
• 5.19 Seguridad de la información en las relaciones con proveedores
• 5.20 Tratamiento de la seguridad de la información en acuerdos con proveedores
• 5.21 Gestión de la seguridad de la información en la cadena de suministro TIC
• 5.22 Supervisión, revisión y gestión de cambios de los servicios de proveedores

Para 5.34, Zenith Controls clasifica el control como preventivo, mapeado con confidencialidad, integridad y disponibilidad, alineado con Identify y Protect, y asociado con capacidades de protección de la información, legales y de cumplimiento.

Su mapeo con el RGPD de la UE establece:

“La implantación de 5.34 es evidencia directa de la capacidad de una organización para cumplir los requisitos de responsabilidad proactiva del RGPD de la UE.”

De Zenith Controls, Privacidad y Protección de PII, mapeo cruzado con el RGPD de la UE.

Esa frase importa porque convierte 5.34 de una declaración genérica de privacidad en evidencia de auditoría. Debe estar respaldada por inventarios de PII, clasificación, control de acceso, enmascaramiento, transferencia segura, gobierno de la nube, EIPD, avisos de privacidad, flujos de trabajo de atención de derechos y gestión de violaciones de seguridad.

Zenith Controls también conecta la privacidad y la protección de PII con normas relacionadas, como ISO/IEC 27018 para el tratamiento de PII en nube pública, ISO/IEC 29100 para principios de privacidad e ISO/IEC 29151 para prácticas de protección de PII. El gobierno de privacidad de proveedores se apoya en la familia ISO/IEC 27036 para relaciones con proveedores y seguridad de la cadena de suministro TIC, y en ISO/IEC 27017 para responsabilidades compartidas de seguridad en la nube.

Las evidencias de proveedores y subencargados son el punto donde convergen los roles

Las obligaciones de responsables y encargados del tratamiento suelen encontrarse en el límite con el proveedor.

Si la empresa de María actúa como responsable del tratamiento, el RGPD de la UE espera que utilice encargados que ofrezcan garantías suficientes. Si actúa como encargada, los clientes esperan que gestione subencargados, traslade obligaciones contractualmente y proporcione aseguramiento. Si actúa como subencargada, hereda obligaciones a través de la cadena.

Esto convierte los controles 5.19 y 5.20 de ISO/IEC 27002:2022 en elementos centrales para la aplicabilidad de los controles de ISO 27701.

Para 5.19, Zenith Controls enfatiza la seguridad de las relaciones con proveedores en los dominios de gobierno, ecosistema y protección. Se vincula directamente con 5.20 acuerdos con proveedores, 5.21 seguridad de la cadena de suministro TIC, 5.14 transferencia de información, 5.36 Cumplimiento de políticas, reglas y normas de seguridad de la información, y 5.10 Uso aceptable de la información y otros activos asociados.

Para 5.20, Zenith Controls enfatiza la formalización contractual. Los acuerdos con proveedores deben definir confidencialidad, notificación de violaciones de seguridad, derechos de auditoría, aprobación de subcontratistas, transferencia segura, devolución o destrucción de datos, obligaciones de cumplimiento y supervisión.

Zenith Blueprint, fase Controles en Acción, Paso 23: Controles organizativos, ofrece una instrucción práctica para subencargados:

“Para cada proveedor crítico, identifica si utiliza subcontratistas (subencargados) que puedan acceder a tus datos o sistemas. Documenta cómo se trasladan tus requisitos de seguridad de la información a estas partes, ya sea mediante los términos contractuales de tu proveedor o mediante tus propias cláusulas directas.”

Los auditores no se detendrán en “¿tenéis un contrato de encargo del tratamiento?”. Preguntarán si los proveedores son encargados del tratamiento, subencargados, responsables independientes o corresponsables, si las aprobaciones de subencargados están documentadas, si las obligaciones se trasladan contractualmente, si los plazos de notificación de violaciones de seguridad están claros, si existe supervisión y si pueden obtenerse evidencias de supresión o devolución.

Cumplimiento cruzado sin sistemas de control duplicados

La aplicabilidad de los controles de ISO 27701 aporta más valor cuando respalda conversaciones de aseguramiento sobre el RGPD de la UE, NIS2, DORA, NIST CSF 2.0 y COBIT 2019 a partir de la misma base de evidencias.

El RGPD de la UE impulsa obligaciones de privacidad basadas en roles: responsabilidad proactiva del responsable, deberes del encargado, base jurídica, derechos de los interesados, seguridad, gobierno de violaciones de seguridad y contratos.

NIS2 añade gestión de riesgos de ciberseguridad, gestión de incidentes, continuidad del negocio, seguridad de la cadena de suministro, desarrollo seguro, gestión de vulnerabilidades, control de acceso, criptografía, autenticación multifactor y formación para entidades esenciales e importantes.

DORA aplica desde el 17 de enero de 2025 a entidades financieras dentro de su alcance y exige gestión del riesgo de las TIC, notificación de incidentes, pruebas de resiliencia y gestión del riesgo de terceros TIC. A los proveedores SaaS y TIC que prestan servicio a entidades financieras se les suele pedir que aporten evidencias de privacidad, seguridad, resiliencia, derechos de auditoría y salida en un único paquete de aseguramiento.

NIST CSF 2.0 proporciona una capa de gobierno mediante la función GOVERN, incluidas obligaciones legales, regulatorias, contractuales y de privacidad, roles, apetito de riesgo, supervisión de políticas y gobierno de la cadena de suministro.

COBIT 2019 añade prácticas de gobierno y gestión. Para privacidad, Zenith Controls mapea 5.34 con COBIT DSS06.02, DSS06.08 y APO13.01. Para proveedores, 5.19 y 5.20 respaldan prácticas de riesgo de proveedores y acuerdos con proveedores.

El punto estratégico es sencillo. REG03 debe ser más que un artefacto de ISO 27701. Debe ser un mapa reutilizable de aplicabilidad de controles para auditorías de clientes, revisiones regulatorias y aseguramiento ante el consejo.

Cómo prueban los auditores la aplicabilidad de los controles de ISO 27701

Distintos auditores empiezan desde ángulos diferentes, pero normalmente convergen en la misma pista de evidencias.

Un auditor de sistemas de gestión ISO empieza por el alcance, las partes interesadas, las obligaciones, la evaluación de riesgos, la alineación con la SoA, la auditoría interna, la revisión por la dirección y la mejora continua. Comprobará si REG02, REG03 y la SoA de ISO/IEC 27001:2022 son coherentes.

Un auditor centrado en el RGPD de la UE o un revisor DPD comprueba la lógica de roles. Tomará muestras de actividades y revisará base jurídica, avisos de privacidad, contratos de encargo del tratamiento, subencargados, EIPD, gestión de solicitudes de ejercicio de derechos, conservación y toma de decisiones sobre violaciones de seguridad de los datos personales.

Un evaluador orientado a NIST busca resultados de gobierno, categorización de riesgos, inventarios de datos, controles de acceso, protección de datos en reposo y en tránsito, supervisión, respuesta a incidentes, riesgo de proveedores y planes de mejora.

Un auditor COBIT 2019 o ISACA observa la propiedad del gobierno, la capacidad de los procesos, el diseño del control y la eficacia operativa. Comprobará si los controles de privacidad están integrados en compras, gestión de cambios, gestión de incidentes y supervisión de proveedores.

Para 5.34, Zenith Controls describe a auditores revisando políticas de privacidad, inventarios de datos, EIPD, registros de formación, salvaguardas técnicas, muestras de solicitudes de ejercicio de derechos, incidentes de PII y evidencias de privacidad desde el diseño. Para 5.19 y 5.20, los auditores solicitan inventarios de proveedores, clasificaciones de riesgo, registros de diligencia debida, contratos, términos sobre violaciones de seguridad, derechos de auditoría, aprobación de subcontratistas, evidencias de salida y prueba de que los informes de proveedores se revisan.

La distinción es crítica. La preparación para auditorías no consiste en “tenemos una cláusula”. La preparación para auditorías consiste en “usamos la cláusula, la supervisamos, revisamos evidencias y actuamos cuando cambió el riesgo”.

Errores comunes en la aplicabilidad para responsables y encargados

Clarysec observa repetidamente cinco fallos evitables.

Primero, las organizaciones clasifican toda la empresa con un único rol del RGPD de la UE. Eso no funciona para SaaS, fintech, tecnología de RR. HH., tecnología sanitaria, servicios gestionados o proveedores en la nube con flujos de datos mixtos.

Segundo, tratan los controles de ISO 27701 como aplicables universalmente sin justificación por rol. Esto crea requisitos de evidencias sobredimensionados y exclusiones débiles.

Tercero, excluyen controles sin documentar por qué. En la lógica de la SoA de ISO/IEC 27001:2022 y en la lógica de aplicabilidad del PIMS, las exclusiones deben ser conscientes, razonadas y respaldadas por análisis de alcance, rol, riesgo o base legal.

Cuarto, olvidan a los subencargados. La historia de aseguramiento de un encargado es tan sólida como su cadena posterior. Los registros de subencargados, los mecanismos de aprobación, las cláusulas trasladadas contractualmente y las evidencias de supresión son esenciales.

Quinto, no conectan los controles de privacidad con las operaciones de seguridad. La privacidad desde el diseño no es solo una plantilla de EIPD. Debe influir en los controles de acceso, el registro de eventos, el desarrollo seguro, la configuración de la nube, la diligencia debida de proveedores, la automatización de la conservación y la respuesta a incidentes.

Lista de verificación Clarysec para la aplicabilidad de controles en REG03

Usa esta lista de verificación antes de revisiones de preparación de ISO 27701, aseguramiento ante clientes conforme al RGPD de la UE o evaluaciones de proveedores impulsadas por DORA:

• Crear o actualizar REG02 para cada actividad de tratamiento que involucre PII.
• Clasificar el rol del PIMS para cada actividad antes de iniciar el tratamiento.
• Clasificar cada relación con terceros en REG08 antes de la aprobación contractual o del tratamiento de PII.
• Identificar obligaciones según el rol: responsable del tratamiento, encargado del tratamiento, corresponsable del tratamiento o subencargado.
• Registrar los controles del PIMS aplicables en REG03 con propietario, estado de implantación y evidencias.
• Registrar los controles excluidos con una justificación clara.
• Vincular las decisiones de REG03 con riesgos, obligaciones legales, contratos o justificación de alcance.
• Alinear REG03 con la SoA de ISO/IEC 27001:2022 cuando los controles de seguridad respalden la privacidad.
• Mapear los controles de privacidad con ISO/IEC 27002:2022 5.34 cuando se requiera protección de PII.
• Mapear los requisitos de proveedores y subencargados con 5.19, 5.20, 5.21 y 5.22.
• Añadir referencias de cumplimiento cruzado para el RGPD de la UE, NIS2, DORA, NIST CSF 2.0 y COBIT 2019 cuando corresponda.
• Probar la pista de evidencias con una muestra de auditoría interna antes de la revisión de preparación para la certificación.
• Obtener aprobación de la alta dirección cuando cambie el alcance del PIMS o la aplicabilidad de los controles.

La Política del Sistema de Gestión de la Privacidad de la Información cierra este ciclo de gobierno:

“[Ambos] La Alta Dirección DEBE aprobar los cambios en el alcance del PIMS y en la aplicabilidad de los controles en REG01 y REG03 antes de presentar cambios en el alcance de certificación.”

De la sección “Gobierno del PIMS”, cláusula 6.1.3 de la política.

Ese es el tipo de evidencias de gobierno en las que confían los auditores.

Convertir las decisiones sobre roles del RGPD en evidencias defendibles

La aplicabilidad de los controles de ISO 27701 es el punto donde la teoría de roles del RGPD de la UE se convierte en realidad operativa. Un responsable del tratamiento necesita evidencias de base jurídica, transparencia, conservación, EIPD, gestión de derechos y supervisión de encargados. Un encargado necesita evidencias de instrucciones documentadas, confidencialidad, seguridad, asistencia, subencargados, apoyo ante violaciones de seguridad y supresión. Un corresponsable necesita un acuerdo transparente de responsabilidades. Un subencargado necesita obligaciones trasladadas contractualmente y apoyo de aseguramiento.

Clarysec ayuda a las organizaciones a construir esa capa de evidencias mediante:

• Estructura de inventario de tratamientos REG02 y base jurídica.
• Registros REG03 de aplicabilidad de controles del PIMS.
• Clasificación REG08 de relaciones de privacidad con terceros.
• Alineación con la SoA de ISO/IEC 27001:2022.
• Cláusulas de política que asignan propietarios, plazos y requisitos de aprobación.
• Mapeo de cumplimiento cruzado mediante Zenith Controls.
• Secuenciación de la implantación mediante Zenith Blueprint.

Si tu organización se prepara para la preparación del PIMS ISO 27701, aseguramiento ante clientes conforme al RGPD de la UE, revisiones de proveedores DORA o gobierno de seguridad alineado con NIS2, empieza por una actividad de tratamiento de alto riesgo. Clasifica el rol. Mapea los controles aplicables. Vincula las evidencias. Luego repite hasta que tu programa de privacidad no solo cumpla sobre el papel, sino que pueda explicarse en auditoría.

Descarga el paquete de políticas PIMS de Clarysec, explora Zenith Blueprint o reserva una evaluación de preparación de Clarysec para convertir las decisiones de responsable del tratamiento, encargado del tratamiento, corresponsable del tratamiento y subencargado en un registro de evidencias de privacidad preparado para certificación.