Um Plano de Continuidade de Negócios (BCP) define como sua empresa mantém (ou retoma) as operações críticas após uma interrupção — ataque (ransomware), falha de datacenter, erro humano, indisponibilidade de fornecedor, desastre físico. O caminho prático é: BIA (impacto) → RTO/RPO → estratégia de continuidade → runbooks/testes. (NIST SP 800-34 Rev.1)

O que é um plano de continuidade de negócios e por que não é “um documento de gaveta”?

BCP não é um PDF bonito. É um sistema operacional de sobrevivência com:

  • prioridades do negócio (o que volta primeiro)

  • metas objetivas (RTO/RPO)

  • pessoas e papéis (quem decide, quem executa)

  • procedimentos testados (runbooks e exercícios)

O NIST trata “contingency planning” como medidas para recuperar serviços após uma disrupção e destaca a integração com gestão de risco e ciclo de vida. (NIST SP 800-34 Rev.1)

O que a vida real ensina sobre continuidade (sem romance)

Caso Maersk / NotPetya: quando a identidade cai, o mundo para

No NotPetya (2017), a Maersk teve interrupção global e precisou reconstruir muito do ambiente. Um aprendizado recorrente em análises do caso é que recuperação de Active Directory/identidade é crítica e desafiadora, e sem ela “nada volta direito”. (CSO Online; Information Age)

Tradução prática: se seu BCP ignora identidade (AD/Entra ID), você tem um “plano de continuidade” que falha no primeiro ataque sério.

Ransomware e backups: a diferença entre “voltar” e “negociar”

A CISA é bem direta: manter backups offline/criptografados e testar regularmente a disponibilidade e integridade em cenário de recuperação. Isso é continuidade aplicada (não teoria). (CISA StopRansomware Guide)

Quais perguntas você precisa responder antes de escrever qualquer plano?

Um BCP bom nasce quando você responde (com números, não opiniões):

  1. Quais processos são críticos? (faturamento, produção, logística, atendimento, ERP, e-commerce, folha etc.)

  2. Quanto tempo posso ficar parado? (RTO)

  3. Quanto dado posso perder? (RPO)

  4. Quais dependências existem? (internet, nuvem, fornecedores, AD/SSO, banco, API, links, pessoas-chave)

  5. Quais cenários são mais prováveis? (ransomware, indisponibilidade de provedor, erro operacional, energia, incêndio, sabotagem)

Como montar um plano de continuidade de negócios passo a passo (modelo Infob)

Aqui vai um playbook “sem frescura” em 7 passos.

1) Como fazer o BIA (Business Impact Analysis) do jeito certo?

BIA é a etapa onde você define impacto financeiro, operacional, reputacional e legal se algo parar.

Saídas mínimas do BIA:

  • lista de processos críticos (Tier 0/1/2)

  • impacto por janela de tempo (2h, 8h, 24h, 72h)

  • dependências (sistemas + pessoas + fornecedores)

  • RTO e RPO por processo/sistema

O NIST usa esse raciocínio para orientar planejamento de contingência e recuperação. (NIST SP 800-34 Rev.1)

Dica prática: se o BIA vira “planilha eterna”, você travou. Faça um MVP: 10 processos e 20 sistemas no máximo na primeira rodada.

2) O que são RTO e RPO (e como definir sem chute)?

  • RTO (Recovery Time Objective) = tempo máximo aceitável para o serviço voltar

  • RPO (Recovery Point Objective) = ponto máximo de perda de dados aceitável

Exemplo realista:

  • ERP financeiro: RTO 8h / RPO 30min–2h

  • e-mail: RTO 24h / RPO 4–12h

  • arquivos compartilhados: depende do negócio, mas costuma ser crítico em ransomware

3) Quais estratégias de continuidade escolher (sem gastar dinheiro errado)?

Agora você casa RTO/RPO com estratégia:

  • Alta disponibilidade (HA): quando RTO é muito baixo (minutos)

  • Disaster Recovery (DR) / site secundário: quando RTO é horas

  • Backup 3-2-1 + restore rápido: quando RTO/RPO permitem

  • Contingência operacional: “modo manual” temporário (faturar offline, planilha, canal alternativo)

  • Redundância de fornecedor: ISP, DNS, e-mail, pagamentos

A regra é: quanto menor o RTO/RPO, mais caro. O BIA impede você de “gastar caro no que não é crítico”.

4) Como desenhar backup para continuidade (não só para “arquivo perdido”)?

Para continuidade, backup precisa ser:

  • 3-2-1 (3 cópias, 2 mídias, 1 offsite)

  • com isolamento (conta separada, sem dependência do domínio comprometido)

  • com teste de restauração (mensal/trimestral)

A CISA recomenda explicitamente backups offline/criptografados e testes regulares em cenário de recuperação. (CISA StopRansomware Guide)

5) Como transformar o plano em runbooks (o que realmente salva no dia D)?

BCP “vive” em runbooks curtos e executáveis.

