Plan de recuperación ante desastres (DRP): qué es y cómo hacerlo

Un plan de recuperación ante desastres es el documento que dice cómo vuelve a funcionar la tecnología de una empresa después de un incidente grave. También se le llama DRP, por sus siglas en inglés. En esta guía verá qué es un plan de recuperación ante desastres, para qué sirve y qué debe contener. También verá en qué se diferencian el BCP y el DRP, cómo elegir un sitio alterno y cómo hacer las pruebas de DRP. Además, incluye un ejemplo con cifras.

El tema no es teórico. Según el análisis anual de interrupciones de 2026 del Uptime Institute, el 57 % de los encuestados dijo que su última interrupción grave costó más de 100.000 dólares. Además, uno de cada cinco reportó más de un millón. Por otra parte, la energía sigue siendo la primera causa, y los errores humanos más frecuentes vienen de no seguir los procedimientos. Es decir, el problema casi nunca es la falta de tecnología, sino la falta de un plan que alguien haya ensayado.

Esta guía sirve a dos lectores. Si usted dirige una empresa o un área, le bastan los apartados de qué es, para qué sirve, qué contiene y el ejemplo. En cambio, si administra la infraestructura, encontrará también los tipos de sitio alterno, las fases, las pruebas y las normas de referencia. El ejemplo, por su parte, continúa el caso de nuestra guía de RTO y RPO: la misma empresa, los mismos siete servidores y las mismas copias.

¿Qué es un plan de recuperación ante desastres (DRP)?

Un plan de recuperación ante desastres es un conjunto de procedimientos escritos para restablecer los sistemas de información después de una interrupción grave. DRP significa «Disaster Recovery Plan». En concreto, el plan responde cinco preguntas: qué se recupera, en qué orden, dónde, quién lo hace y en cuánto tiempo.

La definición más citada es la de la guía SP 800-34 del NIST, el instituto de normas de Estados Unidos. Según esa guía, el DRP es un plan centrado en los sistemas de información. Su fin es restablecer un sistema, una aplicación o un centro de cómputo en un sitio alterno después de una emergencia. Además, la guía precisa que se aplica a interrupciones graves, normalmente físicas, que impiden usar la instalación principal durante un periodo largo.

El DRP explicado sin tecnicismos

Piense en el plan de evacuación de un edificio. Nadie lo lee todos los días, pero está escrito, tiene responsables y se ensaya con simulacros. Por eso, cuando suena la alarma, nadie discute por dónde salir. El plan DRP es lo mismo para los sistemas: dice por dónde «sale» la operación cuando la sede o los servidores dejan de estar disponibles.

En cambio, sin plan, el día del incidente se decide todo a la vez y con prisa: qué se restaura primero, en qué equipo y con qué contraseña. Además, esas decisiones las toma quien esté disponible, no quien debería tomarlas.

Qué cuenta como desastre

Un desastre no es solo un terremoto o un incendio. Para el plan, es cualquier evento que deja sin servicio los sistemas críticos más tiempo del que la empresa tolera. Por ejemplo:

Tipo de evento	Ejemplos	Qué se pierde
Físico	Incendio, inundación, robo de equipos, daño del edificio	La sede o el cuarto de servidores
Energía y clima	Corte prolongado, falla de la UPS o del aire acondicionado	El funcionamiento de los equipos
Fallas técnicas	Daño del almacenamiento, corrupción de una base de datos	Uno o varios sistemas
Conectividad	Corte de fibra, caída del proveedor de internet	El acceso a los sistemas
Error humano	Borrado masivo, cambio mal aplicado	Datos o configuración
Ataque	Cifrado de los servidores por un programa malicioso	Datos y sistemas a la vez
Proveedor	Caída de un servicio en la nube del que depende la operación	Un servicio que la empresa no controla

Así que el primer trabajo del plan es decidir qué escenarios cubre. De hecho, un mismo sistema puede tener una respuesta para la falla de un servidor y otra muy distinta para la pérdida de la sede.

Para qué sirve un DRP: importancia y beneficios

Un DRP sirve para que la recuperación dependa de un procedimiento y no de la memoria de una persona. Por eso su importancia crece con cada proceso que pasa a depender de un sistema. Estos son sus beneficios principales:

Beneficio	En la práctica
Menos tiempo detenido	El orden y los pasos ya están decididos, así que no se improvisa
Menos datos perdidos	Las copias se diseñan para el escenario, no solo para la falla de un disco
Decisiones claras	Se sabe quién declara el desastre y con qué criterio
Costos previsibles	Se elige de antemano cuánto invertir en cada sistema
Cumplimiento	Clientes, aseguradoras y normas piden un plan y sus pruebas
Confianza	La dirección conoce cifras medidas, no promesas
Menos dependencia de personas	Otro técnico puede ejecutar el plan si falta quien lo escribió

Además, hay un beneficio que se nota antes de cualquier incidente. Escribir el plan obliga a hacer un inventario, a revisar las copias y a descubrir dependencias que nadie había anotado. En otras palabras, el ejercicio mejora la operación diaria aunque el desastre nunca llegue.

Usos principales del DRP

• Responder a la pérdida de la sede: es el uso clásico, y el que exige un sitio alterno.
• Recuperarse de un cifrado masivo: el plan fija qué se restaura primero y desde qué copia limpia.
• Atender una falla grave del centro de datos propio: por ejemplo, del almacenamiento compartido.
• Sustentar un contrato: muchos clientes piden ver el plan y el resultado de la última prueba.
• Justificar el presupuesto: el plan muestra cuánto cuesta cada hora detenida y cuánto reducirla.

BCP y DRP: diferencias y cómo se relacionan

BCP y DRP se confunden a menudo, pero no son lo mismo. El BCP, o plan de continuidad del negocio, se ocupa de que los procesos de la empresa sigan funcionando. En cambio, el DRP se ocupa de recuperar la tecnología que los soporta. Por tanto, el DRP es una parte del BCP, no su sinónimo.

BCP y DRP ante un mismo incidente

Por ejemplo, ante un incendio, el BCP decide dónde trabajarán las personas y cómo se atenderá a los clientes ese día. Mientras tanto, el DRP dice cómo vuelven el ERP, los archivos y el correo. La guía del NIST ordena estos planes así:

Plan	Para qué sirve	Enfoque
Plan de continuidad del negocio (BCP)	Sostener los procesos de la empresa mientras dura la recuperación	Procesos
Plan de recuperación ante desastres (DRP)	Trasladar la operación de los sistemas a un sitio alterno	Sistemas, tras una interrupción grave
Plan de contingencia de un sistema	Recuperar un sistema concreto, en su sitio o en otro	Un solo sistema
Plan de respuesta a incidentes	Contener y corregir un ataque informático	Seguridad
Plan de comunicación de crisis	Informar a empleados, clientes y público	Comunicaciones
Plan de emergencia de ocupantes	Proteger a las personas del edificio	Personas e instalaciones

Esa tabla trae un matiz útil para los profesionales. Para el NIST, el DRP en sentido estricto solo trata las interrupciones que obligan a reubicar los sistemas. En cambio, la recuperación de un sistema en su mismo sitio corresponde al plan de contingencia de ese sistema. Sin embargo, en el uso corriente se llama DRP al conjunto, y así lo usa esta guía.

Qué comparten el BCP y el DRP

Además, BCP y DRP comparten el mismo punto de partida: el análisis de impacto al negocio, o BIA. De ahí salen los objetivos de cada sistema, que el plan de recuperación ante desastres debe cumplir. Por eso conviene escribir el BCP y el DRP juntos, o al menos con las mismas cifras.

Qué debe contener un plan de recuperación ante desastres

Un plan de recuperación ante desastres útil cabe en pocas páginas, más sus anexos. No hace falta un documento de cien hojas. De hecho, cuanto más largo es, menos se lee el día que importa. Estos son los apartados que no pueden faltar:

Apartado	Qué responde
Alcance y escenarios	Qué sistemas y qué eventos cubre el plan, y cuáles no
Objetivos	El RTO y el RPO de cada sistema, por escenario
Roles y contactos	Quién declara, quién ejecuta y quién comunica, con nombre y teléfono
Criterios de activación	Cuándo una falla pasa a ser un desastre
Inventario	Servidores, aplicaciones, licencias, proveedores y dependencias
Estrategia y sitio alterno	Dónde se recupera y con qué equipos
Procedimientos	Los pasos de recuperación de cada sistema, en orden
Copias y credenciales	Dónde están las copias y cómo se accede a ellas sin la sede
Comunicación	Qué se dice a empleados, clientes y proveedores, y quién lo dice
Regreso	Cómo se vuelve a la operación normal y se cierra el plan
Pruebas y mantenimiento	Qué se prueba, cada cuánto y quién actualiza el documento

