Um guia prático de Quando as plataformas analíticas violam seus dados

Incidente em fornecedor de dados raramente vira manchete, mas quando as plataformas analíticas violam seus dados a responsabilidade legal continua sendo sua.

As violações de dados analíticos raramente são tratadas com a urgência de vazamentos de cartões de pagamento ou roubo de credenciais. Isso é um erro. As plataformas analíticas podem conter URLs, termos de pesquisa, referenciadores, campanha IDs, localização derivada de IP, eventos de conta, uso de produto e, às vezes, identificadores de nível de usuário. No contexto errado, esses dados podem revelar clientes, estratégia, interesses de saúde, funis de aquisição ou comportamento confidencial de produtos.

A questão jurídica também é clara: ao abrigo da GDPR, uma violação de dados pessoais inclui destruição, perda, alteração acidental ou ilegal, divulgação não autorizada ou acesso a dados pessoais. O responsável pelo tratamento deve avaliar o risco e poderá ter de notificar a autoridade de controlo no prazo de 72 horas nos termos do artigo 33 e as pessoas afetadas nos termos do artigo 34. O fato de um fornecedor ter causado o incidente não elimina a responsabilidade do controlador.

Como são as violações de análise

Nem todo incidente é um hacker filtrando um banco de dados. Muitos incidentes de análise resultam de falhas operacionais comuns:

• Um painel multilocatário exibe os dados de um cliente para outro cliente.
• O registro de depuração armazena URLs completo contendo e-mails, tokens de redefinição ou parâmetros de consulta de integridade.
• Uma exportação mal configurada do BigQuery, S3 ou data warehouse torna-se pública.
• A equipe de suporte pode acessar fluxos de eventos brutos sem motivo comercial.
• Um gerenciador de tags carrega um script não aprovado que copia os dados do evento para terceiros.
• Um fornecedor subprocessa dados em um país que não foi coberto pelo contrato ou pela avaliação de transferência.

Esses incidentes são dolorosos porque os dados analíticos geralmente são amplos. Um script de rastreamento pode afetar cada página e cada jornada do usuário.

A soberania dos dados é mais do que a localização do servidor

A soberania dos dados significa que você entende quais leis, empresas, pessoas e infraestrutura podem afetar seus dados. Hospedar-se em Frankfurt ou Dublin é útil, mas não responde a todas as perguntas. Você ainda precisa saber a jurisdição corporativa do provedor, subprocessadores, acesso de suporte remoto, modelo de criptografia, processo de resposta a incidentes e se os dados podem ser transferidos fora do EEA.

Para os dados pessoais da EU, as transferências internacionais são regidas pelo GDPR Capítulo V. As transferências podem depender de uma decisão de adequação, de cláusulas contratuais padrão, de regras corporativas vinculativas ou de outro mecanismo aprovado. Depois de o Tribunal de Justiça ter invalidado o Privacy Shield no Schrems II, as organizações também tiveram de considerar se eram necessárias medidas suplementares para transferências para países com riscos de vigilância. A Estrutura de Privacidade de Dados EU-US já existe, mas se aplica apenas a organizações US certificadas e continua sendo uma área de risco que deve ser monitorada.

Por que a infraestrutura compartilhada muda o modelo de risco

A maioria das plataformas analíticas SaaS são multilocatários. Isso é normal, mas torna o isolamento dos inquilinos um controle crítico. Você deseja evidências de que os dados do cliente estão separados nas camadas de aplicativo, banco de dados, controle de acesso, registro, backup e suporte.

Peça aos fornecedores respostas precisas:

• Os locatários estão separados por banco de dados, esquema, permissões em nível de linha ou lógica de aplicativo?
• A equipe pode consultar diretamente os eventos brutos do cliente?
• As sessões de acesso à produção são registradas e revisadas?
• As exportações são criptografadas em repouso e em trânsito?
• Como os backups são isolados e excluídos?
• O que acontece se a configuração de um locatário for aplicada acidentalmente a outro?

Se um fornecedor não consegue explicar claramente a separação dos inquilinos, isso é um risco de aquisição, e não uma peculiaridade de documentação.

