Riscos dos fluxos internacionais de dados

Uma seguradora sediada no Reino Unido transferiu dados de sinistros de clientes a um fornecedor de análise de dados dos EUA com base em um acordo de cláusulas contratuais padrão, o mecanismo aprovado para transferir dados pessoais do Reino Unido para países terceiros sem decisão de adequação. As cláusulas foram celebradas corretamente, o fornecedor apresentou a documentação de salvaguardas adequadas e a transferência de dados estava legalmente autorizada. O que o acordo de SCC não abordou, porque ninguém perguntou, foi o que aconteceria com os dados depois que chegassem ao fornecedor nos EUA. O fornecedor tinha infraestrutura da AWS em us-east-1 para as operações principais, em eu-west-1 para o suporte a clientes da UE e em ap-southeast-1 para cargas de trabalho de análise de dados da Ásia-Pacífico. Os dados dos clientes que chegavam com base no acordo de SCC do Reino Unido eram rotineiramente tratados pela carga de trabalho de análise de dados executada em Singapura, por razões de desempenho. O tratamento em Singapura não estava coberto pelo acordo de SCC. A seguradora havia transferido os dados legalmente para os EUA. Em seguida, os dados foram para Singapura sem nenhum mecanismo de transferência.

Qual é, de fato, o problema do risco dos fluxos internacionais de dados?

O risco dos fluxos internacionais de dados surge quando dados pessoais circulam entre jurisdições com padrões de proteção de dados diferentes, criando obrigações de conformidade regulatória que devem ser cumpridas em cada transferência. O Capítulo V do GDPR, o GDPR do Reino Unido e marcos equivalentes no Brasil, na Índia, na China e em outras jurisdições restringem a transferência de dados pessoais para países que não oferecem um nível equivalente de proteção de dados sem um mecanismo de transferência adequado: decisões de adequação, cláusulas contratuais padrão, normas corporativas vinculantes ou derrogações específicas. Esses mecanismos existem para garantir que os direitos de proteção de dados das pessoas acompanhem seus dados através das fronteiras internacionais.

O problema das transferências posteriores é onde a governança de fluxos internacionais de dados falha com mais frequência. Os mecanismos de transferência costumam ser estabelecidos para a transferência direta do exportador de dados para o importador de dados, ou seja, da organização para o fornecedor. Eles não cobrem automaticamente as transferências que o fornecedor faz em seguida a suboperadores, provedores de infraestrutura ou unidades operacionais em outras jurisdições. Um fornecedor que recebe dados com base em um acordo de SCC válido e depois os trata em um suboperador localizado em uma jurisdição não coberta pelo SCC criou, no segundo salto, uma transferência não autorizada que o mecanismo de transferência do primeiro salto não aborda. O artigo 44 do GDPR deixa claro que a restrição às transferências se aplica a cada transferência na cadeia de tratamento, e não apenas à transferência inicial do controlador para o operador.

A geografia da infraestrutura em nuvem acrescenta uma dimensão particularmente complexa à governança de fluxos internacionais de dados. As arquiteturas de nuvem modernas distribuem cargas de trabalho por várias regiões por razões de desempenho, redundância e otimização de custos. Um fornecedor com a região principal da AWS em us-east-1 pode executar cargas de trabalho de análise de dados em eu-west-1, a recuperação de desastres em ap-southeast-1 e a entrega de conteúdo por meio de pontos de borda em dezenas de países. Cada um desses locais pode tratar dados dos clientes como parte das operações normais. O mecanismo de transferência celebrado para a relação principal com o fornecedor cobre o local principal. Todos os demais locais por onde os dados circulam no curso das operações multirregionais do fornecedor exigem sua própria base legal nos marcos de restrição de transferências aplicáveis, um requisito de governança raramente tratado de forma sistemática.

Os riscos de fluxos internacionais de dados concentram-se em cinco padrões específicos de falha de governança:

• Transferências posteriores a suboperadores em países terceiros: o fornecedor transfere dados a suboperadores em jurisdições não cobertas pelo mecanismo de transferência original sem estabelecer mecanismos de transferência adequados para a localização de cada suboperador
• Tratamento em nuvem multirregional sem mecanismos de transferência: a infraestrutura em nuvem do fornecedor distribui o tratamento por várias regiões, e algumas delas tratam dados dos clientes sem que os mecanismos de transferência cubram esses locais
• Degradação do mecanismo de transferência: dependência de mecanismos de transferência que foram invalidados, modificados ou substituídos sem atualização. A decisão Schrems II invalidou o Privacy Shield, exigindo sua substituição por cláusulas contratuais padrão ou outros mecanismos para transferências aos EUA
• Mecanismo de transferência que não cobre o tratamento real: cláusulas contratuais padrão ou equivalente cobrindo a relação principal com o fornecedor, enquanto o tratamento sensível de fato ocorre em uma localização de suboperador fora do escopo do mecanismo
• Mudança de infraestrutura sem revisão da governança de transferências: migrações da infraestrutura do fornecedor para novas regiões sem avaliar se a migração cria novas transferências internacionais que exigem autorização

