Plano de resposta a incidentes: as decisões que precisam vir antes do ataque

Quase toda empresa que passa por um ataque descobre a mesma coisa nas primeiras horas: o problema técnico é só metade do problema. A outra metade é gente perguntando quem autoriza desligar o servidor, quem tem o telefone da hospedagem, se é para avisar os clientes e quem assina o comunicado. Enquanto essas perguntas circulam, o relógio corre.

Os guias mais conhecidos sobre o tema vêm de fornecedores globais e descrevem fases e componentes. Este artigo parte de outro lugar: da revisão que o NIST publicou em 2025 e da regra brasileira de comunicação de incidentes. A partir delas, mostra quais decisões precisam estar escritas antes do ataque, sobretudo na empresa média que tem TI, site e sistemas nas mãos de terceiros.

O que é um plano de resposta a incidentes?

Plano de resposta a incidentes é o documento que diz o que a empresa faz quando a segurança de um sistema ou de um dado falha. Ele cobre quem identifica e declara o incidente, quem toma as decisões de alto impacto, como o problema é contido, quem é avisado e em que ordem, e como a operação volta ao normal.

Incidente, aqui, é mais amplo do que "fomos hackeados". Entram ransomware que criptografa arquivos, conta de e-mail invadida que passa a mandar boletos falsos, site derrubado, planilha de clientes exposta por engano, notebook furtado com dados sem proteção. A Resolução CD/ANPD nº 15/2024 define incidente de segurança, para fins de dados pessoais, como qualquer evento adverso confirmado que viole a confidencialidade, a integridade, a disponibilidade ou a autenticidade desses dados.

O plano não é um manual de ferramentas. Um bom plano cabe em poucas páginas e responde, principalmente, a perguntas de autoridade e contato: quem pode decidir o quê, e como encontrar essa pessoa às três da manhã de um sábado.

Para que serve o plano de resposta a incidentes?

A função do plano é transformar uma situação de pânico em uma sequência de tarefas já combinadas. Sem ele, cada decisão vira uma reunião; com ele, a equipe executa o que foi decidido com calma, semanas antes.

• Reduzir o tempo de reação: ninguém procura telefone, senha de painel ou contrato no meio da crise.
• Limitar o dano: a contenção começa quando alguém com autoridade decide, e não quando todos concordam.
• Preservar evidência: registros e máquinas afetadas são tratados de modo a permitir saber depois o que aconteceu.
• Cumprir prazos legais: a comunicação à ANPD e aos titulares tem regra e prazo, e o plano já traz o caminho.
• Proteger a reputação: clientes, SAC e imprensa recebem a mesma versão, no tempo certo.

Repare que só um desses itens é estritamente técnico. Esse é o ponto central deste artigo: o plano existe para que as decisões de gestão não travem a parte técnica.

O que mudou com a revisão do NIST em 2025?

Durante mais de uma década, a principal referência mundial no assunto foi o guia SP 800-61 do NIST, o instituto de padrões dos Estados Unidos, na revisão de 2012. Ele descrevia a resposta como um ciclo de quatro fases: preparação; detecção e análise; contenção, erradicação e recuperação; e atividade pós-incidente. Muitos materiais em português ainda ensinam esse ciclo.

O motivo da mudança está escrito no próprio documento novo. Segundo o NIST, quando o guia anterior foi feito os incidentes eram relativamente raros, de escopo estreito, e a resposta e a recuperação costumavam terminar em um ou dois dias. Hoje os incidentes são frequentes, causam muito mais dano, e a recuperação muitas vezes leva semanas ou meses.

Na prática, isso muda o que se espera de um plano. Se a recuperação pode levar semanas, o plano precisa prever quem decide durante semanas, como a empresa opera enquanto isso e como a comunicação se mantém consistente do primeiro ao último dia. A Revisão 3 também lista papéis que vão muito além do técnico: liderança, jurídico, relações com a imprensa, recursos humanos, donos dos sistemas e fornecedores.

Qual a diferença entre plano, política e playbook?

Os três termos aparecem juntos e costumam ser confundidos. A Revisão 3 do NIST trata a política como o documento que governa a resposta, o plano e os procedimentos como o que dela decorre, e os playbooks como uma forma prática de escrever procedimentos: passos acionáveis para cenários específicos.

Elaborado pela Alliance Comunicação a partir da seção 2.3 da NIST SP 800-61 Rev. 3.