Dos de esos apartados suelen quedar flojos. El primero son los contactos. En concreto, deben ser nombres y teléfonos personales, no cargos ni extensiones de una central que quizá no funcione. El segundo son las credenciales. Por ejemplo, si la contraseña que descifra las copias solo está en un servidor de la sede, las copias de la nube no sirven de nada.

Además, el propio plan debe guardarse fuera de la sede. Si el documento vive solo en el servidor de archivos, se pierde junto con lo que pretende recuperar. Por eso conviene tener una copia impresa y otra en un servicio en la nube al que el equipo pueda entrar desde cualquier lugar.

Cómo hacer un plan de recuperación ante desastres paso a paso

Para hacer un plan de recuperación ante desastres no hay que inventar el método. La guía del NIST propone siete pasos, y sirven igual para una entidad pública que para una empresa mediana. A continuación los adaptamos a un lenguaje de empresa.

1. Definir la política y el responsable

Primero, la dirección decide que el plan existe, qué cubre y quién responde por él. Sin ese respaldo, el plan compite por tiempo con el trabajo diario y pierde. Además, este paso fija el presupuesto y el alcance: qué sedes, qué sistemas y qué escenarios.

2. Hacer el análisis de impacto al negocio

Después, cada área estima qué pasa si su proceso se detiene y a partir de cuándo el daño es inaceptable. De ese análisis salen el RTO, o tiempo máximo detenido, y el RPO, o datos máximos perdidos. Si esos conceptos son nuevos para usted, los explicamos con fórmulas y ejemplos en la guía de RTO y RPO.

3. Identificar controles preventivos

El mejor desastre es el que no ocurre. Por eso, antes de diseñar la recuperación, conviene reducir la probabilidad: una UPS dimensionada, discos en RAID, equipos duplicados y monitoreo de servidores que avise antes de la falla. Sin embargo, la prevención no reemplaza al plan. Por ejemplo, la alta disponibilidad protege de la falla de un equipo, pero no de la pérdida del edificio ni de un borrado.

4. Elegir la estrategia de recuperación

Luego se decide cómo se va a recuperar cada sistema: con copias, con réplica o con un sitio alterno listo. Cada opción ofrece un tiempo y un costo distintos. Por tanto, la estrategia se elige por sistema, no para toda la empresa. Así, el ERP puede necesitar réplica, mientras que al archivo histórico le basta una copia semanal.

En cuanto a las copias, la regla mínima es conocida: tres copias, en dos soportes distintos y una fuera de la sede. Además, conviene que una de ellas no se pueda modificar durante un plazo, lo que se llama respaldo inmutable. De lo contrario, un ataque que cifra los servidores puede cifrar también las copias.

5. Escribir el plan

Con lo anterior decidido, se redactan los procedimientos. Cada uno debe poder ejecutarlo un técnico que no participó en el diseño. Por eso se escriben como una lista de pasos numerados, con el resultado esperado de cada paso. En el sector, a esas listas se les llama «runbooks».

6. Probar, capacitar y ensayar

Un plan sin pruebas es una hipótesis. Así que el sexto paso es comprobarlo: primero en una mesa, leyendo el escenario, y después restaurando de verdad. Más adelante detallamos cada tipo de prueba.

7. Mantener el plan

Por último, el plan se actualiza cada vez que cambia algo importante: un sistema nuevo, un proveedor distinto o una persona que se va. De lo contrario, en pocos meses describe una empresa que ya no existe.

Sitio alterno: frío, tibio, caliente y la nube

El sitio alterno es el lugar donde funcionarán los sistemas mientras la sede principal no está disponible. Es la decisión que más pesa en el costo del plan y, a la vez, en el tiempo de recuperación. El NIST distingue tres tipos según lo preparados que están:

Sitio alterno	Qué tiene	Costo	Tiempo de puesta en marcha
Frío	Espacio, energía, clima y conexiones, pero sin equipos	Bajo	Largo
Tibio	Parte o todos los equipos, apagados o sin los datos al día	Medio	Medio
Caliente	Equipos completos, datos al día y personal de apoyo	Medio o alto	Corto

Además, la guía menciona dos variantes. Por un lado, el sitio móvil: un contenedor equipado que se transporta a donde haga falta. Por otro, el sitio espejo: una instalación idéntica a la principal que recibe los datos de forma continua. Este último es el más caro, pero ofrece una disponibilidad cercana al 100 %.

Un sitio alterno puede ser propio, arrendado a un proveedor o compartido con otra organización mediante un acuerdo recíproco. En todos los casos, debe estar en una zona que no sufra la misma amenaza que la sede principal. Por ejemplo, un sitio alterno en el mismo edificio no sirve ante un incendio, ni uno en la misma manzana ante un corte de energía del sector.

Qué pedirle al contrato de un sitio alterno

Si el sitio alterno es de un proveedor, el contrato importa tanto como los equipos. La guía del NIST advierte de un riesgo poco conocido: varios clientes pueden contratar el mismo espacio. Por tanto, si un desastre afecta a varios a la vez, quizá no haya sitio para todos. Estas son las cláusulas que conviene revisar:

• Qué circunstancias cuentan como desastre y cómo se notifica.
• Qué prioridad tiene su empresa frente a los demás clientes.
• Cuántos días puede ocupar el sitio durante la recuperación.
• Qué equipos, conexiones y puestos de trabajo incluye.
• Cuántas pruebas al año puede hacer y cuánto duran.
• Qué costo tiene declarar el desastre y cada día de uso.

La nube como sitio alterno

Para una empresa mediana, la nube es hoy el sitio alterno más accesible. En lugar de pagar un segundo cuarto de servidores, se paga por guardar las copias o las réplicas y, solo si hay un desastre, por encender las máquinas. De ese modo funcionan servicios como Azure Site Recovery, que mantiene una réplica lista para arrancar en otra región.

Sin embargo, la nube no elimina el plan. Alguien debe saber cómo se encienden esas máquinas, cómo se conectan los usuarios y cuánto cuesta cada día allí. Además, bajar los datos de vuelta depende del ancho de banda, como muestra el ejemplo de más abajo.

Las tres fases del DRP: activar, recuperar y volver

Cuando ocurre el incidente, el DRP se ejecuta en tres fases. Así lo plantea la guía del NIST, y conviene que el documento siga ese mismo orden.

Fase 1: activación y notificación

Primero se evalúa el daño y se decide si se activa el plan. Esa decisión necesita un criterio escrito. Por ejemplo: «se declara el desastre si la sede no estará disponible en cuatro horas». Sin ese criterio, la decisión se aplaza con la esperanza de que el problema se resuelva solo, y ese tiempo se resta del objetivo.

Además, el plan nombra a quien declara el desastre y a su suplente. Después se notifica al equipo de recuperación, a la dirección y a los proveedores, según una lista de llamadas.

Fase 2: recuperación

Después se restablecen los sistemas en el sitio alterno, en el orden que fija el plan. Ese orden sigue dos reglas. Primero, las dependencias: sin el servidor que valida usuarios y contraseñas, casi nada más arranca. En un entorno de Windows, ese servidor es el controlador de dominio de Active Directory. Segundo, la prioridad del negocio: antes lo que más cuesta por hora detenida.

Mientras tanto, cada paso se anota con su hora. Ese registro sirve después para comparar lo logrado con el objetivo.

Fase 3: reconstitución, o el regreso

Por último, cuando la sede vuelve a estar disponible, hay que regresar. Esta fase se olvida con frecuencia. Sin embargo, el regreso es otra migración: los datos que se crearon en el sitio alterno deben volver a la sede sin perder nada. Por eso se planifica con el mismo cuidado, se valida con los usuarios y solo entonces se da por cerrado el plan.

Ejemplo de DRP: la pérdida de la sede, con cifras

