Como criar um plano de resposta a incidentes de TI que funciona na crise

O servidor caiu às 3 da manhã. Quem acorda? Quem decide desligar o serviço? Quem avisa o cliente? Se a resposta depende de quem estiver acordado no grupo de mensagens, sua operação não tem um plano: tem sorte.

Times maduros respondem a incidentes no reflexo porque decidiram tudo antes. Papéis, níveis de severidade, cadeia de acionamento, canais de comunicação e procedimentos de contenção já estão documentados. Ou seja, ninguém gasta os primeiros minutos da crise decidindo como decidir.

Neste guia, você vai aprender a montar o plano para a operação de TI como um todo, não apenas para ataques cibernéticos. Além disso, verá como testá-lo, mantê-lo vivo e conectá-lo ao monitoramento para que ele se acione sozinho.

O que é um plano de resposta a incidentes de TI

Um plano de resposta a incidentes de TI é o documento que define, antes da crise, como a operação reage a falhas. Ele estabelece quem assume o comando, como classificar a severidade, quem é acionado, o que comunicar e quais procedimentos executar. Em resumo, transforma o improviso da madrugada em processo repetível.

O conceito nasceu na segurança cibernética, mas vale para toda a operação. Indisponibilidade, degradação de performance, falha de hardware ou ataque: o mecanismo de resposta é o mesmo. Por isso, trate o plano como parte da gestão de incidentes de TI, não como documento exclusivo do time de segurança.

Vale destacar também o que o plano não é. Ele não é uma coleção de runbooks (esses são os procedimentos que o plano referencia), nem o documento de continuidade do negócio. O plano de resposta é curto, operacional, escrito para ser lido em 5 minutos por alguém sob pressão.

E quem precisa de um? Em resumo, qualquer operação que sustenta serviço crítico: e-commerce, SaaS, hospital, indústria, órgão público. No entanto, o tamanho muda a sofisticação, não a necessidade. Uma equipe de cinco pessoas precisa das mesmas respostas que um NOC de cem, apenas em um documento menor.

Os números explicam a urgência. O relatório Cost of a Data Breach da IBM estima o custo médio global de uma violação de dados em US$ 4,44 milhões em 2025.

Do lado da operação, o cenário é parecido. A análise anual do Uptime Institute mostra que quase 40% das organizações tiveram um outage grave por erro humano em 3 anos. Desses casos, 85% envolvem procedimentos ignorados ou falhos.

Procedimento ignorado é sintoma de plano fraco: ou o documento não existe, ou ninguém treinou com ele. Por isso, os dois pilares deste guia são estrutura enxuta e teste frequente. Plano que ninguém consegue seguir sob pressão é apenas burocracia com boas intenções.

Plano de resposta, contingência e disaster recovery: qual a diferença

A diferença está na pergunta que cada documento responde. O plano de resposta define como reagir ao incidente agora, minuto a minuto. O plano de contingência, por outro lado, define como manter o negócio operando durante uma interrupção prolongada.

Já o disaster recovery cuida da reconstrução da infraestrutura após um desastre físico ou lógico. Os três se complementam, mas não se substituem. A tabela resume os limites de cada um:

 
Um exemplo torna os limites concretos. O banco de dados primário corrompeu: a resposta a incidentes isola o dano e ativa a réplica. Se a recuperação vai levar dias, a contingência entra em cena com o procedimento manual de faturamento. Em paralelo, o disaster recovery reconstrói o ambiente a partir dos backups.

Na prática, portanto, um incidente grave pode acionar os três documentos em sequência. A resposta contém o dano, a contingência segura o negócio, a recuperação reconstrói o que foi perdido. O plano de resposta é sempre o primeiro a entrar em campo.

Cabe ressaltar que muitos times confundem os três porque herdaram um documento único chamado “plano de crise”. Se esse é o seu caso, comece separando as perguntas: o que fazemos agora, como o negócio continua, como reconstruímos. Três respostas, três documentos enxutos, três donos claros.

O que documentar antes da crise: os componentes do plano

Um plano útil cabe em poucas páginas e responde perguntas concretas. Antes de escrever procedimentos extensos, documente quatro componentes essenciais. Eles formam o esqueleto que sustenta qualquer resposta, do incidente trivial à crise de madrugada.

