Disaster Recovery Plan: Template e Guia Passo a Passo

Por que Todo Negócio Precisa de um DRP Formal

Pontos-Chave

• Um DRP testado transforma recuperação de semanas em horas
• O custo médio global de uma violação atingiu US$ 4,88 milhões, segundo o IBM Cost of a Data Breach Report
• A ISO 22301 define BIA e RTO/RPO como núcleo do planejamento de continuidade
• Ataques de ransomware atingem maioria das organizações anualmente, conforme o Sophos State of Ransomware
• Testes semestrais são o mínimo — DRP sem teste é ficção documentada

Um Disaster Recovery Plan (DRP) é um dos documentos mais críticos para qualquer empresa que depende de tecnologia — e hoje, praticamente todas dependem. Pesquisas setoriais mostram que uma fatia significativa das PMEs que sofrem perda total de dados encerra atividades em poucos meses. Ainda assim, a maioria das empresas brasileiras opera sem um DRP formalizado.

O DRP não é um documento técnico guardado na gaveta. É um roteiro acionável que permite à equipe de TI — e a toda a organização — agir de forma coordenada quando o pior acontece. Seja um ataque de ransomware, falha de servidor, incêndio no datacenter ou erro humano apagando produção, o DRP define o que fazer, quem faz e em quanto tempo.

Neste guia, você encontra um template completo adaptado à realidade brasileira, com seções que podem ser usadas como base direta para o plano da sua empresa.

DRP, BCP e a Relação com Backup

O DRP foca recuperação de TI. O BCP (Business Continuity Plan) abrange pessoas, processos e instalações. O DRP é um componente do BCP, e ambos dependem de uma base de backup corporativo sólida. Sem backup confiável, não há DRP — só esperança.

Soluções modernas integram o DRP com BaaS e DRaaS, viabilizando replicação contínua para nuvem e failover automatizado. Isso reduz drasticamente RTO e RPO, permitindo recuperação em minutos.

Template de Disaster Recovery Plan

Seção 1: Visão Geral e Escopo

• Nome do documento: Plano de Recuperação de Desastres — [Nome da Empresa]
• Versão: controle de versões com histórico
• Data de aprovação e próxima revisão (máximo 6 meses)
• Patrocinador executivo: C-level responsável
• Gestor do plano: responsável pela manutenção (CIO, CISO)
• Escopo: quais sistemas, sites e processos estão cobertos
• Exclusões: o que explicitamente não está coberto

Seção 2: Equipe de Resposta (DR Team)

1. Coordenador do DR — autoridade de decisão durante o incidente
2. Líder técnico de infraestrutura — executa restaurações
3. Líder de aplicações — valida sistemas restaurados
4. Líder de rede — reestabelece conectividade
5. Comunicação e crise — mídia, clientes, parceiros
6. Jurídico e compliance — notificações LGPD à ANPD
7. Liderança executiva — decisões estratégicas

Cada função precisa ter um titular e um substituto documentados. Contatos 24/7 obrigatórios.

Seção 3: Análise de Impacto ao Negócio (BIA)

A base de todo DRP, conforme a ISO 22301. Para cada sistema crítico:

• Impacto financeiro por hora de indisponibilidade
• Impacto operacional (processos dependentes)
• Impacto regulatório (LGPD, BACEN, ANS)
• Impacto reputacional
• Dependências upstream e downstream
• RTO e RPO definidos e validados

Seção 4: Classificação de Sistemas (Tiers)

Seção 5: Cenários de Desastre Cobertos

• Ransomware e malware destrutivo — ver proteção contra ransomware
• Falha de hardware crítico (servidor, storage, switch core)
• Falha de datacenter (energia, refrigeração, conectividade)
• Desastres naturais (enchente, incêndio, terremoto)
• Erro humano (exclusão acidental, comando destrutivo)
• Ataque à cadeia de suprimentos (comprometimento de fornecedor)
• Indisponibilidade de provedor cloud

