Projeto de consultoria de DRP: como funciona, o que entrega e quem participa

Um projeto de consultoria de DRP (Disaster Recovery Plan, plano de recuperação de desastres) tem começo, meio e fim. Ele parte do ambiente que a empresa tem hoje e termina com um plano escrito, com roteiro de teste e equipe treinada, com responsáveis definidos para cada etapa da recuperação.

Na prática, o trabalho se divide em sete etapas: análise de riscos, levantamento de sistemas e dependências, definição de RTO e RPO com cada área, ordem de recuperação e procedimentos, responsáveis e suplentes, roteiro de teste com treinamento e revisão periódica. Cada etapa tem uma entrega concreta, e a empresa sabe o que vai receber antes de começar.

Este texto mostra como esse projeto funciona por dentro, quem precisa participar e onde ele costuma travar. Para a definição conceitual de DRP, RTO e RPO, leia DRP (Disaster Recovery Plan): o que é, como elaborar e com que frequência testar. Aqui o foco é a condução do projeto.

Para quem faz sentido uma consultoria de DRP

A consultoria não é a compra de uma ferramenta, nem um documento para guardar na gaveta. Ela faz sentido em três situações comuns.

• Não existe plano. A recuperação depende da memória de duas ou três pessoas, e ninguém sabe dizer em que ordem os sistemas voltam.
• Existe um plano antigo. Ele nunca foi testado, ou não acompanhou as mudanças do ambiente: sistemas novos, fornecedores trocados, pessoas que saíram.
• A empresa vai mudar o ambiente. Uma migração para a nuvem, a troca de data center ou a consolidação de sistemas é o melhor momento para colocar a recuperação no desenho desde o início.

A consultoria não substitui a equipe interna. Ela soma experiência em um projeto que a equipe faz poucas vezes na vida e deixa o plano nas mãos de quem vai executá-lo.

Onde um projeto de DRP costuma travar

Quase toda empresa tem alguma cópia de segurança. Poucas têm um plano que diga, sem improviso, o que sobe primeiro, quem decide e o que fazer quando a pessoa que conhece o sistema não atende o telefone.

O trabalho trava em três pontos conhecidos:

1. O DRP tratado como assunto só da TI. O negócio fica de fora das decisões de tempo e de perda de dados, e o plano nasce com números que ninguém aprovou.
2. O plano escrito como documento de auditoria. Fica bonito, mas sem um passo a passo que alguém consiga seguir numa madrugada de incidente.
3. O plano que nunca foi exercitado. Ele só é validado no dia em que já é tarde para corrigir.

Um projeto bem conduzido trata os três desde o início. O plano sai com roteiro de teste e treinamento da equipe; o teste em si vem depois, feito com a empresa. Por isso a lista de entregas abaixo mistura decisão de negócio, documento e rotina de teste.

As sete etapas do projeto, uma a uma

A ordem importa. Cada etapa usa o resultado da anterior, e pular uma delas costuma aparecer depois, como um buraco no plano.

1. Análise de riscos

O ponto de partida são as ameaças que podem parar a operação daquele ambiente, do ransomware à falha de hardware e à perda de um site. O resultado é uma lista priorizada, que orienta onde vale investir primeiro. Um plano genérico tende a falhar justamente no cenário que ninguém mapeou.

O que você recebe: a lista de cenários, ordenada pelo efeito que cada um teria na operação.

2. Levantamento de sistemas e dependências

Aqui se descobre o que existe, o que é crítico e o que depende de quê. É a etapa que evita a surpresa clássica: um sistema em nuvem que não volta porque depende de um serviço de autenticação local. O levantamento inclui a análise de impacto no negócio (BIA, do inglês business impact analysis): saber o que cada sistema sustenta e o que a empresa perde quando ele para.

O que você recebe: o inventário dos sistemas e o mapa do que depende de quê.

3. RTO e RPO acordados com cada área

O RPO é quanto dado é aceitável perder. O RTO é em quanto tempo o serviço precisa voltar. Quem responde pelo processo define os dois números, porque são uma decisão de negócio com custo: quanto menor o tempo, maior o investimento. A TI diz como entregar o número, não qual número é aceitável. O artigo Como definir RTO e RPO detalha essa conversa.

O que você recebe: uma tabela de RTO e RPO por sistema, com a aprovação de quem responde por cada processo.

4. Ordem de recuperação e procedimentos

Com RTO, RPO e dependências na mesa, define-se a ordem: o que sobe primeiro, como e o que espera. Cada passo vira um procedimento escrito para quem vai executar, não para quem vai auditar.

