Qué incluye
Un plan de recuperación sin probar es una hipótesis. El cronograma de abajo lo dibuja la secuencia escalonada de pruebas, porque cada prueba cuesta una ventana de cambio y cada una encuentra cosas que la anterior no podía:
- Análisis de impacto en el negocio, Inventario de aplicaciones y servicios, mapa de dependencias, los talleres de impacto, y los objetivos de RTO y RPO a los que se sujeta cada servicio. Todo lo que viene después se presupuesta a partir de esas cifras. Hito: línea base de RTO y RPO aprobada.
- Estrategia y arquitectura, Asignación de niveles de recuperación, elección de centro o región de respaldo, arquitectura de réplica y de copias de seguridad, diseño de conmutación de red y de DNS, y la revisión de coste contra los objetivos. Hito: arquitectura aprobada.
- Construcción y réplica, Infraestructura de respaldo, réplica de almacenamiento y de bases de datos, cambios en la política de copias, identidad y controles de seguridad en el centro de respaldo, y monitorización del retardo de réplica. Hito: réplica en régimen estable verificada.
- Procedimientos y documentación, Un procedimiento de conmutación por cada nivel de recuperación, procedimientos de vuelta atrás y de retorno, el árbol de comunicación de crisis, y los criterios de declaración que dicen quién está autorizado a activarlo. Hito: procedimientos publicados.
- Secuencia de pruebas, Primero el simulacro de mesa, después una conmutación parcial de las aplicaciones de nivel 1 con vuelta atrás, y después una conmutación completa con validación de negocio y retorno, con tiempo de corrección presupuestado detrás de cada una. Hito: prueba de conmutación completa superada.
- Aprobación y mantenimiento, Informe de pruebas y riesgo residual, aprobación de la dirección, formación de los equipos de respuesta, el calendario anual de pruebas, y el enganche con la gestión de cambios que evita que las aplicaciones nuevas queden en silencio fuera del plan. Hito: plan aprobado.
Quién usa esta plantilla
Responsables de resiliencia de TI, equipos de infraestructura y gestores de continuidad de negocio utilizan esta línea de tiempo para construir y demostrar la capacidad de recuperación. Avanza desde el análisis de impacto en el negocio y los objetivos RTO/RPO, pasando por la construcción de la replicación y los runbooks, hasta las pruebas de mesa, parciales y de conmutación total, y garantiza que la organización pueda recuperarse dentro de sus objetivos y no solo sobre el papel.
Cómo personalizarla
- Fija el RTO y el RPO por servicio, no por organización: un servicio de pagos y una wiki interna no deberían compartir nivel.
- Reserva pronto las dos ventanas de cambio; la de conmutación completa suele necesitar aprobación de dirección y un periodo de baja actividad, que son restricciones de calendario, no técnicas.
- Mantén la fila de vuelta atrás junto a cada prueba: una prueba sin retorno ensayado es una caída esperando a un mal día.
- Añade filas por nivel de aplicación si vas a conmutar por grupos en lugar de todo a la vez.
- Alarga la ventana de corrección posterior a la prueba parcial: ahí es donde aparecen la mayoría de los hallazgos reales.
- Añade la repetición anual como filas con fecha para que el plan no caduque en silencio doce meses después de aprobarse.
- Si estás sujeto al Esquema Nacional de Seguridad, a NIS2 o a DORA, alinea los niveles y la periodicidad de prueba con lo que exige tu marco: en varios casos la prueba periódica documentada es obligatoria y no una buena práctica.
Consejos de programación
- Prueba el retorno, no solo la conmutación. Funcionar en el centro de respaldo es la mitad del ejercicio; la mayoría de las organizaciones descubren los problemas caros en el camino de vuelta.
- Haz el simulacro de mesa antes que nada técnico. Es barato, no necesita ventana de cambio, y encuentra de forma fiable teléfonos desactualizados, autoridad de declaración poco clara y pasos del procedimiento que dan por sabido lo que nadie escribió.
- Valida con el negocio, no con un ping. Un servicio que responde no es un servicio que funciona: que haya usuarios reales completando transacciones reales durante la conmutación completa.
- Vigila el retardo de réplica como métrica viva. Un RPO que no estás midiendo de forma continua es un RPO que solo vas a verificar durante un incidente.
- Engancha la recuperación a la gestión de cambios. Cada aplicación nueva que entra sin nivel de recuperación asignado ensancha la distancia entre el plan y la realidad, y esa distancia solo se ve el día de la prueba.
Plantillas relacionadas
- Plantilla de cronograma de construcción de centro de datos
- Plantilla de plan de migración a la nube
- Plantilla de plan de auditoría interna
- Ver todas las plantillas de diagramas de Gantt
Esta plantilla está en español. Las páginas relacionadas que aún no se han traducido se abren en inglés.
Preguntas frecuentes
¿Cuánto se tarda en construir y probar un plan de recuperación?
Lo habitual son de nueve a quince meses desde el análisis de impacto hasta un plan aprobado y probado. La plantilla usa unos quince meses. La construcción es previsible; lo que se estira es la secuencia de pruebas del final, porque cada una necesita una ventana de cambio y un ciclo de corrección detrás.
¿Qué diferencia hay entre RTO y RPO?
El RTO es cuánto tiempo puedes estar caído, es decir, el tiempo hasta restablecer el servicio. El RPO es cuántos datos puedes permitirte perder, es decir, la antigüedad de la última copia utilizable. El RTO dimensiona la infraestructura en espera y el RPO la frecuencia de réplica, y entre los dos determinan casi todo el coste del plan.
¿Por qué tres pruebas y no una?
Porque encuentran cosas distintas. El simulacro de mesa encuentra huecos en el procedimiento y en la cadena de decisión al precio de una sala de reuniones. La conmutación parcial encuentra fallos técnicos con un radio de impacto limitado. La conmutación completa con validación de negocio es lo único que demuestra el RTO. Y cada una necesita que la anterior se haya corregido antes.
¿Hace falta ventana de cambio para las pruebas?
Para la conmutación parcial y la completa, sí: mueven tráfico de producción y llevan riesgo real. Resérvalas con una vuelta atrás ensayada y un criterio de aborto definido. El simulacro de mesa no necesita ventana, que es exactamente por lo que hay que exprimirlo primero.
¿Qué relación tiene con la continuidad de negocio?
La recuperación ante desastres es el subconjunto tecnológico: restablecer sistemas y datos. La continuidad de negocio es más amplia y cubre personas, sedes y procesos. Esta plantilla cubre el lado tecnológico, aunque las filas de comunicación de crisis y de criterios de declaración se comparten con cualquier plan de continuidad.
¿Es gratuita?
Sí, con descarga en Excel, PowerPoint y CSV y edición online sin registro.