¿Cómo abordan las Cláusulas de Contrato Estándar las preocupaciones sobre la soberanía de datos y en qué aspectos resultan insuficientes?
Las Cláusulas Contractuales Tipo (SCC) son el mecanismo más utilizado para transferir datos personales de la UE a terceros países. Sin embargo, desde Schrems II, suelen malinterpretarse: se tratan como una solución de soberanía cuando, en el mejor de los casos, son solo un punto de partida. Las SCC cumplen con el requisito de documentación de transferencia del GDPR. No pueden —y legalmente no lo hacen— anular las leyes de vigilancia de los países a los que se transfieren los datos.
Comprender exactamente dónde funcionan las SCC y dónde fallan es la base de cualquier programa serio de soberanía de datos transfronteriza.
Resumen Ejecutivo
Idea principal: Las cláusulas contractuales tipo establecen obligaciones contractuales vinculantes entre exportadores e importadores de datos para transferencias transfronterizas de datos personales bajo el Capítulo V del GDPR. Tras Schrems II, las SCC deben complementarse con Análisis de Impacto de Transferencia (TIA) que evalúen si la legislación del país de destino reduce su eficacia y, donde se identifique un riesgo activo, con medidas técnicas suplementarias. Para transferencias a infraestructuras controladas por EE. UU., el EDPB ha identificado el cifrado controlado por el cliente con claves fuera de la infraestructura del proveedor como la principal medida técnica adecuada. Las SCC sin este respaldo arquitectónico son solo documentación legal, no protección real.
Por qué te interesa: Las autoridades de protección de datos de Austria, Francia e Italia han emitido decisiones sancionadoras indicando que ciertos acuerdos con proveedores cloud estadounidenses violan el GDPR, precisamente porque las SCC no se complementaron con medidas técnicas adecuadas. Las multas pueden alcanzar el 4% de los ingresos globales anuales. Un programa de SCC que no se haya revisado según los estándares posteriores a Schrems II no es una postura de cumplimiento, es una exposición documentada.
Puntos clave
- Las SCC son un instrumento legal, no un control técnico. Vinculan a las partes entre sí. No vinculan a gobiernos extranjeros, no anulan leyes de vigilancia ni evitan la divulgación forzada. Protegen contra el uso indebido voluntario por parte del importador de datos, no contra el acceso forzado por parte del gobierno que el importador no puede resistir legalmente.
- Schrems II cambió radicalmente lo que exigen las SCC. La sentencia del TJUE en 2020 estableció que las SCC para transferencias a EE. UU. deben complementarse con Análisis de Impacto de Transferencia y, cuando se identifique un riesgo activo bajo el CLOUD Act o FISA 702, con medidas técnicas suplementarias. Las SCC por sí solas ya no cumplen con el estándar de transferencia para acuerdos con proveedores estadounidenses.
- El EDPB ha señalado el cifrado controlado por el cliente como la medida suplementaria requerida. Las Recomendaciones 01/2020 identificaron el cifrado con claves mantenidas exclusivamente fuera del país de destino —fuera de la infraestructura del proveedor— como la medida técnica capaz de abordar el acceso forzado del gobierno. Las medidas contractuales suplementarias (compromisos de notificación, procedimientos de impugnación) son explícitamente insuficientes.
- Las SCC no cubren datos no personales, riesgos en tránsito, exposición en la cadena de suministro ni brechas de DLP. Su alcance es el dato personal según el GDPR. La soberanía de datos transfronteriza requiere un marco de control más amplio que abarque datos no personales bajo la Ley de Datos de la UE, interceptación en tránsito y cadenas de procesadores terceros.
- Los programas de SCC estáticos son una responsabilidad activa de cumplimiento. El principio de responsabilidad del GDPR exige revisión continua. Los TIA elaborados antes de Schrems II, antes de las decisiones de las autoridades de Austria/Francia/Italia, o antes de los desafíos legales al Marco de Privacidad de Datos UE-EE. UU. probablemente ya no sean adecuados según los estándares regulatorios actuales.
Qué hacen realmente las SCC — y qué no hacen
Las cláusulas contractuales tipo son términos modelo aprobados por la Comisión Europea que proporcionan una base legal para transferir datos personales de la UE fuera del EEE según el Artículo 46 del GDPR. Obligan al importador de datos a cumplir obligaciones específicas: tratar los datos solo para los fines indicados, implementar medidas de seguridad adecuadas, notificar al exportador sobre solicitudes de acceso gubernamental cuando esté permitido y oponerse a solicitudes que se consideren ilícitas. Las SCC actuales se actualizaron en 2021 para reflejar el entorno posterior a Schrems II.
Lo que no hacen las SCC es igual de relevante. No modifican las obligaciones legales de las empresas estadounidenses bajo el CLOUD Act o la Sección 702 de FISA. Un proveedor estadounidense con el acuerdo de SCC más riguroso sigue estando legalmente obligado a cumplir con una solicitud válida bajo el CLOUD Act. Las SCC obligan al proveedor a impugnar solicitudes excesivas; no pueden obligarle a rechazar el cumplimiento de una orden legal válida de su propio gobierno. Esto no es un error de redacción, es una limitación estructural de los contratos como instrumentos de protección de datos. Los contratos vinculan a las partes entre sí, no a los gobiernos soberanos. El TJUE lo confirmó en Schrems II: cuando la ley del país de destino permite un acceso gubernamental incompatible con los derechos fundamentales de la UE, las SCC por sí solas son insuficientes.
Lista de verificación integral de cumplimiento GDPR
Léelo ahora
El requisito de Schrems II: Análisis de Impacto de Transferencia
Desde Schrems II, las organizaciones que confían en SCC para transferencias a EE. UU. deben realizar Análisis de Impacto de Transferencia: evaluaciones documentadas sobre si la legislación estadounidense reduce la eficacia de las SCC para la transferencia concreta. Un TIA no es un mero trámite. Debe abordar de manera honesta el CLOUD Act y FISA 702 como autoridades legales activas capaces de exigir la divulgación de datos sin supervisión judicial europea, y concluir si las medidas técnicas suplementarias son adecuadas para cubrir el riesgo identificado.
Un TIA que reconoce la exposición al CLOUD Act pero concluye que los compromisos de notificación y los procedimientos de impugnación son suficientes no cumple con el estándar posterior a Schrems II. El EDPB distingue entre medidas contractuales suplementarias —que modifican lo que promete el proveedor— y medidas técnicas suplementarias —que modifican lo que el proveedor puede hacer técnicamente—. Para transferencias expuestas al CLOUD Act, solo las medidas técnicas son adecuadas. Un proveedor que puede verse obligado a entregar datos legibles no ofrece protección suficiente, sin importar lo que haya prometido no hacer. Justo en esto se han basado las decisiones de las autoridades nacionales de protección de datos.
La medida técnica exigida por el EDPB: cifrado controlado por el cliente
Las Recomendaciones 01/2020 del EDPB identificaron una medida técnica suplementaria específica adecuada para la exposición al CLOUD Act: cifrado donde el proveedor estadounidense nunca tenga acceso a las claves de cifrado. Las claves deben ser generadas por el cliente de la UE, almacenadas en infraestructura fuera del control del proveedor y nunca transmitidas a este. Con esta arquitectura, una solicitud bajo el CLOUD Act solo produce texto cifrado: el proveedor es técnicamente incapaz de entregar datos legibles, sin importar la presión legal. Así se cumplen simultáneamente la obligación de divulgación del CLOUD Act y el requisito de protección del GDPR.
El cifrado gestionado por el cliente (BYOK/BYOE) con claves almacenadas en módulos de seguridad hardware bajo el control exclusivo del cliente de la UE es la implementación práctica. Las organizaciones que no pueden demostrar una arquitectura de gestión de claves donde el proveedor estadounidense no tenga capacidad de descifrado no cumplen con el estándar técnico suplementario de Schrems II, sin importar la integridad de las SCC. La misma lógica rige los controles de residencia de datos: los compromisos de localización de datos en SCC deben estar respaldados por geofencing a nivel de infraestructura —una medida técnica suplementaria— y no solo por declaraciones contractuales que una acción administrativa podría anular.
Dónde dejan brechas las SCC
Incluso un programa de SCC plenamente conforme cubre solo una parte del panorama de soberanía de datos transfronteriza. Persisten tres brechas, independientemente de la integridad de las SCC.
Datos no personales. Las SCC solo cubren datos personales bajo el GDPR. Los datos no personales se rigen por el Capítulo VII de la Ley de Datos de la UE, que exige a los proveedores cloud implementar medidas técnicas que impidan el acceso ilícito de gobiernos no comunitarios. Un programa de SCC plenamente conforme al GDPR deja los datos no personales completamente desprotegidos desde la perspectiva de la soberanía.
Exposición en la cadena de suministro. Las SCC regulan la relación directa exportador-importador. Si un proveedor estadounidense utiliza subprocesadores en otras jurisdicciones, cada uno crea un vector adicional de acceso gubernamental. Una gestión eficaz de riesgos de terceros requiere mapear y evaluar toda la cadena de subprocesadores de forma independiente.
Obligaciones sectoriales. Los requisitos de riesgo de terceros TIC de DORA y el mandato de seguridad en la cadena de suministro de la directiva NIS 2 imponen obligaciones de soberanía más allá del cumplimiento de transferencias del GDPR. Las SCC satisfacen la dimensión GDPR, pero no las sectoriales.
Cómo Kiteworks respalda el cumplimiento de SCC — y va más allá
Kiteworks ofrece los controles arquitectónicos que convierten los programas de SCC en verdaderamente protectores, no solo completos a nivel documental. La Red de Datos Privados de Kiteworks implementa cifrado gestionado por el cliente (BYOK/BYOE) con cifrado validado FIPS 140-3 Nivel 1 y AES-256 en reposo — claves mantenidas exclusivamente por el cliente de la UE, nunca accesibles para Kiteworks.
Una solicitud bajo el CLOUD Act dirigida a Kiteworks solo produce texto cifrado. La conclusión del TIA se vuelve defendible no por lo que Kiteworks ha prometido, sino porque técnicamente no puede hacer otra cosa. La implementación de tenencia única en la ubicación europea elegida por el cliente garantiza la residencia de los datos a nivel de infraestructura, no solo a nivel contractual.
Los controles de seguridad de confianza cero gobiernan todo acceso y cada evento queda registrado en registros de auditoría inmutables a través del panel CISO. Informes preconfigurados para GDPR, NIS 2, DORA e ISO 27001 mantienen la documentación de transferencias actualizada en todos los marcos aplicables. Correo electrónico, uso compartido de archivos, MFT, formularios web y APIs bajo una sola plataforma con controles coherentes, cerrando las brechas de fragmentación que generan los entornos multiplaforma.
Para ver cómo Kiteworks respalda tu programa de cumplimiento de SCC y cierra las brechas arquitectónicas que no puede cubrir por sí solo, solicita una demo personalizada hoy.
Preguntas frecuentes
Las cláusulas contractuales tipo son términos modelo aprobados por la Comisión Europea que proporcionan una base legal para transferir datos personales de la UE a terceros países bajo el Artículo 46 del GDPR. Obligan a los importadores de datos a cumplir obligaciones sobre limitación de finalidad, medidas de seguridad, cooperación en derechos de los interesados, notificación de acceso gubernamental y procedimientos de impugnación de solicitudes ilícitas. Las SCC actuales, actualizadas en 2021, reflejan el requisito posterior a Schrems II de medidas suplementarias. Tras Schrems II, las SCC para transferencias a EE. UU. deben ir acompañadas de Análisis de Impacto de Transferencia y —donde se identifique riesgo bajo el CLOUD Act o FISA 702— medidas técnicas suplementarias.
La sentencia Schrems II del TJUE en julio de 2020 estableció que solo se puede confiar en las SCC cuando la legislación del país de destino no reduce su eficacia para la transferencia concreta. Para transferencias a EE. UU., las organizaciones deben realizar TIA que aborden de forma honesta el CLOUD Act y FISA 702 como riesgos activos de divulgación, e implementar medidas técnicas suplementarias cuando se identifiquen. Las Recomendaciones 01/2020 del EDPB aclararon que las medidas contractuales suplementarias son insuficientes cuando la ley estadounidense exige el cumplimiento del proveedor, sin importar los términos contractuales. Los programas de SCC previos a Schrems II que no se han revisado presentan una exposición activa de cumplimiento.
Una medida suplementaria contractual modifica lo que el importador de datos promete hacer —por ejemplo, comprometerse a impugnar solicitudes de acceso gubernamental o notificar al exportador cuando reciba requerimientos—. Una medida suplementaria técnica modifica lo que el importador puede hacer técnicamente. El cifrado controlado por el cliente con claves fuera de la infraestructura del proveedor es una medida técnica: significa que el proveedor no puede entregar datos legibles, sin importar la solicitud legal que reciba, porque nunca tuvo las claves de descifrado. El EDPB exige medidas técnicas suplementarias para transferencias expuestas al CLOUD Act porque las contractuales no pueden anular la obligación legal en EE. UU.: lo que el proveedor ha prometido no hacer no cambia lo que la ley estadounidense le exige.
No. Las cláusulas contractuales tipo (SCC) son un instrumento del GDPR que cubre datos personales. Los datos no personales transferidos internacionalmente se rigen por marcos separados: el Capítulo VII de la Ley de Datos de la UE exige a los proveedores cloud implementar medidas técnicas que impidan el acceso ilícito de gobiernos no comunitarios a datos no personales almacenados en la UE; las regulaciones sectoriales imponen requisitos adicionales para datos financieros, de salud y gubernamentales. Un programa de SCC que cumpla los requisitos de transferencia del GDPR para datos personales puede dejar los datos no personales de una organización completamente desprotegidos desde la perspectiva de la soberanía, por lo que los programas integrales de soberanía transfronteriza deben ir más allá del cumplimiento del GDPR.
Una revisión de adecuación a Schrems II debe evaluar cuatro elementos: si los TIA existentes abordan de manera honesta el CLOUD Act y FISA 702 como riesgos activos (no solo los mencionan como preocupaciones teóricas); si esos TIA documentan medidas técnicas suplementarias adecuadas para cubrir los riesgos identificados (cifrado controlado por el cliente con arquitectura de custodia de claves documentada, no solo compromisos contractuales); si los controles de residencia de datos se aplican técnicamente y no solo se declaran en contrato (geofencing a nivel de infraestructura, no compromisos de política); y si los registros de auditoría inmutables proporcionan la documentación de responsabilidad continua que exige el principio de responsabilidad del GDPR. Las organizaciones que usan Kiteworks pueden generar paquetes de documentación de cumplimiento preconfigurados —evidencia de arquitectura, registros de gestión de claves y exportaciones de registros de auditoría— que respaldan cada elemento de esta revisión para GDPR, NIS 2, DORA y requisitos de autoridades nacionales.
Recursos adicionales
- Artículo del Blog
Soberanía de datos: ¿mejor práctica o requisito normativo? - eBook
Soberanía de datos y GDPR - Artículo del Blog
Evita estos errores en soberanía de datos - Artículo del Blog
Mejores prácticas de soberanía de datos - Artículo del Blog
Soberanía de datos y GDPR [Entendiendo la seguridad de los datos]