Linhagem de dados entre terceiros

Uma empresa de varejo compartilhou o histórico de compras de seus clientes com um fornecedor de análise de marketing. O acordo de tratamento de dados abrangia o manuseio dos dados pelo fornecedor principal. O que a empresa não sabia era que o fornecedor principal tinha uma cláusula padrão nos termos de sua plataforma que lhe permitia repassar dados a suboperadores de infraestrutura para fins de tratamento. Um desses suboperadores era uma plataforma de análise em nuvem situada em uma jurisdição que a empresa de varejo não havia autorizado para transferência de dados. A plataforma de análise tinha um recurso de aprendizado de máquina que usava dados anonimizados de clientes para melhorar o desempenho dos modelos para todos os clientes da plataforma, o que, na prática, transformava o histórico de compras da empresa de varejo em insumo de treinamento para modelos usados pelos concorrentes do fornecedor. Nada disso foi divulgado na relação com o fornecedor principal. A linhagem dos dados se estendia quatro etapas além do limite aprovado pela empresa antes que alguém a rastreasse. A empresa havia aprovado o primeiro salto. Os dados tinham ido muito mais longe.

O que é, de fato, a linhagem de dados entre terceiros?

A linhagem de dados é o registro rastreável de onde os dados se originaram, de como foram transformados e por onde passaram: uma cadeia de custódia que identifica cada sistema, processo e parte que teve contato com os dados desde a criação até o estado atual. No contexto do risco de terceiros, a linhagem de dados descreve especificamente o caminho que os dados do cliente percorrem desde os sistemas do cliente, passando pelo ambiente do fornecedor e por quaisquer partes a jusante que o fornecedor contrate para tratar, armazenar ou analisar esses dados. Compreender a linhagem de dados significa ser capaz de responder: depois que compartilhei esses dados com o fornecedor, para onde eles foram, o que foi feito com eles e quem mais teve acesso a eles?

O problema da linhagem a jusante nas relações com fornecedores surge porque a visibilidade contratual do cliente costuma terminar no fornecedor principal. O fornecedor principal tem uma relação direta com o cliente: um contrato, um acordo de tratamento de dados, responsabilização pelas obrigações de manuseio. Os suboperadores, provedores de infraestrutura, plataformas de análise e serviços de nuvem do fornecedor principal que recebem dados do cliente como parte das operações do fornecedor não têm relação direta com o cliente. Eles são invisíveis para o programa de governança do cliente, a menos que o cliente peça especificamente ao fornecedor principal que os divulgue, e a própria visibilidade de linhagem do fornecedor principal pode ser limitada: ele sabe com quem tem contratos, mas pode não ter visibilidade completa dos fluxos a jusante de seus próprios suboperadores.

A dimensão regulatória agravou consideravelmente esse problema. O artigo 28 do GDPR exige que os operadores obtenham autorização prévia por escrito, específica ou geral, do controlador antes de contratar suboperadores. As disposições do CCPA sobre prestadores de serviços criam obrigações equivalentes. Os marcos específicos da área da saúde exigem que as entidades cobertas obtenham acordos de associado comercial dos subcontratados de seus fornecedores que lidam com PHI. Esses requisitos regulatórios criam uma obrigação para o controlador, a organização cliente, não apenas de ter um DPA com o fornecedor principal, mas de compreender e aprovar a cadeia de suboperadores pela qual seus dados circulam. Um DPA que torna o fornecedor “responsável por sua cadeia de fornecimento” sem nomear e autorizar essa cadeia não atende ao requisito regulatório de divulgação de suboperadores.

As falhas de linhagem de dados em relações com terceiros se concentram em cinco lacunas específicas de visibilidade:

Cadeias de suboperadores não divulgadas: fornecedores principais que contratam suboperadores para análise, infraestrutura ou tratamento sem divulgar a lista de suboperadores aos clientes nem obter autorização específica
Fluxos de dados entre países: dados transferidos para suboperadores em jurisdições não aprovadas no acordo de tratamento de dados, criando situações de transferência internacional não autorizada nos termos do GDPR e de marcos equivalentes
Transformação e enriquecimento de dados: tratamento pelo fornecedor que enriquece ou combina dados de clientes com fontes de dados de terceiros, criando conjuntos de dados derivados com características diferentes das dos dados originalmente compartilhados
Reaproveitamento de dados por suboperadores: plataformas de suboperadores que usam dados de clientes para finalidades além do caso de uso declarado pelo fornecedor principal, incluindo treinamento de modelos, melhoria de produtos ou benchmarking entre conjuntos de dados de clientes
Extensão indefinida da linhagem: suboperadores que contratam seus próprios suboperadores, criando cadeias de linhagem de dados que se estendem além do que o fornecedor principal ou o cliente conseguem rastrear

Por que isso importa

A linhagem de dados entre terceiros é importante para TPRM porque as obrigações regulatórias aplicáveis aos dados do cliente (limitações de tratamento, restrições geográficas, requisitos de autorização de suboperadores, direitos dos titulares) se aplicam aos dados independentemente de quantos elos os separam do cliente. O direito do titular à eliminação previsto no GDPR não termina no banco de dados do fornecedor principal. Ele se aplica a todas as cópias de seus dados em todos os sistemas ao longo da cadeia de linhagem. Uma restrição geográfica à transferência de dados não exclui os suboperadores que atuam em jurisdições não autorizadas. Uma limitação de finalidade ao uso dos dados não permite que um suboperador use os dados para uma finalidade diferente da autorizada pelo controlador.

A consequência prática é que as obrigações de proteção de dados do cliente se estendem até onde os dados chegam, mas a visibilidade de governança do cliente normalmente termina no primeiro salto. Isso cria uma lacuna sistemática entre as obrigações que o cliente assumiu e as obrigações que ele de fato consegue monitorar e fazer cumprir. Um cliente que obteve um DPA de seu fornecedor principal, mas não tem visibilidade da cadeia de suboperadores, possui um arcabouço contratual que cobre apenas uma fração do ecossistema real de tratamento de dados pelo qual circulam os dados de seus clientes.

A dimensão do risco de quartas partes é onde isso se torna um verdadeiro desafio para o programa corporativo de riscos. O risco de quartas partes, aquele que surge do fornecedor do fornecedor do seu fornecedor, é estruturalmente difícil de avaliar porque não existe relação direta entre o cliente e a quarta parte. O cliente não pode auditá-la, não pode contratar diretamente com ela e talvez nem saiba que ela existe sem perguntar ao fornecedor principal e, depois, ao suboperador do fornecedor principal. No caso específico da linhagem de dados, isso significa que a cadeia completa pode ser desconhecida a qualquer momento, e um evento em qualquer nó da cadeia (uma violação, uma mudança de jurisdição, uma atualização de funcionalidade que permita o reaproveitamento de dados) gera exposição para o cliente, independentemente de quantas camadas de relacionamento o separam dele.

Onde a maioria das equipes erra

A falha mais recorrente é tratar o acordo de tratamento de dados como o limite da governança da linhagem de dados. Um DPA que torna o fornecedor responsável pela conformidade dos suboperadores cria uma obrigação de responsabilização, mas não cria visibilidade. O cliente sabe que o fornecedor é responsável. Ele não sabe quem são os suboperadores, quais dados cada um recebe nem quais controles se aplicam em cada nó. Responsabilização sem visibilidade não é governança: é a capacidade de atribuir responsabilidade depois que algo dá errado, e não a capacidade de impedir que algo dê errado.

A segunda falha é não exigir a divulgação de suboperadores como elemento padrão da integração e da governança contínua de fornecedores. A maioria dos DPAs inclui uma cláusula geral de autorização de suboperadores: o fornecedor pode contratar suboperadores, desde que sujeitos a obrigações equivalentes de proteção de dados. Pouquíssimos exigem que o fornecedor mantenha e forneça uma lista atualizada de suboperadores, notifique o cliente quando suboperadores forem acrescentados ou alterados e obtenha a aprovação do cliente antes de acrescentar suboperadores em jurisdições não autorizadas. Sem esses requisitos específicos, a cláusula geral de autorização é um cheque em branco para o compartilhamento de dados a jusante pelo fornecedor.