Tome la empresa de 120 personas de nuestra serie de Veeam. Tiene siete máquinas virtuales protegidas, una copia diaria en la nube y un enlace de 100 Mbit/s. En la guía de RTO y RPO vimos qué pasa si falla un servidor. Ahora el escenario es peor: un martes a las 09:00, un incendio deja inservible el cuarto de servidores. Los datos son de ejemplo, pero las cuentas son exactas.

El plan de recuperación ante desastres de esta empresa define un sitio alterno tibio. En concreto, es un servidor de reserva apagado en otra sede, sin datos. Las copias están en la nube y pesan 451 GiB comprimidas. Por tanto, hay que bajarlas, y el enlace se usa al 80 %. Los supuestos nuevos son tres tiempos: 10 minutos para detectar, 60 para evaluar el daño y declarar el desastre, y 60 para llegar al sitio alterno y encender el equipo.

Primer hallazgo: el orden vale cuatro horas

Antes de restaurar nada ya pasaron 130 minutos, así que la primera bajada empieza a las 11:10. A partir de ahí, todo depende del orden. El plan fija este: primero el controlador de dominio, después el ERP, luego la web y, al final, los archivos.

Sistema	Copia en la nube	Tiempo de bajada	En servicio a las
dc-01 (directorio)	11 GiB	20 minutos	11:54
ERP (erp-db y erp-app)	138 GiB	4 horas y 7 minutos	16:01
web-01	10,5 GiB	19 minutos	16:20
file-01 (archivos)	270 GiB	8 horas y 3 minutos	00:23 del día siguiente
dc-02 y web-02	21,5 GiB	39 minutos	01:02 del día siguiente

Es decir, con el orden del plan el ERP vuelve a las 16:01, siete horas y dos minutos después del incendio. Además, a la mañana siguiente todo funciona.

Qué pasa sin el orden del plan

Ahora suponga que no hay plan y el técnico lanza las siete restauraciones a la vez. El enlace se reparte entre todas, de modo que la base de datos del ERP no termina de bajar hasta las 19:45. Por tanto, el ERP queda en servicio a las 20:10, más de cuatro horas después y con la jornada ya terminada.

Dato	Con el orden del plan	Todo a la vez
El ERP vuelve a las	16:01	20:10
Tiempo total sin ERP	7 horas y 2 minutos	11 horas y 10 minutos
Jornada perdida ese día	7 horas y 2 minutos	9 horas, la jornada completa
Horas-persona perdidas (45 personas)	316	405
Los archivos vuelven a las	00:23	01:02

En resumen, el orden no cambia cuándo termina todo, sino quién espera. Con el mismo enlace y el mismo equipo, escribir una lista de seis líneas ahorra casi 90 horas-persona. Además, permite facturar esa misma tarde.

Segundo hallazgo: bajar los datos es el 63 % del tiempo

De las siete horas y dos minutos del ERP, bajar los datos ocupa el 63 %. En cambio, los pasos previos son el 31 %, y verificar, el 6 %. Así que aquí el cuello de botella es el ancho de banda, no las personas. Es lo contrario de lo que pasaba con la falla de un servidor, donde restaurar era solo el 40 %.

Por eso un mismo sistema necesita dos objetivos. Ante la falla de un servidor, el ERP de este caso tiene un RTO de 2 horas. En cambio, ante la pérdida de la sede, la dirección debe aprobar otro. Por ejemplo, 8 horas: con el orden del plan se cumple con 58 minutos de margen y, sin él, se incumple.

Tercer hallazgo: el sitio alterno decide la escala

¿Y si el sitio alterno fuera otro? Comparamos tres opciones para el mismo ERP:

Sitio alterno	Qué hay preparado	El ERP vuelve en
Frío	Nada: el servidor de reemplazo llega en tres días	79 horas
Tibio	Servidor de reserva apagado, con las copias en la nube	7 horas y 2 minutos
Tibio con copia	El mismo servidor, con una segunda copia local al día	3 horas y 21 minutos

Por un lado, pasar de frío a tibio cambia los días por horas, y solo exige tener un equipo esperando. Por otro, llevar además una copia al sitio alterno ahorra otras tres horas y cuarenta minutos, porque restaurar desde un disco local toma 46 minutos en lugar de cuatro horas y media. Así que, en este caso, la segunda copia rinde más que contratar un enlace mayor.

Lo que queda escrito en el plan