O que você recebe: a sequência de recuperação e os procedimentos passo a passo.

5. Responsáveis e suplentes

Cada etapa tem um responsável e um suplente. O plano precisa funcionar quando a pessoa principal está de férias, doente ou fora do alcance.

O que você recebe: a lista de papéis, com titular e suplente de cada um.

6. Roteiro de teste e treinamento

O plano sai com um roteiro de teste, e a equipe é treinada para os seus papéis. O teste em si é feito depois, com a empresa, no intervalo combinado, e o que falha volta para o plano. O texto Como testar o plano de continuidade: o que não exige parar a operação detalha os formatos de teste.

O que você recebe: o roteiro de teste e a equipe treinada para executá-lo.

7. Revisão periódica

Sistemas mudam, fornecedores mudam, pessoas mudam. A revisão periódica confere se sistemas, dependências e responsáveis continuam os mesmos. Uma mudança relevante de arquitetura, como uma migração ou um sistema novo, pede revisão fora do calendário.

O que você recebe: o plano atualizado, com o registro do que mudou.

Quem precisa estar na sala

Três grupos participam do projeto, e nenhum deles dispensa os outros.

• Áreas de negócio: definem quanto tempo a operação aguenta parada e quanto dado pode ser perdido.
• TI e infraestrutura: informa o que existe, desenha a estratégia de recuperação e executa os procedimentos.
• Direção: aprova o investimento que os números do negócio exigem e decide quando o plano é acionado.

Se só a TI participa, o resultado é um plano tecnicamente correto para números que ninguém aprovou.

Uma conversa que mostra a diferença: quando a TI pergunta “quanto tempo o faturamento pode ficar fora?”, a resposta costuma vir como “o mínimo possível”. Esse número não serve para projetar nada. O projeto troca a pergunta por outra, que o gestor consegue responder: “o que acontece com a operação se este sistema ficar parado por meio dia? E por dois dias?”. A partir da resposta, o RTO deixa de ser palpite.

Como escolher a estratégia de recuperação de cada sistema

Nem tudo precisa voltar na mesma velocidade, e é essa distinção que controla o custo. As estratégias vão da recuperação a partir do backup, mais barata e mais lenta, até o ambiente em espera já ligado e sincronizado (hot standby), mais caro e mais rápido. O projeto de DRP não exige um ambiente secundário duplicado: a escolha é feita sistema por sistema, de acordo com o RTO que o negócio definiu.

Na prática, o desenho segue quatro perguntas, na ordem:

1. Qual é o RTO deste sistema? Quanto menor, mais perto do ambiente em espera a estratégia precisa ficar.
2. Qual é o RPO? Se a empresa não pode perder mais do que alguns minutos de dado, o backup diário não basta e entra algum tipo de replicação.
3. De que ele depende? Não adianta um sistema ter estratégia rápida se o serviço de que ele depende tem estratégia lenta.
4. Quanto custa manter essa estratégia? O custo entra na conversa com a direção junto com o número do negócio, para que a decisão seja consciente.

Um exemplo ilustrativo, não de um cliente: um sistema de consulta interna, que a empresa consegue ficar um dia sem, costuma ser recuperado a partir do backup. O sistema de pedidos, sem o qual a empresa para de vender, pede uma estratégia mais rápida. O mesmo ambiente tem as duas, cada uma com o custo que cabe no negócio.

Duas distinções ajudam na conversa. Backup guarda cópias dos dados, e o DRP organiza a recuperação do ambiente. Alta disponibilidade mantém o serviço de pé quando um componente falha, mas não substitui backup nem DRP. Para a primeira, veja a página de Backup.

Ambiente híbrido e ransomware

Em ambiente híbrido, o plano trata das dependências entre o que está local e o que está em nuvem, que é onde costumam aparecer as surpresas. Um exemplo comum: o aplicativo está em nuvem, mas o login passa por um servidor de identidade local. Se o site local cai, o aplicativo, que estava intacto, deixa de abrir. Somos parceiros Microsoft Azure e atuamos com as demais nuvens.

No ransomware, a lógica muda. Num desastre físico, a cópia mais recente serve. Num ataque, ela pode já estar comprometida, e o plano precisa prever a volta a um ponto anterior à infecção. Isso afeta a retenção das cópias e coloca a proteção do backup dentro do desenho do DRP.

Por isso o projeto trata o cenário de ransomware como um caso à parte, com procedimento próprio. Ele define quem decide isolar o ambiente, qual cópia é considerada confiável e em que ordem os sistemas voltam depois que o ambiente foi limpo.