São eles: o inventário de serviços com contatos, a matriz de severidade com a escalação, o desenho da comunicação e os runbooks dos cenários prováveis. Nada disso exige ferramenta sofisticada; inclusive, uma página bem organizada por componente já coloca a operação à frente da maioria.

Inventário de serviços críticos e contatos

Antes de tudo, o plano lista os serviços críticos, seus donos, dependências e horários de maior impacto. Inclua também a lista de contatos sempre atualizada: plantonistas, fornecedores, gestores. Durante um incidente, procurar telefone é desperdício puro de tempo de resolução.

Nesse inventário, registre ainda as dependências entre serviços. Por exemplo: o checkout que cai pode ser vítima do gateway de pagamento, que por sua vez depende de um DNS externo. Mapear essas correntes antes da crise economiza os minutos mais confusos do incidente.

Matriz de severidade e cadeia de escalação

A matriz de severidade de incidentes classifica cada evento por impacto e urgência, de SEV1 a SEV4. Cada nível carrega tempo de primeira resposta e uma cadeia de escalação de alertas pré-definida.

Sem esses níveis, a operação oscila entre acordar todo mundo e não acordar ninguém. Além disso, registre no plano os tempos-alvo por nível. Um SEV1 exige primeira resposta em minutos; um SEV4 pode esperar o expediente seguinte sem culpa.

Um cuidado: severidade não é prioridade de backlog. Ela mede o tamanho do incêndio agora, sobretudo o impacto sobre usuários e receita. Logo, a correção definitiva pode esperar a fila da gestão de problemas; a severidade não espera ninguém.

Comunicação: canais e cadência

Da mesma forma, defina antes da crise os canais internos (war room, canal dedicado no chat) e externos. Uma status page assume a comunicação com usuários: o que falhou, o andamento, a próxima atualização. O plano fixa a cadência por severidade e nomeia quem escreve.

Prepare também modelos de mensagem por cenário. Durante a crise, ninguém redige bem: com o texto-base pronto, o responsável só preenche horário, escopo e próxima atualização. Dessa forma, a primeira comunicação sai em minutos, não em rascunhos disputados no chat.

Runbooks por cenário

Para os cenários mais prováveis, o plano aponta runbooks: procedimentos passo a passo de diagnóstico e contenção. Eles eliminam o tempo de decisão no meio da madrugada e reduzem a dependência de heróis que carregam tudo na memória.

Comece pelos 3 a 5 cenários que mais doeram nos últimos 12 meses: queda do banco, fila estourada, certificado vencido, disco cheio. Em seguida, valide cada runbook com alguém que nunca executou o procedimento. Se essa pessoa trava, o documento ainda depende de contexto que só existe na cabeça de alguém.

As fases da resposta a incidentes

Os dois frameworks de referência organizam a resposta em fases equivalentes. A norma NIST SP 800-61 agrupa o ciclo em 4 fases; o SANS Institute separa em 6. Para a operação de TI, o essencial é o que o plano define em cada uma:

 
Sobre os frameworks, a escolha importa menos que a consistência. O NIST agrupa contenção, erradicação e recuperação em uma fase única; o SANS as separa. Ambos funcionam como referência, portanto adapte a nomenclatura ao seu contexto e mantenha a mesma em todos os documentos.

Duas observações práticas sobre as fases. Primeiro, elas se sobrepõem: a contenção pode começar enquanto a triagem ainda refina a severidade. Segundo, a comunicação não é uma fase, é uma trilha contínua que atravessa todas elas, da detecção ao encerramento.

Outro ponto decisivo: a detecção define a qualidade de todas as fases seguintes. Alerta atrasado ou impreciso contamina triagem, contenção e comunicação. Por isso, o plano precisa nascer conectado ao monitoramento, tema da última seção deste guia.

Quem faz o quê: papéis na resposta a incidentes

Todo incidente relevante precisa de um dono único. O comandante do incidente coordena a resposta, decide prioridades e mantém o foco da sala. Ele não executa a correção: orquestra quem executa. Em operações menores, o papel cabe ao líder do plantão; em maiores, é uma função rotativa com treinamento próprio.

Ao lado dele, o responsável pela comunicação publica as atualizações e blinda o time técnico das cobranças. Os especialistas de domínio investigam e aplicam a correção. Por fim, a gestão de on-call garante que sempre exista alguém acionável para cada serviço crítico.

