Template de plan de recuperación ante desastres (DRP)

El 60% de las PyMEs que sufren una pérdida de datos significativa cierran dentro de los 6 meses siguientes. No porque el incidente sea irrecuperable, sino porque no tenían un plan documentado para recuperarse. Un Plan de Recuperación ante Desastres (DRP) no es un documento que escribes y guardas en un cajón — es la diferencia entre un incidente que interrumpe tu operación por horas y uno que la detiene por semanas.

En este artículo te damos la estructura completa de un DRP práctico, con las secciones, roles y procedimientos que necesitas. Úsalo como template para crear el tuyo.

Qué debe incluir tu DRP

Sección 1: Información general

El documento debe comenzar con datos básicos: nombre de la empresa, fecha de última actualización del plan, responsable del plan (nombre, cargo, contacto), lista de distribución (quiénes tienen copia), versión del documento y aprobaciones.

Parece burocrático, pero es crítico. Durante un desastre real, nadie quiere preguntarse "¿esta es la versión actual del plan?" o "¿quién es el responsable?".

Sección 2: Análisis de impacto (BIA)

Antes de planificar la recuperación, necesitas saber qué recuperar primero. El Business Impact Analysis clasifica tus sistemas por criticidad.

RTO (Recovery Time Objective) es el tiempo máximo que puedes estar sin ese sistema antes de que el impacto al negocio sea inaceptable. RPO (Recovery Point Objective) es la cantidad máxima de datos que puedes perder — si tu RPO es de 1 hora, necesitas backups al menos cada hora.

Sección 3: Inventario de infraestructura

Documenta toda tu infraestructura crítica en un formato claro que incluya, para cada servidor o servicio: nombre y función, ubicación (físico/cloud/proveedor), sistema operativo y versión, aplicaciones que ejecuta, datos que almacena, método de backup (frecuencia, destino, tipo), credenciales de acceso (referencia al vault, nunca en texto plano) y dependencias (de qué otros sistemas depende).

Este inventario debe actualizarse cada vez que se agrega, modifica o retira un sistema. Un DRP con inventario desactualizado es un DRP que fallará.

Sección 4: Estrategia de backup

Documenta tu estrategia de backup con detalle suficiente para que alguien que no configuró los backups pueda restaurarlos.

Para cada sistema crítico, define qué se respalda (base de datos completa, archivos de configuración, datos de usuarios), con qué frecuencia (cada hora, diario, semanal), dónde se almacena (servidor local, NAS, cloud, cinta), cuántas copias se mantienen y por cuánto tiempo, si los backups son incrementales o completos, cómo se verifica la integridad (pruebas de restauración) y el procedimiento paso a paso para restaurar.

Sección 5: Procedimientos de recuperación

Para cada escenario de desastre, documenta el procedimiento paso a paso. Los escenarios más comunes que debe cubrir tu DRP son:

Fallo de servidor individual. Quién detecta el fallo, cómo se notifica al equipo, procedimiento para levantar el servicio en hardware alternativo o desde backup, verificaciones post-recuperación y comunicación a usuarios afectados.

Ataque de ransomware. Aislamiento inmediato de los sistemas afectados (desconectar de la red, no apagar), evaluación del alcance (qué sistemas están cifrados, qué backups están intactos), decisión de no pagar rescate (documentar la política), restauración desde el último backup limpio verificado, análisis forense para identificar el vector de entrada y remediación antes de reconectar.

Fallo de proveedor cloud. Qué hacer si tu proveedor cloud tiene una interrupción prolongada, dónde están los backups fuera del proveedor principal y procedimiento para migrar temporalmente a infraestructura alternativa.

Desastre físico (incendio, inundación, terremoto). Protección de personal primero, activación de sitio alternativo, restauración desde backups fuera del sitio y comunicación con clientes y proveedores.

Sección 6: Equipo de respuesta

Define quién hace qué durante un desastre. Los roles mínimos son un coordinador de incidentes (toma decisiones, coordina esfuerzos, comunica al liderazgo), un líder técnico (ejecuta los procedimientos de recuperación), un responsable de comunicación (informa a empleados, clientes y proveedores) y un tomador de decisiones ejecutivo (autoriza gastos extraordinarios, decide prioridades de negocio).

Cada rol debe tener titular y suplente. Durante un desastre real, la persona principal puede no estar disponible. La lista de contactos debe incluir números de celular personal, no solo extensiones de oficina.

Sección 7: Comunicación durante el incidente

Define plantillas de comunicación predefinidas para cada audiencia. Para empleados: qué pasó (sin detalles técnicos), qué sistemas están afectados, cuándo se espera la recuperación y qué deben hacer mientras tanto. Para clientes: notificación de interrupción, tiempo estimado de recuperación, canal alternativo de contacto y actualización cuando el servicio se restablezca. Para proveedores y partners: notificación de impacto, solicitud de soporte si aplica.

Tener plantillas listas ahorra tiempo valioso durante una crisis. No querrás estar redactando comunicados mientras tu equipo intenta restaurar servidores.

Sección 8: Pruebas y mantenimiento

Un DRP que no se prueba no funciona. Define un calendario de pruebas: una prueba tabletop semestral donde el equipo recorre los procedimientos en una mesa sin tocar sistemas reales, una prueba de restauración anual donde realmente se restauran sistemas críticos desde backup y se mide si se cumple el RTO y RPO definidos, y una actualización del plan cada vez que cambia la infraestructura, el personal o los proveedores.

Documenta los resultados de cada prueba: qué funcionó, qué falló, qué se necesita mejorar. Cada prueba fallida es una oportunidad de mejora antes de que el desastre real ocurra.

Errores comunes en los DRP

Los errores que vemos con más frecuencia al revisar planes de recuperación de empresas: el plan existe pero nadie sabe dónde está (o está en el servidor que falló), los backups nunca se han probado restaurando (y cuando lo intentan, descubren que están corruptos o incompletos), no hay suplentes para los roles clave (si el director de TI está de vacaciones cuando ocurre el desastre, nadie sabe qué hacer), las credenciales de acceso a los sistemas de backup no están documentadas fuera del sistema principal y el plan no se ha actualizado en más de un año (los servidores cambiaron, los proveedores cambiaron, los contactos cambiaron).

Cada uno de estos errores convierte tu DRP de un plan de recuperación en un documento decorativo. La prueba anual existe precisamente para detectar estos problemas antes de que importen.