Una aseguradora con sede en el Reino Unido transfirió datos de reclamaciones de clientes a un proveedor de analítica de EE. UU. mediante un acuerdo de cláusulas contractuales tipo, el mecanismo aprobado para transferir datos personales del Reino Unido a terceros países sin decisión de adecuación. Las cláusulas contractuales tipo se formalizaron correctamente, el proveedor proporcionó la documentación de garantías adecuada y la transferencia de datos estaba legalmente autorizada. Lo que el acuerdo de SCC no abordaba, porque no se preguntó, era qué ocurriría con los datos después de llegar al proveedor estadounidense. El proveedor tenía infraestructura de AWS en us-east-1 para las operaciones principales, en eu-west-1 para el soporte a clientes de la UE y en ap-southeast-1 para las cargas de trabajo de analítica de Asia-Pacífico. Los datos de clientes que llegaban en virtud del acuerdo de SCC del Reino Unido se trataban de forma habitual en la carga de trabajo de analítica que se ejecutaba en Singapur por razones de rendimiento. El tratamiento en Singapur no estaba cubierto por el acuerdo de SCC. La aseguradora había transferido legalmente los datos a EE. UU. Luego los datos se habían trasladado a Singapur sin mecanismo de transferencia alguno.
¿Cuál es realmente el problema del riesgo de los flujos transfronterizos de datos?
El riesgo de los flujos transfronterizos de datos surge cuando los datos personales se trasladan entre jurisdicciones con distintos estándares de protección de datos, lo que genera obligaciones de cumplimiento regulatorio que deben satisfacerse en cada transferencia. El capítulo V del GDPR, el GDPR del Reino Unido y los marcos equivalentes de Brasil, la India, China y otras jurisdicciones restringen la transferencia de datos personales a países que no ofrecen un nivel equivalente de protección de datos sin un mecanismo de transferencia adecuado: decisiones de adecuación, cláusulas contractuales tipo, normas corporativas vinculantes o excepciones específicas. Estos mecanismos existen para garantizar que los derechos de protección de datos de las personas acompañen a sus datos a través de las fronteras internacionales.
El problema de las transferencias ulteriores es donde el gobierno de los flujos transfronterizos de datos falla con mayor frecuencia. Los mecanismos de transferencia suelen establecerse para la transferencia directa del exportador de datos al importador de datos, es decir, de la organización al proveedor. No cubren automáticamente las transferencias que el proveedor realiza a su vez a subencargados, proveedores de infraestructura o ubicaciones operativas en otras jurisdicciones. Un proveedor que recibe datos en virtud de un acuerdo de SCC válido y luego los trata en un subencargado ubicado en una jurisdicción no cubierta por las SCC ha generado, en el segundo salto, una transferencia no autorizada que el mecanismo de transferencia del primer salto no aborda. El artículo 44 del GDPR deja claro que la restricción de las transferencias se aplica a cada transferencia de la cadena de tratamiento, no solo a la transferencia inicial del responsable del tratamiento al encargado del tratamiento.
La geografía de la infraestructura en la nube añade una dimensión especialmente compleja al gobierno de los flujos transfronterizos de datos. Las arquitecturas modernas en la nube distribuyen las cargas de trabajo entre varias regiones por razones de rendimiento, redundancia y optimización de costos. Un proveedor con una región principal de AWS en us-east-1 puede ejecutar cargas de trabajo de analítica en eu-west-1, la recuperación ante desastres en ap-southeast-1 y la entrega de contenido mediante ubicaciones en el borde en decenas de países. Cada una de estas ubicaciones puede tratar datos del cliente como parte de las operaciones normales. El mecanismo de transferencia formalizado para la relación con el proveedor principal cubre la ubicación principal. Cada una de las demás ubicaciones por las que fluyen los datos en el curso de las operaciones del proveedor en varias regiones requiere su propia base jurídica conforme a los marcos de restricción de transferencias aplicables, un requisito de gobierno que rara vez se aborda de forma sistemática.
Los riesgos de los flujos transfronterizos de datos se concentran en cinco patrones específicos de falla de gobierno:
- Transferencias ulteriores a subencargados en terceros países: el proveedor transfiere datos a subencargados en jurisdicciones no cubiertas por el mecanismo de transferencia original sin establecer mecanismos de transferencia adecuados para cada ubicación de subencargado
- Tratamiento en la nube en varias regiones sin mecanismos de transferencia: la infraestructura en la nube del proveedor distribuye el tratamiento entre varias regiones, y algunas de ellas tratan datos del cliente sin que los mecanismos de transferencia cubran esas ubicaciones
- Degradación del mecanismo de transferencia: dependencia de mecanismos de transferencia que han sido invalidados, modificados o sustituidos sin actualización. La sentencia Schrems II invalidó el Escudo de la Privacidad, lo que obligó a sustituirlo por cláusulas contractuales tipo u otros mecanismos para las transferencias a EE. UU.
- Mecanismo de transferencia que no cubre el tratamiento real: las cláusulas contractuales tipo o un mecanismo equivalente cubren la relación con el proveedor principal, mientras que el tratamiento sensible real se realiza en una ubicación de un subencargado que no está dentro del alcance del mecanismo
- Cambio de infraestructura sin revisión del gobierno de las transferencias: migraciones de la infraestructura del proveedor a nuevas regiones sin evaluar si la migración genera nuevas transferencias transfronterizas que requieren autorización
Por qué es importante
El gobierno de los flujos transfronterizos de datos es importante para TPRM porque las obligaciones regulatorias que se aplican a las transferencias internacionales de datos (cláusulas contractuales tipo, normas corporativas vinculantes, decisiones de adecuación) son responsabilidad del exportador de datos, no del importador de datos. Una organización cliente que transfiere datos a un proveedor en virtud de un acuerdo de SCC es responsable de garantizar que el acuerdo cubra todas las transferencias a las que se someterán los datos en el curso del tratamiento del proveedor, incluidas las transferencias ulteriores a subencargados e infraestructura en otras jurisdicciones. Si la carga de trabajo de analítica del proveedor en Singapur trata los datos sin un mecanismo de transferencia que cubra Singapur, la organización cliente ha generado una transferencia no autorizada, aunque el proveedor haya tomado esa decisión de tratamiento de forma unilateral.
El panorama de las medidas de cumplimiento regulatorio hace concreto este riesgo. Las autoridades europeas de protección de datos han impuesto multas sustanciales por transferencias transfronterizas de datos no autorizadas: no solo por la transferencia inicial sin garantías adecuadas, sino por transferencias ulteriores a subencargados en terceros países que no estaban cubiertas por el mecanismo de transferencia original. La sentencia Schrems II abordó explícitamente la insuficiencia de suponer que los mecanismos de transferencia cubren toda la cadena de tratamiento, y las medidas de cumplimiento posteriores han confirmado que los responsables del tratamiento deben mapear y autorizar cada transferencia a la que se someten sus datos.
Para los profesionales de TPRM, la obligación práctica es comprender a dónde van los datos, no solo en la transferencia inicial sino a lo largo de toda la cadena de tratamiento del proveedor: qué regiones de la nube, qué subencargados y qué ubicaciones operativas tratan los datos en el curso del servicio contratado. Esto exige pedir a los proveedores que mapeen su huella geográfica completa del tratamiento, no solo que confirmen dónde se encuentra su infraestructura principal.
Dónde se equivocan la mayoría de los equipos
La falla más constante es considerar que la formalización del mecanismo de transferencia completa el gobierno de los flujos transfronterizos de datos. Un acuerdo de SCC formalizado confirma que la transferencia inicial del cliente al proveedor está legalmente autorizada. No aborda las transferencias ulteriores a subencargados, el tratamiento en regiones de la nube fuera de la ubicación principal ni las migraciones de infraestructura que ocurren después de establecido el mecanismo. La formalización del mecanismo de transferencia es el punto de partida del gobierno transfronterizo, no su conclusión.
La segunda falla es no preguntar por la huella geográfica completa del tratamiento del proveedor: todas las regiones de la nube, las ubicaciones de los subencargados y los sitios operativos que intervienen con los datos. La mayoría de las evaluaciones de TPRM preguntan dónde se encuentra el centro de datos o la región de la nube principal del proveedor y lo utilizan como base para seleccionar el mecanismo de transferencia. La geografía real del tratamiento del proveedor puede ser mucho más amplia, con cargas de trabajo distribuidas entre regiones por razones operativas que nunca se divulgaron en la evaluación del proveedor.
- Considerar que la formalización de las SCC completa el gobierno transfronterizo: el mecanismo de transferencia inicial no cubre las transferencias ulteriores
- Huella geográfica completa del tratamiento no evaluada: se conoce la ubicación del centro de datos principal, pero se desconocen el tratamiento en varias regiones de la nube y las ubicaciones de los subencargados
- Vigencia del mecanismo de transferencia no verificada: dependencia de mecanismos que pueden haberse visto afectados por cambios regulatorios sin revisión
- No se exige la notificación de migraciones de infraestructura: proveedores que pueden migrar a nuevas regiones sin notificar a los clientes, lo que genera nuevas transferencias transfronterizas sin autorización
- Ubicaciones de los subencargados no evaluadas en cuanto a la cobertura de transferencias: la geografía de los subencargados no se compara con la cobertura del mecanismo de transferencia
Cómo se ve una buena práctica
Los programas maduros de gobierno de los flujos transfronterizos de datos mantienen un mapa completo de a dónde fluyen geográficamente los datos del cliente (ubicación principal del proveedor, regiones de la nube utilizadas para el tratamiento, ubicaciones de los subencargados y sitios operativos) y verifican que mecanismos de transferencia adecuados cubran cada transferencia de ese mapa. Los mecanismos de transferencia se mantienen vigentes a medida que evolucionan los marcos regulatorios. Los cambios de infraestructura que generan nuevas transferencias transfronterizas activan una revisión de gobierno antes de su implementación.
- Huella geográfica completa del tratamiento documentada: todas las regiones de la nube, ubicaciones de subencargados y sitios operativos que tratan datos del cliente están mapeados y se ha verificado la cobertura del mecanismo de transferencia
- Disposiciones sobre transferencias ulteriores en el DPA: el proveedor debe garantizar mecanismos de transferencia adecuados para todas las transferencias ulteriores a subencargados y regiones de la nube
- Notificación de cambios de infraestructura con revisión del gobierno de las transferencias: el proveedor está obligado a notificar al cliente antes de las migraciones de infraestructura que generen nuevas transferencias transfronterizas
- Mantenimiento de la vigencia del mecanismo de transferencia: revisión periódica que confirma que los mecanismos de transferencia reflejan los requisitos regulatorios vigentes y no se han visto afectados por cambios regulatorios
- Confirmación del mecanismo de transferencia de los subencargados: todos los subencargados en terceros países están cubiertos por mecanismos de transferencia adecuados, no solo reconocidos en la lista de subencargados
Herramientas
Gestionar el gobierno de los flujos transfronterizos de datos requiere herramientas de mapeo de la huella geográfica del tratamiento y herramientas de gestión de la privacidad para el mantenimiento de los mecanismos de transferencia.
Mapeo de flujos de datos: OneTrust, TrustArc, Privado
Las plataformas de gestión de la privacidad y de los flujos de datos facilitan el mapeo de los flujos transfronterizos de datos, al identificar todas las ubicaciones a las que se transfieren datos personales y los mecanismos de transferencia que cubren cada flujo. La función de mapeo de flujos de datos de OneTrust permite a las organizaciones documentar la geografía del tratamiento de los proveedores y asociar mecanismos de transferencia a cada flujo identificado. Para los profesionales de TPRM, preguntar si el proveedor puede proporcionar un mapa de la huella geográfica del tratamiento que abarque todas las regiones y subencargados constituye una solicitud de documentación concreta que saca a la luz toda la cadena de transferencias.
Geografía de la infraestructura en la nube: AWS Config, Azure Policy, GCP Asset Inventory
Las herramientas de gestión de la configuración en la nube inventarían las regiones de la nube en las que se despliegan las cargas de trabajo de una organización o de un proveedor, lo que aporta una confirmación técnica de la huella geográfica del tratamiento que complementa las declaraciones contractuales. Para los profesionales de TPRM que evalúan proveedores alojados en la nube, solicitar un inventario de regiones de la nube junto con la documentación del mecanismo de transferencia aporta una confirmación en la capa técnica del alcance geográfico del tratamiento de datos.
Cláusulas contractuales tipo: cláusulas contractuales tipo de la UE (2021), IDTA del Reino Unido, APEC CBPR
Los marcos de mecanismos de transferencia vigentes incluyen las cláusulas contractuales tipo de la Comisión Europea de 2021 (que sustituyen a las versiones de 2010 invalidadas por la sentencia Schrems II), el Acuerdo Internacional de Transferencia de Datos del Reino Unido y las Reglas de Privacidad Transfronteriza de APEC para las transferencias en Asia-Pacífico. Para los profesionales de TPRM, confirmar que los mecanismos de transferencia se basan en versiones vigentes, y no en mecanismos heredados que han sido reemplazados, es una verificación de vigencia de gobierno concreta que la mayoría de los programas no realiza de forma sistemática.
Desafíos de gobernanza
El desafío de gobierno de los flujos transfronterizos de datos es su naturaleza dinámica. La huella geográfica del tratamiento de un proveedor cambia a medida que evoluciona su infraestructura: se añaden nuevas regiones de la nube por rendimiento, los subencargados cambian conforme evolucionan las relaciones del proveedor y las migraciones de infraestructura trasladan cargas de trabajo entre ubicaciones. Cada cambio puede generar nuevas transferencias transfronterizas que requieren autorización. Un programa de gobierno que mapea el panorama de transferencias en la incorporación y nunca lo revisa se irá alejando progresivamente del panorama real de transferencias a medida que evoluciona la infraestructura del proveedor.
Para los programas de TPRM, la respuesta práctica de gobierno es combinar el mapeo inicial de la huella geográfica con requisitos de notificación de cambios de infraestructura y reevaluaciones periódicas. La huella geográfica del tratamiento del proveedor debe documentarse en la incorporación, actualizarse mediante el mecanismo de notificación cuando se produzcan cambios de infraestructura y verificarse frente a la realidad actual en cada ciclo de reevaluación. La vigencia del mecanismo de transferencia debe confirmarse en cada ciclo, y deben exigirse actualizaciones cuando cambien los marcos regulatorios.
- Documentar la huella geográfica del tratamiento en la incorporación: todas las regiones de la nube, ubicaciones de subencargados y sitios operativos
- Exigir la notificación de cambios de infraestructura antes de las migraciones a nuevas regiones que generen nuevas transferencias transfronterizas
- Verificar la vigencia del mecanismo de transferencia en cada reevaluación: versiones vigentes en uso y cambios regulatorios reflejados
- Confirmar la cobertura del mecanismo de transferencia de los subencargados: no solo la lista de subencargados, sino los mecanismos de transferencia que cubren a cada subencargado en un tercer país
- Incluir la geografía del tratamiento en la respuesta a incidentes: el estado de las transferencias transfronterizas es pertinente para las obligaciones de notificación de violaciones de datos
Si usted forma parte de un equipo pequeño
Añada a su evaluación de transferencias transfronterizas una pregunta que vaya más allá del mecanismo de transferencia: además de su centro de datos o región de la nube principal, ¿en qué otras ubicaciones geográficas se tratan los datos de nuestros clientes (incluidas las cargas de trabajo de analítica, la recuperación ante desastres, la entrega de contenido y el tratamiento por subencargados) y qué mecanismos de transferencia cubren cada una de esas ubicaciones? Esa pregunta mapea toda la cadena de transferencias en lugar de solo el primer salto y sacará a la luz la realidad del tratamiento en varias regiones que la formalización de un mecanismo de transferencia para una sola ubicación no aborda.
- Solicitar la huella geográfica completa del tratamiento, no solo la ubicación principal
- Añadir requisitos de notificación de cambios de infraestructura a su DPA
- Verificar la vigencia del mecanismo de transferencia: confirmar que se utilizan las cláusulas contractuales tipo de 2021, no las versiones de 2010
- Confirmar que las ubicaciones de los subencargados están cubiertas por mecanismos de transferencia, no solo divulgadas
Qué exigir
Pregunte directamente:
"¿En qué ubicaciones geográficas (regiones de la nube, centros de datos y sitios de subencargados) se tratan los datos de nuestros clientes, además de la ubicación de su infraestructura principal?"
"¿Qué mecanismos de transferencia cubren cada ubicación donde se tratan nuestros datos fuera de nuestra jurisdicción? ¿Puede confirmar que todas las transferencias ulteriores a subencargados están cubiertas por mecanismos adecuados y no solo reconocidas en su lista de subencargados?"
"¿Cuál es su proceso para notificarnos cuando migran infraestructura a una nueva región o incorporan un subencargado en una nueva jurisdicción que genera nuevas transferencias transfronterizas de nuestros datos?"
Evidencia que debe esperar
- Mapa de la huella geográfica del tratamiento: todas las ubicaciones donde se tratan los datos del cliente
- Inventario de mecanismos de transferencia: tipo de mecanismo y versión vigente para cada ubicación de transferencia
- Confirmación del mecanismo de transferencia de los subencargados: no solo la lista, sino la cobertura del mecanismo
- Documentación del proceso de notificación de cambios de infraestructura
Un proveedor que responde a la pregunta sobre la huella geográfica con 'nuestra infraestructura principal está en us-east-1' ha confirmado una sola ubicación. Pregunte qué otras regiones de AWS, regiones de Azure o regiones de GCP utilizan sus cargas de trabajo y si alguna de esas regiones trata datos del cliente. La ubicación principal es la que tienen en mente. La carga de trabajo de analítica en Singapur es la que no.
Cómo demostrarlo
Las restricciones a las transferencias de los artículos 44 a 49 del GDPR, el capítulo V del GDPR del Reino Unido y los marcos equivalentes crean obligaciones para cada transferencia de la cadena de tratamiento. Las medidas de cumplimiento de las autoridades han confirmado que los responsables del tratamiento deben mapear y autorizar todo el panorama de transferencias, no solo la transferencia inicial. Demostrar la diligencia debida requiere evidencia de que se evaluó toda la huella geográfica del tratamiento y de que se autorizaron todas las transferencias.
- Documentación de la huella geográfica del tratamiento de todos los proveedores con obligaciones de transferencia transfronteriza
- Inventario de mecanismos de transferencia con confirmación de la versión vigente
- Evidencia de la cobertura del mecanismo de transferencia de los subencargados
- Registros de notificación de cambios de infraestructura
- Registros de la reevaluación periódica del panorama de transferencias
Conclusión clave
Las SCC cubren la transferencia que usted autorizó. Cubren la frontera que usted tuvo en cuenta. La carga de trabajo de analítica del proveedor en Singapur, su subencargado en la UE, su infraestructura de entrega en el borde: cada uno de ellos es una frontera que los datos cruzan en el curso del tratamiento normal. El GDPR se aplica a cada transferencia. Las SCC cubren una de ellas. La brecha entre el mecanismo de transferencia que usted formalizó y las transferencias a las que realmente se someten los datos es la transferencia no autorizada que una autoridad reguladora puede detectar antes que usted. Mapear a dónde van los datos no es un ejercicio único en la incorporación del proveedor. Es una obligación de gobierno continua que debe mantenerse a medida que evoluciona la infraestructura del proveedor. Las SCC son el instrumento. El mapa es el gobierno.