Vazou dado pessoal: o relógio começa a correr agora

Quando um vazamento de dados pessoais acontece, a lei brasileira de proteção de dados (LGPD) dá um prazo curto para reagir. Segundo a autoridade nacional de proteção de dados, a comunicação do incidente — à autoridade e às pessoas afetadas — deve ser feita em até três dias úteis, contados a partir do momento em que a empresa toma conhecimento do problema. A regra está na Resolução nº 15, de abril de 2024, editada pela própria autoridade, que regulamenta o artigo 48 da LGPD.

Três dias úteis é pouco tempo para qualquer processo dentro de uma empresa — e é assim mesmo, de propósito. O detalhe que quase nenhuma empresa de pequeno ou médio porte percebe antes de precisar dele é outro: esse prazo só começa a contar quando alguém sabe que o incidente aconteceu. Descobrir o que houve, o que foi acessado e quem foi atingido não entra na conta dos três dias — precisa estar resolvido antes de o relógio começar.

Para quem decide na empresa, isso muda a pergunta que vale fazer. Não é "meu advogado sabe o que fazer se vazar um dado?" — quase sempre sabe. É "se vazar hoje, em quanto tempo minha equipe vai saber que vazou, o que vazou e quem foi afetado?" Sem resposta para essa segunda pergunta, o prazo legal já nasce perdido.

O prazo que ninguém cumpre sozinho

A norma que trata da comunicação de incidentes é específica sobre o que precisa constar na mensagem enviada à autoridade e às pessoas afetadas: a natureza do incidente, as categorias e a quantidade de dados pessoais atingidos, os riscos envolvidos, as medidas adotadas para reverter ou reduzir os efeitos e a data em que a empresa tomou conhecimento do problema, entre outras informações.

Cada um desses pontos depende de um registro que já precisa existir antes do incidente. Não dá para descrever "a quantidade de dados afetados" sem saber, de antemão, onde os dados pessoais de clientes e funcionários estão guardados e quem tem acesso a eles. Não dá para informar "a data do conhecimento do incidente" com precisão se ninguém olha os sinais de acesso fora do padrão todos os dias — a data vira "não sabemos ao certo", e isso já entra na comunicação como uma falha.

A própria autoridade prevê um alívio para quando a informação completa ainda não existe: é possível enviar uma comunicação preliminar dentro dos três dias úteis e complementar os dados em até vinte dias úteis depois. Mas mesmo essa comunicação preliminar exige saber, no mínimo, que algo aconteceu e ter uma primeira ideia do alcance — o que já é mais do que muitas empresas conseguem dizer quando descobrem um vazamento.

A autoridade descreve seu próprio modelo de fiscalização como uma "regulação responsiva", em que as medidas aplicadas levam em conta a cooperação do agente de tratamento com o processo. Na prática, a empresa que chega com algum registro — mesmo incompleto — está numa posição bem diferente da empresa que só percebe o problema quando alguém de fora avisa.

Por que o jeito comum não resolve

O jeito comum de lidar com dado pessoal numa empresa pequena ou média é, na prática, não lidar: os cadastros de clientes e funcionários ficam espalhados entre planilhas, sistemas de fornecedores e a caixa de e-mail de quem sempre cuidou disso. Ninguém decidiu formalmente quem responde por proteger esses dados — a tarefa foi parar com quem estava mais perto quando a empresa cresceu.

Esse arranjo funciona até o dia em que alguém de fora avisa que algo aconteceu — um cliente, um fornecedor, ou, no pior caso, o próprio invasor anunciando o ataque. Nesse momento a empresa descobre três coisas ao mesmo tempo: o incidente, a falta de registro sobre ele e a falta de alguém com autoridade para decidir o próximo passo.

Comprar mais uma ferramenta de segurança depois do susto não resolve esse problema específico. Antivírus, firewall e backup ajudam a evitar que o ataque aconteça ou se espalhe — mas nenhum deles, sozinho, produz o dado que a comunicação de um incidente exige: o que foi acessado, quando e por quem. Isso é operação, não produto.

O que precisa existir na prática

