Nas primeiras horas de um incidente de segurança, você não consegue montar um panorama técnico completo do que aconteceu. Sua equipe ainda pode estar tentando entender qual conta foi comprometida, quais dados foram acessados, até onde o invasor chegou ou se o incidente ainda está ativo.
Paralelamente à investigação, a pressão para agir começa imediatamente. Os funcionários ouvem fragmentos e precisam saber o que fazer. Enquanto isso, os clientes podem notar interrupção do serviço, atividade suspeita ou pedidos incomuns de redefinição de senha. Parceiros comerciais podem perguntar se seus sistemas ou dados estão envolvidos, e a liderança precisa decidir quem fala, o que pode ser confirmado e quando o silêncio se torna um risco por si só.
A comunicação de incidentes de segurança é difícil porque uma empresa precisa ser transparente antes de ter todas as respostas, mas informada o suficiente para não fazer suposições. Comunicados enviados cedo demais podem gerar confusão, mas, se enviados tarde demais, podem prejudicar a confiança, atrasar ações de proteção e levantar questões regulatórias.
É improvável que pequenas e médias empresas tenham criado ou treinado seu plano de resposta a incidentes, e isso pode causar um caos ainda maior. Mesmo em empresas maiores com um plano, as etapas técnicas podem estar documentadas: conter o incidente, redefinir acessos, preservar evidências, restaurar sistemas. A comunicação pode acabar deixada para depois, até que, de repente, o incidente se agrava ou muda.
Parte da preparação para um incidente é saber quem precisa ouvir você, o que essas pessoas precisam saber, quem aprova a mensagem e como comunicar os fatos com clareza enquanto a investigação ainda está em andamento.
O planejamento de comunicação faz parte da resposta a incidentes
A estrutura de duas frentes para a sua resposta
Comece pelo público, não pelo anúncio
Como notificar os clientes sobre uma violação
Quando notificar os órgãos reguladores
Prepare mensagens antes de precisar delas
Como o Proton Pass for Business pode ajudar
O planejamento de comunicação faz parte da resposta a incidentes
A resposta a incidentes costuma ser descrita como um processo técnico, mas um incidente real rapidamente se torna interdepartamental. As equipes de TI podem conter a ameaça, mas liderança, jurídico, suporte ao cliente, RH, comunicação e operações precisam saber o que está acontecendo e o que podem dizer.
A orientação da NCSC sobre comunicação eficaz em um incidente cibernético(nova janela) — boa prática geral que se aplica muito além do Reino Unido — deixa esse ponto claro: as organizações costumam priorizar a resposta técnica e deixar a comunicação em segundo plano, mesmo que a comunicação defina como funcionários, clientes, partes interessadas e a mídia percebem a organização durante uma crise.
Nem todo incidente exige um pronunciamento público. Mas a empresa deve saber de antemão quem decide o que comunicar, quem aprova mensagens externas, quem fala com os clientes e quem cuida do reporte aos órgãos reguladores.
Um bom plano de resposta a violações de dados precisa incluir uma camada de comunicação. Isso deve incluir detalhes práticos:
- Listas de contatos
- Modelos de rascunho
- Fluxos de aprovação
- Análise jurídica
- Pontos de discussão para o suporte ao cliente
- Responsabilidades de notificação aos órgãos reguladores
- Registros do que foi enviado, quando e para quem.
A estrutura de duas frentes para a sua resposta
A resposta a incidentes precisa de duas frentes: a resposta técnica e a resposta de comunicação. Elas correm em paralelo, e o líder do incidente/responsável pela resposta faz a conexão entre ambas.
| Frente esquerda: resposta técnica | Frente direita: resposta de comunicação |
| Conter o incidente | Atualizar a equipe interna |
| Proteger as contas afetadas | Notificar clientes ou parceiros afetados |
| Preservar evidências | Avaliar a notificação aos órgãos reguladores |
| Restaurar sistemas | Manter as mensagens consistentes conforme os fatos mudam |
Isso permite estruturar a resposta e garantir que a colaboração continue à medida que os membros da equipe assumem tarefas diferentes.
Comece pelo público, não pelo anúncio
A comunicação de incidentes de segurança falha quando uma única mensagem tenta atender a todos. Funcionários, clientes, parceiros e órgãos reguladores precisam de níveis diferentes de detalhe porque têm decisões diferentes a tomar.
Sua equipe interna precisa de clareza primeiro
Ela não precisa de cada detalhe — especialmente enquanto a investigação está em andamento —, mas precisa de clareza sobre o que está confirmado, o que fazer agora e quem lidera a resposta. Isso significa saber quais sistemas ou contas evitar, que ação tomar imediatamente e quais perguntas ainda estão em aberto.
Os funcionários também precisam saber o que não fazer. Por exemplo:
- Não discutir o incidente publicamente
- Não redefinir credenciais fora do processo aprovado
- Não entrar em contato com clientes com explicações improvisadas
- Não encaminhar mensagens suspeitas sem orientação.
Clientes e parceiros precisam saber como são afetados
Eles querem saber se seus dados, acessos, pagamentos, serviços ou operações foram afetados. Uma boa notificação ao cliente deve explicar:
- O que se sabe
- Que tipo de dados podem estar envolvidos
- O que a empresa está fazendo
- O que os clientes devem fazer agora, se houver algo a fazer
- Onde é possível obter atualizações.
O tom deve ser simples e direto. O cliente também não precisa de detalhes forenses, precisa apenas de informações suficientes para se proteger.
Os reguladores precisam de um registro factual
A notificação de violação do GDPR à autoridade supervisora competente (a ICO(nova janela) no Reino Unido, a autoridade nacional de proteção de dados em cada estado-membro da UE) não é uma mensagem de marketing nem uma nota de tranquilização ao cliente. Em vez disso, precisa ser um registro factual do que aconteceu, quem foi afetado e o que você está fazendo a respeito. Abordamos exatamente o que incluir na seção sobre como notificar os reguladores abaixo.
O que comunicar internamente
Os colaboradores fazem parte da resposta, mesmo quando não estão na equipe de resposta ao incidente. Uma equipe confusa pode acidentalmente criar mais ruído, compartilhar informações imprecisas ou atrasar a contenção. Por outro lado, uma equipe bem informada pode ajudar a proteger contas, direcionar clientes para o canal certo e evitar que a especulação cresça.
Um anúncio interno de incidente de segurança deve abordar:
- Um resumo claro do que foi confirmado até agora, em linguagem simples
- Quais sistemas, contas, equipes ou dados podem estar afetados
- O que a empresa está fazendo agora
- O que os colaboradores devem fazer imediatamente
- Quem está autorizado a se comunicar externamente
- Onde as atualizações serão publicadas
- Como relatar atividades suspeitas relacionadas
Há aspectos que não devem ser incluídos: vetores de ataque, análise de causa raiz e vulnerabilidades específicas geralmente não são compartilhados internamente enquanto um incidente está em andamento, e muitas vezes nem depois, já que esses detalhes podem ajudar outros atacantes, criar exposição legal ou revelar lacunas que ainda não foram fechadas.
A primeira mensagem interna não precisa responder a todas as perguntas, precisa criar ordem. Por exemplo, os colaboradores podem precisar redefinir senhas apenas por meio de um processo aprovado, evitar usar um sistema específico, preservar e-mails suspeitos ou parar de usar credenciais compartilhadas até que a equipe de resposta conclua a análise.
Avaliar os controles de acesso existentes com base nas melhores práticas para gerenciamento de senhas também é essencial. Durante um incidente, o compartilhamento de credenciais desatualizado ou informal pode dificultar a compreensão do que foi exposto.
Os guias da Proton sobre proteção contra violações de dados e prevenção de violações de dados para empresas explicam como os controles em camadas reduzem a exposição antes que uma violação ocorra. O gerenciamento seguro de credenciais é uma dessas camadas, pois ajuda a empresa a saber quais contas existem, quem pode acessá-las e o que precisa ser alterado rapidamente.
Como notificar os clientes sobre uma violação
Uma notificação de violação de dados aos clientes é mais difícil porque tem peso reputacional e legal. As pessoas podem estar preocupadas com roubo de identidade, invasão de conta, fraude financeira ou exposição de informações privadas. Também podem ficar frustradas porque a empresa não conseguiu prevenir o incidente.
Uma boa mensagem ao cliente deve ser honesta sem ser alarmante. Deve evitar jargão técnico, mas ser clara. Os clientes precisam entender quais dados estavam envolvidos, que risco isso cria e o que devem fazer em seguida.
Uma estrutura útil é:
- O que aconteceu, com um nível de detalhe apropriado para os clientes
- Quando a empresa tomou conhecimento
- Quais informações ou serviços podem estar afetados
- Quais medidas a empresa tomou
- O que os clientes devem fazer agora
- Como a empresa fornecerá atualizações
- Com quem os clientes podem entrar em contato em caso de dúvidas
Quando a investigação ainda estiver em andamento, isso deve ser divulgado. Precisão e transparência ajudam a restaurar a confiança. Ser aberto sobre o impacto não exige divulgar detalhes técnicos que ajudariam alguém a repetir o ataque.
Para incidentes graves, os clientes podem precisar de instruções práticas: alterar uma senha, ativar o MFA, ficar atento a e-mails de phishing, entrar em contato com o banco e ignorar mensagens que afirmam ser da empresa, a menos que cheguem por um canal oficial. A notificação deve tornar essas etapas fáceis de entender.
Quando e como notificar órgãos reguladores
Nem todo incidente de segurança precisa ser reportado às autoridades supervisoras. Uma violação notificável sob o GDPR do Reino Unido e da UE depende de se uma violação de dados pessoais provavelmente resultará em risco aos direitos e liberdades das pessoas.
O guia sobre violações de dados pessoais(nova janela) da ICO reflete um requisito comum ao GDPR do Reino Unido e da UE: as organizações devem reportar uma violação notificável sem atraso indevido e no prazo máximo de 72 horas após tomarem conhecimento dela. Um relatório tardio precisa de justificativas para o atraso.
Esse prazo de 72 horas pode gerar pressão, especialmente quando a investigação ainda está incompleta. O GDPR reconhece que as organizações podem não ter todos os detalhes nas primeiras 72 horas, então as informações podem ser fornecidas em fases, desde que atualizações adicionais sejam dadas sem atraso indevido.
Uma notificação à autoridade supervisora competente (a ICO no Reino Unido, ou a autoridade nacional de proteção de dados na UE) geralmente deve incluir:
- A natureza da violação de dados pessoais
- As categorias e o número aproximado de indivíduos afetados
- As categorias e o número aproximado de registros de dados pessoais afetados
- O nome e os detalhes de contato do DPO ou de outro ponto de contato
- As prováveis consequências da violação
- As medidas tomadas ou propostas para lidar com ela
A ICO também oferece uma página central para reportar uma violação(nova janela) e direcionar as organizações ao processo de reporte apropriado.
Para os indivíduos afetados, o limite é diferente. Quando uma violação de dados pessoais provavelmente resultar em alto risco aos direitos e liberdades das pessoas, elas devem ser informadas sem atraso indevido. Essa é uma situação em que as equipes jurídica, de privacidade e de liderança devem se envolver desde o início, mesmo em uma pequena empresa.
Prepare as mensagens antes de precisar delas
O pior momento para elaborar um processo de comunicação é durante um incidente. Não é útil emitir declarações ou orientações que precisem ser atualizadas e alteradas.
É por isso que é útil preparar a estrutura das suas mensagens antes de precisar delas. Não o texto final, porque cada incidente será diferente, mas a estrutura: quem precisa aprovar a mensagem, quais detalhes devem ser incluídos, onde as atualizações serão registradas e quem é responsável por cada público.
Um kit de comunicação simples é suficiente para tornar a primeira hora menos caótica. Ele pode incluir:
- Um modelo de anúncio de incidente interno
- Um modelo de notificação ao cliente
- Um modelo de atualização para parceiros ou fornecedores
- Pontos de discussão para o suporte ao cliente
- Uma lista de verificação de notificação à autoridade supervisora
- Lista de porta-vozes aprovados
- Contatos de escalonamento para as áreas jurídica, de TI, privacidade, liderança e comunicação
- Um local para registrar todas as atualizações e decisões
A preparação dá à equipe um ponto de partida seguro quando velocidade e precisão são igualmente importantes. Um modelo pronto deixa mais atenção para os fatos do incidente: o que aconteceu, quem foi afetado, o que já foi feito e o que as pessoas precisam fazer em seguida.
Como o Proton Pass for Business pode ajudar
A comunicação de incidentes de segurança depende de fatos. Quanto mais claramente uma empresa gerencia o acesso antes de um incidente, mais fácil é explicar o que aconteceu, o que pode ter sido afetado e o que foi alterado.
Um gerenciador de senhas para empresas como o Proton Pass for Business ajuda as equipes a reduzir a exposição relacionada a credenciais. Os funcionários podem gerar senhas fortes, armazená-las em cofres de senhas criptografados, usar o preenchimento automático, compartilhar credenciais com segurança, gerenciar passkeys e usar a autenticação de dois fatores integrada. Os administradores podem aplicar políticas de senha, revisar registros de atividade, gerenciar o acesso com controles baseados em funções e oferecer suporte ao provisionamento por meio de integrações SCIM e SSO.
Durante um incidente, esses recursos podem ajudar as empresas a agir com mais confiança. Se uma conta de funcionário for comprometida, os administradores podem revisar o acesso, identificar credenciais compartilhadas que talvez precisem ser trocadas, reforçar a autenticação e reduzir a dependência de senhas copiadas por chat ou planilhas.
Esteja pronto para responder antes que uma violação aconteça com um gerenciador de senhas para empresas.
