Como este tema funciona na sua empresa
Quando incidente acontece, tudo é caos. Não há plano, pessoas chamam para um número errado, não há quem tome decisão. Resultado: reação lenta, dados perdidos.
Há plano básico: quem chamar, que reunião fazer, responsabilidades. Mas não é testado regularmente. Quando incidente crítico acontece, plano falha porque ninguém se lembra ou houve mudança de pessoas.
Plano é formal e testado anualmente (disaster recovery drill). War room é ativado, cadeia de comando é clara, comunicação é estruturada. Post-mortem é obrigatória. ITIL e compliance exigem isso.
Plano de resposta a incidentes é o documento e processo que define como organização detecta, comunica, escalada e resolve problemas de TI, minimizando tempo sem serviço (RTO) e perda de dados (RPO), com papéis, contatos, checklist e pós-análise estruturados.
Por que ter plano de resposta a incidentes é crítico
Quando sistema cai, primeiros 15-30 minutos são caóticos. Sem plano claro, energia é gasta descobrindo "quem liga", "qual equipe resolve", "isso é crítico ou não". Com plano, decisões já estão feitas. Resultado: resposta 2-3x mais rápida, menos downtime total.
Dados indicam que empresas com plano de incidente reduzem tempo médio de resolução em 40-50% comparado a empresas sem.
Componentes essenciais de um plano de incidente
1. Definição de severidade e escalação
Classificar incidentes em níveis. Exemplo: (Crítico = usuários não conseguem fazer nada, sistema inteiro fora), (Grave = funcionalidade reduzida, alguns usuários impactados), (Menor = incômodo, não impacta negócio). Cada nível tem escalação diferente (crítico = CEO é avisado, maior = apenas time técnico).
2. Organograma de resposta (war room)
Definir quem participa: incident commander (quem coordena), technical lead (quem soluciona), communicator (quem avisa pessoas), business representative (quem avalia impacto). Papéis devem ser definidos antes do incidente.
3. Contatos de emergência
Lista com: gestor de TI, CIO, especialistas chave (database, rede, segurança), fornecedores críticos (MSP, cloud provider, fornecedor de software), liderança da empresa. Incluir telefones pessoais e WhatsApp (para fora do horário). Lista deve ser atualizada a cada mudança.
4. Checklist de ações imediatas
Primeiros 5 minutos: (1) Confirmar que é incidente real (não é problema de rede local). (2) Determinar severidade. (3) Ativar war room (convocar pessoas). (4) Iniciar comunicação (notificar que sabemos do problema). (5) Começar root cause analysis.
5. Processo de comunicação durante incidente
Quem comunica, para quem, via qual canal, com que frequência. Exemplo: "Communicator envia email a cada 30 minutos para all-hands, SMS cada 1 hora para liderança, atualiza status page a cada 15 min".
6. Procedimentos de escalação (de quem para quem)
Se problema não for resolvido em 30 minutos, quem entra. Se não em 1 hora, quem mais. Se não em 4 horas, envolve CEO/COO. Escalar para especialista externo (MSP, fornecedor) sem hesitar se tem expertise que time interno não tem.
7. Documentação e post-mortem
Durante incidente: registrar cada ação, hora, resultado (log estruturado). Após resolução: dentro de 24h, convocar post-mortem para rever o que aconteceu, o que foi feito certo, o que foi errado, o que mudar para não acontecer novamente. Documentação fica no wiki/Jira para consultas futuras.
8. Backup de fornecedores críticos
Se fornecedor principal de software não consegue resolver problema crítico em X horas, ter contato de fornecedor alternativo (concorrente) pronto para ativar. Mesmo para internet: ter contato de segundo ISP.
Processo prático: 6 passos para criar plano de incidente
Passo 1 — Mapear sistemas críticos
Listar top 10 sistemas que se não funcionarem impactam negócio. Para cada um: qual é o impacto de 1h de downtime (R$, usuários afetados), qual é RTO aceitável (máximo X minutos fora), qual é RPO (máximo Y minutos de dados).
Passo 2 — Definir níveis de severidade
Exemplo: Crítico (downtime > R$ 50k/h ou cliente grande impactado), Grave (downtime R$ 5-50k/h), Menor (downtime < R$ 5k/h). Colocar sistemas em categorias.
Passo 3 — Montar organograma e contatos
Definir: Incident Commander (quem centraliza as decisões), Technical Lead (quem lidera resolução), Communicator (quem avisa), Business Owner (quem sabe impacto). Listar suplentes para cada papel (se titular não conseguir). Incluir contatos com múltiplos telefones e emails.
Passo 4 — Criar checklist de ação imediata
Documento de uma página com "primeiros 30 minutos". Checklist: confirmar incidente real, determinar severidade, ativar war room, enviar aviso inicial, iniciar diagnóstico. Pendurado perto de onde time de TI fica.
Passo 5 — Definir processo de comunicação
Template de email de aviso, frequência de atualizações por severidade, quem escreve, quem aprova antes de enviar. Para incidentes críticos: enviar aviso em menos de 10 minutos de descoberta.
Passo 6 — Testar e documentar aprendizados
A cada trimestre, fazer simulation (não é incidente real, é exercício): "suponha que servidor X falhou", ativar plano, ver quanto tempo leva resolver a simulação, registrar problemas, corrigir plano. Toda pessoa do time participa pelo menos 1x/ano.
Plano simples: documento 1 página com severidades, 5-6 contatos principais, checklist de primeiros passos. Guardar em lugar acessível (Slack pin, email, papel na parede da sala de TI).
Plano estruturado: documento de 5-10 páginas, organograma de war room, processo de comunicação formal, lista de escalação. Treinar time 2x/ano. Atualizar quando houver mudança de pessoas.
Plano executado em ITIL, simulado anualmente, com comitê de revisão. Disaster recovery drill é formal com auditoria. Post-mortem é obrigatória para cada incidente crítico.
Sinais de que sua empresa precisa de plano de incidente
Se você se reconhece em três ou mais cenários, plano formal é urgente.
- Último incidente crítico foi caótico: ninguém sabia quem ligar ou que fazer.
- Quando problema surge, pessoas têm conflito sobre responsabilidades ("isso não é da minha área").
- Documentação do que aconteceu em incidentes passados é mínima ou não existe.
- Erros similares acontecem múltiplas vezes (falta de aprendizado).
- Comunicação durante incidente é desorganizada (alguns sabem, outros não).
- Não há escalação clara (quando chamar especialista externo, quando avisar liderança).
- Contatos de emergência estão dispersos ou desatualizados.
Caminhos para implementar plano de resposta a incidentes
Dois caminhos: montar internamente, ou contratar consultoria ITIL.
Viável para empresas que têm gestor de TI com experiência em ITIL.
- Perfil necessário: Gestor de TI ou líder de operações com experiência em gerenciamento de incidentes
- Tempo estimado: 4-6 semanas para plano estruturado + 2-3 meses para testes e ajustes
- Faz sentido quando: Você tem capacidade, quer manter controle, budget é limitado
- Risco principal: Esforço é subestimado; plano fica incompleto ou fora de realidade operacional
Consultoria acelera e garante framework ITIL correto.
- Tipo de fornecedor: Consultoria ITIL, especialista em crisis management, ou company especializada em disaster recovery
- Vantagem: Framework pronto, experiência em múltiplas empresas, facilita workshop de discovery, treinamento incluído
- Faz sentido quando: Budget permite, quer processo robusto desde dia 1, complexity é alta
- Resultado típico: Plano executável + simulação de teste em 3-4 semanas
Precisa estruturar seu plano de resposta a incidentes?
O oHub conecta você gratuitamente a especialistas em ITIL e disaster recovery. Descreva seus sistemas críticos, receba proposta de plano personalizado, sem compromisso.
Encontrar fornecedores de TI no oHub
Sem custo, sem compromisso. Você recebe propostas e decide se e com quem avançar.
Perguntas frequentes
Com quantos sistemas começar um plano de incidente?
Começar com top 5-10 mais críticos. Para cada um, definir severidade, RTO, RPO, quem resolve. Expandir para outros sistemas conforme maturidade de processo.
Quem deve ser Incident Commander?
Alguém com autoridade para tomar decisões rapidamente. Geralmente gestor de TI ou CIO (pequena/média) ou especialista em incident response (grande empresa). Ter suplente definido (se titular não está disponível).
Com que frequência testar o plano?
Mínimo anual (disaster recovery drill). Ideal trimestral. Cada teste deve documentar problemas encontrados e melhorias implementadas.
O que fazer com aprendizados de incidentes passados?
Post-mortem obrigatória (reunião de análise 24-48h após incidente). Documentar: o que aconteceu, por quê, o que foi feito certo, o que foi errado, que mudança fazer. Plano de ação para evitar repetição.
Quando escalar para fornecedor externo?
Se problema não é resolvido em RTO pré-definido (ex: 2 horas), sem hesitar contacte MSP ou fornecedor especializado. Melhor "pedir ajuda cedo" do que "descobrir tarde que não consegue sozinho".