Qual a diferença entre incidente e problema?

Incidente é uma interrupção ou degradação não planejada de um serviço de TI. Problema é a causa raiz de um ou mais incidentes. Exemplo: o servidor caiu (incidente) porque o disco estava cheio (problema). Tratar incidentes é apagar incêndios; gestão de problemas é prevenir que o fogo comece.

Com que frequência devo testar o plano de resposta a incidentes?

No mínimo trimestralmente. Tabletop exercises (simulações em mesa) podem ser mensais com baixo custo. Simulações técnicas completas (com failover real) devem ser trimestrais. Após incidentes reais de severidade P1 ou P2, revise e atualize o plano imediatamente.

Preciso de uma equipe dedicada de resposta a incidentes?

Depende do porte. Empresas com até 500 funcionários podem usar um modelo de equipe rotativa com on-call. Acima disso, considere um time dedicado de pelo menos 2-3 pessoas. O mais importante é que os papéis e responsabilidades estejam claros, independente de ser dedicado ou não.

O que a LGPD exige em caso de incidente de segurança?

A LGPD exige comunicação à ANPD e aos titulares em prazo razoável quando houver incidente que possa acarretar risco ou dano relevante. A ANPD recomenda 2 dias úteis. O plano deve incluir templates de comunicação e critérios claros para decidir quando notificar.

Plano de Resposta a Incidentes de TI: Como Montar e Testar

São 2h da manhã e seu celular toca. O sistema principal da empresa está fora do ar, clientes estão reclamando nas redes sociais e ninguém sabe exatamente o que aconteceu. Quem faz o quê? Em que ordem? Quem comunica o cliente?

Se essas perguntas não têm resposta imediata, sua empresa não tem um plano de resposta a incidentes — tem apenas esperança de que tudo vai dar certo. Neste guia, vamos montar esse plano do zero.

Por Que Ter um Plano Formal

A diferença entre uma empresa com plano testado e uma sem não é sutil:

Com plano: Incidente detectado → equipe acionada em 5 minutos → contenção em 30 minutos → comunicação estruturada ao cliente → resolução em 2-4 horas → post-mortem em 48h.

Sem plano: Incidente detectado (ou pior, reportado pelo cliente) → pânico → ligações em cadeia → tentativas desorganizadas → 8-24 horas de downtime → sem aprendizado.

Dados do mercado mostram que empresas com plano estruturado reduzem o MTTR (tempo médio de resolução) em 50-70% e o custo total do incidente em 30-40%.

As 6 Fases do Framework NIST

O framework de resposta a incidentes do NIST (SP 800-61) é o mais adotado globalmente. São 6 fases que se alimentam em ciclo:

Fase 1: Preparação

Tudo que acontece antes do incidente. É a fase mais importante e a mais negligenciada.

O que preparar:

Inventário de sistemas críticos com classificação de impacto
Definição de papéis e responsabilidades (quem é o Incident Commander?)
Canais de comunicação de emergência (não dependa apenas do email corporativo)
Playbooks para cenários mais prováveis (queda de servidor, ransomware, vazamento de dados)
Ferramentas de diagnóstico e forense já instaladas e testadas
Contatos de fornecedores e parceiros de emergência

Erro comum: Ter o plano documentado mas nunca testado. Plano não testado é plano que não funciona.

Fase 2: Identificação

Detectar que um incidente está acontecendo e classificar sua severidade.

Fontes de detecção:

Monitoramento automatizado (alertas de Zabbix, PRTG, Datadog, PingGrid)
Relato de usuários ou clientes
Análise de logs e anomalias
Alertas de segurança (SIEM, antivírus, WAF, SonicWall)

Classificação de severidade:

P1 (Crítico) — Sistema principal indisponível, impacto em receita ou segurança. Resposta imediata, todas as mãos no deck.
P2 (Alto) — Degradação significativa ou sistema secundário fora. Resposta em até 30 minutos.
P3 (Médio) — Impacto limitado, workaround disponível. Resposta em até 2 horas.
P4 (Baixo) — Cosmético ou impacto mínimo. Próximo horário comercial.

A classificação correta evita dois problemas: tratar tudo como P1 (fadiga de alarmes) ou subestimar um incidente real.

Fase 3: Contenção

Parar o sangramento antes de tentar curar. O objetivo não é resolver — é impedir que piore.

Contenção de curto prazo: Isolar o sistema afetado, bloquear acesso comprometido via firewall (SonicWall, por exemplo, permite criar regras de bloqueio em segundos), redirecionar tráfego. Minutos contam. Ferramentas de acesso remoto como TeamViewer permitem que a equipe atue mesmo fora do escritório.

Contenção de longo prazo: Aplicar patches temporários, ativar sistemas de backup, configurar regras de firewall. Estabilizar para investigar.

Decisão crítica: Preservar evidências vs. restaurar rápido. Em incidentes de segurança, a tentação de “limpar tudo e reinstalar” pode destruir evidências necessárias para entender o que aconteceu.

Fase 4: Erradicação

