Guía práctica sobre soberanía de datos en el intercambio de datos con terceros: proveedores, subcontratistas y entornos multinacionales
La soberanía de los datos es manejable cuando los datos permanecen dentro de una sola organización y jurisdicción. Se convierte en un problema de gobernanza en el momento en que los datos se comparten —con un proveedor, un subcontratista, una filial regional o un socio que opera bajo un régimen legal diferente.
La mayoría de las organizaciones gestionan razonablemente bien su capa principal de cumplimiento y pierden soberanía en los extremos: en la cadena de proveedores, en las transferencias internas transfronterizas dentro de estructuras multinacionales y en los canales de correo electrónico y uso compartido de archivos que transportan la mayor parte del contenido confidencial fuera de los marcos formales de control de soberanía.
Esta guía cubre las obligaciones regulatorias que acompañan a los datos en relaciones con terceros, los riesgos de soberanía de los modelos de datos multinacionales centralizados, la superficie de soberanía ignorada de los datos no estructurados en movimiento, lo que deben incluir los contratos con proveedores y lo que no pueden sustituir, y la arquitectura de cifrado que permite hacer exigible técnicamente la soberanía frente a terceros.
Resumen Ejecutivo
Idea principal: El responsable del tratamiento sigue siendo responsable de cómo los encargados y subencargados gestionan los datos, sin importar la profundidad de la cadena contractual. La mayoría de los fallos de soberanía no ocurren en el proveedor principal de la nube, sino en la cadena de proveedores, en las transferencias internas multinacionales y en los canales de datos no estructurados —correo electrónico, uso compartido de archivos y MFT— que llevan contenido confidencial fuera de los controles formales de soberanía. La base técnica son las claves de cifrado controladas por el cliente: cuando el propietario de los datos posee las claves y el proveedor nunca las tiene, el proveedor no puede acceder ni divulgar contenido legible, sin importar la presión legal —cerrando la brecha que los contratos por sí solos no pueden cerrar.
Por qué te debe importar: Las obligaciones para los encargados del tratamiento del artículo 28 del GDPR, los requisitos de riesgo de terceros TIC de DORA (operativos desde enero de 2025) y el mandato de seguridad en la cadena de suministro de NIS 2 crean obligaciones de responsabilidad superpuestas, con sanciones que pueden alcanzar el 4% de los ingresos globales y responsabilidad personal de la dirección. Estas obligaciones aplican por igual a los datos no estructurados en correo electrónico y uso compartido de archivos que a los datos estructurados en bases de datos —una distinción que la mayoría de las organizaciones aún no ha operacionalizado.
Puntos Clave
- El responsable del tratamiento es responsable de toda la cadena de procesamiento. El artículo 28 del GDPR hace responsable al responsable del tratamiento del cumplimiento por parte de los encargados y subencargados, sin importar cuántas capas contractuales los separen. Una violación o fallo de soberanía por parte de un subcontratista de cuarto nivel es una exposición regulatoria para el responsable del tratamiento.
- Las transferencias internas dentro de multinacionales son transferencias internacionales según el GDPR. Un almacén de datos centralizado en EE. UU. al que acceden filiales europeas constituye una transferencia a un tercer país sujeta a los requisitos del Capítulo V. La propiedad corporativa no crea una exención jurisdiccional.
- El correo electrónico y el uso compartido de archivos están sujetos a las mismas obligaciones de soberanía que los datos estructurados. El GDPR, NIS 2 y DORA no distinguen según el formato de los datos. La brecha en la aplicación es organizacional: la mayoría de los programas de soberanía se centran en bases de datos e ignoran los canales por donde realmente circulan los datos confidenciales.
- Las claves de cifrado controladas por el cliente son el control técnico que hace exigible la soberanía frente a proveedores. Cuando el propietario de los datos posee las claves y el proveedor nunca las tiene, el proveedor no puede acceder ni divulgar contenido legible, sin importar la presión legal —eliminando la necesidad de confiar en los controles internos de acceso o los compromisos de soberanía del proveedor.
- Los esquemas BYOK y de gestión de claves por el cliente ofrecidos por los principales proveedores de nube no son equivalentes a las claves controladas por el cliente. En los acuerdos BYOK/BYOE, la infraestructura del proveedor gestiona las operaciones de descifrado y retiene la capacidad técnica de acceso. Una citación válida permite obtener datos legibles. Las claves controladas por el cliente, donde el proveedor nunca posee la capacidad de descifrado, son arquitectónicamente distintas —y la única opción que realmente elimina la exposición al CLOUD Act y el acceso gubernamental.
Por Qué el Intercambio de Datos con Terceros Es el Evento de Soberanía de Mayor Riesgo
Cuando los datos salen del control directo de la organización, el riesgo de soberanía se multiplica. El responsable del tratamiento conserva toda la responsabilidad regulatoria bajo el artículo 28 del GDPR por cómo se procesan los datos en toda la cadena de proveedores —pero ya no controla la infraestructura, las políticas de acceso ni la jurisdicción legal de la entidad que los gestiona. La brecha entre responsabilidad y control es donde ocurren la mayoría de los fallos de soberanía.
El problema del CLOUD Act es especialmente grave en las cadenas de proveedores. Una organización de la UE con una infraestructura soberana cuidadosamente diseñada puede compartir datos confidenciales con un proveedor con sede en EE. UU. cuya infraestructura está completamente sujeta a la presión del CLOUD Act. La arquitectura de soberanía termina en el límite de la organización; la estructura corporativa estadounidense del proveedor crea la exposición de acceso que la organización de la UE creía haber eliminado. Una administración eficaz de riesgos de terceros en materia de soberanía requiere evidencia técnica auditable de controles equivalentes por parte del proveedor —o una arquitectura en la que el proveedor nunca posea datos legibles.
El Marco Regulatorio: Obligaciones que Viajan con los Datos
Artículo 28 del GDPR exige que el tratamiento por parte de un encargado solo se realice bajo un contrato vinculante que imponga obligaciones equivalentes al GDPR, también a los subencargados. Los responsables deben autorizar el uso de subencargados, trasladar las obligaciones a lo largo de la cadena y seguir siendo plenamente responsables si los subencargados no las cumplen. Un proveedor que no pueda aportar evidencia lista para auditoría de sus controles de soberanía no cumple con los requisitos del artículo 28, sin importar lo que diga su contrato.
Artículo 30 de DORA exige que las entidades financieras de la UE incluyan en los contratos TIC cláusulas específicas sobre localización de datos, residencia de datos, gestión de claves de cifrado, accesibilidad ante incidentes y estrategias de salida. DORA exige explícitamente evaluar si los proveedores TIC pueden demostrar protección frente al acceso gubernamental de terceros países —una referencia directa a la exposición al CLOUD Act. Los proveedores que no puedan demostrar una gestión de claves conforme generan incumplimiento activo de DORA para la entidad financiera.
Artículo 21 de NIS 2 exige a los operadores de servicios esenciales implementar medidas de seguridad en la cadena de suministro que aborden la postura de soberanía de proveedores y prestadores de servicios directos —y documentar esa evaluación. La obligación se traslada a lo largo de la cadena: un proveedor cuyo subcontratista introduce riesgo de soberanía genera exposición a NIS 2 para el operador de servicios esenciales en la cima.
Recupera el control de tus datos con administración de riesgos de proveedores
Lee ahora
Almacenamiento Centralizado Multinacional: El Problema Oculto de Soberanía
Las multinacionales suelen centralizar el almacenamiento de datos —un único data warehouse, CRM unificado, plataforma de RR. HH. centralizada— al que acceden filiales en varios países. Cada acceso a datos personales de la UE desde un almacén centralizado fuera de la UE es una transferencia internacional sujeta al Capítulo V del GDPR. La propiedad corporativa no crea una exención: una filial de la UE que accede a datos en el almacén centralizado de la matriz estadounidense realiza una transferencia que requiere una decisión de adecuación, SCC con TIA u otro mecanismo válido. La exposición al CLOUD Act aplica al proveedor estadounidense del almacén centralizado, sin importar de qué filial sean los datos almacenados.
Los modelos centralizados también concentran el riesgo: una sola solicitud bajo el CLOUD Act o una acción regulatoria afecta simultáneamente los datos de todas las filiales. Para multinacionales sujetas a NIS 2 o DORA en varios Estados miembros, un único fallo de soberanía centralizada desencadena exposición regulatoria en múltiples jurisdicciones a la vez. La solución conforme a soberanía no es necesariamente abandonar la centralización —sino aplicar cifrado controlado por el cliente en la capa de datos, de modo que el almacén centralizado solo contenga datos cifrados y las claves de descifrado permanezcan en las entidades propietarias de los datos en sus respectivas jurisdicciones.
Correo Electrónico y Uso Compartido de Archivos: La Superficie de Soberanía Ignorada
Los programas de soberanía de datos se centran abrumadoramente en bases de datos y datos estructurados —ignorando los canales por los que realmente se mueve la mayoría de los datos confidenciales: adjuntos de correo electrónico, plataformas de uso compartido de archivos y flujos de trabajo MFT. Un contrato enviado por correo electrónico a un proveedor, un informe financiero compartido por una plataforma de colaboración, un archivo de due diligence transferido al extranjero —cada uno es una transferencia transfronteriza sujeta a las mismas obligaciones de GDPR, NIS 2 y DORA que una replicación de base de datos.
El GDPR aplica a cualquier tratamiento de datos personales, sin importar el formato —incluida la transmisión por correo electrónico. La brecha en la aplicación es organizacional: los controles de soberanía se aplican a bases de datos pero no a los canales de correo electrónico y uso compartido de archivos que los conectan con el exterior, dejando importantes brechas en el perímetro. Los requisitos prácticos de soberanía para datos no estructurados en movimiento son idénticos a los de datos estructurados: cifrado en tránsito y en reposo, controles de acceso en transmisiones transfronterizas, registros auditables de cada evento de transferencia y políticas que impidan la transmisión a destinos no conformes —todo aplicado a nivel de plataforma, ya que los datos salen completamente de la infraestructura de la organización al compartirse con un tercero.
Qué Deben Incluir los Contratos con Proveedores —y Qué No Pueden Sustituir
Los contratos con proveedores para datos sensibles a la soberanía deben incluir: limitaciones de propósito e instrucciones de tratamiento; estándares de cifrado y arquitectura de gestión de claves (especificando si el proveedor retiene capacidad de descifrado); autorización de subencargados y traslado de obligaciones; plazos de notificación de brechas; derechos de auditoría con alcance específico; devolución o eliminación de datos al finalizar el contrato; y —para entidades reguladas por DORA— localización de datos, gestión de claves y cláusulas de salida según el artículo 30.
Igualmente importante es lo que los contratos no pueden hacer. Un contrato que exige a un proveedor estadounidense proteger datos de la UE frente al acceso gubernamental no modifica la obligación legal del proveedor de cumplir con una orden válida bajo el CLOUD Act. Una cláusula de residencia de datos genera responsabilidad si se viola —pero no impide técnicamente que los datos salgan de una jurisdicción. Los contratos documentan obligaciones; no crean controles técnicos. Por tanto, la cuestión central no es si el contrato es completo, sino si el proveedor puede demostrar arquitectónicamente que los datos de la UE están protegidos frente a divulgaciones forzadas, sin importar la presión legal.
Claves de Cifrado Controladas por el Cliente: La Base Técnica
Las claves de cifrado controladas por el cliente resuelven el riesgo de soberanía en la cadena de proveedores desde el origen. El propietario de los datos posee las claves que el proveedor nunca tiene —haciendo que el proveedor sea técnicamente incapaz de acceder o divulgar contenido legible, sin importar la presión legal. Esto es arquitectónicamente distinto de los esquemas BYOK/gestión de claves por el cliente, donde la infraestructura del proveedor gestiona las operaciones de descifrado y retiene capacidad de acceso. En un acuerdo BYOK, una citación válida permite obtener datos legibles. Con claves controladas por el cliente, el proveedor solo almacena datos cifrados que no puede descifrar.
Aplicado al intercambio de datos con proveedores, esto significa que los datos confidenciales llegan al proveedor ya cifrados con claves que el proveedor nunca posee. El proveedor puede almacenarlos, transmitirlos y procesarlos —pero no puede leerlos, divulgarlos ni cumplir con una orden gubernamental para entregar su contenido legible. La soberanía se mantiene no porque el proveedor haga promesas adecuadas, sino porque carece de capacidad técnica para incumplirlas. Esto también simplifica la evaluación de soberanía: en lugar de auditar los controles de acceso, jurisdicción y cadena de subcontratistas de cada proveedor, el propietario de los datos mantiene la soberanía mediante un único control arquitectónico aplicado antes de que los datos salgan de su propia infraestructura.
Cómo Kiteworks Cierra la Brecha de Soberanía Frente a Terceros
La Red de Datos Privados de Kiteworks garantiza soberanía de datos frente a terceros en todos los canales por los que los datos confidenciales salen de una organización —correo electrónico, uso compartido de archivos, MFT, formularios web y APIs— bajo un marco de políticas unificado. Las claves de cifrado controladas por el cliente, en manos exclusivas del propietario de los datos y nunca accesibles para Kiteworks, significan que Kiteworks no puede acceder a los datos del cliente, no puede responder a una citación con contenido legible y no puede ser obligado por ningún gobierno a entregar datos descifrados.
La garantía de soberanía es arquitectónica: se mantiene sin importar qué demandas legales reciba Kiteworks o qué proveedor reciba los datos compartidos. La implementación de tenencia única en la ubicación elegida por el cliente coloca los datos bajo la jurisdicción y control de infraestructura del propietario. La arquitectura de seguridad de confianza cero gobierna todo acceso de proveedores y subcontratistas, con cada evento registrado en registros auditables inmutables a través del CISO Dashboard —proporcionando la cooperación de auditoría del artículo 28, la documentación operativa de DORA y la evidencia de cadena de suministro de NIS 2 que exigen los reguladores. Los informes de cumplimiento preconfigurados para GDPR, NIS 2, DORA e ISO 27001 respaldan la documentación de responsabilidad que ningún contrato con proveedores puede generar por sí solo.
Para ver cómo Kiteworks protege el intercambio de datos de tu organización con terceros en todos los canales y jurisdicciones, solicita una demo personalizada hoy.
Preguntas Frecuentes
Sí. El artículo 28 del GDPR hace que el responsable del tratamiento sea plenamente responsable del procesamiento realizado por encargados y subencargados, sin importar la profundidad de la cadena contractual. Un fallo de soberanía de un proveedor —una divulgación forzada bajo el CLOUD Act en EE. UU., una violación de residencia de datos— es una exposición regulatoria para el responsable del tratamiento. Una gestión eficaz de la soberanía frente a terceros requiere evidencia técnica auditable de controles equivalentes en toda la cadena, o una arquitectura —claves de cifrado controladas por el cliente— en la que los proveedores nunca posean datos legibles.
El GDPR, NIS 2 y DORA no distinguen según el formato de los datos. La transmisión de correo electrónico, el uso compartido de archivos y los flujos de trabajo MFT que transportan datos personales a través de fronteras del EEE son transferencias transfronterizas sujetas a los mismos requisitos del Capítulo V que la replicación de bases de datos. La brecha en la aplicación es organizacional —la mayoría de los programas de soberanía aplican controles a bases de datos y dejan sin abordar el correo electrónico y el uso compartido de archivos— pero la obligación legal aplica por igual a ambos.
La diferencia está en si el proveedor retiene capacidad técnica de acceso. En los esquemas BYOK y de gestión de claves por el cliente, el cliente controla nominalmente la rotación de claves y la política —pero la infraestructura del proveedor gestiona las operaciones de descifrado y puede generar datos legibles ante una citación. Con claves de cifrado controladas por el cliente, el propietario de los datos mantiene las claves en una infraestructura a la que el proveedor nunca accede; el proveedor solo almacena datos cifrados que no puede descifrar, sin importar la presión legal. BYOK reduce el riesgo de uso indebido voluntario; no impide la divulgación forzada por parte del gobierno. Solo las claves controladas por el cliente cierran realmente la exposición al CLOUD Act y el acceso gubernamental.
La propiedad corporativa no crea una exención en el GDPR. Una filial de la UE que accede a datos personales en el almacén centralizado de la matriz estadounidense realiza una transferencia sujeta al Capítulo V del GDPR —requiriendo una decisión de adecuación, SCC con TIA u otro mecanismo válido. Los acuerdos de intercambio de datos intra-grupo no sustituyen el cumplimiento del Capítulo V. Los modelos centralizados también concentran la exposición al CLOUD Act en EE. UU.: una sola solicitud puede alcanzar simultáneamente los datos de todas las filiales. El cifrado controlado por el cliente en la capa de datos —donde cada entidad propietaria de los datos mantiene sus propias claves— permite mantener la centralización operativa y eliminar esta exposición concentrada de soberanía.
Como mínimo: limitaciones de propósito de tratamiento; estándares de cifrado que especifiquen si el proveedor retiene capacidad de descifrado; autorización de subencargados y traslado de obligaciones; plazos de notificación de brechas; derechos de auditoría que produzcan evidencia técnica verificable; devolución o eliminación de datos al finalizar el contrato; y —para entidades reguladas por DORA— localización de datos, gestión de claves y cláusulas de salida según el artículo 30. Para transferencias a proveedores con sede en EE. UU., los contratos deben documentar la conclusión del TIA y la arquitectura de claves de cifrado controladas por el cliente que la respalda. Kiteworks proporciona documentación de cumplimiento preconfigurada para GDPR, DORA, NIS 2 e ISO 27001.
Recursos adicionales
- Artículo del Blog
Soberanía de los datos: ¿mejor práctica o requisito regulatorio? - eBook
Soberanía de los datos y GDPR - Artículo del Blog
Evita estos errores en la soberanía de los datos - Artículo del Blog
Mejores prácticas para la soberanía de los datos - Artículo del Blog
Soberanía de los datos y GDPR [Entendiendo la seguridad de los datos]