O que é um plano de continuidade de negócios (e por que ele não é disaster recovery)
Plano de continuidade de negócios — ou BCP, de Business Continuity Plan — é o conjunto documentado de decisões, procedimentos e responsabilidades que permite à empresa continuar entregando seus produtos e serviços durante e depois de um evento disruptivo. A palavra-chave aqui é continuar. Não se trata de voltar ao normal em algum momento futuro indeterminado: trata-se de manter a operação funcionando, mesmo que em capacidade reduzida, enquanto o problema é resolvido.
Existe uma confusão muito comum no mercado brasileiro entre BCP e disaster recovery (DR). O plano de recuperação de desastres é um componente técnico: ele responde à pergunta "como eu recupero meus servidores, meus dados e minha infraestrutura depois de uma falha?". O BCP é mais amplo e responde a uma pergunta diferente: "como a empresa continua vendendo, atendendo, faturando e pagando fornecedores enquanto a TI está sendo recuperada — ou enquanto o prédio está inacessível, ou enquanto metade da equipe está doente?".
Na prática, o DR é um capítulo dentro do BCP. Uma empresa pode ter um plano de recuperação impecável, com replicação síncrona entre datacenters e RTO de 15 minutos, e ainda assim parar completamente porque ninguém sabe quem autoriza a ativação do plano fora do horário comercial, porque o telefone do responsável pelo ERP está apenas no Outlook que caiu junto, ou porque o processo de emissão de nota fiscal depende de uma planilha que estava no notebook do analista de faturamento. Esses são problemas de continuidade, não de tecnologia.
Análise de impacto: descobrindo o que realmente não pode parar
Todo BCP sério começa por uma BIA — Business Impact Analysis, ou análise de impacto no negócio. É o exercício de mapear os processos críticos da empresa e quantificar o que acontece quando cada um deles para. Sem essa etapa, o plano vira uma lista de intenções genéricas que ninguém consegue priorizar no momento da crise.
A BIA precisa de números, não de adjetivos. "O ERP é muito importante" não ajuda ninguém. "A parada do ERP impede a emissão de notas fiscais, gerando perda estimada de R$ 40 mil por dia útil e risco de multa contratual com três clientes a partir de 48 horas" é uma informação acionável. É esse tipo de dado que justifica investimento em redundância e que define a ordem em que os sistemas voltam.
Na entrevista com cada área, quatro perguntas costumam extrair o essencial:
- Quais atividades desta área não podem ficar mais de 24 horas paradas? Isso separa o crítico do importante.
- De quais sistemas, dados, pessoas e fornecedores essas atividades dependem? Aqui aparecem as dependências ocultas — a planilha compartilhada, o certificado digital em um token físico, o único colaborador que sabe fechar a folha.
- Existe uma forma manual ou alternativa de executar essa atividade? É a base dos procedimentos de contingência.
- Qual o custo por hora ou por dia de indisponibilidade? Financeiro, contratual, regulatório e reputacional.
Dessa análise saem os dois indicadores que estruturam todo o restante do plano. O RTO (Recovery Time Objective) é o tempo máximo tolerável de indisponibilidade de um processo ou sistema. O RPO (Recovery Point Objective) é a quantidade máxima de dados que a empresa aceita perder, medida em tempo — um RPO de 4 horas significa que o backup precisa rodar, no mínimo, a cada 4 horas. Definir RTO e RPO por sistema, e não um número único para a empresa inteira, é o que torna o plano economicamente viável: proteger o ERP com replicação contínua e o servidor de arquivos de marketing com backup diário é uma decisão racional de alocação de recursos.
Os três pilares: pessoas, processos e tecnologia
A maior parte dos planos de continuidade que encontramos em auditoria cobre bem a camada de tecnologia e ignora as outras duas. É exatamente aí que os planos falham quando são acionados de verdade.
Pessoas. A crise revela imediatamente quem é insubstituível — e essa é uma péssima notícia. Todo processo crítico precisa ter um responsável primário e ao menos um substituto treinado, não apenas nomeado em um organograma. Isso exige documentação de procedimentos, rodízio ocasional de funções e, principalmente, aceitar que conhecimento tácito na cabeça de uma pessoa é um risco operacional. Também entra aqui o plano de acesso remoto: se o escritório ficar inacessível por um alagamento, uma interdição ou um incêndio no andar de cima, quantas pessoas conseguem trabalhar de casa amanhã de manhã, com quais equipamentos e com qual conectividade?
Processos. Para cada processo crítico identificado na BIA, é preciso definir um modo de operação degradado. Como emitir pedidos se o sistema de vendas cair? Como registrar atendimentos se o help desk sair do ar? Como pagar a folha se o banco estiver indisponível na data? Muitas dessas respostas são analógicas e simples — um formulário em papel, uma planilha offline padronizada, um telefone de contingência no fornecedor — mas precisam estar decididas e comunicadas antes, porque no meio da crise ninguém tem tempo de inventar processo.
Tecnologia. É a camada mais madura na maioria das empresas, mas ainda com pontos cegos recorrentes: backup que nunca foi restaurado em teste real, replicação para um site secundário que compartilha o mesmo link de internet do principal, credenciais administrativas guardadas apenas no cofre que depende do Active Directory que caiu, e documentação de rede desatualizada há três anos. Um bom exercício é a pergunta do elo único: para cada componente crítico, existe algum ponto onde uma única falha derruba tudo?
Backup que nunca foi restaurado não é backup — é uma esperança com custo de armazenamento. A única forma de saber se a restauração funciona é executá-la periodicamente, cronometrada, em ambiente isolado.
Comunicação em crise: o componente mais subestimado
Quando um incidente grave acontece, a informação se torna o recurso mais escasso da empresa. Clientes ligam querendo saber se seus pedidos serão entregues, colaboradores não sabem se devem ir ao escritório, fornecedores cobram posicionamento e, dependendo da natureza do evento — especialmente em casos de vazamento de dados — há obrigações legais de notificação com prazo contado em horas.
Um plano de comunicação de crise define, antecipadamente, quem fala, com quem, por qual canal e com qual mensagem. Os elementos mínimos são:
- Árvore de acionamento com nomes, cargos, telefones pessoais e e-mails alternativos — impressa e distribuída fisicamente, porque o diretório corporativo pode estar exatamente dentro do sistema que caiu.
- Canal primário e secundário de comunicação interna. Se a comunicação da empresa depende inteiramente do Microsoft Teams e o incidente afeta a identidade corporativa, é preciso ter um grupo alternativo já criado e testado.
- Porta-voz único para comunicação externa, com mensagens-modelo pré-aprovadas pelo jurídico para os cenários mais prováveis.
- Cadência de atualização. Comunicar de hora em hora, mesmo sem novidades, reduz drasticamente o ruído e o volume de contatos paralelos.
- Critérios de notificação regulatória, especialmente sob a LGPD, com o responsável e o prazo claramente atribuídos.
Vale registrar uma regra prática: o silêncio é interpretado como incompetência ou como ocultação. Comunicar cedo, com o que se sabe e o que ainda não se sabe, preserva mais reputação do que esperar o diagnóstico completo para só então falar.
Testar, revisar e manter o plano vivo
Plano de continuidade guardado em PDF na intranet e nunca exercitado tem valor próximo de zero. O teste é o que transforma documento em capacidade real, e ele pode ser feito em níveis crescentes de custo e realismo.
O tabletop é o formato mais barato e mais subestimado: reúne-se a equipe de crise por duas horas, apresenta-se um cenário ("um ransomware criptografou os servidores de arquivos e o ERP às 6h de uma segunda-feira") e cada participante descreve o que faria. Só nesse exercício costumam aparecer três ou quatro lacunas graves — contatos desatualizados, alçadas indefinidas, dependências que ninguém tinha mapeado.
O teste funcional valida componentes isolados: restaurar um servidor a partir do backup e cronometrar; ativar o link de internet redundante e medir a queda; fazer a equipe de faturamento emitir dez notas pelo procedimento de contingência. Já a simulação completa exerce o plano inteiro em janela programada, com failover real para o ambiente secundário. É mais cara e mais arriscada, mas é a única que comprova o RTO na prática.
Independentemente do formato, todo teste precisa gerar um relatório com desvios encontrados, responsáveis e prazos. E o plano deve ser revisado sempre que houver mudança relevante — novo sistema crítico, mudança de sede, fusão, troca de fornecedor estratégico — e, no mínimo, uma vez por ano. Recomendamos ao menos um tabletop semestral e um teste de restauração trimestral como linha de base para empresas de médio porte.
Como a Duk apoia a continuidade da sua operação
Montar e sustentar um plano de continuidade exige tempo, método e uma visão realista da infraestrutura — três coisas que a equipe interna de TI raramente tem sobrando enquanto sustenta a operação do dia a dia. É nesse ponto que um parceiro de TI faz diferença: trazendo o histórico de quem já viu o plano ser acionado de verdade em outros ambientes.
A Duk Informática & Cloud atua há mais de 18 anos e atende hoje mais de 550 empresas, com estrutura de datacenter própria em Alphaville e certificação Microsoft Gold Partner. Nossa atuação em continuidade cobre o ciclo completo: análise de impacto e definição de RTO/RPO por sistema, desenho da arquitetura de backup e replicação, testes periódicos de restauração documentados, monitoramento 24/7 com SLA e apoio à equipe do cliente na construção dos procedimentos de contingência e do plano de comunicação.
Se a sua empresa ainda não sabe responder com precisão quanto tempo levaria para voltar a faturar depois de uma parada grave, esse é o melhor momento para descobrir — em uma avaliação planejada, e não durante o incidente. Fale com a nossa equipe e conheça o diagnóstico de continuidade que aplicamos em nossos clientes.
Quer proteger e otimizar a TI da sua empresa?
Agende um diagnostico gratuito com nossos especialistas certificados.
Falar com Especialista