Remover a causa raiz. Se a contenção para o sangramento, a erradicação remove o que causou o ferimento.

Exemplos:

Ransomware: remover malware, verificar todos os endpoints, validar backups
Falha de hardware: substituir componente, verificar redundância
Erro de configuração: reverter mudança, atualizar processo de change management
Vulnerabilidade explorada: aplicar patch, revisar sistemas similares

Atenção: Não declare “erradicado” rápido demais. Atacantes sofisticados deixam backdoors. Verifique toda a superfície de ataque.

Fase 5: Recuperação

Restaurar os sistemas à operação normal de forma controlada.

A velocidade de recuperação depende diretamente da qualidade do seu plano de backup. Soluções como Acronis Cyber Protect permitem restore granular com verificação de integridade automática, reduzindo drasticamente o RTO.

Checklist de recuperação:

Validar integridade dos dados antes de restaurar
Restaurar em fases (sistema por sistema, não tudo de uma vez)
Monitorar de perto nas primeiras 24-48 horas
Confirmar com usuários/clientes que o serviço está normalizado
Manter equipe de plantão por pelo menos 24 horas após a restauração

Fase 6: Lições Aprendidas (Post-Mortem)

A fase que transforma incidentes em melhoria. Sem ela, os mesmos problemas se repetem.

Regra de ouro: post-mortem sem culpa (blameless). O objetivo é entender o que aconteceu e como prevenir, não punir pessoas.

Estrutura de um bom post-mortem:

Timeline detalhada do incidente (quando detectado, cada ação tomada)
O que funcionou bem na resposta
O que não funcionou ou poderia melhorar
Causa raiz (use 5 Porquês para chegar na raiz real)
Ações de melhoria com responsáveis e prazos

Prazo: Realize o post-mortem em até 48 horas. Depois disso, detalhes se perdem.

Papéis e Responsabilidades

Um plano sem donos claros não funciona. Defina no mínimo estes papéis:

Incident Commander (IC) — Coordena toda a resposta. Toma decisões quando há conflito de prioridades. Não precisa ser o mais técnico — precisa ser quem melhor organiza e comunica sob pressão.

Líder Técnico — Coordena a investigação e resolução técnica. É o especialista que direciona a equipe de engenharia.

Comunicador — Responsável por manter stakeholders informados: diretoria, clientes, equipe interna. Libera o IC e o time técnico para focar na resolução.

Escriba — Documenta tudo em tempo real. Timeline, decisões, ações. Sem essa pessoa, o post-mortem perde qualidade.

Em empresas menores, uma pessoa pode acumular papéis — mas nunca IC e líder técnico ao mesmo tempo. Quem decide e quem investiga precisam ser pessoas diferentes.

LGPD e Obrigações Regulatórias

A LGPD exige que o controlador comunique à ANPD e aos titulares de dados quando ocorrer incidente de segurança que possa causar risco ou dano relevante. A ANPD recomenda que essa comunicação seja feita em até 2 dias úteis.

O que seu plano deve incluir:

Critérios claros para classificar se o incidente envolve dados pessoais
Templates de comunicação para ANPD e titulares
Processo para avaliar o risco e dano potencial
Registro de todos os incidentes (mesmo os que não exigem notificação)

Empresas em setores regulados (financeiro, saúde) têm exigências adicionais. Consulte as normas específicas do seu regulador. O Checklist de Segurança para CTOs cobre os controles fundamentais que todo plano deveria ter.

Testando o Plano: Simulações que Funcionam

O plano mais bonito do mundo é inútil se nunca foi testado. Três tipos de simulação, do mais simples ao mais completo:

Tabletop Exercise (Exercício de Mesa) — Reunião onde a equipe discute um cenário hipotético passo a passo. “E se o ransomware atingir o servidor de arquivos na sexta à noite?” Baixo custo, alto aprendizado. Faça mensalmente.

Walkthrough Técnico — A equipe percorre os playbooks com as ferramentas reais, sem executar ações destrutivas. Valida que as ferramentas funcionam e o time sabe usá-las.

Simulação Completa — Failover real, restore de backup, ativação de DR. Mais caro e arriscado, mas é o único teste que prova que o plano funciona de verdade. Faça trimestralmente.

Após cada simulação: Documente o que funcionou, o que falhou, e atualize o plano. O plano é um documento vivo, não um PDF na gaveta.

Se esse tipo de conteúdo é útil para você, o Briefing do CTO entrega ferramentas, dados e insights práticos sobre infraestrutura, cloud, segurança e IA toda semana no seu email.

Avaliando Sua Postura de Segurança

Antes de montar o plano de resposta, é fundamental entender onde estão as vulnerabilidades. O Assessment de Segurança avalia 8 vetores de risco do seu ambiente e gera um roadmap de prioridades. E o Checklist de Segurança ajuda a validar que as boas práticas básicas estão cobertas.

O melhor plano de resposta a incidentes é aquele que você raramente precisa usar — porque a preparação e a prevenção estão funcionando.

Perguntas frequentes