Durante a crise, esses papéis se encontram no war room: o canal único onde as decisões acontecem. O comandante conduz, os especialistas reportam o que testaram, o responsável pela comunicação extrai dali as atualizações. Conversa paralela fora do canal é informação perdida para a linha do tempo do incidente.

Atenção também à troca de turno durante incidentes longos. O plano define o ritual de passagem: o comandante que sai resume o estado, as hipóteses descartadas e as ações em andamento para quem entra. Ou seja, cada virada de plantão continua a investigação em vez de reiniciá-la do zero.

Formalize tudo em uma matriz simples de responsabilidades: quem executa, quem aprova, quem é consultado, quem é informado. Em seguida, publique essa matriz no próprio plano. Papel que só existe na cabeça do gestor desaparece exatamente quando o gestor está de férias.

Como testar e manter o plano vivo

Plano não testado é ficção bem formatada. O teste começa barato: exercícios de mesa (tabletop), nos quais o time percorre um cenário hipotético narrando o que faria. Uma hora de exercício revela contatos desatualizados, papéis ambíguos e runbooks incompletos.

Um roteiro simples para a primeira rodada: escolha o cenário do último incidente grave, reúna o time por uma hora e conduza pela linha do tempo real. Ao final, compare as decisões do exercício com as que foram tomadas no incidente verdadeiro.

Depois disso, evolua para simulações reais (game days), com falhas provocadas em ambiente controlado. Elas testam o que o tabletop não alcança: automações, permissões de acesso, tempo real de acionamento. Agende pelo menos um ciclo por trimestre para os cenários de maior risco.

Meça os testes como mediria um incidente real. Tempo até o primeiro acionamento, tempo até a decisão de contenção, número de contatos errados encontrados. Esses indicadores viram baseline: a cada rodada, a operação compara a resposta com a anterior e enxerga a evolução.

Cada incidente real também é um teste involuntário do plano. A análise post-mortem compara o que o documento previa com o que de fato aconteceu: onde a resposta travou, o plano muda. Além disso, revise contatos, severidades e runbooks a cada mudança relevante de arquitetura.

Defina, por fim, um dono para o documento. Sem responsável nomeado, porém, o plano envelhece em silêncio: contatos mudam, serviços nascem, severidades perdem sentido. O dono não escreve tudo sozinho, mas garante a revisão trimestral e cobra as ações que os post-mortems geraram.

Automação e monitoramento: o plano que se aciona sozinho

O melhor plano dispara sem intervenção humana nas fases iniciais. Quando a plataforma de monitoramento de TI confirma a falha, ela registra o incidente, aplica a severidade inicial e aciona o plantonista correto.

Os primeiros minutos são os mais caros. Com a automação, eles deixam de depender de alguém perceber o alerta no celular no meio da noite. Assim, o plano deixa de ser um documento que alguém precisa lembrar de abrir e vira o comportamento padrão da operação.

Como resultado, o ganho aparece nas métricas. O tempo médio de reconhecimento despenca quando o acionamento é automático, bem como o tempo total de resolução, puxado pela contenção mais cedo. Consequentemente, o plano deixa de ser promessa e passa a mostrar resultado em número.

No entanto, automação sobre ruído só acelera o caos. Antes de acordar pessoas, a operação precisa filtrar falsos positivos, correlacionar eventos relacionados e enriquecer o alerta com contexto. Caso contrário, o plano perfeito no papel afoga o time em acionamentos vazios.

É esse papel que o KeepGreen cumpre na prática. Ele limpa o ruído do monitoramento, aponta a causa raiz com IA e aciona a equipe pelo canal definido no plano. Ou seja, a resposta começa com o incidente já explicado, com contexto e solução sugerida na mão do plantonista.

Conclusão

Um plano de resposta a incidentes de TI não elimina incidentes: elimina o improviso. A falha das 3 da manhã continua acontecendo, mas encontra uma operação que sabe quem comanda, quem comunica, o que executar e quando escalar. Essa diferença se mede em minutos de indisponibilidade e em confiança preservada.

Comece pequeno e concreto. Documente o inventário com contatos, a matriz de severidade, a cadência de comunicação e dois ou três runbooks dos cenários mais prováveis. Em seguida, marque o primeiro exercício de mesa: uma hora de simulação vale mais que dez páginas de teoria.

Se a sua operação ainda responde a incidentes na base do susto, a OpServices ajuda a estruturar o caminho completo. Monitoramento, central de eventos com IA e processo de resposta de ponta a ponta: fale com nossos especialistas.