Gobernanza de corresponsables del tratamiento: guía de auditoría sobre el artículo 26 del RGPD

La llamada llegó un martes por la mañana. Para el CISO de CareConnect, un proveedor SaaS de MedTech en rápido crecimiento, fue el momento en que todo cambió.

Al otro lado de la línea estaba la responsable de Cumplimiento de MetroHealth, su principal socio hospitalario. Un paciente que utilizaba la plataforma de monitorización remota gestionada conjuntamente había presentado una solicitud de acceso un mes antes. Ninguna de las dos organizaciones había respondido por completo. Cada una creía que la otra era responsable.

Después, el departamento jurídico reenvió un segundo mensaje. Un desarrollador junior de CareConnect había expuesto accidentalmente un endpoint de API no crítico que incluía identificadores limitados de pacientes. El problema parecía acotable y el plazo de notificación de 72 horas del RGPD para violaciones de seguridad todavía no había vencido. Pero la misma pregunta paralizó a ambos equipos.

¿Quién notifica a la autoridad de control? ¿Quién se comunica con los pacientes? ¿Quién es responsable del aviso de privacidad? ¿Quién valida la solicitud de acceso del interesado? ¿Quién registra la decisión?

El acuerdo comercial detallaba créditos de servicio, plataformas de facturación, límites de responsabilidad e hitos de la hoja de ruta del producto. Apenas decía nada sobre la realidad operativa de la gobernanza de corresponsables del tratamiento conforme al artículo 26 del RGPD.

Aquí es donde fallan muchas alianzas. El problema no es que los equipos de privacidad, jurídico, seguridad y compras nunca hayan oído la expresión “acuerdo de corresponsabilidad del tratamiento”. El problema es que nadie puede demostrar, antes de que comience el tratamiento, quién es responsable de la transparencia, la base jurídica, los derechos de los interesados, el escalado de violaciones de seguridad, las obligaciones trasladadas contractualmente a proveedores, las transferencias, la conservación, las evidencias y la comunicación con los reguladores.

El RGPD define la obligación. ISO/IEC 27701:2025 proporciona a los equipos de privacidad una estructura de sistema de gestión. Las políticas del PIMS de Clarysec, el Zenith Blueprint: hoja de ruta de 30 pasos para auditores y Zenith Controls: guía de cumplimiento cruzado convierten el artículo 26 en evidencias operativas preparadas para auditoría.

Por qué la gobernanza de corresponsables del tratamiento falla antes de que alguien lo advierta

Existe corresponsabilidad del tratamiento cuando dos o más partes determinan conjuntamente los fines y los medios del tratamiento de datos personales. El factor determinante no es la redacción del contrato. Es la capacidad de decisión.

En el ejemplo de CareConnect y MetroHealth, CareConnect proporciona la plataforma, la analítica, la arquitectura técnica, la interfaz de usuario y los flujos de datos. MetroHealth proporciona la relación con el paciente, el contexto clínico, el modelo de servicio y los datos del paciente. Ambas partes influyen en por qué se tratan los datos personales y en cómo funciona el tratamiento. Eso es muy distinto de un proveedor que simplemente aloja una base de datos o envía mensajes siguiendo instrucciones documentadas.

El mismo patrón aparece en campañas de bienestar financiero, alianzas de seguros integrados, marketplaces, consorcios de detección del fraude, plataformas de salud conectada, programas de fidelización, ecosistemas de verificación de identidad y colaboraciones de analítica. Un banco, una aseguradora y una plataforma SaaS podrían decidir conjuntamente segmentos objetivo, reglas de elaboración de perfiles, métricas de conversión y canales de marketing. Un contrato de encargo del tratamiento no resolverá ese problema si las partes son en realidad corresponsables del tratamiento.

Los fallos prácticos son previsibles:

1. El aviso de privacidad dice poco más que “podemos compartir datos con socios”.
2. El inventario de tratamientos identifica a las partes, pero no la asignación de obligaciones.
3. El flujo de trabajo de derechos de los interesados no tiene una ruta para remitir, validar o responder solicitudes.
4. El plan de incidentes dice “notificar a Legal”, pero no indica qué corresponsable del tratamiento lidera la comunicación externa.
5. El contrato se trata como documentación comercial, no como evidencia de responsabilidad proactiva.
6. Las disposiciones de terminación no cubren la devolución de datos, la supresión, la anonimización, la revocación de accesos ni la conservación de evidencias.

El artículo 5 del RGPD hace que estos fallos sean relevantes para auditoría, porque los responsables del tratamiento no solo deben cumplir 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. También deben poder demostrar el cumplimiento. El artículo 6 añade el requisito de base jurídica. El artículo 3 puede incluir en el alcance a proveedores SaaS, fintech, health-tech y de analítica no establecidos en la UE cuando ofrecen servicios a personas en la UE o monitorizan su comportamiento.

La lección para los CISO y los responsables de cumplimiento es directa: la gobernanza de corresponsables del tratamiento no es “solo un asunto jurídico”. Es un sistema de control interfuncional que involucra privacidad, seguridad, compras, producto, ingeniería, soporte, respuesta a incidentes, marketing y supervisión ejecutiva.

El principio del PIMS de ISO/IEC 27701:2025: decidir antes de que empiece el tratamiento

Un Sistema de Gestión de la Información de Privacidad conforme a ISO/IEC 27701:2025 solo funciona si los roles de privacidad se determinan antes de que comience el tratamiento. Esta es la disciplina operativa que evita que el artículo 26 se convierta en un ejercicio de reconstrucción posterior al incidente.

La Política del Sistema de Gestión de la Información de Privacidad de Clarysec, cláusula 4.2.2, establece:

[Corresponsable del tratamiento] El responsable de proveedores / compras DEBE documentar la asignación de responsabilidades de los corresponsables del tratamiento en REG08 antes de que comience el tratamiento conjunto.

La expresión “antes de que comience el tratamiento conjunto” es el punto de control. Significa antes de que la integración de la plataforma entre en producción, antes de que se habilite el panel compartido, antes de que empiece la sincronización con el CRM, antes de que se activen las audiencias de campaña y antes de que comiencen a llegar solicitudes de los interesados.

La obligación de inventario de soporte aparece en la Política de Inventario de Tratamientos de Datos Personales y Base Jurídica, cláusula 4.3.5:

[Corresponsable del tratamiento] El responsable de proveedores / compras DEBE registrar la finalidad del tratamiento de los corresponsables del tratamiento y la referencia de asignación de responsabilidades en REG02 y REG08 antes de que comience el tratamiento por corresponsables.

En conjunto, estas cláusulas crean la cadena de evidencias que esperan los auditores:

• REG02 registra la actividad de tratamiento, la finalidad, las categorías de datos, la base jurídica, la conservación, los sistemas, los destinatarios, las transferencias y la referencia de corresponsabilidad del tratamiento.
• REG08 registra el acuerdo de corresponsabilidad del tratamiento y la asignación de responsabilidades.
• REG07 registra el resumen de transparencia publicado.
• REG06 puede registrar la recepción de solicitudes de ejercicio de derechos, el enrutamiento, la validación, los plazos y las evidencias de respuesta.
• REG10 registra las decisiones de evaluación de incidentes y violaciones de seguridad.

Esa cadena convierte el artículo 26 de una declaración legal en un proceso de sistema de gestión.

Empezar por el alcance, las partes interesadas y una RACI

Zenith Blueprint empieza por el alcance y las partes interesadas porque la gobernanza de corresponsables del tratamiento falla cuando las partes interesadas y los requisitos se identifican demasiado tarde.

En la fase de Fundamentos y Liderazgo del SGSI, paso 2, Necesidades de las partes interesadas y alcance del SGSI, Zenith Blueprint recomienda un análisis de partes interesadas que capture requisitos explícitos e implícitos:

Cómo identificar necesidades y expectativas: Para cada grupo de partes interesadas identificado, enumere qué
requiere en relación con la seguridad de la información. Algunos requisitos son explícitos (leyes, contratos,
SLA), mientras que otros son implícitos (expectativas o buenas prácticas generales). Resulta útil:

✓ Revisar los requisitos legales y regulatorios aplicables a su contexto (a partir del análisis
de contexto del paso 1). Elaborar una lista de cláusulas u obligaciones específicas relacionadas con la seguridad
de la información o la privacidad.
✓ Revisar contratos y acuerdos: muchos contratos de negocio tienen anexos de confidencialidad o
seguridad. Extraiga esos requisitos.
✓ Realizar entrevistas o talleres con partes interesadas: interactúe con representantes de
cada grupo (por ejemplo, un responsable de Recursos Humanos para la perspectiva de los empleados o un responsable de ventas para las
expectativas de los clientes) para comprender sus inquietudes o necesidades.
✓ Considerar normas sectoriales o códigos de buenas prácticas que las partes interesadas esperan que usted
cumpla.

Para un acuerdo auditable de corresponsabilidad del tratamiento conforme al artículo 26 del RGPD, el análisis de partes interesadas debe incluir clientes, pacientes, usuarios, autoridades de control, las demás partes responsables del tratamiento, encargados del tratamiento, subencargados, aseguradoras, proveedores de servicios en la nube, departamentos internos, reguladores y órganos de dirección.

El paso 4, Roles y responsabilidades en el SGSI, convierte después ese análisis en titularidad. Zenith Blueprint destaca el valor de un modelo RACI:

✓ Responsabilidad proactiva frente a responsabilidad operativa: una herramienta útil en este punto es una matriz RACI (responsable de ejecución,
responsable último, consultado, informado). Para cada proceso o control principal del SGSI, identifique
quién es responsable de ejecutar el trabajo, quién tiene la responsabilidad última, a menudo un
responsable designado, quién debe ser consultado porque aporta información y quién debe ser informado.

Para los corresponsables del tratamiento, la RACI no es opcional en la práctica. Sin ella, Legal asume que Privacidad está respondiendo la solicitud, Privacidad asume que Soporte tiene la cola de recepción, Soporte asume que el socio responderá, y el plazo legal sigue corriendo.

El modelo de evidencias de Clarysec para corresponsables del tratamiento

Un acuerdo maduro de corresponsabilidad del tratamiento debe entenderse en una página y demostrarse en diez minutos. El objetivo no es sepultar a los equipos en documentación legal. El objetivo es hacer que las responsabilidades sean visibles, aceptadas y verificables.

Las políticas de privacidad de Clarysec refuerzan cada capa.

La Política de Aviso de Privacidad y Transparencia, cláusula 4.1.5, establece:

[Corresponsable del tratamiento] El Responsable de Privacidad / Responsable del PIMS DEBE registrar en REG07 el resumen público de responsabilidades de los corresponsables del tratamiento y el punto de contacto antes de que se lance o cambie materialmente el tratamiento por corresponsables.

La Política de Gestión de Derechos de los Interesados sobre Datos Personales, cláusula 6.1.5, establece:

[Corresponsable del tratamiento] El Responsable de Privacidad / Responsable del PIMS DEBE documentar las responsabilidades de gestión de derechos y las rutas de contacto en REG02, REG06 o REG08 antes de que comience el tratamiento por corresponsables.

La Política de Gestión de Incidentes y Violaciones de Seguridad de Datos Personales, cláusula 4.2.5, añade:

[Corresponsable del tratamiento] El Responsable de Privacidad / Responsable del PIMS DEBE verificar la responsabilidad acordada ante violaciones de seguridad, la responsabilidad principal de comunicación y el acuerdo de coordinación antes de cualquier notificación o comunicación externa por parte de un corresponsable del tratamiento, y DEBE registrar la decisión en REG08 y REG10.