Para a empresa média, o caminho mais útil costuma ser um documento único: uma página de política, o plano com as decisões e os contatos, e dois ou três playbooks para os cenários mais prováveis do seu negócio. O próprio NIST reconhece que é impossível ter procedimento detalhado para toda situação e sugere documentar os tipos de incidente mais comuns.

Quais decisões precisam estar tomadas antes do ataque?

Este é o coração do plano. Cada item abaixo é uma decisão que, se ficar para o dia do incidente, vira discussão justamente quando ninguém tem tempo para discutir.

1. Quem pode tirar um sistema do ar

Isolar o servidor, suspender a loja virtual ou bloquear o acesso remoto custa dinheiro na hora. Por isso ninguém quer decidir sozinho. A Revisão 3 do NIST cita expressamente, entre os elementos de uma política, os papéis com autoridade para confiscar, desconectar ou desligar ativos de tecnologia, e diz que a liderança pode ter a decisão em ações de alto impacto, como desligar ou reconstruir serviços críticos. Escreva o nome de quem decide, de quem substitui e qual critério dispensa consulta.

2. Quem declara que é um incidente

Um alerta estranho não é, ainda, um incidente. Alguém precisa ter o papel de olhar os sinais e dizer "agora é incidente, o plano está valendo". Sem essa pessoa, a empresa oscila entre ignorar o problema e acionar todo mundo por qualquer coisa. Defina quem declara e com base em que critérios, em linguagem simples.

3. Quem fala com a ANPD e com que documento

A comunicação à ANPD é feita pelo controlador, por meio do encarregado ou de um representante constituído, e os documentos que comprovam esse vínculo devem ir junto, dentro do prazo. Se a empresa ainda não designou encarregado ou não tem procuração pronta, isso vira uma tarefa de cartório no meio da crise. Resolva antes.

4. Quem fala com clientes, SAC e imprensa

Uma pessoa aprova, uma versão circula. O plano define quem redige, quem aprova e por quais canais o aviso sai. A comunicação aos titulares tem conteúdo mínimo definido pela ANPD, e o artigo sobre o aviso de vazamento que a LGPD manda publicar detalha como escrevê-lo sem piorar a crise. Aqui, o que importa é que o responsável já esteja nomeado.

5. Quais telefones precisam estar fora do computador

Hospedagem do site, registro do domínio, provedor de e-mail, empresa de TI, fornecedor do ERP, banco, seguradora, advogado, agência de comunicação. Se a lista está numa pasta da rede que foi criptografada, ela não existe. Mantenha uma cópia impressa e outra num lugar que não dependa das contas da empresa.

6. Por onde a equipe conversa se o e-mail cair

Se a invasão começou pela conta de e-mail, discutir a resposta por e-mail é avisar o invasor. Combine antes um canal alternativo, com os participantes já incluídos, e uma regra simples: durante o incidente, decisões só valem se passarem por ele.

Elaborado pela Alliance Comunicação.

O que a LGPD e a ANPD exigem do plano?

A lei não manda ter um documento chamado "plano de resposta a incidentes". Mas a regra de comunicação é tão apertada que, na prática, sem um plano ela dificilmente é cumprida. O ponto de partida é o prazo.

Lendo a resolução inteira, aparecem os detalhes que mudam o desenho do plano:

• Quando o prazo começa: a contagem parte do conhecimento, pelo controlador, de que o incidente afetou dados pessoais (art. 6º, § 1º). Não do fim da investigação.
• Quando comunicar: a obrigação vale para incidente que possa acarretar risco ou dano relevante aos titulares. A resolução lista critérios, como dados sensíveis, de crianças, adolescentes ou idosos, financeiros, de autenticação em sistemas, protegidos por sigilo ou em larga escala (art. 5º).
• O que informar: são doze itens na comunicação à ANPD, entre eles natureza e categoria dos dados, número de titulares, medidas de segurança antes e depois, riscos, medidas de mitigação e a causa, se identificada (art. 6º, § 2º).
• Complemento: as informações podem ser complementadas, de maneira fundamentada, em até vinte dias úteis contados da comunicação (art. 6º, § 3º).
• Quem assina: o encarregado, com documento de vínculo, ou um representante com poderes, e esses documentos vão junto, no mesmo prazo (art. 6º, §§ 5º e 6º).
• Pequeno porte: para agentes de tratamento de pequeno porte, os prazos de comunicação contam em dobro (art. 6º, § 8º, e art. 9º, § 6º).
• Registro: todo incidente, inclusive o que não foi comunicado, precisa ser registrado e guardado por no mínimo cinco anos, com a avaliação de risco e, se for o caso, os motivos de não ter comunicado (art. 10).