Por que isso importa

A governança de fluxos internacionais de dados é relevante para TPRM porque as obrigações regulatórias aplicáveis às transferências internacionais de dados (cláusulas contratuais padrão, normas corporativas vinculantes, decisões de adequação) são de responsabilidade do exportador de dados, e não do importador. Uma organização cliente que transfere dados a um fornecedor com base em um acordo de SCC é responsável por garantir que o acordo cubra todas as transferências pelas quais os dados passarão no curso do tratamento realizado pelo fornecedor, incluindo transferências posteriores a suboperadores e a infraestruturas em outras jurisdições. Se a carga de trabalho de análise de dados do fornecedor em Singapura tratar os dados sem um mecanismo de transferência que cubra Singapura, a organização cliente terá criado uma transferência não autorizada, mesmo que o fornecedor tenha tomado essa decisão de tratamento unilateralmente.

O cenário de fiscalização regulatória torna esse risco concreto. As autoridades europeias de proteção de dados aplicaram multas expressivas por transferências internacionais de dados não autorizadas, não apenas pela transferência inicial sem salvaguardas adequadas, mas também por transferências posteriores a suboperadores em países terceiros que não estavam cobertas pelo mecanismo de transferência original. A decisão Schrems II tratou explicitamente da inadequação de presumir que os mecanismos de transferência cobrem toda a cadeia de tratamento, e a fiscalização subsequente confirmou que os controladores são responsáveis por mapear e autorizar cada transferência pela qual seus dados passam.

Para os profissionais de TPRM, a obrigação prática é entender para onde os dados vão não apenas na transferência inicial, mas em toda a cadeia de tratamento do fornecedor: quais regiões de nuvem, quais suboperadores e quais unidades operacionais tratam os dados no curso do serviço contratado. Isso exige pedir aos fornecedores que mapeiem toda a abrangência geográfica do seu tratamento, e não apenas que confirmem onde está localizada a sua infraestrutura principal.

Onde a maioria das equipes erra

A falha mais recorrente é tratar a celebração do mecanismo de transferência como a conclusão da governança de fluxos internacionais de dados. Um acordo de SCC celebrado confirma que a transferência inicial do cliente para o fornecedor está legalmente autorizada. Ele não trata das transferências posteriores a suboperadores, do tratamento em regiões de nuvem fora do local principal nem das migrações de infraestrutura que ocorrem depois que o mecanismo é estabelecido. A celebração do mecanismo de transferência é o ponto de partida da governança de transferências internacionais, e não a sua conclusão.

A segunda falha é não perguntar sobre toda a abrangência geográfica do tratamento realizado pelo fornecedor: todas as regiões de nuvem, localizações de suboperadores e unidades operacionais que têm contato com os dados. A maioria das avaliações de TPRM pergunta onde fica o centro de dados ou a região de nuvem principal do fornecedor e usa essa informação como base para escolher o mecanismo de transferência. A geografia real do tratamento do fornecedor pode ser significativamente mais ampla, com cargas de trabalho distribuídas entre regiões por razões operacionais que nunca foram divulgadas na avaliação do fornecedor.

• Tratar a celebração do SCC como a conclusão da governança de transferências internacionais: o mecanismo de transferência inicial não cobre as transferências posteriores
• Abrangência geográfica completa do tratamento não avaliada: a localização do centro de dados principal é conhecida, mas o tratamento em nuvem multirregional e as localizações dos suboperadores são desconhecidos
• Atualidade do mecanismo de transferência não verificada: dependência de mecanismos que podem ter sido afetados por mudanças regulatórias sem revisão
• Notificação de migração de infraestrutura não exigida: fornecedores que podem migrar para novas regiões sem notificar os clientes, criando novas transferências internacionais sem autorização
• Localizações de suboperadores não avaliadas quanto à cobertura de transferência: a geografia dos suboperadores não é comparada com a cobertura do mecanismo de transferência

Como é uma boa prática

Programas maduros de governança de fluxos internacionais de dados mantêm um mapa completo de para onde os dados dos clientes fluem geograficamente (local principal do fornecedor, regiões de nuvem usadas no tratamento, localizações de suboperadores e unidades operacionais) e verificam se mecanismos de transferência adequados cobrem cada transferência desse mapa. Os mecanismos de transferência são mantidos atualizados à medida que os marcos regulatórios evoluem. Mudanças de infraestrutura que criam novas transferências internacionais acionam uma revisão de governança antes da implementação.

