Plano de continuidade de negócios: como voltar a operar em horas, não em dias

Backup é cópia de dado. Plano de continuidade de negócios é o conjunto de decisões, papéis e procedimentos que faz a empresa voltar a operar dentro de um prazo definido, mesmo com o ambiente destruído.

Resumo rápido

• A diferença entre backup, disaster recovery e continuidade, em uma frase cada.
• Como fazer a Análise de Impacto no Negócio (BIA) e tirar dela o RTO e o RPO de cada processo.
• Um método de seis etapas para sair do backup solto e chegar a um plano testado.
• Tabela com cinco cenários: o que para e qual estratégia de recuperação usar.

A cena: o backup existia e a empresa ficou quatro dias parada

Segunda-feira, sete da manhã. O servidor de arquivos não responde e o ERP mostra erro de conexão. Meia hora depois, a suspeita vira certeza: os arquivos estão criptografados e há um bilhete de resgate na tela.

A primeira pergunta da diretoria é sempre a mesma: “temos backup?”. A resposta também: “temos”. O alívio dura até a tarde, quando se descobre que ninguém sabe qual foi a última restauração bem-sucedida, que a cópia estava no mesmo servidor de rede e que restaurar a base leva dezoito horas.

Quem autoriza desligar a rede? O faturamento pode emitir nota no papel? Não há resposta escrita para nenhuma dessas perguntas. A empresa volta na quinta-feira. Não faltou tecnologia. Faltou plano.

O custo de não ter plano: faça a conta em cinco minutos

• Custo da hora parada: (faturamento mensal + folha da área afetada) ÷ horas úteis do mês.
• Incidente sem plano: custo da hora × horas de parada estimadas hoje.
• Incidente com plano: custo da hora × o prazo de retorno que você quer contratar.

A diferença entre as duas últimas linhas é o que a continuidade entrega em um único evento. Compare com o custo anual das medidas de recuperação: a decisão vira aritmética.

Some o que não aparece na planilha: hora extra para relançar o papel, multa por prazo perdido, cliente que não volta. E o risco regulatório: com dado pessoal envolvido, a LGPD (Lei 13.709/2018, art. 52) prevê multa de até 2% do faturamento no Brasil, limitada a R$ 50 milhões por infração.

A causa-raiz: backup virou sinônimo de plano

Na maioria das empresas médias alguém contratou backup, marcou a caixinha e o assunto morreu ali. Mas os três termos respondem a perguntas diferentes.

Conceito	O que é, em uma frase	Pergunta que responde
Backup	Cópia dos dados guardada em outro lugar, para ser restaurada depois.	Eu ainda tenho o dado?
Disaster recovery (DR)	Recursos e procedimentos técnicos para colocar os sistemas de volta no ar após um desastre.	Em quanto tempo o sistema volta?
Continuidade (PCN ou BCP)	Plano de como a empresa segue operando durante e após a crise, incluindo pessoas e alternativas manuais.	A empresa continua entregando?

Ter backup sem plano é ter o ingrediente sem a receita. E vale colar na parede da TI: backup não testado não é backup, é esperança. Enquanto ninguém restaurar de verdade, é só um arquivo grande de utilidade desconhecida.

A segunda causa é organizacional. Continuidade vira assunto de TI, mas decidir quanto tempo o faturamento pode parar é da diretoria. A TI executa; quem define a tolerância é o negócio.

Antes do método: a Análise de Impacto no Negócio (BIA)

A BIA (Business Impact Analysis, ou Análise de Impacto no Negócio) é a reunião que dá origem ao plano. Nela não se fala de servidor, e sim de processo. Três perguntas para cada um:

1. Se este processo parar, o que acontece com o cliente, com o caixa e com a obrigação legal?
2. Qual o tempo máximo tolerável de parada antes que o dano vire irreversível?
3. Qual a perda máxima de dados aceitável: uma hora de lançamentos? um dia inteiro?

Das respostas 2 e 3 saem os dois números que governam todo o investimento:

• RTO (Recovery Time Objective): tempo máximo aceitável entre a parada e a volta do processo ao ar.
• RPO (Recovery Point Objective): quantidade máxima de dados que a empresa aceita perder, medida em tempo desde o último ponto de recuperação.

RTO e RPO não são iguais para a empresa toda. Faturamento e expedição podem exigir duas horas; os arquivos do marketing aguentam um dia. Tratar tudo igual é caro demais ou frouxo demais.

Método em seis etapas para montar o plano de continuidade de negócios

A referência internacional de continuidade é a ISO 22301. Na segurança, o NIST Cybersecurity Framework 2.0 trata o tema nas funções Responder e Recuperar. Não é preciso certificar nada para usar a lógica das duas.

1. Mapear processos e sistemas críticos

Liste os processos que geram receita, atendem cliente ou cumprem obrigação legal. Anote de que sistema, dado, link e pessoa cada um depende. Os pontos únicos de falha aparecem sozinhos: o servidor sem par, o único colaborador que sabe emitir nota, o link sem reserva.

Classifique em crítico, importante e adiável. Sem essa classificação, tudo vira urgente na hora da crise.

2. Definir RTO e RPO por processo

Leve a lista à diretoria e aos donos das áreas. Quem define o prazo tolerável é quem responde pelo resultado, não a TI. Registre o acordo por escrito, com nome e data.

Quando pedirem RTO de quinze minutos para tudo, mostre o custo da redundância necessária. A conversa se ajusta sozinha e sobra um número financiável.

3. Desenhar as estratégias de recuperação

Escolha como cada processo crítico volta: redundância de equipamento, réplica em outro servidor ou site, nuvem, sítio alternativo de trabalho e procedimento manual de contingência — o “faturar no papel até o sistema voltar”. O manual é o mais barato e o mais esquecido, e segura o cliente nas primeiras horas.

Cenário	O que para	Estratégia de recuperação
Ransomware	Quase tudo: servidores, arquivos, ERP e muitas vezes o próprio backup em rede	Cópia isolada e imutável (regra 3-2-1), rede segmentada, restauração ensaiada, plano de comunicação e acionamento jurídico
Falha de hardware do servidor	Os sistemas hospedados naquele equipamento	Virtualização com host reserva, peça de reposição e suporte com prazo definido; réplica para os sistemas de RTO curto
Queda do link de internet	Nuvem, e-mail, sistemas remotos e emissão fiscal	Segundo link de operadora distinta com troca automática e 4G/5G de contingência nos postos essenciais
Erro humano ou exclusão de arquivo	Um dado ou uma pasta, quase sempre em horário de pico	Versionamento e lixeira com retenção definida, pontos de restauração frequentes, restauração granular sem derrubar o sistema
Incêndio ou escritório indisponível	O local inteiro: pessoas, rede e equipamentos	Dados fora do site, sistemas essenciais acessíveis remotamente, trabalho de casa ou de sítio alternativo, contatos impressos

No cenário de ransomware, a cópia isolada é o que separa o incidente do desastre. Vale reler como a regra de backup 3-2-1 protege sua empresa contra ransomware.

4. Escrever o plano: papéis, telefones e ordem de acionamento

O plano precisa ser curto e utilizável sob pressão. Responde: quem declara a crise, quem faz o quê, em que ordem e quando comunicar cliente, seguradora e autoridade.

• Coordenador da crise e substituto, com telefone pessoal.
• Contatos de fornecedores: internet, suporte do ERP, elétrica, seguro, jurídico.
• Ordem de recuperação dos sistemas, do mais crítico ao adiável.
• Critério para acionar a contingência manual e modelo de comunicado.

Guarde uma cópia impressa e outra fora da rede. Plano salvo apenas no servidor criptografado é piada pronta.

5. Testar, com periodicidade definida

É a etapa que quase ninguém cumpre e a única que prova o plano. Três níveis, do mais barato ao mais completo:

• Teste de mesa: a equipe se reúne, alguém narra o cenário e cada um diz o que faria. Acha buracos em uma hora.
• Restauração real: restaurar um sistema em ambiente separado e cronometrar. É aqui que se descobre se o RTO combinado é ficção.
• Simulação completa: exercício com a operação, incluindo o procedimento manual, em janela combinada.