O último item é o mais esquecido. A empresa que decide, corretamente, que um incidente não exigia comunicação precisa ter registrado por que chegou a essa conclusão. O plano deve trazer um modelo desse registro, para que ele seja preenchido na hora e não reconstruído de memória meses depois. Se a empresa ainda não sabe quais dados pessoais trata e onde estão, vale começar pelo trabalho de adequação à LGPD, porque sem esse mapa ninguém responde em três dias quantos titulares foram afetados.

Três dias úteis não dão tempo de descobrir quem é o encarregado, achar a procuração e combinar quem assina o aviso. Dão tempo de executar o que já foi combinado.

Como montar o plano quando TI, site e sistemas são terceirizados?

É o cenário mais comum na empresa média: o site está numa hospedagem, o e-mail num provedor de nuvem, o ERP num fornecedor, a manutenção dos computadores numa empresa de TI e as redes sociais numa agência. Ninguém dentro de casa tem todas as senhas, e cada fornecedor enxerga só a sua parte.

A Revisão 3 do NIST trata esse arranjo como responsabilidade compartilhada: a empresa transfere parte das tarefas ao fornecedor, mas essa divisão precisa estar clara em contrato, incluindo fluxos de informação, coordenação e autoridade para agir em nome da empresa. O documento também lembra que o fornecedor costuma ter acesso privilegiado aos sistemas, então o risco de o próprio fornecedor ser comprometido precisa entrar na conta.

Na prática, o plano de quem terceiriza responde a quatro perguntas para cada fornecedor:

1. Ele tem obrigação contratual de avisar a empresa se detectar algo, e em quanto tempo?
2. Ele pode desligar ou isolar um serviço por conta própria, ou precisa de autorização? De quem?
3. Ele guarda os registros de acesso necessários para saber o que aconteceu, e por quanto tempo?
4. Quem, do lado dele, atende fora do horário comercial, e por qual telefone?

Se alguma resposta for "não sei", a lacuna está no contrato, não no plano. Vale lembrar que, pela LGPD, a obrigação de comunicar o incidente à ANPD e aos titulares é do controlador. Mesmo que o vazamento tenha começado no fornecedor, quem responde perante a autoridade é a sua empresa.

O que um modelo de plano de resposta a incidentes deve conter?

Quem busca "modelo" ou "exemplo" geralmente quer um esqueleto para preencher. Um modelo enxuto, adequado a empresas que não têm equipe própria de segurança, pode seguir esta estrutura:

1. Escopo e compromisso: uma página dizendo a que sistemas e dados o plano se aplica e quem na direção responde por ele.
2. Definições: o que a empresa chama de evento, de incidente e de incidente com dado pessoal.
3. Papéis e autoridades: quem declara, quem decide desligar, quem coordena, quem comunica, com titular e substituto.
4. Contatos de emergência: equipe, fornecedores, encarregado, jurídico, seguradora e agência, com telefone.
5. Canal alternativo: onde a equipe conversa se e-mail e contas corporativas estiverem comprometidos.
6. Critérios de gravidade: como diferenciar o que é rotina do que aciona a direção e do que pode exigir comunicação à ANPD.
7. Playbooks: dois ou três roteiros para os cenários mais prováveis do seu negócio.
8. Comunicação: modelos de aviso ao titular, mensagem-base para clientes e imprensa e o caminho da comunicação à ANPD.
9. Registro: formulário para registrar cada incidente, inclusive os não comunicados, com a avaliação de risco.
10. Revisão: quando o plano é testado e atualizado, e quem faz isso.

Modelos genéricos baixados da internet costumam falhar no item 4. Eles trazem o campo "contato" vazio, e a lista nunca é preenchida. O valor do plano está justamente no que é específico da sua empresa.

Quais são as etapas da resposta a incidentes?

Com o plano pronto, a resposta em si segue uma sequência que combina o modelo do NIST com a regra brasileira. Ela não é um ciclo fechado: várias etapas acontecem ao mesmo tempo, e a recuperação pode se estender por semanas.

