Um plano de continuidade de negócios (PCN, ou BCP na sigla em inglês) é o documento que diz como a sua empresa continua entregando os produtos e serviços críticos quando algo a interrompe: quais processos são recuperados primeiro, em quanto tempo, com quais recursos e quem toma as decisões. Um plano que funciona tem sempre as mesmas peças: escopo e critérios de acionamento, equipes e papéis, processos críticos com os seus tempos de recuperação, estratégias e procedimentos para recuperá-los, comunicação e um calendário de testes e revisão.
Mais abaixo você encontra três exemplos por tipo de empresa e um índice de modelo que você pode passar para o Word e preencher com as suas informações.
Os três números que sustentam o plano
Antes de escrever uma única página, o plano precisa de três valores para cada processo crítico. Eles saem da análise de impacto nos negócios (BIA), e não da intuição do responsável de TI.
- MTPD (período máximo tolerável de interrupção). O tempo a partir do qual o dano passa a ser inaceitável: perda de clientes, multas, descumprimento de contratos ou um dano à reputação que não se recupera.
- RTO (tempo objetivo de recuperação). O prazo em que você se compromete a ter o processo funcionando de novo, mesmo que em modo degradado. Sempre abaixo do MTPD, com margem para o que der errado.
- RPO (ponto objetivo de recuperação). Quantos dados você pode se dar ao luxo de perder, medido em tempo. Um RPO de 15 minutos significa que, ao restaurar, podem faltar no máximo os últimos 15 minutos de operações.
Com esses três valores, você já pode escolher a estratégia. Um RTO de quatro horas pede um site alternativo pronto; um de cinco dias permite contratar a alternativa quando o incidente acontece.
Exemplos de plano de continuidade de negócios por tipo de empresa
Os três casos são ilustrativos: nós os construímos para mostrar o raciocínio, e eles não correspondem a clientes nem a números reais. Os tempos mudam com o porte da empresa, seus contratos e sua regulação, então use-os como forma de pensar, e não como valores para copiar.
Instituição financeira: pagamentos e transferências de clientes
Cenário. Um ataque de ransomware deixa o data center principal inoperante às 10 da manhã de um dia útil. O core bancário e a plataforma de pagamentos não respondem.
MTPD de 8 horas. Se os pagamentos de folha e de fornecedores dos clientes empresariais não saem no mesmo dia, o impacto deixa de ser um incômodo e vira descumprimento: clientes que não pagam os seus funcionários, reclamações e uma conversa difícil com o supervisor. O fechamento do dia marca o limite.
RTO de 4 horas e RPO próximo de zero. Quatro horas deixam margem para que, se a primeira recuperação falhar, ainda dê para liquidar antes do fechamento. O RPO precisa ser mínimo porque perder transações confirmadas obriga a conciliar manualmente, com risco de pagamentos duplicados.
Estratégia. Data center alternativo com réplica da base de dados transacional e cópias isoladas da rede, para que o ransomware não as alcance. Enquanto se restaura, um procedimento manual para pagamentos de alto valor, com dupla assinatura e uma lista fechada de operações autorizadas. Comunicação pronta para clientes, agências e supervisor.
Varejo ou logística: expedição a partir do centro de distribuição
Cenário. Uma enchente fecha por uma semana o centro de distribuição (CD) que abastece 80 lojas. O sistema de gestão de armazém (WMS) continua funcionando, mas o prédio não.
MTPD de 72 horas. Suponha que as lojas tenham estoque para três dias nos produtos de maior giro. A partir daí há prateleiras vazias, vendas que vão para a concorrência e penalidades com os shopping centers se a loja não abrir bem abastecida.
RTO de 48 horas. O tempo que leva para colocar um armazém alternativo em operação se o acordo já estiver assinado. Se for preciso procurá-lo durante o incidente, o prazo não é cumprido.
Estratégia. Contrato guarda-chuva com um operador logístico (3PL) que possa receber mercadoria e fazer cross-docking em outra cidade, lista de SKUs prioritários (não é preciso movimentar todo o catálogo para salvar a venda) e acordos com os principais fornecedores para entrega direta na loja durante a contingência.
Empresa de serviços ou de tecnologia: plataforma para clientes
Cenário. O provedor de nuvem sofre uma queda regional e a plataforma que a empresa oferece aos clientes fica indisponível.
MTPD de 24 horas. Aqui quem define são os contratos. Se os acordos de nível de serviço prometem 99,9 % de disponibilidade mensal, a margem é de cerca de 43 minutos por mês; passado esse ponto começam os créditos de serviço e, depois de um dia, os clientes grandes começam a rever a renovação.
RTO de 4 horas e RPO de 15 minutos. O RTO se ajusta ao que o contrato permite sem penalidade grave, e o RPO a quanto trabalho dos clientes é razoável perder.
Estratégia. Infraestrutura que pode ser implantada em uma segunda região com cópias replicadas, procedimento de failover testado, página de status e modelos de aviso a clientes, e home office para a equipe de suporte caso o escritório também seja perdido.
| Empresa | Processo crítico | MTPD | RTO / RPO | Estratégia principal |
|---|---|---|---|---|
| Instituição financeira | Pagamentos e transferências | 8 horas | 4 h / quase zero | Site alternativo com réplica e cópias isoladas |
| Varejo ou logística | Expedição para as lojas | 72 horas | 48 h / mínimo (o WMS continua ativo) | Operador logístico com contrato prévio |
| Serviços ou tecnologia | Plataforma para clientes | 24 horas | 4 h / 15 min | Segunda região e failover testado |
Repare que nenhuma estratégia é improvisada no dia do incidente. Nos três casos, o que permite cumprir o RTO é algo que foi contratado, configurado ou ensaiado antes.
Estrutura de um plano de continuidade de negócios para copiar
Este é o índice que usaríamos no plano de continuidade de negócios de uma empresa média ou grande. Se você passá-lo para o Word, mantenha cada seção com o seu título e substitua as descrições pelo seu conteúdo.
- Controle do documento. Versão, data, dono do plano, quem o aprovou e data da próxima revisão.
- Objetivo e escopo. Quais unidades, processos, produtos e serviços ele cobre, e o que fica explicitamente de fora.
- Critérios de acionamento. Quais fatos acionam o plano, quem pode acioná-lo e como se decide passar de incidente para contingência.
- Organização e papéis. Comitê de crise, coordenador de continuidade, equipes de recuperação por área, substitutos de cada pessoa e árvore de chamadas.
- Processos críticos. Lista priorizada tirada do BIA, com MTPD, RTO e RPO de cada um e os recursos mínimos para operar: pessoas, sistemas, instalações, fornecedores e informação.
- Cenários contemplados. Perda de instalações, de sistemas, de pessoal ou de um fornecedor crítico. Melhor poucos cenários por tipo de perda do que uma longa lista de catástrofes.
- Estratégias de recuperação. Para cada processo e cenário, a alternativa escolhida: site alternativo, trabalho remoto, fornecedor substituto, procedimento manual.
- Procedimentos de recuperação. Fichas passo a passo por equipe, com responsável, tempo estimado e critério de «concluído». É a parte lida durante a crise, então precisa caber em poucas páginas.
- Comunicação. Mensagens prontas e canais para funcionários, clientes, fornecedores, autoridades e imprensa, e quem fala em nome da empresa.
- Retorno à normalidade. Como se volta do modo de contingência para a operação habitual sem perder dados nem duplicar operações.
- Testes e manutenção. Calendário de exercícios, resultados do último teste, ações de melhoria pendentes e gatilhos de revisão (mudança de fornecedor, de sistema ou de unidade).
- Anexos. Lista de contatos, inventário de recursos críticos, contratos de fornecedores alternativos e registros de acionamento.
Plano de continuidade de negócios, de operações, DRP e plano de crise
Os quatro nomes aparecem misturados em políticas, editais e auditorias. Cada um responde a uma pergunta diferente, e o ideal é que existam como peças conectadas, e não como um documento único que tenta abarcar tudo.
| Plano | Pergunta que responde | Escopo | Quem lidera |
|---|---|---|---|
| Plano de continuidade de negócios (PCN/BCP) | Como continuamos entregando o que é crítico? | A organização inteira: processos, pessoas, unidades, fornecedores e tecnologia | Continuidade ou riscos, com a diretoria |
| Plano de continuidade operacional | Como esta área ou processo continua funcionando? | Um processo, uma planta ou uma área operacional | O responsável por essa operação |
| Plano de recuperação de desastres (DRP) | Como recuperamos os sistemas e os dados? | Infraestrutura e aplicações | TI |
| Plano de gerenciamento de crises | Quem decide e o que comunicamos? | Tomada de decisão, comunicação e reputação | Comitê de crise ou alta direção |
«Plano de continuidade operacional» é o termo que mais muda de uma empresa para outra. Algumas o usam como sinônimo de PCN; outras, principalmente na indústria e na logística, chamam assim os planos por planta ou por processo que ficam pendurados no plano geral. O importante é que a sua política diga o que ele significa na sua empresa. O DRP é uma das estratégias do PCN: sem ele não há recuperação tecnológica, mas um DRP perfeito não resolve um CD alagado nem uma unidade sem pessoal.
O que a ISO 22301 exige e onde entra o BIA
A ISO 22301:2019, Security and resilience. Business continuity management systems. Requirements, é a norma internacional certificável para sistemas de gestão de continuidade de negócios. A ISO a publicou em outubro de 2019 e, em fevereiro de 2024, acrescentou uma emenda (ISO 22301:2019/Amd 1:2024) que obriga a avaliar se a mudança climática é uma questão relevante no contexto da organização. A ISO já tem em andamento uma nova edição, em fase de rascunho de comitê (ISO/CD 22301), então vale acompanhar quando ela será publicada.
A norma não traz um modelo de plano. Ela exige um sistema: o BIA e a avaliação de riscos (seção 8.2), as estratégias que saem deles e planos de continuidade (seção 8.4.4) que são testados e revisados. Por isso, um plano escrito sem BIA não passa em uma auditoria de certificação, mesmo que o documento esteja bem redigido. Se você quer o detalhe da norma, explicamos em o que é a ISO 22301 e para que serve, e a passagem do risco para o BIA está no webinar sobre avaliação de riscos e BIA.
Se você trabalha em uma instituição financeira da Colômbia, do México ou de outro país da região, o seu supervisor tem ainda exigências próprias de continuidade. Nós as revisamos no artigo sobre regulação de segurança e continuidade no setor financeiro da América Latina.
Onde os planos de continuidade falham
Na nossa leitura, os planos costumam falhar mais pelo que dão como certo do que pelo que dizem. Estes são os pontos que revisaríamos primeiro em qualquer plano:
- RTO sem BIA por trás. «Quatro horas para tudo» soa bem, mas se ninguém perguntou ao negócio quando o dano começa, o plano protege o que a TI conhece e deixa de fora processos que não têm sistema próprio.
- Fornecedores fora do plano. O plano parte do princípio de que a nuvem, a transportadora ou a central de atendimento terceirizada vão continuar lá. Se um processo crítico depende de um terceiro, a queda dele precisa ser um cenário, e o contrato dele precisa permitir o que o plano exige.
- Contatos e substitutos desatualizados. A árvore de chamadas é a primeira coisa usada e a primeira que fica velha. Um plano com metade dos telefones errados atrasa o acionamento desde o primeiro minuto.
- Documentos longos demais. Ninguém lê um plano de duzentas páginas durante uma crise. As fichas de ação por equipe, de uma ou duas páginas, são as que se usam; o resto é contexto para a auditoria.
- Testes que não testam. Um teste de mesa por ano é melhor que nada, mas não demonstra que o site alternativo sobe. Nós alternaríamos exercícios de mesa com testes técnicos reais do processo mais crítico.
Por onde nós começaríamos
Se você está partindo do zero, faríamos o BIA de cinco a dez processos antes de escrever qualquer coisa, com o responsável de cada um na sala. Depois, as estratégias para esses processos e, só então, o documento com o índice acima. Ampliar o escopo quando o primeiro plano já foi testado uma vez custa muito menos do que corrigir um plano que ninguém ensaiou.
No módulo de Continuidade de Negócios do GlobalSuite®, o BIA é feito com questionários para cada responsável, que se consolidam automaticamente e geram o RTO e o RPO por processo, e os planos são montados por cenário com seus recursos críticos e a data da última revisão. Os testes ficam programados com os seus resultados e evidências, que é exatamente o que o auditor pede. Se quiser ver isso com os seus processos, peça uma demo.
Fontes oficiais: página da ISO 22301:2019, da sua emenda ISO 22301:2019/Amd 1:2024 e do rascunho ISO/CD 22301 em iso.org. Os exemplos deste artigo são ilustrativos e não correspondem a nenhum cliente. Conteúdo revisado em outubro de 2026.
