Plano de Resposta a Incidentes: Guia para Empresas

Aprenda a criar um plano de resposta a incidentes com papéis, triagem, contenção, comunicação, recuperação, LGPD, testes e melhoria contínua.

O que é um plano de resposta a incidentes?

Um plano de resposta a incidentes é um documento operacional que define como a empresa identifica, avalia, contém, comunica e recupera-se de um incidente de segurança. Ele estabelece papéis, critérios de decisão, contatos, canais alternativos e procedimentos antes que a pressão de uma crise reduza a capacidade de decidir.

O plano não impede ataques, falhas ou erros humanos. Sua função é reduzir improvisação, tornar responsabilidades visíveis e permitir uma resposta proporcional ao impacto. Para funcionar, precisa estar conectado ao inventário de ativos, backups, monitoramento, contratos, continuidade do negócio e obrigações legais.

A orientação vigente do NIST para resposta a incidentes trata a preparação como parte contínua da gestão de riscos. Uma lista técnica isolada, sem autoridade para tomar decisões e comunicar riscos, não cumpre esse papel.

Evento, vulnerabilidade e incidente não são sinônimos

Um evento é uma ocorrência observada, como várias tentativas de login ou a indisponibilidade de uma aplicação. Uma vulnerabilidade é uma fraqueza que pode ser explorada. Um incidente ocorre quando há comprometimento, impacto ou violação que exige resposta coordenada.

No contexto de dados pessoais, a ANPD define incidente de segurança como evento adverso confirmado que compromete confidencialidade, integridade, disponibilidade ou autenticidade. Isso pode incluir acesso não autorizado, divulgação acidental, alteração, perda ou indisponibilidade de dados pessoais.

A distinção evita dois problemas: tratar todo alerta como crise ou ignorar sinais porque ainda não existe certeza absoluta. O plano deve prever triagem de ocorrências suspeitas e critérios para declarar formalmente um incidente.

Resposta, continuidade e recuperação de desastre

Esses planos se complementam:

resposta a incidentes: coordena investigação, contenção, comunicação e recuperação diante de uma ocorrência de segurança;
continuidade de negócios: define como processos essenciais continuam em nível aceitável durante uma interrupção;
recuperação de desastre: orienta a restauração de infraestrutura, aplicações e dados;
gestão de crise: coordena decisões executivas, pessoas, comunicação e impactos amplos.

Um ransomware pode ativar todos eles. A equipe de segurança investiga e contém; tecnologia restaura ambientes; áreas de negócio executam alternativas; jurídico e comunicação avaliam notificações; a liderança prioriza serviços e aprova decisões de maior impacto.

O artigo sobre migração para nuvem aborda objetivos de recuperação, backups e runbooks. O plano de resposta conecta essas capacidades ao processo de decisão durante uma ocorrência real.

O que deve existir antes do incidente

A versão mais útil do plano começa com informações que a equipe conseguirá acessar mesmo quando os sistemas corporativos estiverem indisponíveis ou comprometidos.

Inclua:

inventário dos serviços e dados críticos;
dependências entre aplicações, fornecedores e identidades;
responsáveis técnicos e de negócio;
contatos principais e suplentes;
contratos de suporte, seguro e resposta especializada;
canais de comunicação fora do ambiente afetado;
acessos emergenciais protegidos e auditáveis;
localização de backups e procedimentos de restauração;
fontes de logs e seus períodos de retenção;
modelos de registro de decisões e linha do tempo;
critérios para acionar jurídico, privacidade e comunicação;
autoridades regulatórias e canais aplicáveis ao setor.

Uma avaliação de TI pode revelar lacunas de inventário, acesso, backup e observabilidade antes da criação dos playbooks. Sem essa base, o plano tende a depender de pessoas específicas e informações que podem não estar disponíveis.

Defina uma equipe multidisciplinar

Incidentes relevantes raramente pertencem apenas à TI. O núcleo de resposta pode envolver:

coordenação do incidente: organiza prioridades, ritmo, registros e escalonamento;
segurança e tecnologia: investiga, contém, erradica e recupera;
responsável pelo serviço: explica impacto e valida a recuperação;
privacidade e jurídico: avaliam dados, contratos, evidências e obrigações;
comunicação: mantém mensagens internas e externas consistentes;
liderança executiva: autoriza decisões com impacto operacional, financeiro ou reputacional;
fornecedores: apoiam quando sistemas, nuvem ou serviços terceirizados participam.

Para cada papel, defina titular, suplente, autoridade e forma de contato. Evite uma matriz que exige aprovação de alguém inalcançável para toda ação. Decisões previamente autorizadas, dentro de limites claros, aceleram contenção sem remover governança.

Classifique por impacto, não por aparência técnica

Uma classificação de severidade ajuda a priorizar recursos e comunicação. Avalie dimensões como:

processos e clientes afetados;
criticidade e quantidade de sistemas;
dados envolvidos;
extensão geográfica ou organizacional;
possibilidade de propagação;
duração e reversibilidade;
impacto financeiro, regulatório ou de segurança física;
dependência de terceiros;
nível de confiança das informações.

Um alerta sofisticado pode ter baixo impacto; um e-mail enviado ao destinatário errado pode exigir avaliação imediata por envolver dados pessoais sensíveis. A severidade deve ser revisada conforme surgem fatos.

Registre também quem pode declarar e encerrar um incidente. Encerramento técnico não deve ocorrer antes de validar que serviços, dados, monitoramento e riscos residuais foram tratados.

Fluxo operacional do plano de resposta a incidentes

A publicação NIST SP 800-61 Rev. 3, finalizada em abril de 2025, integra a resposta a incidentes à gestão contínua de risco do Cybersecurity Framework 2.0. O NIST CSF 2.0 organiza resultados nas funções Governar, Identificar, Proteger, Detectar, Responder e Recuperar.

Na operação, um playbook pode seguir as etapas abaixo sem tratá-las como blocos rígidos.

1. Detectar e registrar

Registre horário, fonte do alerta, sintomas, ativos, contas e evidências iniciais. Abra uma linha do tempo única. Não compartilhe detalhes sensíveis em canais que possam estar comprometidos.

A observabilidade de sistemas ajuda a correlacionar logs, métricas e traces, mas alertas precisam de responsáveis e caminhos de escalonamento.

2. Fazer triagem

Confirme o que é conhecido, o que ainda é hipótese e quais informações faltam. Avalie escopo, impacto, dados envolvidos e possibilidade de propagação. Classifique a severidade e acione os papéis adequados.

Evite esperar por certeza completa quando uma ação reversível pode limitar dano. Ao mesmo tempo, não apresente suposições como fatos em atualizações executivas ou externas.

3. Conter com segurança

A contenção pode envolver isolar dispositivo, bloquear credencial, limitar integração, remover acesso público ou segmentar rede. A escolha deve equilibrar interrupção, risco de propagação e preservação de evidências.

Desligar um equipamento por impulso pode destruir dados voláteis úteis à investigação. A orientação da CISA para ransomware recomenda isolar sistemas afetados e considerar preservação de memória, imagens, logs e outros artefatos. A ação correta depende do cenário e da capacidade técnica disponível.

4. Investigar e erradicar

Determine vetor de entrada, contas, persistência, movimento entre sistemas e dados potencialmente acessados. Corrija a causa: revogue sessões, rotacione credenciais, remova artefatos, aplique correções e elimine acessos indevidos.

Não confunda ausência de novo alerta com erradicação. O invasor pode ter criado outros meios de acesso, e uma vulnerabilidade pode continuar exposta.

5. Recuperar por prioridade

Restaure primeiro os serviços definidos como críticos, usando ambientes confiáveis e dados verificados. Teste jornadas de negócio, integrações, permissões e monitoramento antes de ampliar o tráfego.

A recuperação precisa evitar reinfecção. Backups devem ser testados e protegidos do mesmo domínio de falha que afetou a produção. Registre critérios objetivos para declarar o serviço estável.

6. Aprender e acompanhar

Realize uma revisão sem foco em culpados. Reconstrua a linha do tempo, identifique decisões difíceis, controles que funcionaram e lacunas. Cada ação corretiva deve ter responsável, prioridade e prazo.

Atualize o plano, os playbooks, a arquitetura e o treinamento. Uma lição sem acompanhamento vira apenas documentação histórica.

Comunicação durante o incidente

Defina cadência e público para atualizações. Uma mensagem interna pode conter:

situação conhecida e nível de confiança;
impacto observado;
ações em andamento;
decisões necessárias;
cuidados esperados das equipes;
horário da próxima atualização;
contato oficial.

Evite divulgar causa, quantidade de afetados ou prazo de recuperação sem evidência suficiente. A comunicação deve ser consistente, mas pode evoluir à medida que a investigação avança. Registre quem aprovou cada mensagem.

Prepare modelos para colaboradores, clientes, fornecedores, imprensa e autoridades. Modelos economizam tempo, mas não substituem a avaliação do caso concreto.

Incidentes com dados pessoais e ANPD

No Brasil, o controlador deve avaliar se o incidente envolve dados pessoais e pode acarretar risco ou dano relevante aos titulares. Segundo as orientações atuais da ANPD, quando os critérios de comunicação são atendidos, a comunicação à Autoridade e aos titulares deve ocorrer em até três dias úteis, salvo prazo específico previsto em outra legislação.

Se as informações ainda estiverem incompletas, a ANPD admite comunicação preliminar e complementação fundamentada. O regulamento também prevê manutenção do registro de incidentes com dados pessoais por pelo menos cinco anos.