Este es el punto en el que ISO/IEC 27701:2025 y el RGPD se vuelven operativos. La organización no se limita a decir que las responsabilidades están asignadas. Muestra dónde se registran, quién las aprobó, cuándo se probaron y cómo se utilizan.

Ejemplo práctico: REG08 para una plataforma de monitorización remota

Supongamos que CareConnect y MetroHealth operan conjuntamente una plataforma de monitorización remota. Ambas partes deciden por qué se tratan los datos de pacientes, qué datos se recogen, cómo se configuran las alertas de monitorización, cómo se usa la analítica y cómo interactúan los pacientes con el servicio.

Primero, REG02 debe registrar la actividad de tratamiento:

• Nombre del tratamiento: servicio de monitorización remota de pacientes
• Rol de responsable del tratamiento: corresponsable del tratamiento
• Partes: CareConnect y MetroHealth
• Finalidad: monitorización de pacientes, coordinación asistencial, mejora del servicio, analítica de la plataforma
• Categorías de datos personales: datos de contacto, identificadores de cuenta, observaciones clínicas, eventos de dispositivo, interacciones de soporte
• Comprobación de categoría especial: se tratan datos de salud y se requieren salvaguardas reforzadas
• Base jurídica: documentada por parte y finalidad
• Conservación: definida por requisitos clínicos, de plataforma, legales y operativos
• Sistemas: aplicación móvil, plataforma de monitorización, herramienta de soporte, almacén analítico, proveedor de identidad
• Destinatarios: partes corresponsables del tratamiento, proveedor de alojamiento, proveedores de soporte, proveedores de notificación
• Transferencias: acceso remoto y tratamiento fuera del EEE evaluados
• Referencia REG08: JC-2026-004

Segundo, REG08 debe asignar responsabilidades de forma que los equipos operativos puedan aplicarlas.

Tercero, REG07 debe registrar el resumen publicado. El aviso debe explicar la esencia del acuerdo conjunto en lenguaje claro, identificar a los corresponsables del tratamiento, describir de qué es responsable cada uno y proporcionar un punto de contacto utilizable. No debe obligar a pacientes o usuarios a descifrar la complejidad operativa interna.

Cuarto, pruebe el flujo de trabajo antes del lanzamiento. Envíe una solicitud de acceso simulada al punto de contacto publicado. Confirme que Soporte la identifica como una solicitud de ejercicio de derechos del interesado sobre datos personales, la enruta a Privacidad, revisa REG08, solicita aportaciones del socio, registra las acciones en REG06 y produce un paquete de respuesta. A continuación, ejecute un ejercicio de mesa sobre violaciones de seguridad con un escenario como “un endpoint de API expone identificadores de pacientes a usuarios no autorizados” o “usuarios con supresión aplicada se incluyen accidentalmente en una campaña de interacción”.

Estas pruebas exponen las brechas reales: buzones sin responsable, SLA de socios poco claros, texto de aviso no aprobado, registros incompletos de base jurídica, comprobaciones ausentes de categorías especiales y playbooks de incidentes que no nombran al responsable principal de comunicación externa.

Mapear el artículo 26 a los controles de ISO/IEC 27002:2022 mediante Zenith Controls

Un acuerdo de corresponsabilidad del tratamiento no es solo un artefacto legal. Debe estar respaldado por controles técnicos y organizativos. Zenith Controls ayuda a los equipos a mapear las expectativas de control de ISO/IEC 27001:2022 e ISO/IEC 27002:2022 con evidencias de privacidad, proveedores, incidentes, nube y gobernanza.

Tres controles de ISO/IEC 27002:2022 son especialmente relevantes.

Control 5.2, roles y responsabilidades de seguridad de la información, respalda el modelo operativo. Se conecta con la cláusula 5.3 de ISO/IEC 27001:2022, roles, responsabilidades y autoridades de la organización. También respalda la preparación ante incidentes porque los roles poco claros debilitan el Control 5.24 de ISO/IEC 27002:2022, planificación y preparación para la gestión de incidentes de seguridad de la información. En la gobernanza de corresponsables del tratamiento, el Control 5.2 es donde la RACI, los responsables de REG08, los gestores de solicitudes de derechos, los responsables de violaciones de seguridad y los contactos de escalado se convierten en evidencias de auditoría.