Preparação para incidentes para dados analíticos

Um plano prático de incidentes analíticos deve definir o que é considerado reportável, quem faz a chamada e com que rapidez as evidências podem ser coletadas. Inclua análises em seus exercícios de violação. A investigação deve responder:

1. Quais conjuntos de dados foram expostos ou alterados?
2. Os dados incluíam dados pessoais, identificadores pseudônimos ou URLs confidenciais?
3. Quantas pessoas e contas foram afetadas?
4. Os dados poderiam ser vinculados a indivíduos?
5. Os dados foram acessados ​​por outro cliente, funcionário de um fornecedor, público ou invasor?
6. São necessárias notificações ao regulador ou ao cliente?
7. Quais registros comprovam a contenção?

As diretrizes de notificação de violação do EDPB são úteis porque se concentram no risco e não nos rótulos.

Como reduzir a exposição antes de um incidente

O controle mais forte é a minimização. Não envie dados pessoais para análises, a menos que você realmente precise deles. Evite coletar URLs completo se URLs puder conter entradas do usuário. Remova os parâmetros de consulta por padrão e permita apenas parâmetros de campanha aprovados. Nunca coloque e-mails, números de telefone, nomes, tokens ou valores de formulário de texto livre nas propriedades do evento.

Em seguida, reduza a retenção. Mantenha os dados brutos do evento apenas enquanto forem operacionalmente úteis e depois agregue. Uma janela de eventos brutos de 30 ou 90 dias pode ser suficiente para depuração e análise de funil, enquanto os relatórios agregados mensais podem ser retidos por mais tempo.

Por fim, prefira arquiteturas que limitem o acesso de terceiros. Para algumas equipes, isso significa um SaaS com privacidade em primeiro lugar, hospedado pelo EU, com contratos fortes e sem identificadores entre sites. Para equipes regulamentadas ou do setor público, isso pode significar infraestrutura auto-hospedada ou dedicada, chaves de criptografia gerenciadas pelo cliente e aprovações rigorosas de acesso ao suporte.

Perguntas de due diligence do fornecedor

Antes de escolher uma plataforma analítica, peça:

• Um contrato de processamento de dados e uma lista de subprocessadores.
• Documentação de residência e transferência de dados.
• Certificações de segurança ou auditorias independentes, quando disponíveis.
• Um compromisso de notificação de violação com prazos.
• Uma política de retenção e exclusão.
• Uma lista de campos e identificadores coletados.
• Suporte para desabilitar cookies, armazenamento IP, impressão digital e rastreamento no nível do usuário.
• Fluxos de trabalho de exportação e exclusão se você sair.

A análise deve reduzir a incerteza. Se a própria plataforma criar incerteza jurídica, de segurança e de soberania, a ferramenta estará trabalhando contra o negócio.

Lista de verificação de análise pronta para incidentes

Prepare-se para incidentes analíticos antes que eles aconteçam. Mantenha um mapa de dados atualizado, lista de fornecedores, lista de subprocessadores, cronograma de retenção, log de acesso, caminho de exportação e rota de contato para avisos de segurança. Incluir ferramentas analíticas em exercícios de mesa de violação.

Reduza o raio de explosão coletando menos identificadores, excluindo URLs e eventos confidenciais, reduzindo a retenção de dados brutos, limitando o acesso ao painel e preferindo fornecedores que possam explicar a separação de locatários, o acesso de suporte e a localização de dados em termos concretos.

Perguntas Frequentes

Em quanto tempo é preciso notificar uma violação de dados de análise segundo o RGPD?

Segundo o RGPD, os responsáveis pelo tratamento devem notificar a autoridade de controlo no prazo de 72 horas após tomarem conhecimento de uma violação de dados pessoais, nos termos do artigo 33. O artigo 34 trata de quando as pessoas afetadas precisam de ser informadas diretamente. O facto de um fornecedor ter causado o incidente não retira a responsabilidade do responsável pelo tratamento. O prazo começa quando há informação suficiente para avaliar o risco, não quando a investigação termina.

Um erro do fornecedor ainda conta como violação segundo o RGPD?