Con esas cuentas, el procedimiento de este escenario cabe en una tabla. Así se ve un extracto del DRP de ejemplo:

Paso	Qué se hace	Quién	Minuto
1	Confirmar el daño y avisar al responsable del plan	Técnico de turno	10
2	Declarar el desastre y llamar al equipo	Gerente de operaciones o su suplente	70
3	Encender el servidor de reserva y conectar el repositorio de la nube	Técnico de infraestructura	130
4	Restaurar y verificar dc-01	Técnico de infraestructura	175
5	Restaurar erp-db y erp-app, y validar con un usuario de facturación	Técnico y líder del ERP	422
6	Avisar a las áreas de que el ERP está disponible	Responsable de comunicación	425
7	Restaurar web-01, file-01, dc-02 y web-02 durante la noche	Técnico de infraestructura	962

Por último, queda el dato del RPO. Como la nube solo recibe la copia diaria de las 22:00, el ERP vuelve con los datos de la noche anterior. En este ejemplo se pierde una hora de trabajo, de 08:00 a 09:00. Sin embargo, si el incendio hubiera sido a las 17:59, se habría perdido la jornada entera.

Pruebas de DRP: de la mesa al simulacro

Las pruebas de DRP son lo que convierte el documento en una capacidad. Sin ellas, nadie sabe si los tiempos del plan son reales. El NIST describe varios tipos, de menor a mayor exigencia:

Prueba	En qué consiste	Qué demuestra
Ejercicio de mesa	El equipo se reúne, alguien plantea un escenario y cada uno explica qué haría	Que los roles y las decisiones están claros
Ejercicio funcional	Se ejecuta de verdad una parte: una llamada en cadena o una restauración	Que un procedimiento concreto funciona
Ejercicio funcional completo	Se conmuta al sitio alterno y se opera desde allí	Que el plan entero funciona y cuánto tarda
Prueba de las copias	Se restauran datos de muestra y se comprueba su integridad	Que las copias sirven

El ejercicio de mesa es el más barato y el que más rápido descubre vacíos. Por ejemplo, basta preguntar «¿quién tiene la contraseña de las copias?» para encontrar el primero. En cambio, el ejercicio completo es el único que mide cuánto se tarda de verdad, así que conviene hacerlo en un fin de semana y con aviso.

La guía no fija una frecuencia: la deja a cada organización. Como referencia práctica, muchas empresas hacen un ejercicio de mesa al año y restauraciones de prueba cada trimestre. Además, cada prueba debe terminar con un acta: qué se probó, cuánto tardó, qué falló y qué se cambia en el plan. En nuestra serie explicamos cómo automatizar esa verificación con Veeam SureBackup.

Cómo mantener vigente el plan DRP

Un plan DRP envejece rápido. Por eso necesita un dueño y unas fechas de revisión. Estos son los cambios que obligan a actualizarlo:

• Un sistema nuevo, o uno que se retira.
• Un cambio de proveedor de internet, de nube o de respaldo.
• Una persona del equipo de recuperación que entra o que sale.
• Un cambio de sede o de sitio alterno.
• El resultado de una prueba o de un incidente real.
• Un contrato o una norma que exige objetivos más cortos.

Además, la lista de contactos se revisa con más frecuencia que el resto, porque es lo primero que se desactualiza. Así, una revisión corta cada trimestre y una completa cada año suelen bastar para una empresa mediana.

Errores frecuentes en un plan de recuperación ante desastres

• Mezclar BCP y DRP. El primero trata de los procesos y el segundo, de los sistemas; hacen falta los dos.
• Confundir la copia con el plan. Tener copias es necesario, pero el plan dice cómo se usan, en qué orden y dónde.
• Guardar el plan solo en la sede. Entonces se pierde con ella.
• No escribir el criterio de activación. Por consiguiente, la decisión se retrasa y el tiempo corre.
• Olvidar las dependencias. Por ejemplo, restaurar el ERP antes que el directorio que valida a sus usuarios.
• Dejar las credenciales dentro de lo que se perdió. Sin la contraseña, la copia cifrada no abre.
• Calcular solo la restauración. Faltan detectar, declarar, llegar al sitio alterno y verificar.
• No contar el ancho de banda. Bajar cientos de gigabytes toma horas, no minutos.
• Ignorar los servicios en la nube. Sin embargo, el correo y los archivos en línea también necesitan copia, como explica la guía de backup de Microsoft 365.
• No planear el regreso. Volver a la sede es otra migración.
• No probar. Es el error que contiene a todos los demás.

