Uma planilha enviada ao destinatário errado, um token exposto, uma automação que publica dados em log ou um acesso indevido ao CRM podem constituir incidentes relevantes. A primeira reação não deve ser esconder, apagar evidência ou disparar uma mensagem genérica para todos.
A ANPD define incidente de segurança com dados pessoais como evento adverso confirmado que compromete confidencialidade, integridade, disponibilidade ou autenticidade. A página oficial também explica que a comunicação depende da confirmação, do envolvimento de dados pessoais e da possibilidade de risco ou dano relevante.
Este guia organiza resposta operacional. Ele não substitui avaliação jurídica e de segurança do caso concreto.
Prepare antes do incidente
Sem inventário, a equipe perde tempo descobrindo sistemas durante a crise. Mapeie formulários, CRM, planilhas, caixas de e-mail, automações, pixels, integrações, backups e fornecedores.
Para cada ativo, registre:
- owner de negócio e técnico;
- categorias de dados;
- origem e destinos;
- perfis com acesso;
- logs disponíveis;
- fornecedor e contato de emergência;
- retenção;
- procedimento de contenção;
- dependências de receita.
Mantenha o plano fora do sistema que pode ficar indisponível. Defina canal alternativo e lista de contatos.
Confirme o evento sem atrasar contenção
Alerta não é automaticamente incidente confirmado, mas alguns sinais exigem ação imediata. Preserve logs, horários, mensagens, identificadores e alterações. Não edite o ambiente de forma que destrua a trilha.
Ao mesmo tempo, contenha o risco: revogue token, encerre sessão, bloqueie exportação, suspenda integração ou isole conta comprometida. Escolha medidas reversíveis quando a investigação ainda está em curso.
Registre cada ação e responsável. A linha do tempo ajuda a entender alcance e demonstrar resposta.
Não baixe bases para computadores pessoais durante a análise. Centralize evidências com controle de acesso.
Classifique o que foi afetado
Responda com fatos:
- quais sistemas e contas participaram;
- quando o evento começou e terminou;
- quais categorias de dados estavam envolvidas;
- quantas pessoas podem ter sido afetadas, se for possível estimar;
- se houve acesso, cópia, alteração, perda ou indisponibilidade;
- quem recebeu ou pode ter recebido os dados;
- quais controles falharam;
- quais medidas já foram adotadas.
Dados de autenticação, financeiros, sensíveis, de crianças ou adolescentes e tratamento em larga escala merecem atenção específica na avaliação oficial da ANPD. Não presuma baixo risco apenas porque o cadastro era “de marketing”.
Observações livres do CRM podem conter informação mais sensível que os campos estruturados.
Diferencie controlador e operador
A responsabilidade de comunicar à ANPD e aos titulares, quando aplicável, é do controlador. Fornecedores e agências podem atuar como operadores e precisam fornecer informação rapidamente conforme contrato e instrução.
Não espere a discussão contratual terminar para conter o evento. Ative o canal de incidente, peça fatos e registre posições.
Se múltiplas organizações tomam decisões sobre o tratamento, a análise exige cuidado. O papel depende da atividade concreta. Consulte o mapa de fluxo e os contratos, mas não trate o rótulo contratual como resposta automática.
Avalie risco e obrigação de comunicação
A página da ANPD apresenta critérios cumulativos para comunicação: ocorrência confirmada, dados pessoais sujeitos à LGPD e possibilidade de risco ou dano relevante. A lista de regulamentações vigentes aponta a Resolução CD/ANPD nº 15/2024, que regula o processo.
A avaliação deve envolver responsável por privacidade, segurança e jurídico conforme a estrutura da empresa. Documente decisão e evidência, inclusive quando a conclusão for não comunicar.
Não use um score improvisado como substituto. Considere natureza dos dados, contexto, volume, público, capacidade de identificar pessoas, consequências e medidas de mitigação.
Comunique com clareza quando necessário
Uma comunicação útil informa o que ocorreu, quais dados foram afetados, riscos possíveis, medidas tomadas e ações recomendadas. Evite linguagem vaga como “por excesso de cautela” se ela esconde fatos essenciais.
Não atribua culpa antes da apuração. Não prometa que “nenhum dado foi usado” sem evidência. Diferencie acesso possível, acesso confirmado e uso comprovado.
Escolha canal que alcance os titulares sem expor mais dados. Um e-mail em massa com destinatários visíveis pode criar novo incidente.
Centralize perguntas e mantenha mensagens consistentes entre atendimento, vendas, marketing e liderança.
Preserve a operação comercial com segurança
Conter não significa desligar tudo sem análise. Identifique quais funções podem continuar com risco aceitável e quais precisam parar.
Se o formulário foi comprometido, substitua por canal temporário controlado e explique a mudança. Se o CRM está indisponível, use procedimento de contingência com coleta mínima e prazo curto. Não crie uma planilha aberta para “não perder leads”.
Registre dados de contingência em ambiente aprovado e faça reconciliação quando o sistema voltar. Depois, elimine cópias temporárias conforme política.
Priorize serviço ao cliente, integridade e privacidade. A pressão por receita não justifica ampliar exposição.
Investigue integrações e tokens
O CRM raramente opera sozinho. Revise webhooks, apps conectados, contas de serviço, chaves de API, gerenciadores de tags e exportações agendadas.
Rotacionar uma senha pode não invalidar tokens. Remover usuário pode não eliminar app autorizado. Verifique a documentação e confirme por teste.
Analise logs em todos os destinos. Um payload pode ter sido recebido por uma automação, rejeitado por outra e gravado em ferramenta de monitoramento.
Peça ao fornecedor linha do tempo, escopo, indicadores, ações e confirmação de contenção.
Corrija a causa, não apenas o sintoma
Depois da contenção, identifique causa raiz e condições contribuintes. Exemplos:
- acesso excessivo;
- credencial compartilhada;
- ausência de MFA;
- dado pessoal em URL;
- webhook sem autenticação;
- log sem mascaramento;
- fornecedor sem canal de incidente;
- exportação sem owner;
- retenção indefinida;
- offboarding incompleto.
Defina ação, responsável, prazo e evidência de conclusão. Correção declarada sem teste não fecha o incidente.
Atualize inventário, contrato, treinamento e monitoramento. Se o processo permitiu a falha, trocar apenas a senha deixa o risco estrutural.
Faça uma retrospectiva sem caça às bruxas
Reúna as áreas e reconstrua a linha do tempo. Pergunte o que ajudou, o que atrasou e quais sinais foram ignorados.
Meça tempos de detecção, contenção, avaliação e restauração, mas use os dados para melhorar o sistema. Incentivar ocultação destrói a capacidade de resposta.
Compartilhe somente o necessário. A retrospectiva não deve replicar dados pessoais ou evidências sensíveis em apresentações amplas.
Teste o runbook depois das correções. Um exercício de mesa confirma se contatos, permissões e alternativas funcionam.
Checklist de primeira hora
Quando um evento surgir:
- Abra registro com horário e responsável.
- Preserve evidências.
- Contenha acesso ou fluxo suspeito.
- Acione segurança, privacidade e liderança definida.
- Identifique sistemas, dados e pessoas potencialmente afetadas.
- Contate fornecedores pelo canal formal.
- Proteja continuidade sem criar cópias inseguras.
- Evite comunicação externa antes de fatos mínimos, sem atrasar obrigações.
Esse checklist não encerra a análise; ele impede improviso inicial.
Próximo passo
Simule um token do formulário exposto e veja se a equipe consegue revogar acesso, localizar destinos e avaliar dados sem consultar a pessoa que construiu a automação. Cada dúvida vira item do plano.
Para estruturar integrações e continuidade, conheça as soluções de automação da AgenciAR. Leia também o checklist de governança de fornecedores de martech.
