Plano de resposta a incidentes: template executável

Quase toda empresa tem um plano de resposta a incidentes. Poucas conseguem executá-lo às três da manhã de um sábado, com o e-mail corporativo fora do ar e o domínio comprometido. O plano típico tem 40 páginas de política, nenhum telefone atualizado e nenhuma decisão pré-autorizada. Na hora do incidente, ninguém abre o documento.

Plano executável é outra coisa: curto, com papéis nomeados, critérios objetivos e roteiros por cenário. Este artigo traz a estrutura que usamos como base, seção por seção, e o que precisa estar em cada uma para funcionar sob pressão.

Princípios de um plano executável

Cabe em poucas páginas. O núcleo do plano deve ser lido em dez minutos. Detalhes técnicos ficam em runbooks anexos.
Decide antes. As decisões difíceis (desligar um sistema de produção, acionar o seguro, comunicar o regulador) têm dono e critério definidos antes do incidente.
Não depende do ambiente atacado. Contatos, canais e o próprio plano precisam estar acessíveis mesmo sem e-mail, SSO e rede corporativa.
É testado. Plano que nunca passou por exercício é hipótese.

A estrutura abaixo segue o ciclo clássico de preparação, detecção e análise, contenção, erradicação, recuperação e lições aprendidas, o mesmo do NIST SP 800-61, cuja revisão de 2025 passou a organizar a resposta junto às funções do NIST CSF 2.0.

Seção 1: escopo e gatilhos

Defina o que ativa o plano. Uma frase genérica como "qualquer incidente de segurança" faz com que ele seja acionado para tudo ou para nada. Liste gatilhos concretos:

Alerta crítico do SOC confirmado por analista
Indício de cifragem de arquivos em qualquer servidor
Acesso não autorizado a conta privilegiada ou de nuvem
Suspeita de vazamento de dado pessoal ou de cliente
Fraude financeira com origem em credencial interna ou sistema da empresa
Contato de terceiro (cliente, pesquisador, autoridade, imprensa) relatando incidente

Seção 2: classificação de severidade

A severidade define quem é acionado, em quanto tempo e com que autoridade. Use critérios que qualquer pessoa do plantão consiga aplicar em minutos:

Nível	Critério	Aciona	Tempo de resposta
SEV1 — crítico	Operação parada, ransomware ativo, vazamento confirmado de dado sensível	Comitê de crise completo, diretoria	Imediato, 24×7
SEV2 — alto	Comprometimento confirmado sem impacto amplo, conta privilegiada exposta	Líder de incidente, TI, jurídico	Até 1 hora
SEV3 — médio	Malware contido em estação, phishing com clique sem credencial comprometida	SOC e TI	Mesmo dia
SEV4 — baixo	Tentativa bloqueada, varredura externa	SOC	Fila normal

A severidade pode subir durante o incidente. Deixe explícito que qualquer membro do time pode escalar, e que ninguém pode rebaixar um SEV1 sem aval do líder de incidente.

Seção 3: papéis e autoridade

Nomeie pessoas, não áreas, e sempre com titular e substituto:

Líder de incidente: coordena, decide prioridades e é a única voz que distribui tarefas. Não investiga.
Líder técnico: conduz a análise, a contenção e a erradicação.
Comunicação: redige tudo que sai da sala de crise, para dentro e para fora.
Jurídico e DPO: avaliam obrigações legais, regulatórias e contratuais, e a necessidade de comunicar ANPD, titulares e reguladores setoriais.
Patrocinador executivo: aprova as decisões de negócio (desligar sistema, pagar fornecedor emergencial, acionar seguro).
Registro: mantém a linha do tempo com horário de cada fato e decisão.

O plano deve listar as decisões pré-autorizadas: o líder técnico pode isolar qualquer estação ou servidor sem pedir permissão; o líder de incidente pode desabilitar qualquer conta, inclusive de executivo; desligar um sistema crítico de receita exige o patrocinador. Isso elimina a reunião de uma hora que costuma atrasar a contenção.

Seção 4: canais fora de banda

Se o atacante tem acesso ao e-mail e ao chat corporativos, ele lê a resposta ao incidente em tempo real. O plano precisa prever:

Um canal alternativo já criado e testado, fora do domínio corporativo
Lista de contatos impressa e em local acessível sem rede corporativa: time interno, SOC ou MSSP, fornecedores críticos, seguradora, jurídico externo
Uma sala de crise definida, física ou virtual, com ponte de voz
Cópia do próprio plano e dos runbooks fora do ambiente de produção

Seção 5: runbooks por cenário

O plano diz quem decide; o runbook diz o que fazer. Comece pelos quatro cenários que mais acontecem:

Ransomware

Isolar os hosts afetados da rede sem desligá-los, para preservar memória. Bloquear contas usadas na propagação. Proteger e verificar backups antes de qualquer restauração. Identificar o vetor inicial antes de reconectar. Não negociar nem contatar o grupo sem jurídico e patrocinador. Veja as medidas preventivas em como prevenir ransomware.

Comprometimento de e-mail corporativo (BEC)

Revogar sessões e tokens, redefinir credenciais e MFA, revisar regras de encaminhamento e aplicativos autorizados na conta, verificar pagamentos alterados nos últimos dias e avisar o financeiro para congelar transferências pendentes.

Credencial ou chave de nuvem exposta

Revogar e rotacionar a chave, levantar tudo o que foi executado com ela no período, procurar recursos criados pelo atacante (usuários, funções, instâncias) e verificar acesso a buckets e bancos de dados.

Vazamento de dados

Delimitar quais dados, de quantos titulares e desde quando. Preservar evidências do acesso. Acionar jurídico e DPO para avaliar a comunicação. A partir daqui, o relógio regulatório está correndo.

Seção 6: preservação de evidências

A pressa em restaurar costuma destruir a prova de como o atacante entrou, e sem isso ele volta. Regras mínimas: coletar memória e imagem de disco dos hosts críticos antes de reinstalar, exportar logs antes que a retenção os apague, registrar cadeia de custódia (quem coletou, quando, onde está armazenado) e nunca analisar o material original, só cópias.

Seção 7: comunicação e obrigações

Mapeie antes, por tipo de incidente, quem precisa ser comunicado e em que prazo:

ANPD e titulares: incidente com risco ou dano relevante a titulares deve ser comunicado em até três dias úteis, conforme o regulamento de comunicação de incidentes da ANPD
Banco Central: instituições reguladas comunicam incidentes relevantes conforme a política aprovada; veja cibersegurança para fintechs
Clientes e parceiros: conforme contratos, que frequentemente têm prazos próprios
Seguradora: apólices de risco cibernético costumam exigir aviso imediato e uso de fornecedores credenciados
Autoridade policial: quando houver crime e decisão da empresa de registrar

Deixe modelos de texto prontos para cada público. Escrever do zero durante a crise é onde se cometem erros que depois viram problema jurídico.

Seção 8: encerramento e lições aprendidas

Defina quando o incidente está encerrado: causa raiz identificada, acesso do atacante eliminado, sistemas restaurados e monitorados por um período sem recorrência. Em até dez dias úteis, faça a revisão pós-incidente sem busca de culpados, com linha do tempo consolidada, o que funcionou, o que falhou e ações com dono e prazo. Os tempos medidos alimentam as métricas de MTTD e MTTR que vão para o board.

Como testar o plano

Exercício de mesa semestral: um cenário realista, conduzido por facilitador externo, com a diretoria presente pelo menos uma vez por ano
Teste dos canais fora de banda: todos conseguem entrar na ponte alternativa em 15 minutos?
Revisão trimestral dos contatos: telefone desatualizado é a falha mais comum e a mais evitável
Validação técnica: um exercício de Purple Team ou Red Team mostra se a detecção e a contenção funcionam como o plano supõe

Conclusão

Um plano de resposta a incidentes vale pelo que acontece na primeira hora. Papéis nomeados, decisões pré-autorizadas, canais que não dependem do ambiente atacado e roteiros por cenário transformam um documento de gaveta numa ferramenta de trabalho. E só um exercício mostra se ele funciona antes que um atacante faça esse teste.