Control 5.31, requisitos legales, estatutarios, regulatorios y contractuales, es donde el artículo 26 del RGPD pasa a formar parte del SGSI en lugar de ser un asunto exclusivamente jurídico. Respalda la identificación y gestión de la responsabilidad proactiva del artículo 5 del RGPD, la base jurídica del artículo 6, la asignación de responsabilidades del artículo 26, la seguridad del artículo 32, la notificación a la autoridad de control del artículo 33 y la comunicación a las personas afectadas del artículo 34. También se conecta con la cláusula 4.2 de ISO/IEC 27001:2022, comprensión de las necesidades y expectativas de las partes interesadas, y con la cláusula 6.1.3, tratamiento de riesgos de seguridad de la información.

Control 5.34, privacidad y protección de la PII, incorpora la protección de la PII al modelo operativo de seguridad. Es especialmente importante cuando el acuerdo utiliza analítica en la nube, paneles compartidos, clean rooms de datos, plataformas de monitorización, automatización de marketing o herramientas de soporte. Las salvaguardas relacionadas pueden incluir el Control 5.23 de ISO/IEC 27002:2022, seguridad de la información para el uso de servicios en la nube, y el Control 8.11, enmascaramiento de datos.

El ecosistema ISO de soporte también importa. ISO/IEC 27018 ayuda cuando los servicios de nube pública tratan PII. ISO/IEC 29100 proporciona principios de privacidad como transparencia, consentimiento, finalidad legítima, limitación de la recogida, minimización de datos, limitación del uso, exactitud, salvaguardas de seguridad y responsabilidad proactiva. ISO/IEC 27001:2022 proporciona la columna vertebral del sistema de gestión mediante contexto, partes interesadas, alcance, liderazgo, evaluación de riesgos, tratamiento de riesgos, Declaración de Aplicabilidad, auditoría interna, revisión por la dirección y mejora continua.

Los contratos deben reflejar el modelo operativo

Un acuerdo de corresponsabilidad del tratamiento no puede vivir solo en un aviso de privacidad. Debe reflejarse en contratos, anexos, procedimientos operativos, playbooks de incidentes, vías de escalado y disposiciones de terminación.

La Política de Cumplimiento Legal y Normativo de Clarysec, cláusula 5.3.1.2, incorpora explícitamente los tipos de contrato a la gobernanza, incluidos:

Contratos que impliquen intercambio de datos, derechos de propiedad intelectual, limitaciones de responsabilidad o cláusulas de auditoría

La Política de Protección de Datos y Privacidad, cláusula 5.1, establece la base corporativa:

La organización deberá 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.

Para pymes, el mismo principio se adapta a la realidad operativa. La Política de Protección de Datos y Privacidad para pymes, cláusula 5.2.1, establece:

El Coordinador de Privacidad debe mantener un registro de todas las actividades de tratamiento de datos personales, incluidas las categorías de datos, la finalidad, la base jurídica y los períodos de conservación

La cláusula 5.2.2 añade:

Los contratos con terceros que manejen datos personales deben incluir cláusulas de protección de datos y deben ser revisados por el Director General o por un asesor jurídico

Esto es gobernanza proporcional. Una multinacional puede tener equipos separados de legal, privacidad, compras, seguridad, riesgos y cumplimiento. Una pyme puede apoyarse en un Coordinador de Privacidad, un Director General y un asesor jurídico externo. La expectativa de evidencias sigue siendo la misma: las actividades de tratamiento, las responsabilidades, la base jurídica, los avisos, la gestión de derechos, el escalado de incidentes y las obligaciones de terminación deben estar documentados y ser revisables.