Tratar o DPA como governança da linhagem de dados: o DPA cria responsabilização, não visibilidade sobre a cadeia real de suboperadores
Nenhum requisito de lista de suboperadores: DPAs que autorizam a subcontratação do tratamento de forma geral, sem exigir a divulgação dos suboperadores específicos e de como manuseiam os dados
Nenhum requisito de notificação de mudanças: fornecedores que podem acrescentar novos suboperadores sem notificar o cliente, ampliando silenciosamente a cadeia de linhagem dos dados
Nenhuma autorização geográfica: DPAs que não especificam as jurisdições aprovadas para o tratamento de dados, deixando sem governança os fluxos de suboperadores entre países
Nenhuma avaliação de quartas partes: programas de TPRM que avaliam o fornecedor principal sem nenhuma visibilidade da cadeia de suboperadores do fornecedor

Como é uma boa prática

Programas maduros de governança da linhagem de dados tratam a visibilidade dos suboperadores como um direito contratual, e não como um gesto opcional de transparência. As listas de suboperadores são mantidas, divulgadas e atualizadas quando ocorrem mudanças. As restrições geográficas são específicas. Os requisitos de notificação de mudanças criam um gatilho de governança quando a cadeia de linhagem se amplia. E, nas relações de dados de maior risco, a revisão periódica de toda a cadeia de suboperadores garante que a linhagem permaneça dentro dos limites aprovados ao longo do tempo.

Obrigação contratual de divulgação de suboperadores: o fornecedor deve manter e fornecer uma lista atualizada de suboperadores, atualizada sempre que suboperadores forem incluídos ou alterados
Notificação de mudanças com direito de oposição: fornecedores obrigados a notificar o cliente com pelo menos trinta dias de antecedência antes de acrescentar um novo suboperador, mantendo o cliente o direito de se opor
Restrições geográficas ao tratamento: jurisdições específicas aprovadas para o tratamento de dados no DPA, sendo que qualquer tratamento por suboperador em jurisdição não aprovada exige autorização explícita
Mapeamento dos fluxos de dados dos suboperadores: documentação de quais dados cada suboperador recebe, para qual finalidade e sob quais obrigações contratuais
Revisão periódica da cadeia de suboperadores: revisão anual ou acionada por eventos da lista completa de suboperadores para confirmar que ela reflete a realidade atual e permanece dentro dos limites aprovados
Proibição de reaproveitamento de dados: proibição contratual explícita de que suboperadores usem dados do cliente para finalidades além do caso de uso autorizado do fornecedor principal

Ferramentas

Gerenciar a linhagem de dados entre terceiros exige uma combinação de mecanismos contratuais e ferramentas técnicas que permitam descobrir e mapear para onde os dados fluem além da relação com o fornecedor principal.

Plataformas de TPRM com rastreamento de suboperadores: OneTrust, Prevalent, ProcessUnity

As plataformas corporativas de TPRM incluem cada vez mais recursos de acompanhamento de suboperadores e quartas partes, mantendo mapas da cadeia de fornecimento que mostram não apenas os fornecedores principais, mas também os suboperadores e provedores de infraestrutura que os fornecedores principais contratam. O módulo de gestão de riscos de fornecedores da OneTrust apoia a documentação da divulgação de suboperadores e os fluxos de trabalho de notificação de mudanças. Para profissionais de TPRM, essas plataformas oferecem a infraestrutura operacional para manter e revisar em escala a visibilidade da cadeia de suboperadores em uma grande carteira de fornecedores.

Mapeamento de fluxos de dados: Microsoft Purview Data Map, Collibra, Alation

Plataformas de catálogo e linhagem de dados oferecem mapeamento técnico dos fluxos de dados, rastreando como os dados se movem entre sistemas, que transformações ocorrem e onde são armazenados. No contexto de fornecedores, essas plataformas apoiam a documentação dos fluxos de dados aprovados e a detecção de desvios em relação a eles. Para profissionais de TPRM, perguntar se um fornecedor mantém um mapa de fluxos de dados que abranja sua cadeia de suboperadores é uma pergunta específica de documentação de governança que revela se a linhagem é rastreada de forma sistemática ou gerida de maneira informal.