1. Detectar e declarar: alguém percebe o sinal, o responsável avalia pelos critérios e declara o incidente.
2. Conter: isolar o que foi afetado, conforme a autoridade definida, preservando registros e evidências.
3. Avaliar dados pessoais: verificar se houve dado pessoal afetado e se há risco relevante; a partir dessa ciência, conta o prazo da ANPD.
4. Comunicar: direção, fornecedores, ANPD e titulares quando aplicável, e clientes e imprensa com a mesma versão.
5. Erradicar e recuperar: remover a causa, restaurar a partir de cópias íntegras e verificar os sistemas antes de recolocá-los em produção.
6. Encerrar e aprender: declarar o fim da recuperação, completar o registro e escrever o relatório pós-incidente com as lições.

A etapa 5 depende de algo preparado muito antes: uma cópia dos dados que o ataque não alcançou. O NIST recomenda verificar a integridade de backups e outros recursos de restauração antes de usá-los. O artigo sobre backup em nuvem e a cópia que o ransomware também alcança mostra por que pasta sincronizada não basta.

Quais os erros mais comuns em planos de resposta?

• Plano só técnico: descreve ferramentas e comandos, mas não diz quem decide nem quem comunica.
• Contatos desatualizados: o fornecedor mudou, o responsável saiu da empresa e ninguém atualizou a lista.
• Documento guardado onde o ataque chega: o único arquivo do plano fica na rede que foi criptografada.
• Esperar a investigação terminar para comunicar: o prazo da ANPD corre a partir da ciência de que dados pessoais foram afetados, e a resolução admite complemento posterior.
• Desligar tudo no susto: sem critério, apaga evidências e prolonga a parada mais do que o necessário.
• Versões diferentes para cada público: o cliente lê uma coisa, o SAC fala outra, a imprensa publica uma terceira.
• Nunca testar: o plano parece completo até a primeira simulação mostrar o que falta.

Boa parte desses erros não tem a ver com tecnologia. É por isso que o post-pilar sobre segurança da informação na empresa média insiste que o ataque raramente escolhe a empresa: ele encontra a que deixou a porta aberta e, depois, a que demorou a decidir.

Como testar se o plano funciona?

O NIST trata exercícios e testes como fonte de melhoria e recomenda fazê-los também com fornecedores e terceiros relevantes, para preparar todos para a resposta real. O formato mais acessível é o exercício de mesa: a equipe senta, alguém narra um cenário e cada participante diz o que faria, com o plano na mão.

Um roteiro simples para o primeiro exercício: "segunda-feira, 8h, os arquivos do servidor aparecem com extensão estranha e há uma nota pedindo resgate; o e-mail do financeiro mandou boletos para clientes no fim de semana". A partir daí, perguntas diretas: quem declara o incidente? Quem autoriza desligar? Há dado pessoal envolvido? Quem fala com a ANPD, e a procuração está onde? O que se diz ao cliente que ligar?

Depois do exercício, anote o que travou e corrija o plano. Um bom indicador de maturidade é o número de perguntas que ficaram sem resposta, e se esse número cai de um exercício para o outro.

Por onde começar hoje

Não comece pelo modelo de vinte páginas. Comece pelas decisões e pelos contatos, que são o que mais faz falta no dia do incidente.

1. Reúna direção, quem cuida de TI e quem cuida da comunicação por uma hora e responda às seis decisões deste artigo, com nomes.
2. Monte a lista de contatos de fornecedores e guarde uma cópia fora dos sistemas da empresa.
3. Confirme quem é o encarregado e se o documento de designação ou a procuração estão prontos.
4. Releia os contratos de hospedagem, e-mail, ERP e TI procurando o que eles dizem sobre incidente.
5. Escreva dois playbooks: o cenário mais provável e o mais grave para o seu negócio.
6. Marque o primeiro exercício de mesa e a data de revisão do plano.

Se quiser apoio para estruturar o plano, revisar contratos de fornecedores e fazer o primeiro exercício, a área de Tech & Security da Alliance faz esse trabalho com empresas que dependem de terceiros. E se a dúvida for anterior, sobre onde tecnologia, dados e comunicação estão mais frágeis no seu negócio, o diagnóstico gratuito de marketing ajuda a enxergar essas fragilidades junto com o resto da operação.