Defina a periodicidade no plano e registre cada teste: tempo medido, o que falhou e quem corrige até quando. Sem registro, não há aprendizado.

6. Revisar após cada mudança e cada incidente

Trocou o ERP, migrou para nuvem, abriu filial, mudou o responsável pelo faturamento? O plano envelheceu. Mudança relevante dispara revisão.

Depois de qualquer incidente, mesmo pequeno, faça a análise pós-evento: o que aconteceu, quanto tempo levou e o que entra no plano. Incidente sem lição vira reincidência. É o ciclo de Responder e Recuperar do NIST CSF 2.0, alimentado por monitoramento de infraestrutura.

Checklist de autoavaliação

Marque o que sua empresa não tem hoje:

• Lista dos processos críticos, com RTO e RPO acordados com a diretoria.
• Uma cópia de backup isolada da rede.
• Registro da última restauração testada, com data e tempo medido.
• Documento com papéis, ordem de acionamento e telefones, guardado fora da rede.
• Alternativa para o link de internet e para o servidor principal.
• Procedimento manual de contingência conhecido pelas áreas.
• Periodicidade de testes definida, com resultado registrado.
• Revisão do plano após a última mudança de sistema ou de equipe.

Três ou mais marcados: a empresa depende de improviso. Cinco ou mais: um incidente comum vira paralisação de dias.

Quando chamar uma consultoria — e quando não chamar

Faz sentido chamar quando:

• A operação depende de sistemas e ninguém sabe dizer em quantas horas ela voltaria.
• Existe backup, mas nunca houve restauração testada.
• A TI é de uma pessoa só, e essa pessoa é o plano de continuidade.
• Cliente, seguradora ou auditoria começou a pedir evidência de continuidade.

Não faz sentido chamar quando:

• A empresa é pequena, roda tudo em nuvem e uma tarde parada não muda o mês.
• Você já tem plano escrito, testado e revisado; falta cumprir a rotina.
• A diretoria ainda não aceitou discutir prazos de recuperação. Sem essa decisão, qualquer plano é peça de gaveta.

Perguntas frequentes

Quanto custa montar um plano de continuidade de negócios?

Depende do RTO escolhido. Documentar processos, definir prazos e testar restauração exige tempo, não investimento pesado. O custo sobe quando o negócio pede retorno em poucas horas, porque entram redundância e réplica. Por isso a conta da hora parada vem antes.

Já tenho TI interna. Ela não pode fazer isso sozinha?

Pode, e deve conduzir a execução. O que falta é tempo e mandato para negociar prazos com a diretoria. A consultoria traz método, referência externa e teste independente. O plano segue sendo do seu time, agora com munição para defender o que já pedia.

Meus sistemas estão na nuvem. Ainda preciso de plano?

Sim. A nuvem tira o risco de hardware, mas mantém o do link, o de conta comprometida, o de exclusão acidental e o de erro de configuração. E a maioria dos serviços retém dados excluídos por prazo limitado. O plano muda de conteúdo, não some.

Com que frequência devo testar a restauração?

Defina no plano e cumpra. Um ritmo comum é restauração pontual mensal, teste de mesa semestral e simulação ampla uma vez por ano. Vale mais um ritmo modesto e cumprido do que um calendário que ninguém executa.

Preciso certificar a empresa na ISO 22301?

Não. Certificação só faz sentido se cliente ou contrato exigir. A maioria das empresas médias se beneficia só da lógica da norma: analisar impacto, definir prazos, desenhar estratégias, testar e revisar. O ganho está no método.

---

Plano é o que transforma dias de parada em horas

A diferença entre voltar em horas e voltar em dias raramente está no equipamento. Está em ter decidido antes o que é crítico, em quanto tempo precisa voltar e quem faz o quê quando o telefone toca.

Comece pela BIA, defina RTO e RPO com a diretoria, escolha as estratégias e teste. Nossa equipe de redes, servidores e segurança conduz esse trabalho, e o monitoramento antecipa boa parte das paradas.