Gestão da privacidade de dados: TrustArc, BigID, Securiti

As plataformas de gestão de privacidade apoiam a manutenção dos registros das atividades de tratamento (ROPA) exigidos pelo artigo 30 do GDPR e por marcos equivalentes, incluindo a identificação dos operadores e suboperadores na cadeia de tratamento. Para clientes que buscam mapear suas próprias obrigações de linhagem de dados, as plataformas de gestão de privacidade oferecem a infraestrutura de inventário e documentação que torna a governança da cadeia de suboperadores operacionalmente sustentável em uma grande carteira de fornecedores.

Gestão de contratos com cláusulas de suboperadores: Ironclad, Icertis, DocuSign CLM

Plataformas de gestão do ciclo de vida de contratos permitem padronizar as cláusulas de divulgação de suboperadores em todos os contratos com fornecedores, garantindo que todo DPA inclua as obrigações exigidas sobre a lista de suboperadores, os requisitos de notificação de mudanças e as restrições geográficas, em vez de depender da revisão manual de cada contrato. Para programas de TPRM que negociam centenas de contratos com fornecedores, as plataformas de CLM oferecem a aplicação sistemática dos requisitos de visibilidade de suboperadores que a revisão individual de contratos não consegue sustentar.

Desafios de governança

O desafio de governança da linhagem de dados entre terceiros é a natureza dinâmica das cadeias de suboperadores dos fornecedores. Um fornecedor que divulga cinco suboperadores no momento da contratação pode ter contratado mais três suboperadores seis meses depois, por meio de novas parcerias de infraestrutura, migrações de plataforma ou inclusão de funcionalidades no produto. Sem uma obrigação contratual de notificação de mudanças e um processo operacional para revisar as alterações de suboperadores, a lista aprovada no onboarding é precisa em um único momento e se torna progressivamente menos precisa à medida que a relação evolui.

Para programas de TPRM, a resposta prática de governança é combinar exigências contratuais de divulgação de suboperadores com ciclos periódicos de revisão que confirmem que a lista divulgada continua precisa e completa. Uma revisão anual da lista de suboperadores, pedindo ao fornecedor que confirme sua lista atual e comparando-a com a lista divulgada anteriormente, oferece um mecanismo leve, porém eficaz, para detectar mudanças que não foram notificadas. Para fornecedores que tratam dados sensíveis de nível mais crítico, ciclos de revisão mais frequentes ou exigências de notificação de mudanças em tempo real proporcionam uma governança mais forte sem exigir uma reavaliação completa.

Acrescentar requisitos de divulgação de suboperadores a todos os DPAs: lista atualizada, obrigação de atualização, notificação de mudanças com direito de oposição
Especificar explicitamente restrições geográficas ao tratamento: jurisdições aprovadas listadas e jurisdições não autorizadas proibidas sem autorização específica
Incluir a revisão da lista de suboperadores nas reavaliações de fornecedores: confirmação anual de que a lista divulgada está atualizada e completa
Avaliar o risco de reaproveitamento de dados por fornecedores de análise e de ML: proibição explícita do uso de dados de clientes para treinamento de modelos ou benchmarking entre clientes sem autorização específica
Mapear a exposição a quartas partes nas relações com fornecedores de maior risco: pedir aos fornecedores principais que divulguem os suboperadores de seus suboperadores nas relações que envolvem os dados sensíveis de maior criticidade

Se você faz parte de uma equipe pequena

Comece com a pergunta sobre suboperadores nas suas cinco relações com fornecedores de maior risco em compartilhamento de dados: vocês podem fornecer uma lista atualizada de todos os suboperadores que recebem dados que vocês tratam em nosso nome, quais dados cada um recebe e em quais jurisdições operam? Essa pergunta, feita aos seus fornecedores mais críticos, revelará de imediato a cadeia de linhagem que a cláusula de responsabilização do seu DPA menciona, mas não descreve. Para qualquer suboperador que atue em uma jurisdição não abrangida pelo seu marco de transferência de dados, você terá identificado uma transferência internacional não autorizada que precisa ser tratada ou formalmente autorizada.