Zenith Blueprint, paso 23, Controles organizativos, respalda la disciplina de acuerdos con proveedores mediante confidencialidad, responsabilidades de control de acceso, medidas técnicas y organizativas, plazos de notificación de incidentes, derechos de auditoría, controles de subcontratistas y disposiciones de fin de contrato. En las relaciones de corresponsabilidad del tratamiento, esas cláusulas deben adaptarse al intercambio de datos y a la asignación de responsabilidades, no copiarse de una plantilla de encargo del tratamiento.

Gobernanza de incidentes y violaciones de seguridad: decidir el responsable antes de la violación

Las violaciones de seguridad en contextos de corresponsabilidad del tratamiento se vuelven caóticas cuando los equipos esperan al incidente para decidir quién se comunica externamente.

El RGPD define una violación de seguridad de los datos personales como una violación de la 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. Cuando sea exigible, la notificación a la autoridad de control debe realizarse sin dilación indebida y, cuando sea posible, dentro de las 72 horas posteriores al momento en que se tenga constancia de la violación de seguridad. NIS2 y DORA pueden añadir expectativas adicionales de notificación de ciberincidentes y comunicación a clientes.

La Política de Respuesta a Incidentes para pymes de Clarysec, cláusula 5.3.2, recoge la disciplina temporal:

Los plazos de respuesta, incluidas la recuperación de datos y las obligaciones de notificación, deben documentarse y alinearse con los requisitos legales, como el requisito de notificación de violaciones de seguridad de datos personales del RGPD en 72 horas.

Zenith Blueprint, paso 5, Comunicación, concienciación y competencia, enfatiza la planificación de comunicaciones externas, incluidos clientes, reguladores, socios y el público. Para los corresponsables del tratamiento, la matriz de incidentes debe identificar quién realiza la clasificación inicial de la violación de seguridad, quién contacta con el otro responsable del tratamiento, quién determina si la PII está afectada, quién evalúa los umbrales de notificación, quién redacta las notificaciones a la autoridad, quién se comunica con las personas, quién coordina la notificación conforme a NIS2 o DORA, quién aprueba las declaraciones públicas y quién registra evidencias en REG10.

Si el acuerdo involucra a una entidad financiera sujeta a DORA, el proceso de incidentes también debe respaldar la clasificación de incidentes graves relacionados con las TIC, el escalado a la alta dirección, las actualizaciones intermedias, el informe final y la comunicación a clientes cuando sus intereses financieros se vean afectados. Si la organización está incluida en el alcance de NIS2, la notificación de incidentes significativos puede requerir notificación por fases y comunicación a los destinatarios del servicio.

La práctica más segura es un ejercicio de mesa conjunto antes del lanzamiento. Un buen escenario obliga a los equipos a usar REG08, REG10, el playbook de incidentes, los contactos del socio, las plantillas de notificación, los árboles de escalado y los registros de evidencias bajo presión temporal.

Cumplimiento cruzado: el artículo 26 rara vez vive solo

Los acuerdos de corresponsabilidad del tratamiento suelen situarse dentro de ecosistemas regulados más amplios. Una campaña fintech, una plataforma de salud conectada, una relación de servicios gestionados, una integración con un marketplace en la nube o una alianza de infraestructura digital pueden activar obligaciones más allá del RGPD.

NIS2 puede aplicarse a entidades esenciales o importantes medianas y grandes en sectores como infraestructura digital, computación en la nube, centros de datos, proveedores de servicios gestionados, proveedores de servicios de seguridad gestionados, mercados en línea, motores de búsqueda y plataformas de redes sociales. El artículo 20 de NIS2 sitúa la supervisión de la gestión de riesgos de ciberseguridad en los órganos de dirección. El artículo 21 exige medidas técnicas, operativas y organizativas, incluidas análisis de riesgos, gestión de incidentes, continuidad del negocio, seguridad de la cadena de suministro, desarrollo seguro, gestión de vulnerabilidades, formación, cifrado, seguridad de RR. HH., control de acceso, gestión de activos y autenticación. El artículo 23 introduce la notificación por fases para incidentes significativos.

