Plano de Continuidade de Negócio (BCP)

Passo 1 — Definir escopo e governança do BCP

Antes de mapear funções, definir:

- Escopo: o BCP cobre a empresa inteira? Uma unidade de negócio? Apenas um produto?

- Owner: quem é o dono do documento (geralmente Diretor de Operações, COO ou CISO). - Cadência de revisão: anual no mínimo. Trimestral em setor regulado. - Estrutura de governança: comitê de continuidade (quem reúne, com qual frequência, com qual decision right).

Documentar a governança como capítulo 1 do BCP. Sem owner e cadência clara, o documento envelhece em 6 meses.

Passo 2 — Conduzir Business Impact Analysis (BIA)

A BIA é o coração do BCP. Para cada função de negócio, responder:

- O que essa função entrega e para quem?

- Qual o impacto financeiro de parada de 1h, 4h, 24h, 7 dias, 30 dias? - Qual o impacto reputacional / regulatório / contratual? - Qual a dependência tecnológica (sistemas que precisam estar de pé)? - Qual a dependência humana (papéis-chave, número mínimo de pessoas)? - Qual a dependência de terceiros (vendors)?

Output: tabela BIA com pelo menos: função, impacto por janela, dependências, criticidade (Crítica / Importante / Suporte).

Função "crítica" é a que se parar paralisa receita ou compliance no curto prazo. Função "importante" é a que degrada experiência em horas/dias mas não paralisa. Função "suporte" pode ficar parada por dias sem impacto material.

Passo 3 — Definir RTO e RPO por função crítica

Para cada função classificada como Crítica:

- RTO (Recovery Time Objective): quanto tempo a função pode ficar parada antes de causar dano inaceitável.

- RPO (Recovery Point Objective): quanto dado a função pode perder em caso de restauração (medido em tempo: 5min, 1h, 24h).

RTO e RPO não são metas técnicas inventadas; são derivados do impacto na BIA. Função que perde R$ 100k/hora não pode ter RTO de 24h.

Exemplo de tabela:

| Função | Criticidade | RTO | RPO | Justificativa | |---|---|---|---|---| | Cobrança | Crítica | 4h | 1h | Falha em ciclo de cobrança gera reprocessamento e queixa de cliente. | | Suporte ao cliente | Importante | 24h | 24h | Suporte pode operar em modo degradado por 1 dia. | | Onboarding interno (RH) | Suporte | 7 dias | 7 dias | Sem impacto material em janela curta. |

Passo 4 — Mapear cenários de continuidade

BCP não é genérico; cobre cenários concretos. Mapear pelo menos:

1. Indisponibilidade de site físico: incêndio, alagamento, ataque, falta de energia prolongada.

2. Indisponibilidade de sistema crítico: queda de cloud provider, ransomware, corrupção de banco. 3. Indisponibilidade de pessoa-chave: doença, demissão, acidente da liderança ou de detentor único de conhecimento (bus factor 1). 4. Indisponibilidade de fornecedor crítico: vendor de pagamento, autenticação, CDN, fica fora. 5. Crise externa: pandemia, instabilidade política, desastre regional, ataque cibernético setorial.

Para cada cenário: gatilhos, função afetada, ação imediata, time de resposta, RTO/RPO aplicável.

Passo 5 — Definir estratégia de recuperação para cada função crítica

Para cada função Crítica + cenário relevante, definir:

- Solução técnica: failover automático, restauração de backup, ativação de site alternativo, modo degradado manual.

- Tempo estimado de recuperação: consistente com o RTO. - Responsável pela execução: papel, não nome (resiliência a turnover). - Procedimento documentado: link para runbook de DR específico. - Recursos necessários: infra de DR, licenças stand-by, acesso a backup.

Modelos comuns:

- Hot standby: sistema espelho ativo, failover em minutos. Caro mas RTO baixo. - Warm standby: sistema configurado mas não ativo, ativação em horas. - Cold standby: infra disponível mas precisa ser provisionada, ativação em horas a dias. - Modo manual / degradado: operação por planilha, papel, telefone enquanto sistema é restaurado.

Passo 6 — Backup e Disaster Recovery (DR)

Política de backup do BCP cobre, no mínimo:

- O quê: quais sistemas/dados são backupados.

- Frequência: consistente com o RPO de cada função. - Retenção: por quanto tempo backups são guardados (regulatório define mínimo). - Onde: geo-redundância obrigatória para função crítica. Backup imutável (resistente a ransomware) recomendado. - Restore tested: o backup só conta se foi restaurado em teste no último ano. Backup nunca testado = não tem backup. - Quem restaura: owner por sistema.

Documentar isso em tabela e validar com TI/SRE.

Passo 7 — Plano de comunicação em crise

Em crise, comunicação ruim multiplica o dano. Definir:

- Quem comunica: porta-voz único interno, porta-voz único externo (PR/Comunicação).

- Canais: Slack interno, email cliente, status page, redes sociais, mídia. - Templates pré-aprovados: mensagens para cenários comuns (já aprovadas por jurídico/comunicação). - Cadência: primeira comunicação em X minutos, updates a cada Y horas. - Audiências: funcionários, clientes, fornecedores, reguladores, mídia.

Para crise com exposição regulatória (vazamento de dados, breach), seguir também gdpr-data-handling-checklist.

Passo 8 — Sites alternativos e arranjos físicos

Se a empresa tem operação física crítica (escritório, datacenter, atendimento presencial):

- Site alternativo: identificar e contratualizar local de backup.

- Capacidade: quantas pessoas o site comporta. - Tempo de ativação: quantas horas para virar operação. - Equipamento stand-by: laptops, telefones, infra mínima já provisionada. - Arranjo home-office emergencial: lista de quem pode operar de casa e com qual equipamento.

Para empresa 100% remota, este passo se reduz a: política de equipamento mínimo, conectividade redundante, e plano de comunicação fora do canal padrão.

Passo 9 — Exercícios e testes do plano

BCP que nunca foi testado não funciona. Cadência mínima:

- Tabletop exercise (simulação em mesa): trimestral. Time se reúne, recebe cenário fictício, percorre o plano em discussão.

- Walkthrough técnico: semestral. Executar passos do plano em ambiente controlado (ativar standby, restaurar backup, ativar site alternativo). - Teste live: anual. Simulação parcial com sistema real (failover de produção em janela controlada). - Pós-exercício: retro com retro-analysis, atualizar o plano com gaps encontrados.

Registrar cada exercício: data, cenário, participantes, resultado, ações geradas.

Passo 10 — Manutenção e ativação do plano

Definir:

- Quando o plano é ativado: gatilhos objetivos (não "quando o COO decide"). Exemplos: indisponibilidade de >X horas, ataque com dado exposto, evento físico crítico.

- Quem ativa: papel + suplentes (sempre dois níveis). - Como ativa: procedimento específico (canal de Slack dedicado, conferência permanente, etc). - Como desativa: critério objetivo para declarar fim da crise. - Quando o plano é atualizado: após exercício, após incidente real, após mudança organizacional grande, anualmente no mínimo.

Versionamento explícito do documento (v1.0, v1.1...) com histórico de mudanças.