Seção 6: Procedimentos de Recuperação (Runbooks)

Para cada sistema, um runbook detalhado com:

1. Descrição do sistema e dependências
2. Pré-requisitos de recuperação (credenciais, DNS, rede)
3. Passos numerados de restauração
4. Testes de validação pós-restauração
5. Critérios de aceite para considerar o sistema "em produção"
6. Rollback caso a restauração falhe

Seção 7: Comunicação Durante o Incidente

• Matriz de escalada — quem aciona quem, em quanto tempo
• Canais primários e secundários (WhatsApp, telefone, e-mail pessoal)
• Templates de comunicação para clientes, mídia, funcionários
• Ponto único de verdade (war room físico ou virtual)
• Cadência de updates (a cada 30 min nas 4 primeiras horas)

Seção 8: Infraestrutura de Recuperação

• Localização dos backups (primário e secundário)
• Tecnologia de backup (imutável, offsite, air-gapped)
• Provedor de DRaaS
• Site alternativo (hot, warm ou cold)
• Contratos de emergência com fornecedores

Seção 9: Testes e Validação

Um DRP sem testes é ficção documentada. Estabeleça cronograma:

• Trimestral: testes parciais (restauração de sistemas individuais)
• Semestral: teste completo de failover
• Anual: simulação full-scale com todos os times
• Após mudanças relevantes: teste direcionado

Cada teste gera relatório com RTO real medido, gaps identificados e ações corretivas.

Seção 10: Manutenção e Atualização

• Revisão formal a cada 6 meses
• Atualização após qualquer mudança arquitetural significativa
• Atualização após incidentes reais (lições aprendidas)
• Aprovação executiva a cada nova versão

Checklist de Implementação do DRP

1. Patrocínio executivo formalizado
2. Gestor do plano nomeado
3. Equipe de resposta definida com titulares e suplentes
4. BIA concluída para sistemas críticos
5. RTO e RPO aprovados pelas áreas de negócio
6. Sistemas classificados em tiers
7. Tecnologia de backup adequada a cada tier implementada
8. Backup imutável para proteção anti-ransomware
9. Regra 3-2-1-1-0 atendida
10. Runbooks documentados para cada sistema crítico
11. Matriz de comunicação definida
12. Primeiro teste executado e documentado
13. Cronograma de testes futuros aprovado
14. Plano integrado ao política de backup corporativa
15. Aderência a LGPD e normas setoriais validada

Checklist de Seções Obrigatórias do DRP

Um DRP completo precisa conter todas as seções listadas abaixo. Use esta tabela para auditar seu plano existente ou validar um novo documento antes da aprovação executiva.

Dica prática: se uma seção estiver incompleta ou ausente, marque-a como "em construção" com data-alvo de conclusão. Um DRP parcial documentado é melhor que nenhum plano.

Matriz RTO/RPO por Tipo de Sistema

A definição de RTO e RPO precisa ser granular. Cada tipo de sistema tem características diferentes de criticidade, volume de mudanças e complexidade de restauração. Use esta matriz como ponto de partida e ajuste conforme a realidade da sua empresa.

A matriz acima segue a classificação por tiers apresentada na Seção 4 do template. Sistemas Tier 0 e Tier 1 exigem investimento em DRaaS, enquanto Tier 2 e Tier 3 podem utilizar BaaS com restauração manual. O equilíbrio entre custo e RTO é definido pela BIA — nunca pela intuição.

Calendário de Testes de DR: Template Anual

Testes de DR não podem ser ad hoc. Um calendário pré-aprovado garante que os testes aconteçam e que a equipe se prepare adequadamente. Use este template como base e ajuste ao calendário operacional da sua empresa.

