Plano de continuidade de negócios: o fornecedor que para junto com a sua empresa

Quase todo modelo de plano de continuidade de negócios começa pelo mesmo cenário: o prédio pegou fogo, a enchente fechou a rua, a energia caiu por dias. São riscos reais, mas raramente são o que tira uma empresa média do ar numa terça-feira qualquer. O que costuma tirar é mais banal: o sistema de um terceiro parou, e com ele parou tudo o que dependia desse sistema.

Este guia monta o PCN a partir dessa realidade. Mostra o que é o plano e de onde vêm os conceitos, como fazer a análise de impacto por processo e por fornecedor, como definir RTO e RPO sem jargão, o que o documento precisa conter numa empresa de 20 a 200 pessoas e como testar tudo em uma tarde, sem parar a operação.

O que é plano de continuidade de negócios (PCN)?

O plano de continuidade de negócios é o conjunto de decisões, tomadas com antecedência, sobre como manter os processos essenciais funcionando durante uma interrupção e como voltar ao normal depois dela. Ele não trata da causa — ataque, pane, falta de luz, fornecedor fora do ar —, e sim do efeito: o processo que parou e precisa continuar.

O guia de planejamento de contingência do NIST, o instituto de padrões dos Estados Unidos, descreve o plano de continuidade como focado em sustentar os processos de negócio durante e depois de uma interrupção, e dá como exemplos a folha de pagamento e o atendimento ao cliente. O mesmo guia admite que o plano cubra só as funções consideradas prioritárias — o que, para uma empresa média, é a melhor notícia possível: não é preciso planejar tudo de uma vez.

Na prática, o PCN responde a quatro perguntas para cada processo crítico: o que acontece se ele parar, por quanto tempo isso é tolerável, o que se faz enquanto ele estiver parado e quem decide. Se o documento não responde a essas quatro, ele é um inventário de riscos, não um plano.

Qual a diferença entre PCN, plano de recuperação de desastres e plano de resposta a incidentes?

Os três se confundem porque são acionados juntos, mas cada um tem um objeto diferente. O de resposta a incidentes cuida do ataque; o de recuperação de desastres cuida da infraestrutura de TI; o de continuidade cuida do negócio. Um vazamento pode acionar os três ao mesmo tempo — e a pergunta de cada um é outra:

Comparativo elaborado pela Alliance Comunicação com base no NIST SP 800-34 Rev. 1, que descreve cada tipo de plano no capítulo 2.

O NIST registra um detalhe que ajuda a separar os dois primeiros: no vocabulário dele, o plano de recuperação de desastres trata de interrupções que exigem mudar a operação de TI para outro local. Já o plano de resposta a ataques pode ser um anexo do plano de continuidade. Se a sua empresa já tem um plano de resposta a incidentes, ele entra no PCN como uma das causas possíveis — não o substitui.

Por que o fornecedor virou a interrupção mais provável?

Porque a operação de uma empresa média mudou de lugar. A loja virtual roda numa plataforma, o ERP está na nuvem, o atendimento passa pela API de WhatsApp de um parceiro, o pagamento depende de um gateway, o e-mail e os arquivos estão num pacote de escritório online. Cada um desses contratos é uma dependência — e quase nenhum aparece no plano de continuidade herdado da época do servidor no armário.

O caso que tornou isso visível aconteceu em julho de 2024, quando uma atualização defeituosa de um software de segurança derrubou computadores Windows no mundo inteiro. A conta oficial da Microsoft dá a dimensão:

O número que importa ali não é o total, é a proporção: menos de 1% das máquinas bastou para um impacto amplo, porque estavam concentradas em quem opera serviços dos quais outros dependem. Nenhuma das empresas atingidas fez nada de errado naquele dia. Elas apenas dependiam de alguém que errou — e é exatamente esse o cenário que o PCN tradicional, pensado para o prédio, não cobre.

A lição para a empresa média não é trocar de fornecedor, e sim saber, antes de acontecer, quais processos param quando cada fornecedor para. Isso tem nome: análise de impacto nos negócios.

O que é BIA no plano de continuidade de negócios?

A BIA (Business Impact Analysis, ou análise de impacto nos negócios) é a etapa que transforma o medo genérico em números por processo. É ela que diz o que precisa voltar primeiro, quanto tempo cada coisa aguenta parada e quanto vale a pena gastar para encurtar esse tempo. Sem BIA, o PCN vira uma lista de boas intenções.

O mesmo material faz uma observação que vale ouro para quem vai preencher a planilha: o momento da interrupção muda o tamanho da perda. Uma queda de minutos é um incômodo; de horas, pode virar prejuízo sério. E uma loja fora do ar nas semanas antes do pico de vendas perde muito mais do que no mês fraco. Por isso a BIA pergunta “quanto tempo aguenta?”, e não apenas “é importante?”.

A virada que este artigo propõe é simples: em vez de uma linha por local ou por servidor, faça uma linha por processo, com o fornecedor de que ele depende. O quadro abaixo mostra o formato:

O Ready.gov recomenda fazer a BIA com questionário, ouvindo quem conhece cada processo por dentro, e pedir a cada um o impacto se aquela função parar. Na empresa média, isso cabe numa reunião de uma hora com cada gestor — e costuma revelar dependências que nem a TI tinha mapeado, como a planilha compartilhada de onde sai a programação de entregas.

RTO, RPO e MTD: quanto tempo cada processo aguenta parado?

Três siglas resolvem a conversa, e o guia do NIST define cada uma com precisão. Traduzidas para a rotina de uma empresa:

• MTD (tempo máximo tolerável de parada): o tempo total que a direção aceita que um processo fique interrompido, somando todos os impactos. É a decisão de negócio.
• RTO (objetivo de tempo de recuperação): o tempo máximo que um sistema pode ficar indisponível antes de causar impacto inaceitável. É a meta técnica — e precisa ser menor que o MTD, porque depois que o sistema volta ainda há trabalho represado a processar.
• RPO (objetivo de ponto de recuperação): até que ponto do passado os dados podem ser recuperados, considerando a última cópia. Na prática, quantas horas de pedidos, cadastros ou lançamentos a empresa aceita perder ou redigitar.

O NIST observa que o RPO não faz parte do MTD: ele mede quanto dado se tolera perder, não quanto tempo se tolera ficar parado. É por isso que as duas perguntas precisam ser feitas separadamente ao gestor. Um ERP pode aguentar um dia fora do ar e, ao mesmo tempo, não aceitar perder nem uma hora de lançamentos.

Quando o sistema é de um fornecedor, o RPO e o RTO reais dependem do contrato dele, não da sua vontade. Vale ler o acordo de nível de serviço com essa lente: ele promete disponibilidade mensal, mas raramente promete prazo de retorno para uma queda específica. Se o seu RTO é de 4 horas e o fornecedor não garante nada parecido, a diferença precisa ser coberta por um plano B seu. E a sua cópia própria dos dados — o tema do artigo sobre backup em nuvem que o ransomware alcança — é o que segura o RPO quando o fornecedor não segura.

Como elaborar um plano de continuidade de negócios?

O roteiro abaixo foi pensado para uma empresa de 20 a 200 pessoas, sem área dedicada de riscos. Ele cabe em quatro a seis semanas de trabalho em paralelo à operação — prazo que depende, claro, de quantos processos entram no primeiro ciclo.

1. Escolha o escopo do primeiro ciclo

Não comece pela empresa inteira. Escolha os três a cinco processos que, parados, fazem o caixa sentir no mesmo dia — normalmente vender, receber, atender e entregar. O próprio NIST admite um plano focado só nas funções prioritárias. O resto entra no segundo ciclo, com a experiência do primeiro.

2. Faça a BIA por processo e por fornecedor

Para cada processo, liste os sistemas e os fornecedores de que ele depende, incluindo os invisíveis: o provedor de internet, o DNS do domínio, o serviço de e-mail, o certificado digital. Em seguida, pergunte ao dono do processo quanto tempo ele aguenta parado (MTD) e quanto dado aceita perder (RPO).

3. Desenhe um plano B por dependência crítica

Plano B não é necessariamente um segundo fornecedor. Pode ser um procedimento manual: tirar pedido por telefone e anotar em planilha, enviar link de pagamento avulso, publicar uma página estática avisando o que está acontecendo. O critério é um só: a alternativa precisa funcionar dentro do MTD e ser conhecida antes da crise.

4. Defina quem aciona e quem decide

O plano precisa nomear quem declara a interrupção, quem decide ativar a contingência e quem fala com clientes. Nomeie pessoas e substitutos — férias e celular sem bateria acontecem justamente no pior dia.

5. Escreva a comunicação antes de precisar dela

Deixe prontos os textos curtos para equipe, clientes e fornecedores, com espaços para preencher. Interrupção mal comunicada vira crise de reputação; o artigo sobre o relógio da gestão de crise mostra por que as primeiras horas definem a narrativa.

6. Teste, corrija e marque a próxima revisão

O plano só existe depois do primeiro teste. A seção de testes, mais abaixo, mostra como fazer isso em uma tarde. Depois, revise sempre que trocar um fornecedor crítico — e, no mínimo, uma vez por ano.

O que um plano de continuidade de negócios deve conter?

Um PCN de empresa média não precisa de cem páginas. Precisa caber num documento que alguém consiga abrir, entender e executar sob pressão — inclusive em papel, se o próprio sistema de arquivos estiver fora do ar. O conteúdo mínimo:

1. Escopo e objetivo: quais processos o plano cobre e quais ficam para depois.
2. Quadro da BIA: processo, dependências, MTD, RTO e RPO de cada um.
3. Mapa de fornecedores críticos: contato de suporte emergencial, número de contrato, página de status e o que o contrato promete.
4. Critérios de acionamento: o que configura interrupção e quem a declara.
5. Procedimentos de contingência: passo a passo de cada plano B, escrito para quem não é da TI.
6. Árvore de contatos: quem liga para quem, com substitutos.
7. Modelos de comunicação: textos para equipe, clientes e fornecedores.
8. Procedimento de retorno: como processar o que ficou represado e conferir os dados.
9. Registro de testes e revisões: data, o que falhou e o que foi corrigido.

