Gobernanza de acuerdos de intercambio de datos para el RGPD de la UE e ISO 27701

Son las 16:00 de un martes y Sarah, directora de seguridad de la información (CISO) de una fintech en rápido crecimiento, revisa un acuerdo de intercambio de datos de un socio estratégico de analítica de IA. Ventas está entusiasmado. El socio promete mejores perspectivas sobre los clientes, mayor personalización y una predicción más rápida de la pérdida de clientes. Legal actúa con cautela. El acuerdo está lleno de expresiones imprecisas como “seguridad comercialmente razonable” y apenas dice nada sobre plazos de respuesta a incidentes, gestión de derechos de los interesados, conservación, supresión, derechos de auditoría o planificación de salida.
Sarah identifica el riesgo de inmediato. ¿Actúa el socio como encargado del tratamiento, responsable del tratamiento independiente o corresponsable del tratamiento? ¿Quién valida la base jurídica conforme al RGPD de la UE? Si un cliente presenta una solicitud de supresión, ¿qué proceso garantiza que los datos se eliminen del entorno del socio, de los conjuntos de datos derivados y de las canalizaciones de entrenamiento de IA cuando corresponda? Si el socio sufre una brecha de seguridad, ¿quién informa a quién, cuándo y con qué evidencias?
No se trata de un único contrato deficiente. Es el modelo operativo el que está fallando.
Las organizaciones modernas de SaaS, fintech, healthtech, servicios gestionados y plataformas comparten datos de forma constante a través de interfaces de programación de aplicaciones, integraciones, alianzas de analítica, herramientas de soporte, plataformas en la nube, filiales, requerimientos del sector público y servicios de IA. El lenguaje comercial suele avanzar más rápido que la gobernanza. Se firma un contrato, se emite una clave API y los datos personales empiezan a fluir antes de que privacidad, seguridad, compras, ingeniería y el DPO hayan acordado los elementos básicos.
Conforme al RGPD de la UE, un acuerdo de intercambio de datos no es solo un artefacto jurídico. Es evidencia de licitud, lealtad, transparencia, limitación de la finalidad, minimización de datos, limitación del plazo de conservación, integridad, confidencialidad y responsabilidad proactiva. Conforme a ISO/IEC 27701:2025, pasa a formar parte de un Sistema de Gestión de Información de Privacidad, o PIMS, en el que la organización puede demostrar que la información personal se recoge, utiliza, comunica, comparte, conserva, protege y elimina mediante procesos gobernados.
Clarysec trata la gobernanza del intercambio de datos como un sistema de control interfuncional, no como un ejercicio de plantillas contractuales. Mediante Zenith Blueprint, Zenith Controls y el conjunto de políticas del PIMS de Clarysec, las organizaciones pueden pasar de revisiones ad hoc de acuerdos a un ciclo de vida apto para auditoría que conecta cláusulas legales, registros, decisiones de riesgo, controles técnicos y evidencias de cumplimiento.
Por qué fallan los acuerdos de intercambio de datos en auditorías reales
La mayoría de las organizaciones no fallan porque nunca hayan redactado un contrato. Fallan porque el contrato está desconectado de la realidad operativa.
Un revisor de privacidad solicita el registro de intercambio de datos. Legal envía el acuerdo firmado. A continuación, el revisor solicita la base jurídica, la finalidad de la comunicación, el rol del destinatario, las categorías de PII, la regla de conservación, la ubicación del tratamiento, el método de transferencia, la canalización de las solicitudes de los interesados, las salvaguardas técnicas y las evidencias de revisión. De repente, el acuerdo firmado es solo una pieza del rompecabezas.
El Article 5 del GDPR exige que el tratamiento de datos personales siga los principios de licitud, lealtad, transparencia, limitación de la finalidad, minimización de datos, exactitud, limitación del plazo de conservación e integridad y confidencialidad. El Article 5(2) añade la responsabilidad proactiva, lo que significa que el responsable del tratamiento debe poder demostrar el cumplimiento. El Article 6 exige una base jurídica válida. El Article 9 eleva el nivel de exigencia para las categorías especiales de datos personales, incluidos datos de salud, biométricos, genéticos, políticos, religiosos y otras categorías sensibles.
En la práctica, un proceso de gobernanza de acuerdos de intercambio de datos debe responder a estas preguntas antes de que comience un intercambio externo recurrente:
- ¿Quién es el destinatario y cuál es su rol de privacidad?
- ¿Qué datos personales se comparten y con qué finalidad?
- ¿Qué base jurídica respalda la comunicación?
- ¿La nueva finalidad es compatible con la finalidad original de recogida?
- ¿Se ha informado a las personas mediante un aviso de privacidad u otro mecanismo de transparencia?
- ¿Qué registros, aprobaciones y decisiones de riesgo evidencian el intercambio?
- ¿Cómo se canalizan los derechos de los interesados entre las partes?
- ¿Qué obligaciones de conservación, supresión, devolución y terminación aplican?
- ¿Qué salvaguardas protegen la transferencia, el almacenamiento, el acceso, el registro de eventos, la comunicación ulterior y la auditabilidad?
- ¿Qué ocurre si el socio cambia la finalidad, la ubicación, los subcontratistas o las categorías de datos?
Zenith Blueprint, fase Controls in Action, Step 23, resume con claridad la realidad de auditoría:
La base de este control es la conciencia sobre los datos. La organización debe saber qué PII recoge, dónde reside, por qué se trata y quién puede acceder a ella. Sin esta configuración de referencia, cualquier promesa de privacidad queda vacía. La clasificación y el etiquetado (5.12–5.13) son esenciales aquí, porque la PII no puede protegerse si no está identificada.
Si el acuerdo no está vinculado al inventario, la clasificación, la conservación, los controles de seguridad y el proceso de derechos, no es gobernanza. Es un documento en un repositorio.
El intercambio de datos no es lo mismo que el tratamiento por cuenta de un cliente
Un error frecuente es tratar toda relación con terceros que implique datos personales como si fuera un escenario de encargado del tratamiento. El RGPD de la UE exige análisis de roles. Un encargado del tratamiento actúa por cuenta de un responsable del tratamiento. Un responsable del tratamiento determina finalidades y medios. Los corresponsables del tratamiento determinan conjuntamente finalidades y medios. Algunos destinatarios son responsables del tratamiento independientes que reciben datos para sus propias finalidades.
Esta distinción cambia el modelo de acuerdo.
Un contrato de encargo de tratamiento se centra en instrucciones documentadas, confidencialidad, subencargados del tratamiento, asistencia, seguridad, notificación de brechas de seguridad, supresión o devolución y apoyo de auditoría. Un acuerdo de intercambio de datos entre responsables del tratamiento se centra con mayor intensidad en la base jurídica, la finalidad, la transparencia, la independencia del destinatario, los límites a la comunicación ulterior, la coordinación de DSR, la conservación, las salvaguardas de seguridad y la asignación de responsabilidades. Un acuerdo de corresponsabilidad del tratamiento requiere una asignación transparente de obligaciones y claridad sobre la toma de decisiones compartida.
Las políticas del PIMS de Clarysec convierten esta clasificación en un punto de control obligatorio. La política empresarial Política de gestión de privacidad de encargados, subencargados y terceros establece:
[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 del tratamiento 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.
Para pymes, el mismo principio se expresa de forma más sencilla. La Política de Protección de Datos y Privacidad - pyme, Requisitos de gobernanza 5.2.2, exige:
Los contratos con terceros que traten datos personales deben incluir cláusulas de protección de datos y deben ser revisados por el Director General o por el asesor jurídico.
La lección es práctica: antes de redactar cláusulas, clasifique la relación. El rol determina el acuerdo, las aprobaciones, las salvaguardas, las responsabilidades y las evidencias.
El ciclo de vida de la gobernanza del intercambio de datos
Un flujo de trabajo maduro de acuerdos de intercambio de datos debe funcionar como un proceso de negocio controlado, no como una escalada legal de emergencia. Clarysec suele implantarlo mediante siete puntos de control conectados.
| Punto de control de gobernanza | Decisión que debe tomarse | Evidencia que debe conservarse |
|---|---|---|
| 1. Recepción y registro | ¿Qué actividad de intercambio de datos se propone, quién la propone y con qué finalidad de negocio? | Formulario de recepción, propietario de negocio, destinatario, conjunto de datos, fecha de inicio prevista |
| 2. Clasificación de roles | ¿El destinatario es responsable del tratamiento, corresponsable del tratamiento, encargado del tratamiento, subencargado del tratamiento u otro tercero? | Clasificación y aprobación de la relación en REG08 |
| 3. Base jurídica y finalidad | ¿Qué base jurídica del RGPD de la UE respalda la comunicación y la finalidad es compatible? | Registro de tratamiento REG02, nota de base jurídica, evaluación de compatibilidad si es necesaria |
| 4. Datos y clasificación | ¿Qué categorías y clasificaciones de PII se comparten? | Inventario de datos, etiqueta de clasificación, revisión de minimización de datos |
| 5. Contrato y salvaguardas | ¿Qué cláusulas del acuerdo, controles de seguridad, términos de transferencia y límites a la comunicación ulterior aplican? | DSA, DPA, términos de corresponsabilidad del tratamiento, anexo de seguridad, controles de transferencia |
| 6. Integración operativa | ¿Cómo se gestionan las DSR, los incidentes, la conservación, la supresión, las solicitudes de auditoría y las revisiones? | Flujo de trabajo de DSR, interfaz de incidentes, calendario de conservación, calendario de revisión |
| 7. Aseguramiento continuo | ¿El intercambio sigue siendo necesario, seguro, lícito y coherente con los avisos y registros? | Revisión periódica, evidencias de auditoría, acciones correctivas, evidencias de terminación |
La política empresarial Política de recogida, uso, comunicación e intercambio de PII explicita el requisito desde la perspectiva del responsable del tratamiento:
[Responsable del tratamiento] El Responsable de Proveedores / Compras DEBE registrar la identidad del destinatario, el rol del destinatario, la finalidad de la comunicación, las categorías de PII, la frecuencia de intercambio, la ubicación del tratamiento y la fuente fehaciente en REG08 antes de que comience el intercambio externo recurrente.
REG08 es el registro de destinatarios y relaciones de privacidad con terceros. No debe existir separado del inventario de tratamientos. La política empresarial Política de inventario de tratamientos de PII y base jurídica exige:
[Ambos] El Responsable de Proveedores / Compras DEBE verificar que las entradas de destinatarios externos, encargados del tratamiento, subencargados del tratamiento e intercambio de datos en REG02 estén alineadas con REG08 antes de la aprobación del acuerdo o de un cambio material de la relación.
Esto cierra una brecha de auditoría habitual. REG02 puede indicar “analítica de producto para mejora interna”, mientras que REG08 indica “socio de analítica para benchmarking”. Si la finalidad, el destinatario, la base jurídica, las categorías de datos o las reglas de conservación no están alineados, la organización tiene una deficiencia de responsabilidad proactiva.
Qué debe contener todo acuerdo de intercambio de datos
Un acuerdo de intercambio de datos conforme al RGPD de la UE e ISO 27701:2025 no debe apoyarse en lenguaje genérico de confidencialidad. Debe reflejar el flujo de datos real, la clasificación de roles, el perfil de riesgo y las interfaces operativas.
| Área de cláusula | Por qué es importante |
|---|---|
| Partes y roles | Confirma si cada parte es responsable del tratamiento independiente, corresponsable del tratamiento, encargado del tratamiento u otro destinatario |
| Finalidad y base jurídica | Vincula la comunicación a una finalidad válida y a una base jurídica conforme al RGPD de la UE |
| Categorías de datos e interesados | Limita el acuerdo a categorías definidas de PII y de personas afectadas |
| Minimización de datos | Evita compartir campos que no son necesarios para la finalidad |
| Obligaciones de transparencia | Asigna responsabilidades sobre avisos de privacidad y comunicaciones |
| Condiciones para categorías especiales | Añade salvaguardas explícitas y justificación cuando intervienen datos de Article 9 |
| Método de transferencia | Exige canales seguros como interfaces de programación de aplicaciones cifradas, SFTP, portales seguros o controles equivalentes |
| Control de acceso | Define quién puede acceder a los datos compartidos y cómo se aprueba, revisa y revoca el acceso |
| Conservación y supresión | Establece límites de conservación, desencadenantes de supresión, obligaciones de devolución y requisitos de evidencia |
| Comunicación ulterior | Restringe el intercambio con filiales, subcontratistas, organismos públicos o socios comerciales sin condiciones |
| Cooperación en DSR | Define canalización, acuse de recibo, validación de identidad, coordinación de respuesta y evidencias de cierre |
| Notificación de incidentes | Define plazos de notificación, contenido, contactos de escalado y expectativas de cooperación |
| Auditoría y aseguramiento | Permite revisión de evidencias, atestaciones de control, certificaciones o apoyo de auditoría |
| Control de cambios | Exige reevaluación para nuevas finalidades, nuevas categorías de datos, nuevas ubicaciones o nuevos destinatarios |
| Terminación | Cubre devolución de datos, destrucción, revocación de acceso y certificación de supresión |
Zenith Blueprint, fase Controls in Action, Step 23, aporta la perspectiva de los acuerdos con proveedores:
Las áreas clave que suelen abordarse en los acuerdos con proveedores incluyen:
✓ Obligaciones de confidencialidad, incluidos alcance, duración y restricciones de comunicación a terceros; ✓ Responsabilidades de control de acceso, como quién puede acceder a sus datos, cómo se gestionan las credenciales y qué supervisión existe; ✓ Medidas técnicas y organizativas para la protección de datos, cifrado, transmisión segura, copia de seguridad y compromisos de disponibilidad; ✓ Plazos y protocolos de notificación de incidentes, a menudo con plazos definidos (por ejemplo, “notificar en un plazo de 24 horas”); ✓ Derechos de auditoría, incluida frecuencia, alcance y acceso a evidencias relevantes (por ejemplo, informes de pruebas de penetración, SoA, certificaciones); ✓ Controles sobre subcontratistas, que exigen que el proveedor traslade obligaciones de seguridad equivalentes a sus socios aguas abajo; ✓ Disposiciones de fin de contrato, como devolución o destrucción de datos, recuperación de activos y desactivación de cuentas.
La gobernanza legal empresarial refuerza este punto. La Política de Cumplimiento Legal y Normativo, Requisitos de gobernanza 5.3.1.2, identifica contratos que incluyen:
Contratos que implican intercambio de datos, derechos de propiedad intelectual, limitaciones de responsabilidad o cláusulas de auditoría.
Esto sitúa la gobernanza del intercambio de datos en la intersección entre privacidad, asesoría jurídica, riesgo comercial, aseguramiento de proveedores y operaciones de seguridad.
La clasificación y la transferencia segura son el puente que falta
Muchos fallos de intercambio de datos empiezan con una clasificación deficiente. Si el propietario de negocio no puede indicar si el conjunto de datos es público, de uso interno, confidencial, restringido o contiene PII regulada, el acuerdo será impreciso y los controles técnicos serán incoherentes.
La Política de Clasificación y Etiquetado de Datos - pyme de Clarysec establece:
Los acuerdos de intercambio de datos o los acuerdos de confidencialidad deben hacer referencia a los requisitos de manejo de la clasificación.
Para entornos empresariales, la Política de Clasificación y Etiquetado de Datos exige que determinados datos:
Solo puedan compartirse externamente bajo un acuerdo de confidencialidad o salvaguardas contractuales equivalentes.
La etiqueta de clasificación debe aparecer en el acuerdo o en el anexo de seguridad. Si el historial de tickets de soporte se clasifica como confidencial y contiene PII, el acuerdo debe definir destinatarios permitidos, métodos de transferencia aprobados, ubicaciones de almacenamiento, controles de acceso, supervisión, expectativas de supresión y evidencias de aseguramiento.
Zenith Blueprint, fase Controls in Action, Step 22, explica la dimensión operativa de la transferencia de información:
En esencia, este control exige que la organización:
✓ Defina cómo puede transferirse la información, tanto interna como externamente; ✓ Determine qué métodos están permitidos (por ejemplo, correo electrónico cifrado, portales seguros, SFTP, interfaces de programación de aplicaciones, entrega física con cifrado); ✓ Alinee los métodos de transferencia con la clasificación de la información (según se define en 5.12 y se hace visible mediante 5.13); ✓ Y garantice que todas las partes que intervienen en la transferencia comprenden sus roles, responsabilidades y obligaciones.
Para pymes, la Política de Seguridad de Terceros y Proveedores - pyme establece la expectativa de forma directa:
Todos los datos compartidos con proveedores deben protegerse mediante cifrado y transmitirse utilizando protocolos seguros (por ejemplo, HTTPS, SFTP).
La gobernanza empresarial de proveedores añade más detalle. La Política de seguridad de terceros y proveedores exige requisitos de manejo de datos, incluidos:
Requisitos de manejo de datos, incluida la ubicación de almacenamiento, los controles de acceso y las cláusulas de devolución o destrucción.
Estos requisitos no deben quedar enterrados en un cuestionario. Deben ser términos contractuales exigibles y trazables a REG08, a la configuración técnica y a las evidencias de auditoría.
Ejemplo: aprobación del socio de analítica de IA de Sarah
La fintech de Sarah quiere compartir identificadores de clientes seudonimizados, patrones de transacción, métricas de uso e información de nivel de soporte con un socio de analítica de IA para personalización y predicción de abandono. El socio puede combinar los datos con sus modelos analíticos y devolver información de valor a la fintech.
Un flujo de trabajo gobernado sería el siguiente.
Primero, el Responsable de Proveedores o Compras crea la entrada en REG08. El Responsable de Privacidad o Responsable del PIMS clasifica la relación. Si el socio determina finalidades analíticas y diseño del modelo más allá de las instrucciones de Sarah, el rol puede ser responsable del tratamiento independiente o corresponsable del tratamiento, en lugar de encargado del tratamiento.
| Campo | Valor de ejemplo |
|---|---|
| Destinatario | AI Analytics Inc. |
| Rol del destinatario | Responsable del tratamiento independiente, pendiente de validación legal final |
| Base jurídica | Intereses legítimos, evaluación de intereses legítimos archivada |
| Categorías de PII | ID de cliente, historial de transacciones, métricas de uso, nivel de soporte |
| Salvaguardas | Seudonimización, minimización a nivel de campo, interfaz de programación de aplicaciones cifrada, registro de accesos |
| Finalidad | Personalización de producto y predicción de abandono |
| Frecuencia de intercambio | Diaria mediante API |
| Ubicación del tratamiento | UE, Irlanda |
| Acuerdo rector | DSA-2026-042 |
| Fecha de revisión | 2027-04-01 |
Segundo, se concilia REG02. Si el inventario de tratamientos solo describe “analítica interna de producto”, debe actualizarse antes de que comience el intercambio externo. La base jurídica debe documentarse y, si la finalidad ha cambiado, puede ser necesaria una evaluación de compatibilidad o una evaluación de intereses legítimos.
Tercero, el Propietario de la Información aplica la clasificación y la minimización de datos. Los dominios de correo electrónico de administradores pueden no ser necesarios. Los ID de cuenta pueden sustituirse por ID seudónimos específicos para el socio. El nivel de soporte solo debe conservarse si es necesario para la finalidad aprobada.
Cuarto, legal, privacidad y seguridad negocian el acuerdo de intercambio de datos y el anexo de seguridad. El acuerdo prohíbe la reidentificación, restringe la comunicación ulterior, define la conservación, exige evidencias de supresión, especifica plazos de notificación de incidentes, incluye derechos de auditoría o aseguramiento y define pasos de salida.
Quinto, se actualizan el aviso de privacidad y el flujo de trabajo de DSR. La política empresarial Política de gestión de los derechos de los interesados exige:
[Ambos] El Responsable de Proveedores / Compras DEBE hacer seguimiento del acuse de recibo por parte de terceros de las notificaciones relacionadas con derechos en REG08 antes de cerrar la solicitud REG06 correspondiente.
Para pymes, la Política de Protección de Datos y Privacidad - pyme ofrece una expectativa práctica de nivel de servicio:
El Coordinador de Privacidad debe acusar recibo de las solicitudes en un plazo de 3 días laborables y responder en un plazo de 30 días.
Por último, ingeniería aplica el acuerdo. Las credenciales de API se limitan por alcance. Las transferencias usan HTTPS. Los registros capturan las extracciones de datos. Las alertas detectan actividad inusual. El acceso se revisa. La conservación se automatiza cuando es posible. El acuerdo se convierte en un sistema de control vivo, no en un PDF.
Mapeo de cumplimiento transversal para el RGPD de la UE, ISO 27701, DORA, NIS2, NIST y COBIT 19
La gobernanza del intercambio de datos rara vez pertenece a un único marco. Afecta a la responsabilidad proactiva del RGPD de la UE, las operaciones de privacidad de ISO/IEC 27701:2025, los requisitos del sistema de gestión de ISO/IEC 27001:2022, los controles de seguridad de ISO/IEC 27002:2022, el riesgo de terceros de DORA, la seguridad de la cadena de suministro de NIS2, los resultados de NIST CSF 2.0 y las expectativas de gobernanza de COBIT 19.
La cláusula 4.2 de ISO/IEC 27001:2022 exige que las organizaciones comprendan a las partes interesadas y sus requisitos relevantes. La cláusula 5.1 exige que el liderazgo integre los requisitos de seguridad de la información en los procesos de negocio. Para el intercambio de datos, esto significa que las dependencias de socios, los requisitos contractuales, las obligaciones reglamentarias y las decisiones de riesgo deben estar dentro del SGSI y del PIMS, no fuera de ellos.
Los controles más relevantes de ISO/IEC 27002:2022 son:
- 5.14 Transferencia de información
- 5.20 Tratamiento de la seguridad de la información en los acuerdos con proveedores
- 5.34 Privacidad y protección de PII
Zenith Controls ayuda a las organizaciones a usar estos controles como anclajes de mapeo. Vincula el control 5.14 de ISO/IEC 27002:2022 con la protección de datos en tránsito y los requisitos contractuales, incluidos NIST CSF 2.0 PR.DS-02 y GV.SC-05, DORA Article 30(2)(d) y GDPR Article 46 cuando las garantías aplicables a transferencias internacionales son relevantes. Vincula el control 5.20 con la gobernanza de acuerdos con proveedores, incluida la seguridad de la cadena de suministro de NIS2 Article 21(2)(d) y el DORA Chapter V sobre riesgo de terceros de TIC. Vincula el control 5.34 con la privacidad y protección de PII, incluida la responsabilidad proactiva de GDPR Article 5(2) y controles de soporte como cifrado, supresión, gestión de proveedores y limitación de la finalidad.
| Perspectiva del marco | Qué debe demostrar la gobernanza del intercambio de datos |
|---|---|
| RGPD de la UE | Base jurídica, transparencia, limitación de la finalidad, minimización de datos, conservación, seguridad, responsabilidad proactiva, cooperación en derechos |
| ISO/IEC 27701:2025 | Claridad de roles del PIMS, controles de privacidad, tratamiento documentado, gobernanza de comunicaciones de datos, evidencias de operaciones de privacidad |
| ISO/IEC 27001:2022 | Alcance del SGSI, evaluación de riesgos, tratamiento, controles de proveedores, controles de transferencia, supervisión, auditoría, revisión por la dirección |
| ISO/IEC 27002:2022 | Transferencia de información, seguridad en acuerdos con proveedores, privacidad y protección de PII |
| NIS2 | Supervisión de la dirección, seguridad de la cadena de suministro, gestión de riesgos frente a todo tipo de amenazas, gestión de incidentes, formación, control de acceso |
| DORA | Ciclo de vida de terceros de TIC, registros contractuales, apoyo en incidentes, derechos de auditoría, ubicación de datos, salida y resiliencia |
| NIST CSF 2.0 | Resultados GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND y RECOVER para riesgos de terceros y de datos |
| COBIT 19 | Objetivos de gobernanza, responsabilidad proactiva, propiedad del riesgo, desempeño del control, aseguramiento y mejora |
El objetivo no son siete programas de cumplimiento. El objetivo es un único ciclo de vida gobernado del intercambio de datos que produzca evidencias reutilizables.
Cómo auditarán los acuerdos de intercambio de datos
Un proceso de gobernanza sólido debe resistir el muestreo. Los auditores no se detendrán en el acuerdo firmado. Probarán el ciclo de vida.
Un auditor de ISO/IEC 27001:2022 e ISO/IEC 27701:2025 preguntará si el alcance del SGSI y del PIMS incluye el intercambio externo, si la evaluación de riesgos cubre la relación, si los controles se seleccionaron y operaron, y si la dirección revisa el riesgo de privacidad y seguridad de terceros.
Un revisor del RGPD de la UE o una autoridad de control se centrará en la responsabilidad proactiva. Preguntará qué datos personales se compartieron, por qué, con qué base jurídica, si se informó a las personas, durante cuánto tiempo se conservaron los datos, si intervinieron datos de categorías especiales, si se evaluaron las transferencias internacionales y si las solicitudes de derechos se canalizaron y evidenciaron.
Un revisor de DORA, especialmente en servicios financieros, preguntará si el acuerdo da soporte a una función esencial o importante, si está en el registro contractual de TIC, si el contrato incluye asistencia en incidentes, derechos de auditoría, ubicación de datos, condiciones de subcontratación, derechos de terminación y planificación de salida probada.
Un evaluador de NIST CSF 2.0 buscará resultados GOVERN en la gestión de riesgos de proveedores, resultados PROTECT en controles de datos en tránsito, resultados RESPOND en interfaces de incidentes y resultados RECOVER en planificación de salida y continuidad.
Un auditor de COBIT 19 o con enfoque ISACA se centrará en derechos de decisión, apetito de riesgo, realización de beneficios, optimización de recursos, obligaciones de cumplimiento, métricas, excepciones y mejora continua.
| Prueba de auditoría | Evidencia esperada |
|---|---|
| Seleccionar un socio activo de intercambio de datos | DSA firmado o equivalente, entrada REG08, clasificación de roles |
| Trazar al inventario de tratamientos | Entrada REG02 con finalidad, base jurídica, categorías de PII, conservación, destinatarios |
| Verificar la clasificación | Registro de clasificación de datos y requisitos de manejo referenciados en el acuerdo |
| Verificar los controles de seguridad | Cifrado, protocolo seguro, control de acceso, registro de eventos, ubicación de almacenamiento, evidencias de supervisión |
| Verificar el proceso de DSR | Evidencia de solicitud REG06, notificación al destinatario, acuse de recibo registrado en REG08 |
| Verificar conservación y terminación | Regla de conservación, procedimiento de supresión, cláusula de devolución o destrucción, certificado de supresión si ha finalizado |
| Verificar la revisión | Registro de revisión periódica, cambios evaluados, excepciones y acciones correctivas trazadas |
Si su equipo no puede reunir estas evidencias con rapidez, el proceso depende demasiado de la memoria.
Errores habituales en la gobernanza del intercambio de datos
Clarysec observa de forma recurrente cinco patrones de fallo.
El primero es confundir un DPA con un acuerdo de intercambio de datos. Las cláusulas de encargado del tratamiento no resuelven la responsabilidad proactiva entre responsables del tratamiento o corresponsables del tratamiento.
El segundo es una higiene deficiente de registros. REG02 y REG08 no coinciden. El aviso de privacidad se refiere de forma amplia a “socios comerciales”, pero el inventario de tratamientos no contiene una finalidad de comunicación correspondiente.
El tercero es una canalización deficiente de DSR. Un interesado solicita la supresión, pero nadie sabe qué destinatarios deben ser notificados ni cómo se registra el acuse de recibo.
El cuarto es lenguaje de seguridad genérico. “Seguridad adecuada” no basta. El acuerdo debe especificar métodos de transferencia, cifrado, controles de acceso, registro de eventos, ubicación de almacenamiento, plazos de incidentes, supresión y aseguramiento.
El quinto es ignorar la comunicación ulterior. Los ecosistemas SaaS modernos incluyen plataformas en la nube, servicios de IA, proveedores de analítica, herramientas de soporte, proveedores gestionados, filiales y organismos públicos. La gobernanza del intercambio de datos debe controlar la comunicación aguas abajo cuando afecta a la responsabilidad proactiva.
La Política de gestión de privacidad de encargados, subencargados y terceros recoge la vinculación operativa para las relaciones con encargados y subencargados del tratamiento:
[Ambos] El Responsable de Proveedores / Compras DEBE garantizar que los contratos con encargados y subencargados del tratamiento incluyan asistencia en privacidad, aseguramiento de seguridad, interfaz de incidentes mediante PII15, devolución o supresión mediante PII10, vinculación de transferencias mediante PII13 y cooperación en auditoría o aseguramiento antes de la aprobación.
Incluso cuando la relación es entre responsables del tratamiento, la lógica de gobernanza sigue siendo valiosa: la asistencia en privacidad, el aseguramiento de seguridad, la interfaz de incidentes, la vinculación de transferencias, la devolución o supresión y la cooperación en auditoría deben diseñarse deliberadamente.
Lista de verificación práctica para su próximo acuerdo de intercambio de datos
Use esta lista de verificación antes de aprobar un intercambio externo recurrente de datos personales.
- Confirme el rol de privacidad del destinatario en REG08.
- Confirme que REG02 y REG08 están alineados antes de la aprobación.
- Documente la finalidad de la comunicación y la base jurídica.
- Verifique si una nueva finalidad requiere evaluación de compatibilidad.
- Identifique las categorías de PII, las categorías de interesados y los datos de categorías especiales.
- Aplique minimización de datos y elimine campos innecesarios.
- Haga referencia a los requisitos de manejo de la clasificación en el acuerdo.
- Defina los métodos de transferencia aprobados y los requisitos de cifrado.
- Especifique expectativas de control de acceso, registro de eventos, supervisión y ubicación de almacenamiento.
- Asigne responsabilidades de transparencia y actualizaciones del aviso de privacidad.
- Defina la canalización de DSR, el acuse de recibo, el seguimiento y las evidencias de cierre.
- Defina evidencias de conservación, supresión, devolución y terminación.
- Restrinja la comunicación ulterior y exija notificación de cambios.
- Incluya plazos de notificación de incidentes y requisitos de cooperación.
- Incluya derechos de auditoría, aseguramiento o revisión de evidencias.
- Programe revisión periódica y desencadenantes de reevaluación.
Dónde encaja Clarysec
El valor de Clarysec no son solo las plantillas. Es la conexión entre política, registros, evidencias, lógica de auditoría y mapeo de cumplimiento transversal.
Zenith Blueprint proporciona a los equipos de implantación una hoja de ruta de 30 pasos para convertir requisitos de control en prácticas operativas. Para el intercambio de datos, Step 22 ayuda a los equipos a diseñar reglas de transferencia de información, mientras que Step 23 conecta privacidad, acuerdos con proveedores, requisitos legales, protección de PII y obligaciones contractuales.
Zenith Controls proporciona la brújula de cumplimiento transversal. Para este tema, vincula los controles 5.34, 5.14 y 5.20 de ISO/IEC 27002:2022 con la historia de auditoría más amplia: protección de la privacidad, transferencia de información y gobernanza de acuerdos con proveedores. Ayuda a directores de seguridad de la información (CISO), DPO, responsables de cumplimiento, equipos de compras y auditores a hablar el mismo idioma al mapear las expectativas del RGPD de la UE, ISO/IEC 27701:2025, ISO/IEC 27001:2022, NIS2, DORA, NIST CSF 2.0 y COBIT 19.
El conjunto de políticas del PIMS de Clarysec proporciona después las reglas operativas: clasificar relaciones de privacidad, mantener registros de tratamientos y destinatarios, verificar la alineación de registros, definir la base jurídica, gestionar los derechos de los interesados, controlar cláusulas de proveedores y terceros, aplicar el manejo por clasificación y conservar evidencias.
Si su organización comparte datos personales con socios, plataformas, filiales, organismos públicos, proveedores de analítica, servicios de IA o participantes del ecosistema SaaS, no empiece por el contrato. Empiece por la gobernanza.
Use Zenith Blueprint: hoja de ruta de 30 pasos para auditores para situar el intercambio de datos dentro de su plan de implantación del SGSI y del PIMS. Use Zenith Controls: guía de cumplimiento transversal para mapear los controles 5.34, 5.14 y 5.20 de ISO/IEC 27002:2022 frente a las expectativas de aseguramiento del RGPD de la UE, NIS2, DORA, NIST y COBIT. A continuación, implante las políticas del PIMS de Clarysec, incluidas la Política de recogida, uso, comunicación e intercambio de PII, la Política de inventario de tratamientos de PII y base jurídica y la Política de gestión de privacidad de encargados, subencargados y terceros, de modo que cada acuerdo esté respaldado por registros, flujos de trabajo, salvaguardas y evidencias.
La siguiente acción práctica es sencilla: seleccione sus tres relaciones externas de intercambio de datos de mayor riesgo y pruébelas frente a REG02, REG08, base jurídica, canalización de DSR, controles de transferencia, conservación y evidencias de auditoría. Si la cadena de evidencias se rompe, Clarysec puede ayudarle a reconstruirla como un modelo de gobernanza del intercambio de datos apto para auditoría.
About the Author

Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council