Cada teste deve gerar um relatório formal contendo: cenário simulado, tempo real de recuperação vs RTO declarado, gaps identificados, ações corretivas com prazo e responsável. Armazene esses relatórios junto ao DRP — eles são evidência para auditorias de LGPD, compliance e certificações como ISO 22301.

Gatilhos de Revisão do DRP: Quando Atualizar o Plano

O DRP não é um documento estático. Além das revisões periódicas (mínimo semestral), existem eventos específicos que devem disparar uma revisão imediata. Ignorar esses gatilhos significa operar com um plano desatualizado — que pode falhar justamente quando for necessário.

Processo de revisão: o gestor do DRP deve manter uma lista de gatilhos ativos e monitorar proativamente. Cada revisão gera uma nova versão do documento com histórico de alterações. A versão atualizada precisa ser aprovada pelo patrocinador executivo e comunicada a toda a equipe de DR.

Matriz RACI: Papéis e Responsabilidades no DR

Durante um incidente, confusão sobre quem decide, quem executa e quem precisa ser informado atrasa a recuperação e pode transformar um incidente gerenciável em uma crise. A matriz RACI (Responsible, Accountable, Consulted, Informed) elimina essa ambiguidade.

Legenda:

• R = Responsável (executa a atividade)
• A = Aprovador (autoridade final, presta contas)
• C = Consultado (contribui com expertise antes da decisão)
• I = Informado (recebe atualização de status)

Adapte esta matriz à estrutura da sua empresa. Em PMEs, uma mesma pessoa pode acumular múltiplos papéis — mas garanta que cada atividade tenha pelo menos um R e um A claramente designados. Se o coordenador de DR estiver indisponível durante o incidente, o substituto documentado assume todas as funções A.

Cenários Práticos de Aplicação da Matriz RACI

Cenário 1: Ransomware criptografa servidores de produção (sexta-feira, 22h)

1. Alerta automático dispara notificação para o Líder de Infra (R: isolar sistemas)
2. Líder de Infra contata o Coordenador DR (A: declarar incidente)
3. Coordenador escala para Diretoria (R: aprovar ativação do plano de DR)
4. Comunicação é informada (I) e prepara templates de notificação
5. Jurídico avalia obrigação de notificação à ANPD
6. Líder de Infra executa failover DRaaS (R); Líder de Apps valida (R)

Cenário 2: Falha de storage no datacenter principal (terça-feira, 14h)

1. Líder de Infra detecta falha e inicia bare-metal recovery (R)
2. Coordenador DR avalia se é necessário declarar incidente formal (A)
3. Líder de Rede é consultado sobre conectividade com site de DR (C)
4. Diretoria é informada sobre previsão de restauração (I)
5. Após restauração, Líder de Apps valida todos os sistemas (R)

Erros Comuns ao Criar um DRP

Erro 1: Criar e esquecer

O DRP precisa ser vivo. Documento em PDF engavetado não salva ninguém em crise.

Erro 2: Pular a BIA

Sem análise de impacto, o plano tenta proteger tudo da mesma forma e acaba protegendo nada adequadamente.

Erro 3: Não envolver o negócio

DRP não é só TI. Exige diretoria, finanças, operações, jurídico, comunicação.

Erro 4: Não testar

O primeiro teste real é geralmente um balde de água fria. Teste antes que o desastre teste você.

Erro 5: Ignorar dependências

Sistemas não existem isolados. ERP precisa de banco, banco precisa de AD, AD precisa de DNS. O runbook tem que refletir essa cadeia.

Próximos Passos

• Calcule RTO e RPO dos seus sistemas críticos
• Para PMEs, veja disaster recovery para PMEs
• Implemente backup imutável antes de qualquer outro item do DRP
• Avalie DRaaS para reduzir RTO drasticamente
• Revise os hubs de disaster recovery e proteção contra ransomware
• Saiba como recuperar dados após ransomware para incluir cenário específico

Fale com um especialista da DataBackup via WhatsApp e receba um template personalizado para o seu setor.