Quando um incidente de segurança envolve dados pessoais, a equipe defensiva precisa tomar duas decisões quase ao mesmo tempo: preservar a evidência que sustenta a investigação e a comunicação à autoridade, e limitar a exposição de identificadores de titulares que nada têm a ver com a crise. A anonimização e a pseudonimização são as ferramentas dessa fronteira, e a Autoridade Nacional de Proteção de Dados (ANPD) e a agência europeia ENISA já publicaram critérios técnicos para aplicá-las sem destruir o valor investigativo do log. A ação prioritária é institucional, não técnica: definir, antes da crise, quem tem autoridade para anonimizar, qual técnica usar em cada tipo de dado e como registrar cada decisão tomada.
Incidente produz dado pessoal
Todo incidente relevante produz dado pessoal: endereços IP de estações comprometidas, contas de e-mail em logs de proxy, identificadores de sessão, nomes em tickets internos e registros de acesso a sistemas corporativos. Enquanto esses registros permitirem associar, direta ou indiretamente, uma pessoa a um evento, eles seguem o regime de dado pessoal da LGPD, com prazos de comunicação e bases de tratamento próprias. A pseudonimização não retira o dado desse regime: apenas torna a reidentificação dependente de informação adicional, que precisa ficar guardada separadamente e sob medidas técnicas e organizacionais.
A anonimização só se configura quando o dado perde, de forma duradoura, a possibilidade de associação a um indivíduo. Para a ANPD, isso significa recorrer a meios técnicos razoáveis e disponíveis no momento do tratamento — e não uma promessa de proteção absoluta. Um endereço IP truncado em um relatório continua pessoal se, cruzado com outra base, levar de volta ao titular. A decisão sobre o que é anônimo é contextual: depende do dado, do volume tratado e de quem pode acessar o resultado. É por isso que ela não pode ficar a cargo de um analista isolado no meio da crise.
O que a ANPD orienta
O estudo técnico da ANPD sobre anonimização na LGPD parte de uma conclusão que muda o planejamento da resposta a incidentes: a orientação é abordar a anonimização por padrão como um processo contínuo baseado em riscos, e não como aplicação pontual de técnicas. O motivo é direto. Toda técnica isolada está sujeita a reidentificação bem-sucedida quando o contexto muda, o volume de dados cresce ou surge uma base nova disponível para cruzamento. O que protege o titular não é o algoritmo escolhido numa tarde de crise, e sim o processo que reavalia essa escolha ao longo do tempo.
Na prática, isso vira requisito de processo para o plano de resposta. Antes de escolher supressão, generalização ou hash, a equipe precisa caracterizar o cenário: tipo de tratamento, volume tratado, risco de reidentificação e utilidade necessária para a investigação. O estudo preliminar de anonimização e pseudonimização da autoridade acrescenta um ponto de governança que costuma passar despercebido: anonimizar dados coletados para outra finalidade configura tratamento posterior, que precisa ser compatível com a finalidade original informada ao titular. Em linguagem de operação, a política de anonimização de dados de incidente precisa estar prevista na política de privacidade antes do vazamento, não improvisada depois dele.
Quando o tratamento envolve alto risco, entra a avaliação formal de impacto. O relatório que conecta as duas autoridades da crise — o encarregado de dados e o líder de resposta — já foi detalhado quando explicamos em que situações o RIPD se torna obrigatório.
Técnicas e seus limites
O catálogo da ANPD cobre supressão, generalização, perturbação e permutação para dados estruturados, com ressalvas explícitas sobre limitações. A agência europeia complementa com o critério criptográfico: para o ENISA, a função de hash sem chave contribui para integridade, mas é considerada fraca como técnica de pseudonimização, por ser vulnerável a ataques de força bruta e de dicionário. A recomendação prática da agência é gerar pseudônimos com funções de hash que dependem também de uma chave secreta, mantida fora do alcance de quem acessa a cópia pseudonimizada.
A tabela abaixo resume o uso defensivo de cada família de técnicas no contexto de resposta a incidentes:
| Técnica | Uso no incidente | Limite conhecido |
|---|---|---|
| Supressão | Remover CPF, e-mail e telefone de relatórios que circulam fora da equipe | Reduz utilidade quando remove campos de correlação |
| Generalização | Trocar IP completo por faixa de rede em indicadores compartilhados | Diminui a precisão da correlação entre eventos |
| Perturbação e permutação | Estatísticas internas de acesso sem expor indivíduos | Não serve para investigar um caso individual |
| Hash com chave secreta | Pseudonimizar identificadores em cópias de trabalho do log | Exige gestão de chave e separação do mapeamento |
| Hash sem chave | Nenhum, como proteção de identidade | Pode ser revertido por enumeração de valores prováveis |
Quem decide e o que registra
A autoridade de decisão deve ser dupla e definida em tempos de paz: o líder da resposta a incidentes responde pelo que é preservado como evidência; o encarregado de dados responde pelo que é exposto, retido ou compartilhado. A regra operacional que protege os dois lados é trabalhar sempre sobre cópias pseudonimizadas, mantendo o original íntegro sob custódia documentada, com hash de verificação e registro de quem acessou. Assim, a investigação corre sobre identificadores estáveis, e a reidentificação pontual — necessária, por exemplo, para notificar um titular afetado — vira exceção autorizada, registrada e limitada no tempo.
O diário do incidente deve registrar, para cada conjunto de dados tratado: a técnica escolhida, o responsável pela decisão, o momento, a finalidade e o risco de reidentificação considerado. Esse registro transforma a anonimização de intenção em prova de governança — e é o primeiro documento que um regulador vai pedir. A definição de quem fala e quando já é disciplina consolidada de comunicação de crise cibernética e se aplica integralmente ao contato com a autoridade de proteção de dados.
Prioridades P1 e P2
- P1 — antes do incidente: mapear quais fontes de log contêm dado pessoal; incluir a política de anonimização na política de privacidade; definir em documento interno a dupla de decisão entre resposta e encarregado.
- P1 — durante o incidente: preservar o original sob custódia com hash de verificação; investigar sobre cópia pseudonimizada com hash chaveado; registrar cada decisão no diário do incidente.
- P2 — compartilhamento: trocar com CERT e parceiros apenas os identificadores técnicos necessários, generalizados quando possível; revisar retenção e descarte das cópias após o encerramento.
- P2 — após a crise: reavaliar o risco de reidentificação com o que foi aprendido e atualizar o processo, porque o contexto muda e a avaliação precisa acompanhar essa mudança.
O critério final é simples de enunciar e difícil de executar: nenhum dado deve circular com mais identidade do que a decisão exige, e nenhuma decisão deve ficar sem registro. Entre esses dois limites cabe uma investigação rápida, uma comunicação limpa ao regulador e a demonstração de que a organização tratou a privacidade como parte da resposta, não como entrave.