• Abrangência geográfica completa do tratamento documentada: todas as regiões de nuvem, localizações de suboperadores e unidades operacionais que tratam dados dos clientes mapeadas, e a cobertura do mecanismo de transferência verificada
• Disposições sobre transferências posteriores no DPA: o fornecedor deve garantir mecanismos de transferência adequados para todas as transferências posteriores a suboperadores e regiões de nuvem
• Notificação de mudanças de infraestrutura com revisão da governança de transferências: o fornecedor é obrigado a notificar o cliente antes de migrações de infraestrutura que criem novas transferências internacionais
• Manutenção da atualidade do mecanismo de transferência: revisão periódica que confirma que os mecanismos de transferência refletem os requisitos regulatórios vigentes e não foram afetados por mudanças regulatórias
• Confirmação do mecanismo de transferência dos suboperadores: todos os suboperadores em países terceiros cobertos por mecanismos de transferência adequados, e não apenas mencionados na lista de suboperadores

Ferramentas

A gestão da governança de fluxos internacionais de dados exige ferramentas de mapeamento para a abrangência geográfica do tratamento e ferramentas de gestão de privacidade para a manutenção dos mecanismos de transferência.

Mapeamento de fluxos de dados: OneTrust, TrustArc, Privado

As plataformas de gestão de privacidade e de fluxos de dados permitem mapear os fluxos internacionais de dados, identificando todos os locais para onde os dados pessoais são transferidos e os mecanismos de transferência que cobrem cada fluxo. O recurso de mapeamento de fluxos de dados da OneTrust permite que as organizações documentem a geografia do tratamento dos fornecedores e associem mecanismos de transferência a cada fluxo identificado. Para profissionais de TPRM, perguntar se o fornecedor pode apresentar um mapa da abrangência geográfica do tratamento que cubra todas as regiões e todos os suboperadores constitui uma solicitação específica de documentação que revela toda a cadeia de transferências.

Geografia da infraestrutura em nuvem: AWS Config, Azure Policy, GCP Asset Inventory

As ferramentas de gestão de configuração em nuvem inventariam as regiões de nuvem em que as cargas de trabalho de uma organização ou de um fornecedor estão implantadas, oferecendo uma confirmação técnica da abrangência geográfica do tratamento que complementa as declarações contratuais. Para profissionais de TPRM que avaliam fornecedores hospedados em nuvem, solicitar um inventário de regiões de nuvem junto com a documentação do mecanismo de transferência oferece uma confirmação, na camada técnica, do alcance geográfico do tratamento de dados.

Cláusulas contratuais padrão: cláusulas contratuais padrão da UE (2021), IDTA do Reino Unido, APEC CBPR

Os mecanismos de transferência vigentes incluem as cláusulas contratuais padrão de 2021 da Comissão Europeia (que substituíram as versões de 2010 invalidadas pela decisão Schrems II), o International Data Transfer Agreement do Reino Unido e as Cross-Border Privacy Rules da APEC para transferências na Ásia-Pacífico. Para profissionais de TPRM, confirmar que os mecanismos de transferência se baseiam em versões vigentes, e não em mecanismos antigos que foram substituídos, é uma verificação específica de atualidade da governança que a maioria dos programas não realiza de forma sistemática.

Desafios de governança

O desafio de governança dos fluxos internacionais de dados é a sua natureza dinâmica. A abrangência geográfica do tratamento de um fornecedor muda à medida que sua infraestrutura evolui: novas regiões de nuvem são adicionadas por razões de desempenho, os suboperadores mudam conforme evoluem as relações do fornecedor e as migrações de infraestrutura transferem cargas de trabalho entre locais. Cada mudança pode criar novas transferências internacionais que exigem autorização. Um programa de governança que mapeia o panorama de transferências na contratação e nunca o revisita se distanciará progressivamente do panorama real de transferências à medida que a infraestrutura do fornecedor evoluir.

Para os programas de TPRM, a resposta prática de governança é combinar o mapeamento inicial da abrangência geográfica com requisitos de notificação de mudanças de infraestrutura e reavaliações periódicas. A abrangência geográfica do tratamento do fornecedor deve ser documentada na contratação, atualizada por meio do mecanismo de notificação quando ocorrerem mudanças de infraestrutura e verificada em relação à realidade atual em cada ciclo de reavaliação. A atualidade do mecanismo de transferência deve ser confirmada a cada ciclo, com atualizações obrigatórias quando os marcos regulatórios mudarem.