Se procura um modelo de partida, o NIST publica como material suplementar um modelo de BIA e modelos de plano de contingência para sistemas de impacto baixo, moderado e alto, em formato editável. Foram escritos para órgãos federais americanos, então pedem adaptação — mas a estrutura de seções é sólida e gratuita.

Como testar o plano de continuidade em uma tarde?

O formato mais barato é o exercício de mesa (tabletop). O NIST o descreve como um exercício baseado em discussão: um facilitador apresenta um cenário e faz perguntas aos participantes sobre papéis, coordenação e decisões, sem acionar equipamento nenhum. Para sistemas de impacto baixo, o guia considera esse formato suficiente.

Um roteiro de três horas que funciona bem numa empresa média:

1. Reúna o dono de cada processo do escopo, alguém da TI e quem fala com clientes.
2. Anuncie o cenário: “são 10h de uma segunda-feira e o ERP na nuvem está fora do ar, sem previsão de retorno”.
3. A cada 20 minutos, avance o relógio da ficção e acrescente um fato: o atendimento lotou, um cliente grande ligou, o fornecedor publicou que o retorno leva mais 6 horas.
4. Peça que cada um diga o que faz, com quem fala e onde está a informação de que precisa.
5. Anote tudo o que travou: telefone que ninguém tinha, senha guardada num sistema que caiu, decisão sem dono.
6. Feche com a lista de correções, um responsável por item e a data do próximo teste.

Quais são os erros mais comuns no PCN?

• Planejar só o prédio. Incêndio e enchente entram, mas a queda do ERP, do gateway ou da API de WhatsApp — muito mais frequente — fica de fora.
• Confundir backup com continuidade. Backup protege o dado (RPO); não diz como a empresa vende enquanto o sistema não volta (RTO e MTD).
• Guardar o plano onde ele cai junto. Plano só na nuvem corporativa some na mesma pane que deveria resolver. Tenha uma cópia fora, inclusive impressa.
• RTO definido pela TI sozinha. Quanto tempo o processo aguenta é decisão de negócio; a TI responde se a meta é viável e quanto custa.
• Ignorar o contrato do fornecedor. Disponibilidade mensal alta não é promessa de retorno rápido. Leia o SLA com o seu RTO na mão.
• Nunca testar. Plano que nunca passou por um exercício de mesa é hipótese, não plano.
• Escopo grande demais. Tentar cobrir a empresa toda no primeiro ciclo costuma resultar em documento extenso e inacabado.

O que muda no PCN por porte e por setor?

O método é o mesmo; muda o grau de formalidade e quem cobra. A tabela resume uma leitura prática, em ordem crescente de exigência:

Elaborado pela Alliance Comunicação. A linha de setor regulado resume a Resolução CMN nº 4.893/2021, válida para instituições autorizadas pelo Banco Central.

O setor financeiro mostra para onde a régua aponta. A Resolução CMN nº 4.893/2021, que vale para instituições autorizadas a funcionar pelo Banco Central, determina no artigo 19 que a política de continuidade de negócios trate dos procedimentos para a interrupção de serviços relevantes de processamento, armazenamento de dados e computação em nuvem contratados, incluindo cenários que considerem a substituição da empresa contratada. É exatamente o raciocínio deste artigo, transformado em obrigação.

Para a empresa privada não regulada, nada disso é obrigatório. Mas quem vende para bancos, varejistas ou multinacionais tende a receber, cedo ou tarde, um questionário de fornecedor perguntando se existe plano de continuidade e quando foi testado. Ter a resposta pronta passa a ser argumento comercial — a mesma lógica que aparece na nossa leitura sobre política de segurança da informação.

Por onde começar o plano de continuidade hoje

1. Liste os cinco processos que, parados, fazem o caixa sentir no mesmo dia.
2. Para cada um, anote os sistemas e fornecedores de que ele depende — inclusive internet, DNS e e-mail.
3. Pergunte ao dono de cada processo quanto tempo ele aguenta parado e quanto dado aceita perder.
4. Desenhe um plano B por dependência crítica, mesmo que manual.
5. Monte a árvore de contatos e guarde uma cópia do plano fora dos sistemas da empresa.
6. Marque o primeiro exercício de mesa para daqui a 30 dias.

Se a sua empresa quer apoio para mapear as dependências tecnológicas, revisar contratos e montar a contingência, a frente de Tech & Security da Alliance faz esse trabalho com a TI e com os donos de processo. E se a pergunta ainda é mais ampla — onde estão os pontos frágeis da operação digital como um todo —, o diagnóstico gratuito de marketing devolve um retrato da maturidade em tecnologia, dados e presença digital, com as prioridades em ordem.

Continuidade não é sobre prever o desastre certo. É sobre saber, numa terça-feira comum, o que fazer nos primeiros trinta minutos depois que alguém de quem você depende parou de funcionar.