Sim. O RGPD define uma violação de dados pessoais como qualquer destruição, perda, alteração, divulgação ou acesso não autorizados a dados pessoais, acidentais ou ilícitos, independentemente de quem os causou. Uma configuração incorreta do fornecedor que desencadeia o incidente não elimina os deveres de notificação do responsável pelo tratamento.

O que conta como dado pessoal dentro de uma plataforma de análise?

As ferramentas de análise podem captar URLs, termos de pesquisa, referenciadores, IDs de campanha, localização derivada do IP, eventos de conta, uso do produto e, por vezes, identificadores ao nível do utilizador. Qualquer um destes pode tornar-se dado pessoal assim que for associado a uma pessoa, por exemplo um token de redefinição guardado numa URL registada em log de depuração. É por isso que o artigo trata as plataformas de análise com a mesma seriedade que os sistemas de cartões de pagamento.

Qual é a diferença entre hospedar dados na UE e ter soberania de dados de verdade?

A localização do servidor é apenas uma parte. A soberania dos dados também depende da jurisdição corporativa do fornecedor, dos seus subcontratados, do acesso remoto do suporte, do modelo de encriptação, do processo de resposta a incidentes e de os dados poderem ou não sair do EEE. Um painel hospedado em Frankfurt pode continuar acessível a colaboradores ou subcontratados fora da UE.

Por que o caso Schrems II importou para os fornecedores de análise?

O Tribunal de Justiça da União Europeia invalidou o Privacy Shield entre a UE e os EUA no caso Schrems II. Essa decisão obrigou as organizações a reavaliar se eram necessárias medidas suplementares para transferências para países com risco de vigilância. O EU-US Data Privacy Framework existe agora, mas cobre apenas organizações dos EUA certificadas e continua a ser uma área de risco a acompanhar.

O que se deve perguntar a um fornecedor sobre o isolamento de clientes?

Pergunte se os clientes são separados por base de dados, esquema, permissões ao nível da linha ou lógica de aplicação, se a equipa consegue consultar diretamente os eventos brutos de outros clientes, e se as sessões de acesso à produção ficam registadas e revistas. Pergunte também como as exportações e os backups são encriptados e isolados, e o que acontece se a configuração de um cliente for aplicada por engano a outro. Um fornecedor que não consegue responder com clareza representa um risco de contratação, não um pormenor de documentação.

Por quanto tempo se deve manter dados brutos de eventos de análise?

Apenas enquanto continuarem a ser úteis operacionalmente, passando depois para agregados. Uma janela de 30 ou 90 dias de dados brutos costuma bastar para depuração e análise de funil, enquanto relatórios agregados mensais podem ser mantidos por mais tempo sem a mesma exposição.

Quais são exemplos de erros comuns que causam violações de análise?

As causas mais comuns incluem um painel multi-inquilino que mostra os dados de um cliente a outro e logs de depuração que guardam URLs completos com emails ou tokens de redefinição. Juntam-se a estes uma exportação do BigQuery ou S3 mal configurada que fica pública, equipa de suporte a aceder a fluxos de eventos brutos sem motivo de negócio e um gestor de tags que carrega um script não aprovado que copia dados para terceiros. Nenhum destes casos precisa de um atacante. São falhas operacionais.

O que deve responder uma investigação de um incidente de análise?

A investigação deve identificar quais conjuntos de dados foram expostos ou alterados, se os dados incluíam dados pessoais, identificadores pseudonimizados ou URLs sensíveis, e quantas pessoas e contas foram afetadas. Deve também esclarecer se os dados podem ser associados a indivíduos, quem lhes acedeu, e se é necessária notificação ao regulador ou aos clientes, com logs que comprovem a contenção.

O que se deve pedir durante a due diligence de um fornecedor?

Peça um acordo de processamento de dados e a lista de subcontratados, documentação de residência e transferência de dados, e certificações de segurança ou auditorias independentes quando existirem. Peça também um compromisso de notificação de violações com prazos, uma política de retenção e eliminação, uma lista dos campos e identificadores recolhidos, e fluxos de exportação e eliminação para quando decidir sair.