• Documentar a abrangência geográfica do tratamento na contratação: todas as regiões de nuvem, localizações de suboperadores e unidades operacionais
• Exigir notificação de mudanças de infraestrutura antes de migrações para novas regiões que criem novas transferências internacionais
• Verificar a atualidade do mecanismo de transferência em cada reavaliação: versões vigentes em uso, mudanças regulatórias refletidas
• Confirmar a cobertura do mecanismo de transferência dos suboperadores: não apenas a lista de suboperadores, mas os mecanismos de transferência que cobrem cada suboperador em país terceiro
• Incluir o tratamento geográfico na resposta a incidentes: a situação das transferências internacionais é relevante para as obrigações de notificação de violações

Se você faz parte de uma equipe pequena

Inclua na sua avaliação de transferência internacional uma pergunta que vá além do mecanismo de transferência: além do seu centro de dados ou região de nuvem principal, em quais outros locais geográficos ocorre o tratamento dos dados dos nossos clientes, incluindo cargas de trabalho de análise de dados, recuperação de desastres, entrega de conteúdo e tratamento por suboperadores, e quais mecanismos de transferência cobrem cada um desses locais? Essa pergunta mapeia toda a cadeia de transferências, e não apenas o primeiro salto, e revelará a realidade do tratamento multirregional que a celebração de um mecanismo de transferência para um único local não aborda.

• Solicitar toda a abrangência geográfica do tratamento, e não apenas o local principal
• Incluir requisitos de notificação de mudanças de infraestrutura no seu DPA
• Verificar se o mecanismo de transferência está atualizado: confirmar que as cláusulas contratuais padrão de 2021 estão em uso, e não as versões de 2010
• Confirmar que as localizações dos suboperadores estão cobertas por mecanismos de transferência, e não apenas divulgadas

O que exigir

Pergunte diretamente:

“Em quais locais geográficos (regiões de nuvem, centros de dados e instalações de suboperadores) ocorre o tratamento dos dados dos nossos clientes, além do local da sua infraestrutura principal?”

“Quais mecanismos de transferência cobrem cada local onde nossos dados são tratados fora da nossa jurisdição? Vocês podem confirmar que todas as transferências posteriores a suboperadores estão cobertas por mecanismos adequados, e não apenas mencionadas na sua lista de suboperadores?”

“Qual é o seu processo para nos notificar quando vocês migram a infraestrutura para uma nova região ou incluem um suboperador em uma nova jurisdição, criando novas transferências internacionais que envolvem nossos dados?”

O que esperar como evidência

• Mapa da abrangência geográfica do tratamento: todos os locais onde os dados dos clientes são tratados
• Inventário de mecanismos de transferência: tipo de mecanismo e versão vigente para cada local de transferência
• Confirmação do mecanismo de transferência dos suboperadores: não apenas a lista, mas a cobertura do mecanismo
• Documentação do processo de notificação de mudanças de infraestrutura

Um fornecedor que responde à pergunta sobre abrangência geográfica com “nossa infraestrutura principal está em us-east-1” confirmou um único local. Pergunte quais outras regiões da AWS, do Azure ou do GCP suas cargas de trabalho usam e se alguma dessas regiões trata dados dos clientes. O local principal é aquele em que o fornecedor pensa. A carga de trabalho de análise de dados em Singapura é aquela em que ele não pensa.

Como comprovar

As restrições de transferência dos artigos 44-49 do GDPR, o Capítulo V do GDPR do Reino Unido e marcos equivalentes criam obrigações para cada transferência na cadeia de tratamento. A fiscalização regulatória confirmou que os controladores são responsáveis por mapear e autorizar todo o panorama de transferências, e não apenas a transferência inicial. Demonstrar a devida diligência exige evidências de que toda a abrangência geográfica do tratamento foi avaliada e de que todas as transferências foram autorizadas.

• Documentação da abrangência geográfica do tratamento de todos os fornecedores com obrigações de transferência internacional
• Inventário de mecanismos de transferência com confirmação da versão vigente
• Evidências de cobertura do mecanismo de transferência dos suboperadores
• Registros de notificação de mudanças de infraestrutura
• Registros de reavaliação periódica do panorama de transferências

Principal conclusão

O SCC cobre a transferência que você autorizou. Cobre a fronteira em que você pensou. A carga de trabalho de análise de dados do fornecedor em Singapura, seu suboperador na UE, sua infraestrutura de entrega na borda: cada uma delas é uma fronteira que os dados atravessam no curso normal do tratamento. O GDPR se aplica a cada transferência. O SCC cobre uma delas. A lacuna entre o mecanismo de transferência que você celebrou e as transferências pelas quais os dados realmente passam é a transferência não autorizada que um regulador pode perceber antes de você. Mapear para onde os dados vão não é um exercício único feito na contratação do fornecedor. É uma obrigação contínua de governança que deve ser mantida à medida que a infraestrutura do fornecedor evolui. O SCC é o instrumento. O mapa é a governança.