DORA es aplicable desde el 17 de enero de 2025 a muchas entidades financieras. Cubre gestión del riesgo de las TIC, notificación de incidentes graves relacionados con las TIC, pruebas de resiliencia operativa digital, riesgo de terceros de TIC, acuerdos contractuales con proveedores de TIC y supervisión de proveedores terceros esenciales de servicios de TIC. El artículo 5 de DORA sitúa la gobernanza del riesgo de las TIC en el nivel del órgano de dirección. Los artículos 8 a 14 cubren identificación de activos, protección, detección, continuidad, copias de seguridad, recuperación, lecciones aprendidas, formación y comunicaciones de crisis. Los artículos 17 a 20 definen el ciclo de vida y la notificación de incidentes. Los artículos 28 a 30 convierten el riesgo de terceros de TIC, las cláusulas contractuales, los registros, el riesgo de concentración, los derechos de auditoría y la planificación de salida en obligaciones centrales.

NIST CSF 2.0 proporciona una capa práctica de integración. Su función GOVERN incluye obligaciones legales, regulatorias, contractuales, de privacidad y de libertades civiles, responsabilidad del liderazgo, apetito de riesgo, política, supervisión y riesgo de proveedores. Resultados como GV.OC-03 y GV.SC-02 se alinean de forma natural con las evidencias del artículo 26, porque exigen que las obligaciones legales y los roles de socios se comprendan, gestionen, comuniquen y coordinen.

La ventaja del modelo de Clarysec es la reutilización de evidencias. REG08 no es solo un registro del RGPD. Respalda la responsabilidad proactiva de ISO/IEC 27701:2025, la gobernanza de ISO/IEC 27001:2022, la claridad de roles de proveedores de NIST CSF 2.0, la gobernanza de terceros de DORA cuando intervienen servicios financieros y la supervisión por la dirección de NIS2 cuando la entidad está dentro del alcance.

Qué probarán auditores y reguladores

Los distintos revisores abordarán la gobernanza de corresponsables del tratamiento desde perspectivas diferentes, pero convergerán en la misma pregunta central: ¿puede la organización demostrar que la responsabilidad proactiva funciona?

La postura de auditoría más sólida es la trazabilidad. Empiece por el requisito legal, conéctelo con la política del PIMS, apunte a la entrada del registro, muestre el flujo de trabajo y después muestre evidencias de prueba o un registro de caso real.

Por ejemplo, el artículo 26 del RGPD exige asignar las responsabilidades de los corresponsables del tratamiento. La Política del Sistema de Gestión de la Información de Privacidad exige REG08 antes de que comience el tratamiento. REG08 muestra la asignación de responsabilidades sobre avisos, derechos, violaciones de seguridad, conservación, gestión de proveedores y contactos. REG07 muestra el resumen publicado. Una simulación de solicitud de derechos demuestra que el flujo de trabajo opera. Las actas de revisión por la dirección muestran excepciones, decisiones y mejoras.

Eso es gobernanza auditable.

La revisión por la dirección convierte el riesgo de privacidad en responsabilidad ejecutiva

La gobernanza de corresponsables del tratamiento no debe quedar oculta en una carpeta de privacidad. Pertenece a la revisión por la dirección porque afecta a la exposición regulatoria, la confianza de clientes, la confianza de pacientes, la preparación ante incidentes, el riesgo de proveedores, la responsabilidad contractual y la resiliencia operativa.

ISO/IEC 27001:2022 exige compromiso del liderazgo, roles, recursos, alineación de políticas, planificación basada en riesgos, evaluación del desempeño y mejora continua. NIS2 impone obligaciones de supervisión de ciberseguridad a los órganos de dirección. DORA atribuye al órgano de dirección la responsabilidad última sobre el riesgo de las TIC para las entidades financieras.

La Política de funciones y responsabilidades de gobernanza para pymes de Clarysec, cláusula 5.5, establece:

Todas las decisiones, excepciones y escalados de seguridad significativos deben registrarse y ser trazables.

Para organizaciones empresariales, la Política de funciones y responsabilidades de gobernanza, cláusula 5.2, exige:

Debe mantenerse un Registro de funciones y responsabilidades, que debe incluir:

Ese registro debe incluir roles de gobernanza de la privacidad cuando afecten a la seguridad, la respuesta a incidentes, el aseguramiento de proveedores, la resiliencia operativa y los informes ejecutivos. Las excepciones de corresponsables del tratamiento deben escalarse antes del lanzamiento, no descubrirse después de una reclamación.

Un paquete práctico para la revisión por la dirección debe incluir:

• Acuerdos de corresponsabilidad del tratamiento nuevos y modificados
• Estado de finalización de REG08
• Actividades de tratamiento de alto riesgo y estado de EIPD cuando corresponda
• Cuestiones abiertas sobre base jurídica o transparencia
• Desempeño de solicitudes de ejercicio de derechos y acciones vencidas de socios
• Resultados de ejercicios de mesa sobre violaciones de seguridad y brechas no resueltas
• Dependencias de proveedores, subencargados, nube y transferencias
• Excepciones de conservación y terminación
• Hallazgos de auditoría y estado de remediación
• Impacto en informes de GDPR, NIS2, DORA, NIST CSF 2.0 y COBIT 2019

Un enfoque de Clarysec en cinco pasos para hacer auditable el artículo 26

Si su organización comparte con otra parte la capacidad de decisión sobre el tratamiento de PII, no espere a una reclamación, auditoría, violación de seguridad o disputa con un socio para aclarar responsabilidades.

Use este enfoque de cinco pasos:

1. Use Zenith Blueprint, paso 2, para identificar partes interesadas, requisitos legales, expectativas de socios, obligaciones de privacidad y alcance regulatorio.
2. Use Zenith Blueprint, paso 4, para construir una RACI sobre avisos, base jurídica, derechos, comunicación ante violaciones de seguridad, conservación, transferencias, proveedores, evidencias de auditoría y terminación.
3. Registre la actividad de tratamiento en REG02 y la asignación de responsabilidades de los corresponsables del tratamiento en REG08 mediante el conjunto de políticas del PIMS de Clarysec.
4. Mapee el acuerdo mediante Zenith Controls, especialmente el Control 5.2, el Control 5.31 y el Control 5.34 de ISO/IEC 27002:2022.
5. Pruebe el acuerdo con una simulación de solicitud de ejercicio de derechos y un ejercicio de mesa sobre violación de seguridad antes de que comience el tratamiento.

CareConnect y MetroHealth no necesitaban más alineación informal. Necesitaban una asignación documentada de responsabilidades, un resumen publicado, un flujo de trabajo de derechos, un registro de coordinación ante violaciones de seguridad, cláusulas contractuales y evidencias de revisión por la dirección.

Esa es la diferencia entre “creíamos que el socio lo gestionaba” y “aquí están el acuerdo aprobado, el aviso, el flujo de trabajo, las evidencias de prueba y el registro de decisión sobre la violación de seguridad”.

Clarysec puede ayudarle a implantar la gobernanza del PIMS conforme a ISO/IEC 27701:2025, alinearla con el artículo 26 del RGPD, integrarla en su SGSI ISO/IEC 27001:2022 y generar evidencias preparadas para auditoría en relación con las expectativas de GDPR, NIS2, DORA, NIST CSF 2.0 y COBIT 2019.

¿Listo para sustituir la ambigüedad de la corresponsabilidad del tratamiento por evidencias preparadas para auditoría? Explore Zenith Blueprint: hoja de ruta de 30 pasos para auditores, use Zenith Controls: guía de cumplimiento cruzado o contacte con Clarysec para una evaluación PIMS y SGSI que convierta el artículo 26 en un sistema operativo de controles antes de que su próxima alianza entre en producción.