Para muita empresa, ter um plano de continuidade — ou de recuperação de desastre — já parece resolver o assunto. O documento existe, está salvo em algum lugar, alguém aprovou. O guia de planejamento de contingência da NIST, o instituto de padrões técnicos do governo dos Estados Unidos, trata esse documento como só metade do trabalho: a outra metade é testar, treinar e exercitar o plano — e é essa parte que a maioria das empresas nunca chega a fazer.
Um levantamento de 2025 da Databarracks, empresa britânica de recuperação de dados, mostra o tamanho do avanço recente: nove em cada dez organizações testaram algum pedaço da própria capacidade de recuperação nos doze meses anteriores à pesquisa, um salto grande frente aos anos anteriores. Mas a mesma pesquisa aponta um detalhe incômodo — a confiança das empresas na própria recuperação caiu um pouco, e a leitura dos próprios pesquisadores é que o motivo é justamente testar mais: o teste está revelando lacunas que ninguém enxergava antes.
É essa distância que decide o tamanho do prejuízo numa pane real: entre guardar um plano numa pasta e saber, porque ele já foi ensaiado, que funciona com as pessoas que de fato vão executá-lo.
O documento que ninguém abre de novo
Testar "algum pedaço" da recuperação — como mostra o número da Databarracks — costuma significar restaurar um servidor isolado, sozinho, num ambiente controlado. É útil, mas é diferente de reunir as pessoas que estariam de plantão numa pane de verdade e rodar o roteiro inteiro: quem liga para quem, quem decide o quê, quem tem acesso a que sistema.
Esse roteiro completo é o que fica parado. O plano foi escrito uma vez — muitas vezes por uma consultoria, para fechar uma auditoria ou atender a exigência de um cliente maior — e depois guardado numa pasta compartilhada. Ninguém o abre de novo até o dia em que precisa dele, e nesse dia descobre-se junto com a pane: o telefone do fornecedor mudou, a senha do console de emergência não é mais a que está escrita, a pessoa responsável por avisar o banco não trabalha mais na empresa.
A ISO 22301, norma internacional de gestão de continuidade de negócios, trata esse ensaio como etapa obrigatória do próprio ciclo de gestão, não como um extra: depois de planejar, a norma exige testar o plano e registrar o resultado, antes de considerar qualquer coisa pronta. Um documento que nunca passou por essa etapa está, pela própria lógica da norma, incompleto — mesmo que pareça completo no papel.
Um formato comum para esse ensaio, usado inclusive pela CISA — a agência de cibersegurança do governo dos Estados Unidos — é o exercício de mesa: uma simulação em sala, sem desligar nada de verdade, em que cada pessoa responde ao vivo o que faria diante de um cenário de crise. A agência mantém pacotes prontos com mais de cem cenários diferentes, exatamente porque a maior parte do valor do exercício está em descobrir, numa sala tranquila, o que o documento não previu — antes de descobrir isso no meio de uma pane.
Por que o jeito comum não resolve
O jeito comum é escrever o plano, guardar, e torcer. A revisão anual, quando existe, costuma ser uma reunião curta em que alguém lê o documento em voz alta e todo mundo concorda que está bom — sem simular nada, sem testar um único contato, sem cronometrar quanto tempo cada etapa realmente leva.
Outra versão do mesmo problema é distribuir papéis no papel sem checar se ainda fazem sentido: a pessoa listada como responsável pela decisão pode ter trocado de cargo, o fornecedor listado pode ter fechado a conta, o sistema de acesso remoto citado pode ter sido substituído por outro há dois anos. Nada disso aparece revisando o texto — só aparece tentando, de verdade, seguir o roteiro.
O efeito mais caro desse hábito aparece justamente na hora errada: no meio da própria pane, quando a equipe descobre ao vivo que uma etapa do plano depende de algo que não existe mais. Nesse momento, ninguém está testando nada — está improvisando sob pressão, com o negócio parado enquanto decide.
A confiança das empresas na própria recuperação caiu um pouco — sinal de que os testes estão revelando lacunas que antes ninguém via.
O que precisa existir na prática
Um plano de continuidade que funciona quando precisa se apoia em alguns mecanismos verificáveis — não em boa vontade.
Um exercício marcado no calendário, feito de verdade, e não deixado para quando sobrar tempo. Sem data fixa, o ensaio vira a primeira coisa cortada da agenda, mês após mês.
Contato de fornecedor, de banco e de operadora conferido de novo a cada ciclo, não copiado do documento anterior sem checar se ainda funciona.
Senha e acesso de emergência guardados num lugar que funciona mesmo sem a pessoa que sempre usa. Se só uma pessoa sabe entrar no console de emergência, o plano depende dela estar disponível — e ela pode estar de férias justamente no dia da pane.
Um papel específico para quem estiver de plantão naquele dia, não só para quem escreveu o plano. Quem está de plantão raramente é quem redigiu o documento.
Registro do que o exercício revelou, com prazo para corrigir antes do próximo ciclo — sem esse registro, o mesmo problema aparece de novo no ensaio seguinte.
Tempo cronometrado do início ao fim do roteiro, para saber quanto ele realmente leva — e não quanto parece levar só de ler o papel.
É assim que a Skills IT trabalha: com o exercício de continuidade agendado e registrado, e os contatos de fornecedor e os acessos de emergência revisados a cada ciclo, em vez de copiados do documento anterior.
O que muda quando o plano já foi ensaiado
O ganho de ensaiar o plano não é abstrato. Numa pane real, a diferença entre uma equipe que já passou pelo roteiro e uma que está lendo o documento pela primeira vez aparece em minutos: a primeira sabe quem liga, quem decide e onde está o acesso; a segunda gasta esse tempo procurando.
Isso muda o tipo de conversa que acontece durante a crise. Em vez de decidir, ao vivo e sob pressão, quem é responsável por avisar o cliente ou quando desistir de um conserto e seguir para o plano alternativo, a equipe já sabe a resposta — porque já respondeu a essa mesma pergunta, num dia calmo, durante o exercício.
O custo evitado aparece em três lugares: menos hora de equipe reconstruindo decisões que já deveriam estar tomadas, menos risco de um fornecedor ou um cliente perder a confiança por causa de um aviso atrasado, e menos chance de o orçamento de emergência ser gasto resolvendo um problema que o próprio ensaio já teria mostrado antes.
Perguntas para levar à próxima reunião
Antes de revisar o plano de novo só lendo o texto, vale reunir quem estaria de plantão e perguntar:
- Alguém já seguiu esse plano do início ao fim, com as pessoas reais, fora de uma pane de verdade? Se a resposta é não, o plano nunca foi testado — só escrito.
- Os telefones e contatos citados no documento ainda funcionam? Ligar para conferir, hoje, custa poucos minutos.
- Quem substitui a pessoa que sempre resolve isso, se ela estiver de férias ou fora do ar no dia da pane? Um plano com um único responsável não é um plano — é uma dependência.
- Quanto tempo o roteiro realmente leva, cronometrado? A resposta raramente é a mesma que parece no papel.
- O que o último exercício revelou — e isso já foi corrigido? Um problema encontrado e não corrigido vai aparecer de novo, só que da próxima vez pode ser numa pane real.