O plano precisa permitir que tecnologia forneça rapidamente a privacidade e ao jurídico:

data de conhecimento;
sistemas e operadores envolvidos;
categorias e volume estimado de titulares;
natureza dos dados;
medidas de proteção existentes;
impacto e riscos possíveis;
medidas adotadas ou planejadas;
canais para atendimento.

Nem todo incidente precisa ser comunicado, e essa decisão exige análise do controlador conforme a LGPD e o regulamento. Este guia não substitui avaliação jurídica ou regulatória específica.

Crie playbooks para cenários prováveis

O plano principal define governança. Playbooks detalham decisões e ações por cenário. Priorize situações relacionadas ao risco da empresa:

conta administrativa comprometida;
ransomware ou extorsão de dados;
vazamento em armazenamento cloud;
perda de dispositivo;
envio indevido de dados;
exploração de aplicação pública;
indisponibilidade por ataque;
incidente em fornecedor;
alteração ou exclusão de dados;
credenciais expostas em repositório.

Cada playbook deve indicar sinais, perguntas de triagem, contenções autorizadas, evidências, dependências, comunicação e recuperação. Evite comandos rígidos que podem ser perigosos em contextos diferentes; inclua critérios e responsáveis.

Teste o plano antes de precisar dele

Um exercício de mesa apresenta um cenário progressivo à equipe, sem afetar produção. Por exemplo: um login administrativo incomum é detectado; depois surgem exportações de dados e indisponibilidade do canal corporativo.

Observe:

os contatos funcionam?
alguém consegue assumir cada papel?
as decisões têm autoridade clara?
há acesso a logs e backups?
o jurídico recebe informações suficientes?
a equipe consegue usar canal alternativo?
as prioridades de restauração estão acordadas?
ações e horários são registrados?

Depois do exercício, corrija o plano e repita os pontos críticos. Testar apenas a equipe técnica deixa comunicação, negócio e liderança sem prática.

Métricas para melhorar a capacidade de resposta

Métricas devem revelar gargalos, não premiar encerramentos rápidos. Considere:

tempo entre sinal e triagem;
tempo até contenção;
tempo até restauração validada;
percentual de serviços críticos com playbook testado;
contatos e fornecedores revisados no prazo;
ações corretivas vencidas;
incidentes recorrentes pela mesma causa;
restaurações de backup testadas;
qualidade e disponibilidade das evidências.

Compare incidentes semelhantes com cautela. Gravidade, escopo e detecção variam; uma média isolada pode esconder casos críticos.

Erros que tornam o plano inútil

Documento longo sem acesso alternativo

Durante a indisponibilidade, um arquivo guardado apenas na rede corporativa pode ficar inacessível.

Contatos sem suplentes

Férias, troca de função ou telefone desatualizado interrompem o acionamento.

Plano exclusivamente técnico

Decisões sobre paralisação, clientes, contratos e comunicação exigem outras áreas.

Falta de exercícios

Um procedimento não testado contém premissas desconhecidas sobre acesso, tempo e autoridade.

Recuperação sem validação

Ligar servidores não prova que dados, integrações e jornadas estão corretos ou seguros.

Pressa para atribuir culpa

A investigação perde qualidade quando pessoas escondem erros ou evitam relatar sinais. Responsabilização por conduta e aprendizado técnico não devem ser confundidos.

Checklist do plano de resposta a incidentes

Serviços, dados e dependências críticas estão identificados?
Existem coordenador, suplentes e autoridade definida?
Contatos funcionam fora dos sistemas corporativos?
Há critérios de severidade, declaração e encerramento?
A linha do tempo possui modelo único?
A contenção considera impacto e preservação de evidências?
Logs relevantes têm acesso e retenção adequados?
Backups são isolados e testados?
Jurídico, privacidade e comunicação participam do plano?
Contratos definem deveres de fornecedores e operadores?
Existem playbooks para os principais cenários?
Mensagens preliminares estão preparadas?
Requisitos da LGPD e do setor foram mapeados?
Exercícios de mesa são realizados?
Ações corretivas têm responsável e prazo?
Uma cópia protegida do plano está disponível offline?

Conclusão

Um plano de resposta a incidentes transforma uma emergência técnica em um processo coordenado. Ele combina pessoas, autoridade, evidências, comunicação, continuidade e recuperação, com procedimentos proporcionais aos riscos reais da empresa.

Comece pelos serviços críticos e por poucos cenários prováveis. Defina quem decide, teste contatos, execute um exercício e corrija as lacunas. O plano amadurece quando cada incidente ou simulação melhora a capacidade de detectar, responder e recuperar.

Se sua empresa precisa avaliar riscos, estruturar controles e criar playbooks executáveis, conheça o serviço de governança e compliance de TI ou fale com a Mattos Tech Solutions para planejar a primeira etapa.