Cumprir o prazo de três dias úteis não é um problema jurídico — é um problema de rotina montada com antecedência. Seis mecanismos fazem essa diferença.

Um responsável pelo tratamento de dados nomeado antes do problema. Quando o incidente aparece, alguém já precisa ter autoridade formal para decidir a comunicação e falar com a autoridade — não é hora de descobrir quem cuida disso.

Um mapa de onde o dado pessoal está guardado. Cadastro de cliente, folha de pagamento, prontuário, contrato — cada um mora num sistema diferente. Sem esse mapa, "quantos dados foram afetados" vira estimativa, e estimativa não é o que a comunicação exige.

Um registro de acesso que permita reconstruir o que aconteceu. Não é o chamado de suporte técnico — é a trilha de quem entrou em qual sistema com dado pessoal e quando. Sem ela, a data do conhecimento do incidente é sempre "não sabemos ao certo".

Alguém com a tarefa explícita de revisar esse acesso todos os dias. Um mapa e um registro que ninguém olha só servem depois que o estrago já apareceu em outro lugar — o valor deles está em detectar o desvio antes.

Um roteiro de quem avisa quem nas primeiras horas. Quem descobre o problema, quem decide se é incidente, quem aciona o responsável pelo tratamento de dados e quem prepara o aviso às pessoas afetadas — definido com nome, não com "a gente vê na hora".

Um rascunho pronto do que precisa constar na comunicação. Natureza do incidente, categorias de dado, riscos, medidas adotadas — o que a norma exige de conteúdo pode ser preparado como modelo antes de qualquer coisa acontecer, e só precisa ser preenchido, não escrito do zero sob o prazo correndo.

É assim que a Skills IT trabalha com o tema: o registro de acesso aos sistemas com dado pessoal fica disponível para consulta rápida, e o inventário de onde esse dado está hospedado é mantido atualizado — para que a reconstrução do que aconteceu não dependa de memória de ninguém.

O que a empresa ganha em não improvisar

O ganho mais direto é cumprir o prazo — mas o ganho maior aparece antes disso, na hora em que a empresa ainda está decidindo o que dizer. Uma empresa com registro chega à conversa com a autoridade sabendo o alcance do problema; uma empresa sem registro chega admitindo que não sabe, o que pesa contra ela num modelo de fiscalização que considera a cooperação.

Há também um ganho com quem foi afetado. Avisar rápido e com informação concreta — o que aconteceu, o que foi exposto, o que a empresa está fazendo — é diferente de um aviso genérico semanas depois, quando o cliente já soube por outro canal. A segunda situação custa confiança que o primeiro aviso, bem-feito, preserva.

E há um ganho interno, menos falado: uma empresa que sabe onde o dado pessoal está guardado também sabe onde ele não precisa mais estar. Cadastro antigo de cliente que não compra há anos, planilha duplicada em três computadores, backup de um sistema descontinuado — tudo isso é dado que, se vazar, entra na conta do incidente sem trazer valor nenhum para a operação.

Um roteiro para começar

Antes de escrever uma política nova, vale reunir a liderança e responder a estas perguntas com calma — sem o prazo correndo.

Quem, hoje, teria autoridade para decidir que houve um incidente com dado pessoal? Se a resposta não tem um nome, esse é o primeiro problema a resolver, antes de qualquer outro.

Onde estão guardados os dados de clientes e funcionários, e quem tem acesso a cada lugar? Vale listar por sistema, não por departamento — um mesmo cadastro costuma estar em mais de um lugar.

Existe algum registro de quem acessou o quê, e por quanto tempo ele fica guardado? Sem essa trilha, a data do conhecimento do incidente — item obrigatório na comunicação — sempre vai ser uma estimativa.

Se algo acontecesse hoje, quem avisaria quem, e em que ordem, nas primeiras horas? Escrever essa ordem num parágrafo já reduz boa parte da confusão do primeiro dia.

Existe um modelo pronto do que precisa constar no aviso à autoridade e aos titulares? Não precisa estar perfeito — precisa existir, para não ser escrito do zero sob o relógio correndo.