Para muchas empresas, tener un plan de continuidad —o de recuperación ante desastres— ya parece resolver el tema. El documento existe, está guardado en algún lugar, alguien lo aprobó. La guía de planificación de contingencia del NIST, el instituto de normas técnicas del gobierno de Estados Unidos, trata ese documento como solo la mitad del trabajo: la otra mitad es probar, entrenar y ejercitar el plan, y esa es la parte que la mayoría de las empresas nunca llega a hacer.
Una encuesta de 2025 de Databarracks, empresa británica de recuperación de datos, muestra el tamaño del avance reciente: nueve de cada diez organizaciones probaron alguna parte de su propia capacidad de recuperación en los doce meses anteriores a la encuesta, un salto grande frente a años anteriores. Pero la misma encuesta señala un detalle incómodo: la confianza de las empresas en su propia recuperación bajó un poco, y la lectura de los propios investigadores es que el motivo es justamente probar más: la prueba está revelando huecos que antes nadie veía.
Esa distancia es la que decide el tamaño del perjuicio en una caída real: entre guardar un plan en una carpeta y saber, porque ya fue ensayado, que funciona con las personas que realmente lo van a ejecutar.
El documento que nadie vuelve a abrir
Probar "alguna parte" de la recuperación —como muestra el número de Databarracks— suele significar restaurar un servidor aislado, solo, en un entorno controlado. Es útil, pero es distinto de reunir a las personas que estarían de turno en una caída real y correr el guion completo: quién llama a quién, quién decide qué, quién tiene acceso a cada sistema.
Ese guion completo es lo que queda sin tocar. El plan se escribió una vez —muchas veces por una consultora, para cerrar una auditoría o cumplir la exigencia de un cliente grande— y después se guardó en una carpeta compartida. Nadie lo vuelve a abrir hasta el día en que lo necesita, y ese mismo día descubre, junto con la caída, que el teléfono del proveedor cambió, que la contraseña de la consola de emergencia ya no es la que está escrita, que la persona responsable de avisar al banco ya no trabaja en la empresa.
La ISO 22301, norma internacional de gestión de continuidad de negocio, trata ese ensayo como una etapa obligatoria de su propio ciclo de gestión, no como un extra: después de planificar, la norma exige probar el plan y registrar el resultado, antes de considerar algo listo. Un documento que nunca pasó por esa etapa está, por la propia lógica de la norma, incompleto —aunque parezca completo en el papel.
Un formato común para ese ensayo, usado también por la CISA —la agencia de ciberseguridad del gobierno de Estados Unidos— es el ejercicio de mesa: una simulación en sala, sin apagar nada de verdad, en la que cada persona responde en vivo qué haría frente a un escenario de crisis. La agencia mantiene paquetes ya armados con más de cien escenarios distintos, justamente porque la mayor parte del valor del ejercicio está en descubrir, en una sala tranquila, lo que el documento no previó —antes de descubrirlo en medio de una caída real.
Por qué la manera habitual no resuelve
La manera habitual es escribir el plan, guardarlo y confiar en que funcione. La revisión anual, cuando existe, suele ser una reunión corta en la que alguien lee el documento en voz alta y todos coinciden en que está bien —sin simular nada, sin probar un solo contacto, sin cronometrar cuánto tiempo lleva realmente cada etapa.
Otra versión del mismo problema es repartir roles en el papel sin revisar si todavía tienen sentido: la persona indicada como responsable de decidir puede haber cambiado de cargo, el proveedor listado puede haber cerrado la cuenta, el sistema de acceso remoto mencionado puede haber sido reemplazado hace dos años. Nada de eso aparece releyendo el texto —solo aparece cuando alguien de verdad intenta seguir el guion.
El efecto más caro de ese hábito aparece justo en el peor momento: en medio de la propia caída, cuando el equipo descubre en vivo que un paso del plan depende de algo que ya no existe. En ese momento nadie está probando nada, está improvisando bajo presión, con el negocio parado mientras decide.
La confianza de las empresas en su propia recuperación bajó un poco: señal de que las pruebas están revelando huecos que antes nadie veía.
Lo que tiene que existir en la práctica
Un plan de continuidad que funciona cuando hace falta se apoya en algunos mecanismos verificables, no en buenas intenciones.
Un ejercicio marcado en el calendario, hecho de verdad, y no dejado para cuando sobre tiempo. Sin fecha fija, el ensayo se convierte en lo primero que se cancela de la agenda, mes tras mes.
Contactos de proveedor, banco y operadora revisados de nuevo en cada ciclo, no copiados del documento anterior sin comprobar si todavía funcionan.
Contraseñas y accesos de emergencia guardados en un lugar que funciona incluso sin la persona que siempre los usa. Si solo una persona sabe entrar a la consola de emergencia, el plan depende de que esa persona esté disponible, y puede estar de vacaciones justo el día de la caída.
Un rol específico para quien esté de turno ese día, no solo para quien escribió el plan. Quien está de turno casi nunca es quien redactó el documento.
Registro de lo que reveló el ejercicio, con plazo para corregirlo antes del próximo ciclo: sin ese registro, el mismo problema vuelve a aparecer en el siguiente ensayo.
Tiempo cronometrado de principio a fin del guion, para saber cuánto lleva de verdad, y no cuánto parece llevar solo con leer el papel.
Así es como trabaja Skills IT: con el ejercicio de continuidad agendado y registrado, y los contactos de proveedor y los accesos de emergencia revisados en cada ciclo, en lugar de copiados del documento anterior.
Lo que cambia cuando el plan ya fue ensayado
La ganancia de ensayar el plan no es abstracta. En una caída real, la diferencia entre un equipo que ya pasó por el guion y uno que lee el documento por primera vez aparece en minutos: el primero sabe quién llama, quién decide y dónde está el acceso; el segundo gasta ese tiempo buscándolo.
Eso cambia el tipo de conversación que ocurre durante la crisis. En lugar de decidir, en vivo y bajo presión, quién es responsable de avisar al cliente o cuándo abandonar una reparación y pasar al plan alternativo, el equipo ya sabe la respuesta, porque ya respondió esa misma pregunta un día tranquilo, durante el ejercicio.
El costo evitado aparece en tres lugares: menos horas de equipo reconstruyendo decisiones que ya deberían estar tomadas, menos riesgo de que un proveedor o un cliente pierda confianza por un aviso tardío, y menos posibilidad de que el presupuesto de emergencia se gaste resolviendo un problema que el propio ensayo ya habría mostrado antes.
Preguntas para llevar a la próxima reunión
Antes de revisar el plan de nuevo solo leyendo el texto, vale la pena reunir a quienes estarían de turno y preguntar:
- ¿Alguien ya siguió este plan de principio a fin, con las personas reales, fuera de una caída de verdad? Si la respuesta es no, el plan nunca fue probado, solo escrito.
- ¿Los teléfonos y contactos del documento todavía funcionan? Llamar para comprobarlo, hoy, toma pocos minutos.
- ¿Quién reemplaza a la persona que siempre resuelve esto, si está de vacaciones o fuera de alcance el día de la caída? Un plan con un único responsable no es un plan: es una dependencia.
- ¿Cuánto tiempo lleva realmente el guion, cronometrado? La respuesta casi nunca es la misma que parece en el papel.
- ¿Qué reveló el último ejercicio, y ya se corrigió? Un problema encontrado y no corregido va a volver a aparecer, solo que la próxima vez puede ser en una caída real.
