Buscar

O que é PCN?

O que é PCN (Plano de Continuidade de Negócios): o conjunto de planos que mantém as operações críticas de pé durante um desastre. BIA, RTO, RPO, DRP e ISO 22301 explicados.

Gabriel Pedroso10 min de leitura
O que é PCN?

PCN (Plano de Continuidade de Negócios) não é um documento de prateleira: é o conjunto de planos, processos e responsáveis que mantém as operações críticas de pé — ou as restaura em minutos — quando um desastre, um ciberataque ou uma falha derruba a operação normal da empresa.

Um servidor que não liga na segunda-feira, um ransomware que criptografa a rede inteira, um incêndio no data center, uma pandemia que esvazia o escritório. O que separa a empresa que volta a operar no mesmo dia daquela que perde clientes e receita quase nunca é sorte — é ter, ou não, um PCN testado. Neste guia você vai entender o que é PCN, como ele difere de um plano de recuperação de desastres (DRP) e de um simples backup, quais são as etapas para montá-lo (BIA, RTO, RPO, estratégias e testes) e o que diz a norma ISO 22301. O ciclo de vida de um bom plano é este:

1BIAdescobre os processos críticos e o custo de cada hora parada
2Análise de riscosmapeia as ameaças que podem derrubar cada processo
3Estratégiasdefine como manter de pé: redundância, backup, contingência
4Planodocumenta procedimentos, papéis e comunicação de crise
5Testessimula, corrige e revisa — a única prova de que funciona
O ciclo de um PCN: a BIA descobre o que é crítico, a análise de riscos mapeia as ameaças, as estratégias definem como manter tudo de pé, o plano documenta quem faz o quê — e só os testes provam que funciona.

O que é PCN (Plano de Continuidade de Negócios)?

O Plano de Continuidade de Negócios (PCN) — em inglês, Business Continuity Plan (BCP) — é o conjunto de procedimentos, políticas e responsabilidades que garante que uma empresa continue operando, ou volte a operar depressa, mesmo diante de uma crise. Ele cobre bem mais do que a TI: pessoas, comunicação, fornecedores, instalações físicas e sistemas entram todos na conta.

A lógica é simples. Toda operação tem alguns processos sem os quais o negócio para de fato — faturar, atender, produzir, entregar. O PCN mapeia esses processos, decide quanto tempo cada um pode ficar fora do ar, e prepara de antemão como mantê-los rodando (ou restaurá-los) quando o inesperado acontece. Não é privilégio de grande corporação: qualquer empresa que perca dinheiro ou clientes ao ficar horas paralisada tem o que proteger.

Vale separar o PCN de dois conceitos que costumam ser confundidos com ele: a gestão de riscos, que identifica o que pode dar errado, e a gestão de crises, que coordena a resposta imediata ao incidente. O PCN se apoia nas duas, mas seu foco é outro: manter a operação viva. Essa distinção fica mais nítida quando comparamos PCN, DRP e backup lado a lado.

PCN, DRP e backup: não são a mesma coisa

Esse é o erro mais comum do tema — tratar backup como se fosse continuidade. Backup é uma peça; PCN é o plano inteiro. Veja o escopo de cada um:

ConceitoO que cobrePergunta que responde
PCN / BCPO negócio inteiro: processos críticos, pessoas, comunicação, instalações e TIComo a empresa continua operando durante e após a crise?
DRP / PRDSó a TI: restauração de sistemas, servidores, redes e dadosComo coloco os sistemas de volta no ar depois da falha?
BackupSó a cópia dos dadosOnde estão as cópias que eu consigo restaurar?

O DRP (Disaster Recovery Plan), ou Plano de Recuperação de Desastres (PRD), é o subconjunto de TI do PCN. Ele responde à parte técnica: restaurar servidores, bancos de dados, redes e aplicações. É crítico, mas responde a uma fatia do problema. De nada adianta o sistema voltar em duas horas se ninguém sabe quem avisa os clientes, para onde a equipe vai ou como o atendimento segue enquanto isso.

O backup, por sua vez, é a base de tudo, mas é só uma peça: a cópia dos dados. Restaurar arquivos não é o mesmo que retomar a operação. É por isso que uma boa solução de backup sustenta o DRP, que por sua vez é uma engrenagem do PCN — e não o contrário.

Como montar um PCN: as etapas na prática

Criar um Plano de Continuidade de Negócios exige método, não improviso. As etapas seguem a mesma sequência do diagrama acima.

  1. BIA (Análise de Impacto no Negócio). O ponto de partida. Identifica quais processos são críticos e mede o impacto — financeiro e operacional — de cada hora parada. É aqui que nascem o RTO e o RPO.
  2. Análise de riscos. Mapeia as ameaças capazes de derrubar cada processo crítico: falha de hardware, ransomware, queda de energia, desastre natural, erro humano, indisponibilidade de fornecedor.
  3. Estratégias de continuidade. Define como manter ou restaurar cada processo: redundância, backup, site de contingência, procedimentos manuais temporários e acordos com terceiros.
  4. Plano e comunicação de crise. Documenta os procedimentos de resposta, define papéis e responsáveis, e estabelece quem comunica o quê — a funcionários, clientes, parceiros e autoridades.
  5. Testes e revisão. Simulações periódicas expõem falhas antes que a crise real cobre a conta. O plano é revisado após cada teste, incidente ou mudança relevante.

