Um projeto de consultoria de DRP (Disaster Recovery Plan, plano de recupera\u00e7\u00e3o de desastres) tem come\u00e7o, 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\u00e1veis definidos para cada etapa da recupera\u00e7\u00e3o.<\/p>\n
Na pr\u00e1tica, o trabalho se divide em sete etapas: an\u00e1lise de riscos, levantamento de sistemas e depend\u00eancias, defini\u00e7\u00e3o de RTO e RPO com cada \u00e1rea, ordem de recupera\u00e7\u00e3o e procedimentos, respons\u00e1veis e suplentes, roteiro de teste com treinamento e revis\u00e3o peri\u00f3dica. Cada etapa tem uma entrega concreta, e a empresa sabe o que vai receber antes de come\u00e7ar.<\/p>\n
Este texto mostra como esse projeto funciona por dentro, quem precisa participar e onde ele costuma travar. Para a defini\u00e7\u00e3o conceitual de DRP, RTO e RPO, leia DRP (Plan de Recuperaci\u00f3n ante Desastres): qu\u00e9 es, c\u00f3mo elaborarlo y con qu\u00e9 frecuencia probarlo<\/a>. Aqui o foco \u00e9 a condu\u00e7\u00e3o do projeto.<\/p>\n A consultoria n\u00e3o \u00e9 a compra de uma ferramenta, nem um documento para guardar na gaveta. Ela faz sentido em tr\u00eas situa\u00e7\u00f5es comuns.<\/p>\n A consultoria n\u00e3o substitui a equipe interna. Ela soma experi\u00eancia em um projeto que a equipe faz poucas vezes na vida e deixa o plano nas m\u00e3os de quem vai execut\u00e1-lo.<\/p>\n Casi todas las empresas tienen alguna copia de seguridad. Pocas tienen un plan que diga, sin improvisar, qu\u00e9 vuelve primero, qui\u00e9n decide y qu\u00e9 hacer cuando la persona que conoce el sistema no contesta el tel\u00e9fono.<\/p>\n O trabalho trava em tr\u00eas pontos conhecidos:<\/p>\n Um projeto bem conduzido trata os tr\u00eas desde o in\u00edcio. 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\u00e3o de neg\u00f3cio, documento e rotina de teste.<\/p>\n A ordem importa. Cada etapa usa o resultado da anterior, e pular uma delas costuma aparecer depois, como um buraco no plano.<\/p>\n O ponto de partida s\u00e3o as amea\u00e7as que podem parar a opera\u00e7\u00e3o daquele ambiente, do ransomware \u00e0 falha de hardware e \u00e0 perda de um site. O resultado \u00e9 uma lista priorizada, que orienta onde vale investir primeiro. Um plano gen\u00e9rico tende a falhar justamente no cen\u00e1rio que ningu\u00e9m mapeou.<\/p>\n O que voc\u00ea recebe:<\/strong> a lista de cen\u00e1rios, ordenada pelo efeito que cada um teria na opera\u00e7\u00e3o.<\/p>\n Aqui se descobre o que existe, o que \u00e9 cr\u00edtico e o que depende de qu\u00ea. \u00c9 a etapa que evita a surpresa cl\u00e1ssica: um sistema em nuvem que n\u00e3o volta porque depende de um servi\u00e7o de autentica\u00e7\u00e3o local. O levantamento inclui a an\u00e1lise de impacto no neg\u00f3cio (BIA, do ingl\u00eas business impact analysis): saber o que cada sistema sustenta e o que a empresa perde quando ele para.<\/p>\n O que voc\u00ea recebe:<\/strong> o invent\u00e1rio dos sistemas e o mapa do que depende de qu\u00ea.<\/p>\n O RPO \u00e9 quanto dado \u00e9 aceit\u00e1vel perder. O RTO \u00e9 em quanto tempo o servi\u00e7o precisa voltar. Quem responde pelo processo define os dois n\u00fameros, porque s\u00e3o uma decis\u00e3o de neg\u00f3cio com custo: quanto menor o tempo, maior o investimento. A TI diz como entregar o n\u00famero, n\u00e3o qual n\u00famero \u00e9 aceit\u00e1vel. O artigo Como definir RTO e RPO<\/a> detalha essa conversa.<\/p>\n O que voc\u00ea recebe:<\/strong> uma tabela de RTO e RPO por sistema, com a aprova\u00e7\u00e3o de quem responde por cada processo.<\/p>\n Com RTO, RPO e depend\u00eancias 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\u00e3o para quem vai auditar.<\/p>\n O que voc\u00ea recebe:<\/strong> a sequ\u00eancia de recupera\u00e7\u00e3o e os procedimentos passo a passo.<\/p>\n Cada etapa tem um respons\u00e1vel e um suplente. O plano precisa funcionar quando a pessoa principal est\u00e1 de f\u00e9rias, doente ou fora do alcance.<\/p>\n O que voc\u00ea recebe:<\/strong> a lista de pap\u00e9is, com titular e suplente de cada um.<\/p>\n O plano sai com um roteiro de teste, e a equipe \u00e9 treinada para os seus pap\u00e9is. O teste em si \u00e9 feito depois, com a empresa, no intervalo combinado, e o que falha volta para o plano. O texto C\u00f3mo probar el plan de continuidad sin detener la operaci\u00f3n<\/a> detalha os formatos de teste.<\/p>\n O que voc\u00ea recebe:<\/strong> o roteiro de teste e a equipe treinada para execut\u00e1-lo.<\/p>\n Sistemas mudam, fornecedores mudam, pessoas mudam. A revis\u00e3o peri\u00f3dica confere se sistemas, depend\u00eancias e respons\u00e1veis continuam os mesmos. Uma mudan\u00e7a relevante de arquitetura, como uma migra\u00e7\u00e3o ou um sistema novo, pede revis\u00e3o fora do calend\u00e1rio.<\/p>\n O que voc\u00ea recebe:<\/strong> o plano atualizado, com o registro do que mudou.<\/p>\n Tr\u00eas grupos participam do projeto, e nenhum deles dispensa os outros.<\/p>\n Se s\u00f3 a TI participa, o resultado \u00e9 um plano tecnicamente correto para n\u00fameros que ningu\u00e9m aprovou.<\/p>\n Uma conversa que mostra a diferen\u00e7a: quando a TI pergunta “quanto tempo o faturamento pode ficar fora?”, a resposta costuma vir como “o m\u00ednimo poss\u00edvel”. Esse n\u00famero n\u00e3o serve para projetar nada. O projeto troca a pergunta por outra, que o gestor consegue responder: “o que acontece com a opera\u00e7\u00e3o se este sistema ficar parado por meio dia? E por dois dias?”. A partir da resposta, o RTO deixa de ser palpite.<\/p>\n Nem tudo precisa voltar na mesma velocidade, e \u00e9 essa distin\u00e7\u00e3o que controla o custo. As estrat\u00e9gias v\u00e3o da recupera\u00e7\u00e3o a partir do backup, mais barata e mais lenta, at\u00e9 o ambiente em espera j\u00e1 ligado e sincronizado (hot standby), mais caro e mais r\u00e1pido. O projeto de DRP n\u00e3o exige um ambiente secund\u00e1rio duplicado: a escolha \u00e9 feita sistema por sistema, de acordo com o RTO que o neg\u00f3cio definiu.<\/p>\n Na pr\u00e1tica, o desenho segue quatro perguntas, na ordem:<\/p>\n Um exemplo ilustrativo, n\u00e3o 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\u00e9gia mais r\u00e1pida. O mesmo ambiente tem as duas, cada uma com o custo que cabe no neg\u00f3cio.<\/p>\n Duas distin\u00e7\u00f5es ajudam na conversa. Backup guarda c\u00f3pias dos dados, e o DRP organiza a recupera\u00e7\u00e3o do ambiente. Alta disponibilidade mant\u00e9m o servi\u00e7o de p\u00e9 quando um componente falha, mas n\u00e3o substitui backup nem DRP. Para a primeira, veja a p\u00e1gina de Backup<\/a>.<\/p>\n Em ambiente h\u00edbrido, o plano trata das depend\u00eancias entre o que est\u00e1 local e o que est\u00e1 em nuvem, que \u00e9 onde costumam aparecer as surpresas. Um exemplo comum: o aplicativo est\u00e1 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.<\/p>\n No ransomware, a l\u00f3gica muda. Num desastre f\u00edsico, a c\u00f3pia mais recente serve. Num ataque, ela pode j\u00e1 estar comprometida, e o plano precisa prever a volta a um ponto anterior \u00e0 infec\u00e7\u00e3o. Isso afeta a reten\u00e7\u00e3o das c\u00f3pias e coloca a prote\u00e7\u00e3o do backup dentro do desenho do DRP.<\/p>\n Por isso o projeto trata o cen\u00e1rio de ransomware como um caso \u00e0 parte, com procedimento pr\u00f3prio. Ele define quem decide isolar o ambiente, qual c\u00f3pia \u00e9 considerada confi\u00e1vel e em que ordem os sistemas voltam depois que o ambiente foi limpo.<\/p>\n Um plano de DRP bom passa por uma lista curta de perguntas. Se alguma resposta for “n\u00e3o”, o plano ainda tem trabalho pela frente:<\/p>\n A lista \u00e9 um ponto de partida para a conversa com a equipe, n\u00e3o uma certifica\u00e7\u00e3o.<\/p>\n A ISO 22301:2019<\/a> \u00e9 a norma internacional de sistemas de gest\u00e3o de continuidade de neg\u00f3cios. Usamos a norma como refer\u00eancia de boas pr\u00e1ticas para estruturar o plano. O projeto de DRP n\u00e3o certifica a empresa na norma: a certifica\u00e7\u00e3o \u00e9 feita por um organismo certificador acreditado.<\/p>\n Como leitura complementar sobre plano de conting\u00eancia de sistemas de informa\u00e7\u00e3o, h\u00e1 o NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems<\/a>, guia do \u00f3rg\u00e3o de padr\u00f5es dos Estados Unidos, publicado em maio de 2010 e atualizado em 11\/11\/2010.<\/p>\n O come\u00e7o \u00e9 um diagn\u00f3stico do ambiente atual, que levanta sistemas, depend\u00eancias e pontos \u00fanicos de falha. \u00c9 dele que saem o escopo, o esfor\u00e7o e o prazo por fase. Depois do plano pronto, o nosso time pode acompanhar a revis\u00e3o peri\u00f3dica e a execu\u00e7\u00e3o dos testes, conforme a necessidade da empresa.<\/p>\n Prazo e valor dependem do escopo e s\u00e3o definidos em proposta. Contamos com equipe certificada e trabalhamos em nuvem, ambiente local e ambiente h\u00edbrido.<\/p>\n Para chegar \u00e0 primeira conversa com algo \u00fatil em m\u00e3os, vale reunir:<\/p>\n Com isso, o nosso time monta o diagn\u00f3stico. Conhe\u00e7a tamb\u00e9m a p\u00e1gina do servi\u00e7o de DRP (Plan de Recuperaci\u00f3n ante Desastres)<\/a> o fale com um especialista do nosso time<\/a>.<\/p>\n An\u00e1lise de riscos, levantamento de sistemas e depend\u00eancias, RTO e RPO acordados com cada \u00e1rea, ordem de recupera\u00e7\u00e3o, procedimentos passo a passo, respons\u00e1veis e suplentes, roteiro de teste, treinamento e revis\u00e3o peri\u00f3dica.<\/p>\n N\u00e3o necessariamente. A estrat\u00e9gia varia conforme o RTO de cada sistema, da recupera\u00e7\u00e3o a partir do backup at\u00e9 o ambiente em espera. A maioria das empresas usa estrat\u00e9gias diferentes para sistemas diferentes.<\/p>\n As \u00e1reas de neg\u00f3cio e a dire\u00e7\u00e3o. RTO e RPO respondem quanto tempo a opera\u00e7\u00e3o pode ficar parada e quanto dado pode ser perdido, e s\u00f3 quem responde pelo processo sabe dizer.<\/p>\n Alta disponibilidade mant\u00e9m o servi\u00e7o de p\u00e9 quando um componente falha. O DRP organiza a retomada quando o ambiente inteiro se perde. Um n\u00e3o substitui o outro, e nenhum dos dois substitui o backup.<\/p>\n N\u00e3o. A norma \u00e9 usada como refer\u00eancia de boas pr\u00e1ticas. A certifica\u00e7\u00e3o ISO 22301 \u00e9 feita por um organismo certificador acreditado.<\/p>\n Sim. O projeto trata o ransomware como cen\u00e1rio pr\u00f3prio, com a volta a um ponto anterior \u00e0 infec\u00e7\u00e3o e a prote\u00e7\u00e3o do backup dentro do desenho.<\/p>\n Depende del alcance. El plazo y el valor se definen en una propuesta, despu\u00e9s del diagn\u00f3stico del entorno.<\/p>\n \u00daltima atualiza\u00e7\u00e3o:<\/strong> 11 de novembro de 2026.<\/p>\n Fuentes:<\/strong><\/p>\n Como um projeto de consultoria de DRP funciona por dentro: as sete etapas, o que cada uma entrega, quem participa e onde costuma travar.<\/p>","protected":false},"author":6,"featured_media":4905,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_iux_titulo_en":"Disaster Recovery Consulting: How the Project Works and What It Delivers","_iux_conteudo_en":" A disaster recovery (DR) consulting project has a start, a middle and an end. It begins with the environment a company runs today and ends with a written recovery plan with a test plan and a trained team, with a named owner for every step of the recovery.<\/p>\n In practice the work breaks into seven stages: risk analysis, a systems and dependency inventory, RTO and RPO agreed with each business area, recovery order and runbooks, owners and alternates, a test plan with training, and periodic review. Every stage produces a concrete deliverable, so the company knows what it will receive before the work starts.<\/p>\n This article explains how that project works from the inside, who has to take part, and where it tends to stall. For the basic definitions of DR, RTO and RPO, read DRP (Disaster Recovery Plan): what it is, how to build one and how often to test it<\/a> (in Portuguese). Here the focus is how the engagement is run.<\/p>\n\n Consulting is not the purchase of a tool, and it is not a document that sits in a drawer. It makes sense in three common situations.<\/p>\n Consulting does not replace the in-house team. It adds experience to a project the team runs only a few times in a career, and it leaves the plan in the hands of the people who will execute it.<\/p>\n\n Almost every company has some kind of backup. Few have a plan that says, without improvisation, what comes up first, who makes the call, and what to do when the one person who knows the system is not answering the phone.<\/p>\n The work stalls at three well-known points:<\/p>\n A well-run project addresses all three from the start. The plan ships with a test plan and team training; the test itself comes later, run together with the company. That is why the list of deliverables below mixes business decisions, documents and a testing routine.<\/p>\n\n The order matters. Each stage uses the output of the previous one, and skipping a stage usually shows up later as a hole in the plan.<\/p>\n\n The starting point is the threats that could stop operations in that specific environment, from ransomware to hardware failure to the loss of a site. The result is a prioritized list that shows where to invest first. A generic plan tends to fail in exactly the scenario nobody mapped.<\/p>\n What you receive:<\/strong> the list of scenarios, ranked by the effect each one would have on operations.<\/p>\n\n This is where you find out what exists, what is critical and what depends on what. It prevents the classic surprise: a cloud system that will not come back because it depends on an on-premises authentication service. The inventory includes the business impact analysis (BIA): knowing what each system supports and what the company loses when it goes down.<\/p>\n What you receive:<\/strong> the systems inventory and a map of what depends on what.<\/p>\n\n RPO is how much data the business can afford to lose. RTO is how fast a service has to be back. The person who owns the process sets both numbers, because they are a business decision with a cost: the shorter the time, the larger the investment. IT explains how to deliver the number, not which number is acceptable. The article How to define RTO and RPO<\/a> (in Portuguese) covers that conversation.<\/p>\n What you receive:<\/strong> an RTO and RPO table per system, approved by the owner of each process.<\/p>\n\n With RTO, RPO and dependencies on the table, you set the order: what comes up first, how, and what waits. Each step becomes a runbook written for the person who will execute it, not for the person who will audit it.<\/p>\n What you receive:<\/strong> the recovery sequence and the step-by-step runbooks.<\/p>\n\n Every step has an owner and an alternate. The plan has to work when the primary person is on vacation, sick or out of reach.<\/p>\n What you receive:<\/strong> the list of roles, with a primary and an alternate for each.<\/p>\n\n The plan ships with a test plan, and the team is trained for its roles. The test itself is run later, together with the company, at the agreed interval, and whatever fails goes back into the plan. The article How to test a continuity plan without stopping operations<\/a> (in Portuguese) covers the test formats.<\/p>\n What you receive:<\/strong> the test plan and a team trained to run it.<\/p>\n\n Systems change, vendors change, people change. The periodic review checks that systems, dependencies and owners are still the same. A significant architecture change, such as a migration or a new system, calls for a review outside the calendar.<\/p>\n What you receive:<\/strong> the updated plan, with a record of what changed.<\/p>\n\n Three groups take part in the project, and none of them can stand in for the others.<\/p>\n If only IT takes part, the result is a plan that is technically correct for numbers nobody approved.<\/p>\n A conversation that shows the difference: when IT asks \"how long can billing be out?\", the answer usually comes back as \"as little as possible.\" That number cannot be used to design anything. The project swaps in a question the manager can answer: \"what happens to operations if this system is down for half a day? And for two days?\" From that answer on, RTO stops being a guess.<\/p>\n\n Not everything has to come back at the same speed, and that distinction is what controls cost. Strategies range from restoring from backup, the cheapest and slowest, to a hot standby environment that is already running and synchronized, the most expensive and the fastest. A DR project does not require a duplicate secondary site: the choice is made system by system, according to the RTO the business set.<\/p>\n In practice, the design follows four questions, in order:<\/p>\n An illustrative example, not from a client: an internal lookup system the company can do without for a day is usually recovered from backup. The order system, without which the company stops selling, calls for a faster strategy. The same environment holds both, each at a cost the business can carry.<\/p>\n Two distinctions help the conversation. Backup keeps copies of the data, and DR organizes the recovery of the environment. High availability keeps a service up when a component fails, but it replaces neither backup nor DR. For the first, see our Backup page<\/a> (in Portuguese).<\/p>\n\n In a hybrid environment, the plan deals with the dependencies between what runs on premises and what runs in the cloud, which is where the surprises tend to appear. A common example: the application runs in the cloud, but login goes through an on-premises identity server. If the local site goes down, the application, which was intact, no longer opens. We are a Microsoft Azure partner and also work with the other clouds.<\/p>\n With ransomware, the logic changes. After a physical disaster, the most recent copy will do. After an attack, it may already be compromised, and the plan has to provide for rolling back to a point before the infection. That affects backup retention and brings backup protection inside the DR design.<\/p>\n That is why the project treats ransomware as a separate case with its own procedure. It defines who decides to isolate the environment, which copy is considered trustworthy, and in what order systems come back once the environment has been cleaned.<\/p>\n\n A good DR plan passes a short list of questions. If any answer is \"no,\" the plan still has work ahead:<\/p>\n The list is a starting point for a conversation with the team, not a certification.<\/p>\n\n ISO 22301:2019<\/a> is the international standard for business continuity management systems. We use it as a good-practice reference to structure the plan. A DR project does not certify the company to the standard: certification is done by an accredited certification body.<\/p>\n For further reading on contingency planning for information systems, there is NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems<\/a>, a guide from the U.S. standards agency, published in May 2010 and updated on 11\/11\/2010.<\/p>\n\n It starts with a diagnostic of the current environment that maps systems, dependencies and single points of failure. The scope, the effort and the timeline for each phase come from it. Once the plan is ready, our team can support the periodic review and the execution of tests, depending on what the company needs.<\/p>\n Timeline and price depend on the scope and are set in a proposal. We have a certified team and work in the cloud, on premises and in hybrid environments.<\/p>\n\n To reach the first conversation with something useful in hand, gather:<\/p>\n With that, our team builds the diagnostic. See also the DRP (Disaster Recovery Plan)<\/a> service page or talk to a specialist on our team<\/a>.<\/p>\n\n Risk analysis, a systems and dependency inventory, RTO and RPO agreed with each area, recovery order, step-by-step runbooks, owners and alternates, a test plan, training and periodic review.<\/p>\n Not necessarily. The strategy varies with each system's RTO, from restoring from backup to a standby environment. Most companies use different strategies for different systems.<\/p>\n The business areas and leadership. RTO and RPO answer how long operations can stay down and how much data can be lost, and only the person who owns the process can say.<\/p>\n High availability keeps a service up when a component fails. DR organizes the restart when the whole environment is lost. Neither replaces the other, and neither replaces backup.<\/p>\n No. The standard is used as a good-practice reference. ISO 22301 certification is done by an accredited certification body.<\/p>\n Yes. The project treats ransomware as its own scenario, with a rollback to a point before the infection and backup protection built into the design.<\/p>\n It depends on the scope. Timeline and price are set in a proposal, after the diagnostic of the environment.<\/p>\n\n Last updated:<\/strong> November 11, 2026.<\/p>\n Sources:<\/strong><\/p>\n Un proyecto de consultor\u00eda de DRP (Disaster Recovery Plan, plan de recuperaci\u00f3n ante desastres) tiene principio, desarrollo y fin. Parte del entorno que la empresa tiene hoy y termina con un plan escrito, con guion de pruebas y equipo capacitado, con responsables definidos para cada paso de la recuperaci\u00f3n.<\/p>\n En la pr\u00e1ctica, el trabajo se divide en siete etapas: an\u00e1lisis de riesgos, relevamiento de sistemas y dependencias, definici\u00f3n de RTO y RPO con cada \u00e1rea, orden de recuperaci\u00f3n y procedimientos, responsables y suplentes, guion de pruebas con capacitaci\u00f3n y revisi\u00f3n peri\u00f3dica. Cada etapa tiene un entregable concreto, y la empresa sabe qu\u00e9 va a recibir antes de empezar.<\/p>\n Este texto muestra c\u00f3mo funciona ese proyecto por dentro, qui\u00e9n tiene que participar y d\u00f3nde suele atascarse. Para la definici\u00f3n conceptual de DRP, RTO y RPO, lea DRP (Disaster Recovery Plan): qu\u00e9 es, c\u00f3mo elaborarlo y con qu\u00e9 frecuencia probarlo<\/a> (en portugu\u00e9s). Aqu\u00ed el foco es la conducci\u00f3n del proyecto.<\/p>\n\n La consultor\u00eda no es la compra de una herramienta ni un documento para guardar en un caj\u00f3n. Tiene sentido en tres situaciones comunes.<\/p>\n La consultor\u00eda no sustituye al equipo interno. Suma experiencia en un proyecto que el equipo hace pocas veces en la vida y deja el plan en manos de quien va a ejecutarlo.<\/p>\n\n Casi toda empresa tiene alguna copia de seguridad. Pocas tienen un plan que diga, sin improvisar, qu\u00e9 se levanta primero, qui\u00e9n decide y qu\u00e9 hacer cuando la persona que conoce el sistema no atiende el tel\u00e9fono.<\/p>\n El trabajo se atasca en tres puntos conocidos:<\/p>\n Un proyecto bien conducido trata los tres desde el inicio. El plan sale con guion de pruebas y capacitaci\u00f3n del equipo; la prueba en s\u00ed viene despu\u00e9s, hecha junto con la empresa. Por eso la lista de entregables de abajo mezcla decisi\u00f3n de negocio, documento y rutina de pruebas.<\/p>\n\n El orden importa. Cada etapa usa el resultado de la anterior, y saltarse una suele notarse despu\u00e9s, como un hueco en el plan.<\/p>\n\n El punto de partida son las amenazas que pueden detener la operaci\u00f3n de ese entorno, desde el ransomware hasta la falla de hardware y la p\u00e9rdida de un sitio. El resultado es una lista priorizada que orienta d\u00f3nde conviene invertir primero. Un plan gen\u00e9rico tiende a fallar justo en el escenario que nadie mape\u00f3.<\/p>\n Qu\u00e9 recibe:<\/strong> la lista de escenarios, ordenada por el efecto que cada uno tendr\u00eda en la operaci\u00f3n.<\/p>\n\n Aqu\u00ed se descubre qu\u00e9 existe, qu\u00e9 es cr\u00edtico y qu\u00e9 depende de qu\u00e9. Es la etapa que evita la sorpresa cl\u00e1sica: un sistema en la nube que no vuelve porque depende de un servicio de autenticaci\u00f3n local. El relevamiento incluye el an\u00e1lisis de impacto en el negocio (BIA, por business impact analysis): saber qu\u00e9 sostiene cada sistema y qu\u00e9 pierde la empresa cuando se detiene.<\/p>\n Qu\u00e9 recibe:<\/strong> el inventario de los sistemas y el mapa de qu\u00e9 depende de qu\u00e9.<\/p>\n\n El RPO es cu\u00e1ntos datos es aceptable perder. El RTO es en cu\u00e1nto tiempo debe volver el servicio. Quien responde por el proceso define ambos n\u00fameros, porque son una decisi\u00f3n de negocio con costo: cuanto menor el tiempo, mayor la inversi\u00f3n. TI explica c\u00f3mo lograr el n\u00famero, no cu\u00e1l n\u00famero es aceptable. El art\u00edculo C\u00f3mo definir RTO y RPO<\/a> (en portugu\u00e9s) detalla esa conversaci\u00f3n.<\/p>\n Qu\u00e9 recibe:<\/strong> una tabla de RTO y RPO por sistema, con la aprobaci\u00f3n de quien responde por cada proceso.<\/p>\n\n Con RTO, RPO y dependencias sobre la mesa, se define el orden: qu\u00e9 se levanta primero, c\u00f3mo y qu\u00e9 espera. Cada paso se convierte en un procedimiento escrito para quien lo va a ejecutar, no para quien lo va a auditar.<\/p>\n Qu\u00e9 recibe:<\/strong> la secuencia de recuperaci\u00f3n y los procedimientos paso a paso.<\/p>\n\n Cada etapa tiene un responsable y un suplente. El plan tiene que funcionar cuando la persona principal est\u00e1 de vacaciones, enferma o fuera de alcance.<\/p>\n Qu\u00e9 recibe:<\/strong> la lista de roles, con titular y suplente para cada uno.<\/p>\n\n El plan sale con un guion de pruebas, y el equipo se capacita para sus roles. La prueba en s\u00ed se hace despu\u00e9s, junto con la empresa, en el intervalo acordado, y lo que falla vuelve al plan. El texto C\u00f3mo probar el plan de continuidad sin detener la operaci\u00f3n<\/a> (en portugu\u00e9s) detalla los formatos de prueba.<\/p>\n Qu\u00e9 recibe:<\/strong> el guion de pruebas y el equipo capacitado para ejecutarlo.<\/p>\n\n Los sistemas cambian, los proveedores cambian, las personas cambian. La revisi\u00f3n peri\u00f3dica comprueba que sistemas, dependencias y responsables siguen siendo los mismos. Un cambio relevante de arquitectura, como una migraci\u00f3n o un sistema nuevo, exige una revisi\u00f3n fuera del calendario.<\/p>\n Qu\u00e9 recibe:<\/strong> el plan actualizado, con el registro de lo que cambi\u00f3.<\/p>\n\n Tres grupos participan en el proyecto, y ninguno prescinde de los otros.<\/p>\n Si solo participa TI, el resultado es un plan t\u00e9cnicamente correcto para n\u00fameros que nadie aprob\u00f3.<\/p>\n Una conversaci\u00f3n que muestra la diferencia: cuando TI pregunta \"\u00bfcu\u00e1nto tiempo puede estar fuera la facturaci\u00f3n?\", la respuesta suele ser \"lo m\u00ednimo posible\". Ese n\u00famero no sirve para dise\u00f1ar nada. El proyecto cambia la pregunta por otra que el gestor s\u00ed puede responder: \"\u00bfqu\u00e9 le pasa a la operaci\u00f3n si este sistema queda detenido medio d\u00eda? \u00bfY dos d\u00edas?\". A partir de la respuesta, el RTO deja de ser una corazonada.<\/p>\n\n No todo necesita volver a la misma velocidad, y esa distinci\u00f3n es la que controla el costo. Las estrategias van desde la recuperaci\u00f3n a partir del respaldo, m\u00e1s barata y m\u00e1s lenta, hasta el entorno en espera ya encendido y sincronizado (hot standby), m\u00e1s caro y m\u00e1s r\u00e1pido. El proyecto de DRP no exige un entorno secundario duplicado: la elecci\u00f3n se hace sistema por sistema, seg\u00fan el RTO que defini\u00f3 el negocio.<\/p>\n En la pr\u00e1ctica, el dise\u00f1o sigue cuatro preguntas, en orden:<\/p>\n Un ejemplo ilustrativo, no de un cliente: un sistema de consulta interna, que la empresa puede pasar un d\u00eda sin usar, suele recuperarse a partir del respaldo. El sistema de pedidos, sin el cual la empresa deja de vender, pide una estrategia m\u00e1s r\u00e1pida. El mismo entorno tiene las dos, cada una con el costo que cabe en el negocio.<\/p>\n Dos distinciones ayudan en la conversaci\u00f3n. El respaldo guarda copias de los datos, y el DRP organiza la recuperaci\u00f3n del entorno. La alta disponibilidad mantiene el servicio en pie cuando falla un componente, pero no sustituye ni al respaldo ni al DRP. Para el primero, vea la p\u00e1gina de Backup<\/a> (en portugu\u00e9s).<\/p>\n\n En un entorno h\u00edbrido, el plan trata las dependencias entre lo que est\u00e1 local y lo que est\u00e1 en la nube, que es donde suelen aparecer las sorpresas. Un ejemplo com\u00fan: la aplicaci\u00f3n est\u00e1 en la nube, pero el inicio de sesi\u00f3n pasa por un servidor de identidad local. Si el sitio local se cae, la aplicaci\u00f3n, que estaba intacta, deja de abrir. Somos socios de Microsoft Azure y trabajamos tambi\u00e9n con las dem\u00e1s nubes.<\/p>\n Con ransomware, la l\u00f3gica cambia. En un desastre f\u00edsico, sirve la copia m\u00e1s reciente. En un ataque, puede estar ya comprometida, y el plan debe prever la vuelta a un punto anterior a la infecci\u00f3n. Eso afecta la retenci\u00f3n de las copias y pone la protecci\u00f3n del respaldo dentro del dise\u00f1o del DRP.<\/p>\n Por eso el proyecto trata el escenario de ransomware como un caso aparte, con procedimiento propio. Define qui\u00e9n decide aislar el entorno, qu\u00e9 copia se considera confiable y en qu\u00e9 orden vuelven los sistemas una vez limpio el entorno.<\/p>\n\n Un buen plan de DRP pasa una lista corta de preguntas. Si alguna respuesta es \"no\", al plan todav\u00eda le queda trabajo:<\/p>\n La lista es un punto de partida para la conversaci\u00f3n con el equipo, no una certificaci\u00f3n.<\/p>\n\n La ISO 22301:2019<\/a> es la norma internacional de sistemas de gesti\u00f3n de continuidad del negocio. La usamos como referencia de buenas pr\u00e1cticas para estructurar el plan. El proyecto de DRP no certifica a la empresa en la norma: la certificaci\u00f3n la realiza un organismo certificador acreditado.<\/p>\n Como lectura complementaria sobre planes de contingencia de sistemas de informaci\u00f3n, existe la NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems<\/a>, gu\u00eda del organismo de normas de Estados Unidos, publicada en mayo de 2010 y actualizada el 11\/11\/2010.<\/p>\n\n El comienzo es un diagn\u00f3stico del entorno actual, que releva sistemas, dependencias y puntos \u00fanicos de falla. De ah\u00ed salen el alcance, el esfuerzo y el plazo por fase. Con el plan listo, nuestro equipo puede acompa\u00f1ar la revisi\u00f3n peri\u00f3dica y la ejecuci\u00f3n de las pruebas, seg\u00fan la necesidad de la empresa.<\/p>\n Plazo y valor dependen del alcance y se definen en una propuesta. Contamos con equipo certificado y trabajamos en la nube, en entorno local y en entorno h\u00edbrido.<\/p>\n\n Para llegar a la primera conversaci\u00f3n con algo \u00fatil en mano, conviene reunir:<\/p>\n Con eso, nuestro equipo arma el diagn\u00f3stico. Conozca tambi\u00e9n la p\u00e1gina del servicio de DRP (Disaster Recovery Plan)<\/a> o hable con un especialista de nuestro equipo<\/a>.<\/p>\n\n An\u00e1lisis de riesgos, relevamiento de sistemas y dependencias, RTO y RPO acordados con cada \u00e1rea, orden de recuperaci\u00f3n, procedimientos paso a paso, responsables y suplentes, guion de pruebas, capacitaci\u00f3n y revisi\u00f3n peri\u00f3dica.<\/p>\n No necesariamente. La estrategia var\u00eda seg\u00fan el RTO de cada sistema, desde la recuperaci\u00f3n a partir del respaldo hasta el entorno en espera. La mayor\u00eda de las empresas usa estrategias distintas para sistemas distintos.<\/p>\n Las \u00e1reas de negocio y la direcci\u00f3n. RTO y RPO responden cu\u00e1nto tiempo puede estar detenida la operaci\u00f3n y cu\u00e1ntos datos se pueden perder, y solo quien responde por el proceso lo sabe.<\/p>\n La alta disponibilidad mantiene el servicio en pie cuando falla un componente. El DRP organiza la reanudaci\u00f3n cuando se pierde el entorno completo. Uno no sustituye al otro, y ninguno de los dos sustituye al respaldo.<\/p>\n No. La norma se usa como referencia de buenas pr\u00e1cticas. La certificaci\u00f3n ISO 22301 la realiza un organismo certificador acreditado.<\/p>\n S\u00ed. El proyecto trata el ransomware como un escenario propio, con la vuelta a un punto anterior a la infecci\u00f3n y la protecci\u00f3n del respaldo dentro del dise\u00f1o.<\/p>\n Depende del alcance. Plazo y valor se definen en una propuesta, despu\u00e9s del diagn\u00f3stico del entorno.<\/p>\n\n \u00daltima actualizaci\u00f3n:<\/strong> 11 de noviembre de 2026.<\/p>\n Fuentes:<\/strong><\/p>\nPara quem faz sentido uma consultoria de DRP<\/h2>\n
\n
Onde um projeto de DRP costuma travar<\/h2>\n
\n
As sete etapas do projeto, uma a uma<\/h2>\n
1. An\u00e1lise de riscos<\/h3>\n
2. Levantamento de sistemas e depend\u00eancias<\/h3>\n
3. RTO e RPO acordados com cada \u00e1rea<\/h3>\n
4. Ordem de recupera\u00e7\u00e3o e procedimentos<\/h3>\n
5. Respons\u00e1veis e suplentes<\/h3>\n
6. Roteiro de teste e treinamento<\/h3>\n
7. Revis\u00e3o peri\u00f3dica<\/h3>\n
Quem precisa estar na sala<\/h2>\n
\n
Como escolher a estrat\u00e9gia de recupera\u00e7\u00e3o de cada sistema<\/h2>\n
\n
Ambiente h\u00edbrido e ransomware<\/h2>\n
Como saber se o plano est\u00e1 bom: crit\u00e9rios de confer\u00eancia<\/h2>\n
\n
O que a norma ISO 22301 muda neste trabalho<\/h2>\n
C\u00f3mo conduce Integrity-UX este trabajo<\/h2>\n
Pr\u00f3ximos pasos<\/h2>\n
\n
Preguntas frecuentes<\/h2>\n
\u00bfQu\u00e9 entrega una consultor\u00eda de DRP?<\/h3>\n
\u00bfEl DRP necesita un ambiente secundario duplicado?<\/h3>\n
\u00bfQui\u00e9n debe participar en el proyecto adem\u00e1s de TI?<\/h3>\n
\u00bfCu\u00e1l es la diferencia entre DRP y alta disponibilidad?<\/h3>\n
\u00bfEl DRP de Integrity-UX certifica a la empresa en la ISO 22301?<\/h3>\n
\u00bfEl plan cubre el ransomware?<\/h3>\n
\u00bfCu\u00e1nto cuesta y cu\u00e1nto tiempo lleva?<\/h3>\n
\n
When disaster recovery consulting makes sense<\/h2>\n
\n
Where a DR project usually stalls<\/h2>\n
\n
The seven stages of the project, one by one<\/h2>\n
1. Risk analysis<\/h3>\n
2. Systems and dependency inventory<\/h3>\n
3. RTO and RPO agreed with each business area<\/h3>\n
4. Recovery order and runbooks<\/h3>\n
5. Owners and alternates<\/h3>\n
6. Test plan and training<\/h3>\n
7. Periodic review<\/h3>\n
Who needs to be in the room<\/h2>\n
\n
How to choose the recovery strategy for each system<\/h2>\n
\n
Hybrid environments and ransomware<\/h2>\n
How to tell whether the plan is good: a checklist<\/h2>\n
\n
What ISO 22301 changes in this work<\/h2>\n
How Integrity-UX runs this work<\/h2>\n
Next steps<\/h2>\n
\n
Frequently asked questions<\/h2>\n
What does a disaster recovery consulting engagement deliver?<\/h3>\n
Does disaster recovery require a duplicate secondary site?<\/h3>\n
Who needs to take part besides IT?<\/h3>\n
What is the difference between disaster recovery and high availability?<\/h3>\n
Does the Integrity-UX DR service certify a company to ISO 22301?<\/h3>\n
Does the plan cover ransomware?<\/h3>\n
How much does it cost and how long does it take?<\/h3>\n
\n
Para qui\u00e9n tiene sentido una consultor\u00eda de DRP<\/h2>\n
\n
D\u00f3nde suele atascarse un proyecto de DRP<\/h2>\n
\n
Las siete etapas del proyecto, una por una<\/h2>\n
1. An\u00e1lisis de riesgos<\/h3>\n
2. Relevamiento de sistemas y dependencias<\/h3>\n
3. RTO y RPO acordados con cada \u00e1rea<\/h3>\n
4. Orden de recuperaci\u00f3n y procedimientos<\/h3>\n
5. Responsables y suplentes<\/h3>\n
6. Guion de pruebas y capacitaci\u00f3n<\/h3>\n
7. Revisi\u00f3n peri\u00f3dica<\/h3>\n
Qui\u00e9n tiene que estar en la sala<\/h2>\n
\n
C\u00f3mo elegir la estrategia de recuperaci\u00f3n de cada sistema<\/h2>\n
\n
Entorno h\u00edbrido y ransomware<\/h2>\n
C\u00f3mo saber si el plan es bueno: criterios de revisi\u00f3n<\/h2>\n
\n
Qu\u00e9 cambia la norma ISO 22301 en este trabajo<\/h2>\n
C\u00f3mo conduce este trabajo Integrity-UX<\/h2>\n
Pr\u00f3ximos pasos<\/h2>\n
\n
Preguntas frecuentes<\/h2>\n
\u00bfQu\u00e9 entrega una consultor\u00eda de DRP?<\/h3>\n
\u00bfEl DRP necesita un entorno secundario duplicado?<\/h3>\n
\u00bfQui\u00e9n debe participar adem\u00e1s de TI?<\/h3>\n
\u00bfCu\u00e1l es la diferencia entre DRP y alta disponibilidad?<\/h3>\n
\u00bfEl DRP de Integrity-UX certifica a la empresa en la ISO 22301?<\/h3>\n
\u00bfEl plan cubre el ransomware?<\/h3>\n
\u00bfCu\u00e1nto cuesta y cu\u00e1nto tiempo lleva?<\/h3>\n
\n