Pedir aos seus fornecedores de maior risco a lista atualizada de suboperadores: suboperadores específicos, dados recebidos e jurisdições
Inclua requisitos de divulgação de suboperadores e de notificação de mudanças na próxima renovação do seu DPA
Para fornecedores de análise e de ML, acrescentar proibições explícitas de reaproveitamento de dados para impedir que dados de clientes sejam usados no treinamento de modelos
Revisar as jurisdições dos suboperadores divulgados em relação ao seu marco aprovado de transferência de dados: jurisdições não autorizadas são uma lacuna regulatória que exige atenção imediata

O que exigir

Pergunte diretamente:

“Vocês podem fornecer uma lista atualizada de todos os suboperadores que recebem dados que vocês tratam em nosso nome, incluindo nomes, localizações, quais dados recebem e a finalidade para a qual os recebem?”

“Qual é o seu processo para nos notificar quando vocês acrescentam, alteram ou removem um suboperador? E qual é o nosso direito de nos opor a um novo suboperador antes que ele receba nossos dados?”

“Algum suboperador da sua cadeia está autorizado a usar os dados que recebe de vocês para finalidades além do caso de uso contratado, incluindo treinamento de modelos, melhoria de produtos ou benchmarking entre conjuntos de dados de clientes?”

O que esperar como evidência

Lista atualizada de suboperadores com nomes, jurisdições, dados recebidos e finalidade do tratamento
Documentação do processo de notificação de mudanças com direito de oposição do cliente
Confirmação da proibição de reaproveitamento de dados: suboperadores contratualmente proibidos de usar dados do cliente para finalidades não autorizadas
Confirmação da localização geográfica do tratamento: todos os suboperadores atuando em jurisdições cobertas pelos mecanismos aplicáveis de transferência de dados

Um fornecedor que responde à pergunta sobre suboperadores com “usamos provedores de infraestrutura de nuvem padrão do setor” descreveu uma categoria sem nomear os provedores, suas jurisdições ou quais dados recebem. Peça a lista. A descrição da categoria não diz nada sobre se os provedores específicos estão em jurisdições aprovadas ou têm obrigações contratuais adequadas.

Como comprovar

Os requisitos de autorização de suboperadores do Artigo 28 do GDPR, as obrigações sobre a cadeia de prestadores de serviço da CCPA e os requisitos para subcontratados de business associates da HIPAA criam obrigações específicas de divulgação e autorização de suboperadores. Demonstrar a devida diligência exige evidências de que as cadeias de suboperadores foram divulgadas, revisadas e autorizadas, e não apenas de que o fornecedor principal era contratualmente responsável por elas.

Registros de divulgação de suboperadores: listas atualizadas recebidas dos fornecedores no onboarding e em cada ciclo de reavaliação
Documentação da cláusula de suboperadores do DPA: direitos de divulgação, notificação e oposição especificados contratualmente
Registros de autorização de transferências geográficas: jurisdições dos suboperadores revisadas em relação aos marcos de transferência de dados aplicáveis
Documentação da proibição de reaproveitamento de dados nos contratos com fornecedores
Registros da revisão anual da lista de suboperadores que confirmem a atualização e a completude da lista divulgada

Principal conclusão

Os dados não param de circular quando chegam ao seu fornecedor. Eles seguem para os suboperadores do fornecedor, que os levam para seus provedores de infraestrutura, que podem repassá-los a plataformas de análise, que podem usá-los para finalidades que ninguém autorizou. O acordo de tratamento de dados que você assinou torna o fornecedor responsável por essa cadeia. Ele não diz qual é essa cadeia. Responsabilização sem visibilidade é gestão de responsabilidade civil, não governança de dados. A lista de suboperadores é o mapa de para onde seus dados realmente vão. Exigi-la, revisá-la e autorizá-la de forma específica, e não genérica, é a etapa de governança que transforma um DPA em um instrumento efetivo de proteção de dados, e não em uma formalidade contratual.