BIA, RTO e RPO: o coração do plano

A BIA (Business Impact Analysis) é a etapa que dá números ao PCN. Ela pergunta, processo por processo: quanto a empresa perde a cada hora que isso fica parado? Quanto tempo até o prejuízo se tornar insustentável? A partir daí, define duas metas que orientam todo o resto:

  • RTO (Recovery Time Objective): o tempo máximo tolerável de parada de um processo. Ou seja, em quanto tempo ele precisa estar de volta.
  • RPO (Recovery Point Objective): a perda máxima tolerável de dados, medida em tempo. Ou seja, para qual ponto no passado você aceita voltar.

Um exemplo torna a diferença clara. Suponha um sistema de faturamento com RTO de 4 horas e RPO de 15 minutos. Isso significa que, após uma falha, ele deve voltar em no máximo 4 horas — e que a empresa não aceita perder mais do que 15 minutos de dados. Um RPO de 15 minutos, na prática, exige backups (ou replicação) a cada 15 minutos, não um único backup diário. É a BIA que justifica esse custo: quanto menor o RTO e o RPO, mais cara é a estratégia — por isso ela se aplica só ao que é de fato crítico.

Estratégias de continuidade: redundância e sites de contingência

Definidas as metas, a etapa de estratégia decide como cumpri-las. Isso costuma combinar redundância (componentes duplicados para que a falha de um não pare o serviço), alta disponibilidade e infraestrutura de apoio como o nobreak, que segura a operação durante uma queda de energia.

Para desastres que atingem o local inteiro, a resposta clássica é o site de contingência — uma instalação alternativa para onde a operação migra. Eles variam conforme o RTO exigido e o orçamento:

Tipo de siteEstadoTempo de retomada (RTO)Custo
Hot siteRéplica pronta, com dados sincronizadosMinutosAlto
Warm siteInfraestrutura montada, dados a restaurarHorasMédio
Cold siteSó o espaço e a estrutura básicaDiasBaixo

A escolha não é técnica, é de negócio: um hot site custa caro, mas se paga para processos que não podem parar; um cold site basta para funções que toleram dias de indisponibilidade. É o RTO definido na BIA que aponta qual faz sentido para cada processo.

ISO 22301: a norma que dá método ao PCN

Continuidade de negócios não é improviso, e existe uma norma internacional que define como estruturá-la: a ISO 22301 (Segurança e resiliência — Sistemas de gestão de continuidade de negócios — Requisitos). Diferente da ISO 31000 (gestão de riscos, que é uma diretriz), a ISO 22301 é certificável: uma organização pode ser auditada e receber o certificado de conformidade.

A norma organiza o ciclo que este guia descreveu — análise de contexto, BIA, estratégias, resposta a incidentes, testes e melhoria contínua — dentro de um sistema de gestão formal. Para setores regulados, como o financeiro e o de saúde, adotar esse método (mesmo sem buscar a certificação) costuma ser exigência prática. Se a certificação for um objetivo, vale entender antes como funcionam as certificações ISO.

Acima de tudo, lembre-se de que um PCN é um documento vivo. Ele precisa acompanhar o crescimento da empresa, as novas tecnologias e as ameaças que surgem a cada ano. E, por mais bem escrito que esteja, um plano só prova o próprio valor quando é testado — de preferência antes, e não durante, a crise que ele deveria conter.

Perguntas frequentes sobre PCN

O que é PCN (Plano de Continuidade de Negócios)?

PCN (Plano de Continuidade de Negócios), ou BCP (Business Continuity Plan) em inglês, é o conjunto de planos, processos e responsáveis que garante que as funções críticas de uma organização continuem operando — ou sejam restauradas rapidamente — durante e após um evento disruptivo, como desastre natural, ataque cibernético, incêndio ou falha sistêmica.

Qual a diferença entre PCN e DRP?

O PCN abrange a organização inteira e garante a operação dos processos críticos de negócio: pessoas, comunicação, instalações e sistemas. O DRP (Disaster Recovery Plan / Plano de Recuperação de Desastres) é focado especificamente em restaurar a infraestrutura de TI, os sistemas e os dados. O DRP é um componente dentro do PCN, mais amplo.

Qual a diferença entre PCN e backup?

O backup é apenas a cópia dos dados — uma única peça dentro do plano. O PCN é a estratégia completa que decide quais processos precisam voltar primeiro, em quanto tempo (RTO), com quanta perda de dados aceitável (RPO), quem faz o quê e como a empresa se comunica durante a crise. Backup sem PCN restaura arquivos, mas não garante que o negócio volte a operar.

O que é BIA no contexto de PCN?

BIA (Business Impact Analysis / Análise de Impacto no Negócio) é a etapa que identifica as funções críticas, mede o impacto financeiro e operacional de cada interrupção e define os valores de RTO (tempo máximo tolerável de parada) e RPO (perda máxima tolerável de dados) de cada processo. É a BIA que prioriza para onde os recursos de recuperação vão.

Com que frequência o PCN deve ser testado?

Recomenda-se testar o PCN ao menos uma vez por ano com exercícios de simulação (tabletop), com testes de recuperação de TI mais frequentes (por exemplo, semestrais). O plano também deve ser revisado após qualquer incidente real ou mudança significativa na organização, na infraestrutura ou nas ameaças. Plano que nunca foi testado é uma suposição, não uma garantia.