ES 
PT 
EN 
Un proyecto de consultoría de DRP (Disaster Recovery Plan, plan de recuperación 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ón.
En la práctica, el trabajo se divide en siete etapas: análisis de riesgos, relevamiento de sistemas y dependencias, definición de RTO y RPO con cada área, orden de recuperación y procedimientos, responsables y suplentes, guion de pruebas con capacitación y revisión periódica. Cada etapa tiene un entregable concreto, y la empresa sabe qué va a recibir antes de empezar.
Este texto muestra cómo funciona ese proyecto por dentro, quién tiene que participar y dónde suele atascarse. Para la definición conceptual de DRP, RTO y RPO, lea DRP (Disaster Recovery Plan): qué es, cómo elaborarlo y con qué frecuencia probarlo (en portugués). Aquí el foco es la conducción del proyecto.
Para quién tiene sentido una consultoría de DRP
La consultoría no es la compra de una herramienta ni un documento para guardar en un cajón. Tiene sentido en tres situaciones comunes.
- No existe un plan. La recuperación depende de la memoria de dos o tres personas, y nadie sabe decir en qué orden vuelven los sistemas.
- Existe un plan antiguo. Nunca se probó, o no acompañó los cambios del entorno: sistemas nuevos, proveedores distintos, personas que se fueron.
- La empresa va a cambiar su entorno. Una migración a la nube, el cambio de centro de datos o la consolidación de sistemas es el mejor momento para incluir la recuperación en el diseño desde el principio.
La consultoría 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.
Dónde suele atascarse un proyecto de DRP
Casi toda empresa tiene alguna copia de seguridad. Pocas tienen un plan que diga, sin improvisar, qué se levanta primero, quién decide y qué hacer cuando la persona que conoce el sistema no atiende el teléfono.
El trabajo se atasca en tres puntos conocidos:
- El DRP tratado como asunto solo de TI. El negocio queda fuera de las decisiones sobre tiempo y pérdida de datos, y el plan nace con números que nadie aprobó.
- El plan escrito como documento de auditoría. Queda prolijo, pero sin un paso a paso que alguien pueda seguir de madrugada durante un incidente.
- El plan que nunca se ejercitó. Solo se valida el día en que ya es tarde para corregirlo.
Un proyecto bien conducido trata los tres desde el inicio. El plan sale con guion de pruebas y capacitación del equipo; la prueba en sí viene después, hecha junto con la empresa. Por eso la lista de entregables de abajo mezcla decisión de negocio, documento y rutina de pruebas.
Las siete etapas del proyecto, una por una
El orden importa. Cada etapa usa el resultado de la anterior, y saltarse una suele notarse después, como un hueco en el plan.
1. Análisis de riesgos
El punto de partida son las amenazas que pueden detener la operación de ese entorno, desde el ransomware hasta la falla de hardware y la pérdida de un sitio. El resultado es una lista priorizada que orienta dónde conviene invertir primero. Un plan genérico tiende a fallar justo en el escenario que nadie mapeó.
Qué recibe: la lista de escenarios, ordenada por el efecto que cada uno tendría en la operación.
2. Relevamiento de sistemas y dependencias
Aquí se descubre qué existe, qué es crítico y qué depende de qué. Es la etapa que evita la sorpresa clásica: un sistema en la nube que no vuelve porque depende de un servicio de autenticación local. El relevamiento incluye el análisis de impacto en el negocio (BIA, por business impact analysis): saber qué sostiene cada sistema y qué pierde la empresa cuando se detiene.
Qué recibe: el inventario de los sistemas y el mapa de qué depende de qué.
3. RTO y RPO acordados con cada área
El RPO es cuántos datos es aceptable perder. El RTO es en cuánto tiempo debe volver el servicio. Quien responde por el proceso define ambos números, porque son una decisión de negocio con costo: cuanto menor el tiempo, mayor la inversión. TI explica cómo lograr el número, no cuál número es aceptable. El artículo Cómo definir RTO y RPO (en portugués) detalla esa conversación.
Qué recibe: una tabla de RTO y RPO por sistema, con la aprobación de quien responde por cada proceso.
4. Orden de recuperación y procedimientos
Con RTO, RPO y dependencias sobre la mesa, se define el orden: qué se levanta primero, cómo y qué espera. Cada paso se convierte en un procedimiento escrito para quien lo va a ejecutar, no para quien lo va a auditar.
Qué recibe: la secuencia de recuperación y los procedimientos paso a paso.
5. Responsables y suplentes
Cada etapa tiene un responsable y un suplente. El plan tiene que funcionar cuando la persona principal está de vacaciones, enferma o fuera de alcance.
Qué recibe: la lista de roles, con titular y suplente para cada uno.
6. Guion de pruebas y capacitación
El plan sale con un guion de pruebas, y el equipo se capacita para sus roles. La prueba en sí se hace después, junto con la empresa, en el intervalo acordado, y lo que falla vuelve al plan. El texto Cómo probar el plan de continuidad sin detener la operación (en portugués) detalla los formatos de prueba.
Qué recibe: el guion de pruebas y el equipo capacitado para ejecutarlo.
7. Revisión periódica
Los sistemas cambian, los proveedores cambian, las personas cambian. La revisión periódica comprueba que sistemas, dependencias y responsables siguen siendo los mismos. Un cambio relevante de arquitectura, como una migración o un sistema nuevo, exige una revisión fuera del calendario.
Qué recibe: el plan actualizado, con el registro de lo que cambió.
Quién tiene que estar en la sala
Tres grupos participan en el proyecto, y ninguno prescinde de los otros.
- Áreas de negocio: definen cuánto tiempo aguanta la operación detenida y cuántos datos se pueden perder.
- TI e infraestructura: informa qué existe, diseña la estrategia de recuperación y ejecuta los procedimientos.
- Dirección: aprueba la inversión que exigen los números del negocio y decide cuándo se activa el plan.
Si solo participa TI, el resultado es un plan técnicamente correcto para números que nadie aprobó.
Una conversación que muestra la diferencia: cuando TI pregunta “¿cuánto tiempo puede estar fuera la facturación?”, la respuesta suele ser “lo mínimo posible”. Ese número no sirve para diseñar nada. El proyecto cambia la pregunta por otra que el gestor sí puede responder: “¿qué le pasa a la operación si este sistema queda detenido medio día? ¿Y dos días?”. A partir de la respuesta, el RTO deja de ser una corazonada.
Cómo elegir la estrategia de recuperación de cada sistema
No todo necesita volver a la misma velocidad, y esa distinción es la que controla el costo. Las estrategias van desde la recuperación a partir del respaldo, más barata y más lenta, hasta el entorno en espera ya encendido y sincronizado (hot standby), más caro y más rápido. El proyecto de DRP no exige un entorno secundario duplicado: la elección se hace sistema por sistema, según el RTO que definió el negocio.
En la práctica, el diseño sigue cuatro preguntas, en orden:
- ¿Cuál es el RTO de este sistema? Cuanto menor, más cerca del entorno en espera debe estar la estrategia.
- ¿Cuál es el RPO? Si la empresa no puede perder más que unos minutos de datos, el respaldo diario no alcanza y entra algún tipo de replicación.
- ¿De qué depende? De nada sirve que un sistema tenga una estrategia rápida si el servicio del que depende tiene una lenta.
- ¿Cuánto cuesta mantener esa estrategia? El costo entra en la conversación con la dirección junto con el número del negocio, para que la decisión sea consciente.
Un ejemplo ilustrativo, no de un cliente: un sistema de consulta interna, que la empresa puede pasar un día sin usar, suele recuperarse a partir del respaldo. El sistema de pedidos, sin el cual la empresa deja de vender, pide una estrategia más rápida. El mismo entorno tiene las dos, cada una con el costo que cabe en el negocio.
Dos distinciones ayudan en la conversación. El respaldo guarda copias de los datos, y el DRP organiza la recuperación 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ágina de Backup (en portugués).
Entorno híbrido y ransomware
En un entorno híbrido, el plan trata las dependencias entre lo que está local y lo que está en la nube, que es donde suelen aparecer las sorpresas. Un ejemplo común: la aplicación está en la nube, pero el inicio de sesión pasa por un servidor de identidad local. Si el sitio local se cae, la aplicación, que estaba intacta, deja de abrir. Somos socios de Microsoft Azure y trabajamos también con las demás nubes.
Con ransomware, la lógica cambia. En un desastre físico, sirve la copia más reciente. En un ataque, puede estar ya comprometida, y el plan debe prever la vuelta a un punto anterior a la infección. Eso afecta la retención de las copias y pone la protección del respaldo dentro del diseño del DRP.
Por eso el proyecto trata el escenario de ransomware como un caso aparte, con procedimiento propio. Define quién decide aislar el entorno, qué copia se considera confiable y en qué orden vuelven los sistemas una vez limpio el entorno.
Cómo saber si el plan es bueno: criterios de revisión
Un buen plan de DRP pasa una lista corta de preguntas. Si alguna respuesta es “no”, al plan todavía le queda trabajo:
- ¿Cada sistema crítico tiene RTO y RPO aprobados por quien responde por el proceso?
- ¿Existe un orden de recuperación escrito, con las dependencias consideradas?
- ¿Puede seguir cada procedimiento alguien que no participó en su redacción?
- ¿Cada rol tiene titular y suplente, con contacto actualizado?
- ¿El plan tiene guion de pruebas, y se corrigió lo que falló en las pruebas ya hechas?
- ¿Hay una fecha de revisión y un disparador para revisar fuera del calendario?
- ¿El respaldo está protegido contra alteración y borrado, incluso en un escenario de ransomware?
La lista es un punto de partida para la conversación con el equipo, no una certificación.
Qué cambia la norma ISO 22301 en este trabajo
La ISO 22301:2019 es la norma internacional de sistemas de gestión de continuidad del negocio. La usamos como referencia de buenas prácticas para estructurar el plan. El proyecto de DRP no certifica a la empresa en la norma: la certificación la realiza un organismo certificador acreditado.
Como lectura complementaria sobre planes de contingencia de sistemas de información, existe la NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems, guía del organismo de normas de Estados Unidos, publicada en mayo de 2010 y actualizada el 11/11/2010.
Cómo conduce este trabajo Integrity-UX
El comienzo es un diagnóstico del entorno actual, que releva sistemas, dependencias y puntos únicos de falla. De ahí salen el alcance, el esfuerzo y el plazo por fase. Con el plan listo, nuestro equipo puede acompañar la revisión periódica y la ejecución de las pruebas, según la necesidad de la empresa.
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íbrido.
Próximos pasos
Para llegar a la primera conversación con algo útil en mano, conviene reunir:
- la lista de los sistemas que la empresa considera críticos;
- el diseño del entorno (local, nube o híbrido);
- qué respaldo existe hoy;
- si algún plan ya se probó y cuándo.
Con eso, nuestro equipo arma el diagnóstico. Conozca también la página del servicio de DRP (Plan de Recuperación ante Desastres) o hable con un especialista de nuestro equipo.
Preguntas frecuentes
¿Qué entrega una consultoría de DRP?
Análisis de riesgos, relevamiento de sistemas y dependencias, RTO y RPO acordados con cada área, orden de recuperación, procedimientos paso a paso, responsables y suplentes, guion de pruebas, capacitación y revisión periódica.
¿El DRP necesita un entorno secundario duplicado?
No necesariamente. La estrategia varía según el RTO de cada sistema, desde la recuperación a partir del respaldo hasta el entorno en espera. La mayoría de las empresas usa estrategias distintas para sistemas distintos.
¿Quién debe participar además de TI?
Las áreas de negocio y la dirección. RTO y RPO responden cuánto tiempo puede estar detenida la operación y cuántos datos se pueden perder, y solo quien responde por el proceso lo sabe.
¿Cuál es la diferencia entre DRP y alta disponibilidad?
La alta disponibilidad mantiene el servicio en pie cuando falla un componente. El DRP organiza la reanudación cuando se pierde el entorno completo. Uno no sustituye al otro, y ninguno de los dos sustituye al respaldo.
¿El DRP de Integrity-UX certifica a la empresa en la ISO 22301?
No. La norma se usa como referencia de buenas prácticas. La certificación ISO 22301 la realiza un organismo certificador acreditado.
¿El plan cubre el ransomware?
Sí. El proyecto trata el ransomware como un escenario propio, con la vuelta a un punto anterior a la infección y la protección del respaldo dentro del diseño.
¿Cuánto cuesta y cuánto tiempo lleva?
Depende del alcance. Plazo y valor se definen en una propuesta, después del diagnóstico del entorno.
Última actualización: 11 de noviembre de 2026.
Fuentes:
- ISO 22301:2019, Security and resilience, Business continuity management systems, Requirements. Edición 2, publicada en octubre de 2019. iso.org/standard/75106.html (consultada el 11/11/2026).
- ISO 22301:2019/Amd 1:2024, Security and resilience, Business continuity management systems, Requirements, Amendment 1: Climate action changes. Publicada en febrero de 2024. iso.org/standard/88412.html (consultada el 11/11/2026).
- NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems. Publicada en mayo de 2010, actualizada el 11/11/2010. csrc.nist.gov/pubs/sp/800/34/r1/upd1/final (consultada el 11/11/2026).