Normas y guías de referencia

Si necesita sustentar el plan ante un cliente o un ente de control, estas son las referencias más usadas:

Referencia	Qué es	Para qué sirve
NIST SP 800-34 Rev. 1	Guía de planes de contingencia para sistemas de información	Método de siete pasos, tipos de sitio alterno y plantillas
ISO 22301:2019	Norma de sistemas de gestión de continuidad del negocio	Marco del BCP; es certificable
ISO/IEC 27031:2025	Guía de preparación de las TIC para la continuidad del negocio	Marco de la parte tecnológica; su segunda edición se publicó en mayo de 2025
Guía 10 de MinTIC	Guía para la preparación de las TIC para la continuidad del negocio	Referencia para las entidades públicas de Colombia

La ISO/IEC 27031 complementa a la ISO 22301, igual que el DRP complementa al BCP. Por eso, quien documenta BCP y DRP suele citar las dos. Por su parte, la guía de MinTIC forma parte del Modelo de Seguridad y Privacidad de la Información. Además, las cifras de interrupciones que citamos al inicio provienen del informe anual del Uptime Institute, publicado en mayo de 2026.

Preguntas frecuentes sobre el plan de recuperación ante desastres

¿Qué es un DRP en informática?

Es el plan de recuperación ante desastres: los procedimientos escritos para restablecer los sistemas de una empresa después de una interrupción grave. En informática, DRP son las siglas de «Disaster Recovery Plan».

¿Cuál es la diferencia entre BCP y DRP?

El BCP mantiene en marcha los procesos del negocio. En cambio, el DRP recupera la tecnología que los soporta. Por tanto, el DRP es una parte del BCP.

¿Qué diferencia hay entre un DRP y un plan de contingencia?

En el uso corriente se emplean como sinónimos. Sin embargo, para el NIST el plan de contingencia recupera un sistema concreto, esté donde esté. El DRP, por su parte, traslada la operación a un sitio alterno.

¿Una empresa pequeña necesita un DRP?

Sí, aunque sea de dos páginas. De hecho, una empresa pequeña suele depender de menos personas y de menos equipos, así que una sola falla la detiene entera.

¿Qué es un sitio alterno?

Es el lugar, propio, arrendado o en la nube, donde funcionan los sistemas mientras la sede principal no está disponible. Puede ser frío, tibio o caliente, según lo preparado que esté.

¿Cada cuánto se hacen las pruebas de DRP?

Depende de cada organización. Como referencia, conviene un ejercicio de mesa al año, restauraciones de prueba cada trimestre y una prueba adicional después de cada cambio importante.

¿El DRP es lo mismo que las copias de seguridad?

No. Las copias son un insumo del plan. El DRP añade el orden, los responsables, el sitio alterno y los tiempos. Si quiere repasar las clases de copia, vea nuestra guía de tipos de backup.

¿Quién debe declarar el desastre?

Una persona con autoridad sobre la operación, nombrada en el plan junto con su suplente. No conviene que sea solo el técnico, porque la decisión afecta a toda la empresa.

Cómo lo aborda KHARONTE

En KHARONTE, la recuperación no se deja a la improvisación. Dentro de nuestra línea de continuidad operativa y respaldo diseñamos, implementamos y administramos Veeam Backup, con esquemas de respaldo local, en NAS y en nube. Además, el servicio incluye pruebas periódicas de restauración y un plan de recuperación ante desastres con RTO y RPO definidos, acordado con usted y por escrito. El alcance completo está en nuestra página de backup para empresas.

Por otra parte, cada copia fallida y cada solicitud de restauración entra como caso en nuestra mesa de ayuda TI, con trazabilidad de principio a fin. Y si su empresa necesita personal de TI dedicado a operar esa infraestructura, contamos con outsourcing de infraestructura de TI. Por último, si busca servicios administrados de TI que reúnan respaldo, monitoreo y soporte, conozca el resto de nuestros servicios de TI para empresas.