Como saber se o plano está bom: critérios de conferência

Um plano de DRP bom passa por uma lista curta de perguntas. Se alguma resposta for “não”, o plano ainda tem trabalho pela frente:

• Cada sistema crítico tem RTO e RPO aprovados por quem responde pelo processo?
• Existe uma ordem de recuperação escrita, com as dependências consideradas?
• Cada procedimento pode ser seguido por alguém que não participou da sua escrita?
• Cada papel tem titular e suplente, com contato atualizado?
• O plano tem roteiro de teste, e o que falhou nos testes já feitos foi corrigido?
• Existe uma data de revisão e um gatilho para revisão fora do calendário?
• O backup está protegido contra alteração e exclusão, inclusive em um cenário de ransomware?

A lista é um ponto de partida para a conversa com a equipe, não uma certificação.

O que a norma ISO 22301 muda neste trabalho

A ISO 22301:2019 é a norma internacional de sistemas de gestão de continuidade de negócios. Usamos a norma como referência de boas práticas para estruturar o plano. O projeto de DRP não certifica a empresa na norma: a certificação é feita por um organismo certificador acreditado.

Como leitura complementar sobre plano de contingência de sistemas de informação, há o NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems, guia do órgão de padrões dos Estados Unidos, publicado em maio de 2010 e atualizado em 11/11/2010.

Como a Integrity-UX conduz esse trabalho

O começo é um diagnóstico do ambiente atual, que levanta sistemas, dependências e pontos únicos de falha. É dele que saem o escopo, o esforço e o prazo por fase. Depois do plano pronto, o nosso time pode acompanhar a revisão periódica e a execução dos testes, conforme a necessidade da empresa.

Prazo e valor dependem do escopo e são definidos em proposta. Contamos com equipe certificada e trabalhamos em nuvem, ambiente local e ambiente híbrido.

Próximos passos

Para chegar à primeira conversa com algo útil em mãos, vale reunir:

• a lista dos sistemas que a empresa considera críticos;
• o desenho do ambiente (local, nuvem ou híbrido);
• o que já existe de backup;
• se algum plano já foi testado e quando.

Com isso, o nosso time monta o diagnóstico. Conheça também a página do serviço de DRP (Disaster Recovery Plan) ou fale com um especialista do nosso time.

Perguntas frequentes

O que uma consultoria de DRP entrega?

Análise de riscos, levantamento de sistemas e dependências, RTO e RPO acordados com cada área, ordem de recuperação, procedimentos passo a passo, responsáveis e suplentes, roteiro de teste, treinamento e revisão periódica.

O DRP precisa de um ambiente secundário duplicado?

Não necessariamente. A estratégia varia conforme o RTO de cada sistema, da recuperação a partir do backup até o ambiente em espera. A maioria das empresas usa estratégias diferentes para sistemas diferentes.

Quem precisa participar do projeto além da TI?

As áreas de negócio e a direção. RTO e RPO respondem quanto tempo a operação pode ficar parada e quanto dado pode ser perdido, e só quem responde pelo processo sabe dizer.

Qual a diferença entre DRP e alta disponibilidade?

Alta disponibilidade mantém o serviço de pé quando um componente falha. O DRP organiza a retomada quando o ambiente inteiro se perde. Um não substitui o outro, e nenhum dos dois substitui o backup.

O DRP da Integrity-UX certifica a empresa na ISO 22301?

Não. A norma é usada como referência de boas práticas. A certificação ISO 22301 é feita por um organismo certificador acreditado.

O plano cobre ransomware?

Sim. O projeto trata o ransomware como cenário próprio, com a volta a um ponto anterior à infecção e a proteção do backup dentro do desenho.

Quanto custa e quanto tempo leva?

Depende do escopo. Prazo e valor são definidos em proposta, depois do diagnóstico do ambiente.

Última atualização: 11 de novembro de 2026.

Fontes:

• ISO 22301:2019, Security and resilience, Business continuity management systems, Requirements. Edição 2, publicada em outubro de 2019. iso.org/standard/75106.html (consultada em 11/11/2026).
• ISO 22301:2019/Amd 1:2024, Security and resilience, Business continuity management systems, Requirements, Amendment 1: Climate action changes. Publicada em fevereiro de 2024. iso.org/standard/88412.html (consultada em 11/11/2026).
• NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems. Publicado em maio de 2010, atualizado em 11/11/2010. csrc.nist.gov/pubs/sp/800/34/r1/upd1/final (consultada em 11/11/2026).