Esta página faz parte do nosso guia para montar um plano de resposta a incidentes, que apresenta as oito etapas, onde guardar o plano e como testá-lo. Aqui você encontra as fases de uma resposta e o que cada seção do plano deve conter. Para cenários específicos, veja os playbooks de resposta a incidentes.
As seis fases da resposta a incidentes
A Special Publication 800-61 do NIST é a referência mais usada em resposta a incidentes. A Revisão 2 (2012) descreveu um ciclo de vida de quatro fases: Preparação; Detecção e Análise; Contenção, Erradicação e Recuperação; e Atividade Pós-Incidente. A Revisão 3, publicada em abril de 2025, substitui a anterior. Ela enquadra a resposta a incidentes nas seis funções do NIST Cybersecurity Framework 2.0 (Governar, Identificar, Proteger, Detectar, Responder e Recuperar) e trata a preparação e a melhoria como parte da gestão contínua de riscos, e não como fases isoladas.
Para os procedimentos operacionais, a maioria dos profissionais ainda segue as seis etapas abaixo, com a contenção e a erradicação tratadas separadamente. Elas valem para qualquer tipo de incidente, de uma conta de e-mail comprometida a um ataque de ransomware em toda a rede.
1
Preparação
Tudo o que acontece antes de um incidente: documentar funções e responsabilidades, criar caminhos de escalonamento, manter uma lista de contatos atualizada, inventariar ativos críticos e suas prioridades de recuperação, definir o que constitui um incidente notificável, treinar a equipe para reconhecer e relatar atividades suspeitas e testar backups em condições realistas. A preparação é a única fase sem pressão de tempo, e também a que muitas organizações adiam indefinidamente.
2
Detecção e análise
Identificar que houve um incidente e determinar sua natureza, escopo e gravidade. Isso requer registro e alertas centralizados, capazes de correlacionar eventos entre sistemas. Muitas organizações só descobrem um incidente quando alguém de fora avisa: um cliente, um parceiro, um banco ou a polícia. Nesse intervalo, o invasor pode passar semanas ou meses no ambiente sem ser notado. Uma detecção melhor encurta o tempo entre o início do ataque e o momento em que alguém o percebe. Onde investir depende da visibilidade existente, dos caminhos de ataque prováveis e da capacidade da sua equipe de agir sobre os alertas.
3
Contenção
Limitar a propagação e o impacto do incidente sem destruir as provas forenses. A contenção de curto prazo isola imediatamente os sistemas afetados. A contenção de longo prazo restaura parte das funções enquanto mantém isolado o ambiente comprometido. Os invasores agem rapidamente: o CrowdStrike 2026 Global Threat Report estima em 29 minutos o breakout time médio do eCrime, ou seja, o tempo entre o acesso inicial e o movimento para outros sistemas. A decisão de contenção requer autoridade predefinida. Quem pode autorizar o desligamento de um sistema de produção em horário comercial? Essa pergunta precisa ter um nome como resposta antes do incidente.
4
Erradicação
Remover a ameaça do ambiente: códigos maliciosos, contas comprometidas, backdoors e mecanismos de persistência deixados pelos invasores. Sem uma análise forense completa, a remoção tende a ficar incompleta, e remoção incompleta leva à reinfecção. No caso de ransomware, voltar a operar numa infraestrutura que ainda contém o vetor de acesso inicial ou as ferramentas do invasor costuma levar a uma segunda criptografia, em geral mais rápida.
5
Recuperação
Restaurar as operações normais. É aqui que os backups passam pelo teste real: a organização pode restaurar para um estado utilizável dentro do tempo de inatividade máximo tolerável? A recuperação inclui monitorar sinais de reinfecção, ampliar os logs para detectar o invasor caso ele volte e validar que os sistemas afetados funcionam corretamente antes de devolvê-los à produção. Sem esse monitoramento, um invasor que manteve um ponto de apoio pode desfazer a recuperação.
6
Atividade pós-incidente
A revisão estruturada realizada após a resolução do incidente: o que aconteceu, como foi detectado pela primeira vez, o que funcionou, o que falhou, o que precisa mudar no plano, nos controles ou no ambiente. É principalmente nas revisões pós-incidente que a capacidade de resposta melhora. As organizações que pulam esta etapa porque a equipe está exausta tendem a repetir os mesmos erros no próximo incidente.
O que seu plano deve conter
O plano precisa funcionar sob pressão. Estes são os elementos mínimos de um documento utilizável.
Escopo e objetivos
Que tipos de incidentes o plano cobre, quais são os objetivos de resposta da organização (minimizar o impacto operacional, cumprir as obrigações de notificação legal, preservar as provas forenses, proteger a reputação) e o que fica explicitamente fora do escopo. Um plano que tenta cobrir todas as situações possíveis com igual detalhe muitas vezes não cobre nenhuma delas de forma útil. Comece com os tipos de incidentes que sua organização provavelmente enfrentará.
Funções, responsabilidades e autoridade
Uma pessoa nomeada para cada função, com um substituto também nomeado. Autoridade definida: quem pode declarar formalmente um incidente, quem pode autorizar ações de contenção (inclusive tirar sistemas do ar), quem pode aprovar comunicações externas e quem pode autorizar uma decisão de pagamento. Sem isso, a decisão fica com a pessoa mais sênior disponível, que pode não ser a certa e vai decidir mais devagar.
Caminhos de escalonamento e contatos externos
Escalonamento interno: quem é acionado primeiro, quem é acionado se essa pessoa não atender e a partir de que nível de gravidade o conselho é avisado. Contatos externos: consultor jurídico (com número de emergência 24 horas por dia, 7 dias por semana), seguro cibernético (número da apólice, canal de sinistros e a empresa de resposta a incidentes credenciada pela seguradora, se houver), sua empresa de resposta a incidentes ou provedor de MDR, se houver, fornecedores críticos e provedores de nuvem (referências de conta e rotas de escalonamento de suporte), a autoridade de proteção de dados e eventuais reguladores setoriais, a agência nacional de cibersegurança e a polícia. No Brasil isso significa a ANPD, o Banco Central onde se aplica, o CERT.br e a polícia; no Reino Unido, o ICO e o NCSC; nos EUA, a CISA e o IC3 do FBI. Uma lista de contatos que só existe no sistema de e-mail fica inútil quando o e-mail é comprometido. Combine um canal fora de banda, como celulares pessoais ou um serviço de mensagens separado, para quando o e-mail corporativo ou os serviços de identidade estiverem fora do ar. Combine também como os membros da equipe confirmam a identidade uns dos outros nesse canal, por exemplo ligando de volta para um número que já consta na folha de contatos: um invasor que lê seu e-mail pode ver o plano e tentar entrar na conversa.
Protocolos de comunicação
Protocolos separados para comunicação interna e externa. Quem fala com os funcionários e o que pode dizer. Quem fala com o público externo (clientes, fornecedores, imprensa e reguladores) e o que precisa de aprovação do jurídico antes de sair. Comunicações externas improvisadas durante um incidente criam riscos jurídicos e de reputação que duram mais do que o impacto técnico. Modelos prontos para as comunicações mais comuns reduzem o tempo de decisão e os erros sob pressão.
Classificação do incidente
Uma escala de gravidade (P1 a P3, ou Crítica, Alta e Média) com critérios claros para cada nível, uma meta de resposta e um caminho de escalonamento. Sem essa escala, todo incidente recebe o mesmo tratamento: esforço demais nos eventos pequenos e recursos de menos nos grandes. Use o exemplo abaixo como ponto de partida e adapte.
| Nível | Exemplos | Meta de resposta | Quem é informado |
|---|---|---|---|
| P1 Crítico | Ransomware se espalhando; roubo confirmado de dados pessoais ou sensíveis; um serviço crítico inativo; comprometimento de uma conta de administrador ou do sistema de identidade | Imediatamente, a qualquer hora | Líder do incidente, patrocinador executivo, jurídico e encarregado (DPO); conselho informado no mesmo dia |
| P2 Alto | Comprometimento confirmado, mas contido em um sistema ou conta; suspeita de exposição de dados sob investigação; um incidente em um fornecedor crítico que afeta você | Dentro de 1 hora, a qualquer hora | Líder do incidente e líder técnico; encarregado (DPO) se houver dados pessoais envolvidos |
| P3 Médio | Malware capturado em um dispositivo; um clique em phishing com a senha redefinida na hora; uma violação de política sem nenhum sinal de dano | Dentro de 4 horas úteis | Equipe de segurança ou TI; líder do incidente informado |
São metas internas ilustrativas, não prazos legais. A gravidade pode aumentar ou diminuir à medida que as evidências chegam; registre cada alteração e o motivo no registro de decisões. A necessidade de comunicar um regulador é uma avaliação separada, feita contra o critério de cada lei. Um P3 ainda pode exigir comunicação, por exemplo um e-mail com dados de saúde enviado para a pessoa errada.
Prioridades e dependências de recuperação
Os serviços críticos, os sistemas e fornecedores dos quais cada um depende e a ordem em que retornam. Registre um objetivo de tempo de recuperação (RTO) e um objetivo de ponto de recuperação (RPO) para cada um, alinhados às metas dos seus planos de continuidade de negócios e recuperação de desastres, para que a equipe de recuperação não precise definir prioridades no meio do incidente. Combine a passagem para esses planos: quem decide que um sistema está limpo o suficiente para ser restaurado e quais imagens de disco e registros a equipe forense precisa manter antes que qualquer coisa seja reconstruída.
Registro de decisões e evidências
Um registro contínuo, mantido fora do ambiente afetado desde a primeira hora: o que foi decidido, quem autorizou, quando, quais evidências estavam disponíveis no momento e quais ações foram seguidas. Ele apoia a investigação forense, responde a perguntas de seguradoras e reguladores e alimenta a revisão pós-incidente. Também mostra ao regulador que as decisões foram tomadas numa base razoável, mesmo que, olhando para trás, outra decisão pareça melhor.
Registro de fornecedores críticos
Os fornecedores cuja falha interromperia um serviço crítico, e para cada um deles: o que ele executa para você, quais dados ele contém, que acesso ele tem aos seus sistemas, como você o alcança fora do expediente, o que o contrato diz que ele deve informar e com que rapidez, e a solução alternativa caso ele caia. Mantenha-o curto o bastante para usar numa crise e armazene-o com a cópia offline do plano. Um fornecedor que mantém seus dados ou pode fazer login em seus sistemas pertence à lista, mesmo que seu serviço pareça secundário. Se você já classificou seus fornecedores por níveis, a lista de nível 1 é o ponto de partida.
Critérios de fechamento e aprovação
As condições para encerrar um incidente: o acesso do invasor é removido e o monitoramento não mostra retorno por um período acordado, os sistemas afetados são restaurados e os responsáveis por eles confirmam que funcionam, todas as notificações foram feitas ou a decisão de não notificar é registrada, as evidências são retidas e a revisão pós-incidente é agendada. Defina quem declara o incidente encerrado, em geral o líder do incidente junto com o patrocinador executivo. Sem isso, incidentes ficam abertos por semanas ou são encerrados antes de o invasor sair do ambiente.