Runbook mínimo por sistema crítico deve ter:

  • dono do sistema e contatos

  • dependências (AD/SSO, DNS, banco, rede, certificados)

  • ordem de recuperação (o que vem antes)

  • passo a passo de restore (com prints, comandos, caminhos)

  • validação pós-restore (testes)

  • critérios de “pronto para produção”

Exemplo de ordem (bem comum):

  1. Identidade (AD/SSO/DNS)

  2. Rede e acesso (VPN, firewall, links)

  3. Banco de dados

  4. ERP / aplicações core

  5. File server / colaboração

  6. periféricos e legados

O caso Maersk reforça o peso da identidade: sem recuperar isso, o resto vira caos. (CSO Online)

6) Como testar o BCP (sem travar a operação)?

Se você não testa, você não tem BCP — você tem esperança.

Tipos de teste (do mais leve ao mais real):

  • Tabletop (simulação em sala): decisão, comunicação, papéis

  • Teste técnico parcial: restaurar 1 sistema crítico em ambiente de teste

  • Teste de restauração real (amostra): validar RPO/RTO com evidência

  • Exercício completo (raro): “virar a chave” para DR

O NIST enfatiza testes/exercícios e validação de recuperação como parte do planejamento de contingência. (NIST SP 800-34 Rev.1)

7) Como governar e manter o plano atualizado?

BCP “morre” quando:

  • ninguém é dono

  • ninguém revisa

  • o ambiente muda (cloud, SaaS, novo ERP) e o plano fica velho

Ritual mínimo:

  • revisão trimestral dos 10 processos críticos

  • teste mensal/trimestral de restauração (amostral)

  • atualização após mudanças grandes e após incidentes

  • KPIs: sucesso de restore, tempo de recuperação, cobertura de backup, saúde do EDR

Como o BCP se conecta a ransomware, incidentes e “alert fatigue”

Como evitar ransomware na empresa usando continuidade?

Continuidade não impede a entrada do ransomware, mas reduz o impacto e o poder de chantagem. O núcleo é:

  • backups isolados e testados

  • runbooks de recuperação

  • prioridade clara do que volta primeiro

CISA reforça backups offline/criptografados e testes de integridade/disponibilidade. (CISA StopRansomware Guide)

Empresa foi atacada por ransomware: o que fazer (BCP na prática)

  • isolar e conter (IRP)

  • proteger repositórios de backup

  • identificar último ponto íntegro (RPO real)

  • restaurar por prioridade (Tier 0 → Tier 1 → Tier 2)

Como responder a incidente de segurança sem improviso?

BCP anda junto com IRP: IRP contém e investiga; BCP recupera e mantém operação.

Como reduzir alert fatigue com continuidade?

Quando você tem:

  • detecção mínima (EDR/logs)

  • critérios de severidade

  • e plano de recuperação testado
    …você evita a “tempestade de alertas” virar pânico operacional. Você decide rápido e executa.

Como melhorar visibilidade de endpoints e detectar movimentação lateral

BCP depende de saber o que existe e o que é crítico. Endpoint e identidade são as primeiras peças em ataques modernos; sem visibilidade, você perde tempo e aumenta downtime.

Como proteger dados sensíveis LGPD dentro do BCP

BCP precisa incluir:

  • inventário de dados sensíveis

  • prioridade de recuperação de sistemas com dados pessoais

  • controles de acesso e trilha de auditoria

  • plano de comunicação/registro de incidente quando houver impacto em dados

FAQ — Como montar um plano de continuidade de negócios

1) Qual a diferença entre BCP e DR (Disaster Recovery)?
BCP é o guarda-chuva do negócio (processos, pessoas, decisões). DR é o braço técnico (infra, recuperação de sistemas).

2) O que é BIA e por que ele vem primeiro?
BIA mede impacto e define prioridades e metas (RTO/RPO). Sem BIA, o plano vira “achismo”. (NIST SP 800-34 Rev.1)

3) RTO e RPO são obrigatórios?
Se você quer um plano que funcione, sim. Eles viram metas e orçamento.

4) Backup 3-2-1 é suficiente para continuidade?
Para muitos cenários, sim — se houver isolamento e teste de restauração. Para RTO muito baixo, você pode precisar HA/DR. (CISA StopRansomware Guide)

5) Com que frequência devo testar o plano?
Tabletop pode ser trimestral; restore técnico deve ser mensal/trimestral (amostral). O NIST reforça testes e validação como parte do ciclo. (NIST SP 800-34 Rev.1)

6) Quais são os erros mais comuns ao criar um BCP?
Não definir RTO/RPO, não testar restore, não mapear dependências (AD/SSO/DNS), não ter runbooks, não ter dono do plano.

7) Como o BCP ajuda contra ransomware?
Ele reduz impacto e tempo parado e diminui a chance de “pagar para voltar”. A CISA destaca backups testados como pilar anti-ransomware. (CISA StopRansomware Guide)