El directorio que aprueba un plan de continuidad sin exigir su prueba aprueba un documento. La primera prueba real de ese documento llega con el incidente, delante del cliente.
Una certificación prueba que el sistema existe. Solo la operación prueba que funciona. La auditoría de ISO 22301:2019 verifica que la organización tenga un programa de ejercicios (cláusula 8.5), y la de ISO/IEC 27001:2022 verifica que la preparación de las tecnologías de la información para la continuidad esté planificada y probada (control 5.30 del Anexo A). Las dos verifican que la prueba exista. Lo que la prueba encontró, con qué escenario y con qué equipo, lo decide la organización, y casi siempre lo decide a favor de un ejercicio cómodo.
El mismo incidente, dos resultados
En julio de 2024, una actualización defectuosa del software de seguridad de CrowdStrike dejó fuera de servicio equipos con Windows en todo el mundo. La misma falla golpeó a las grandes aerolíneas de Estados Unidos, y Delta Air Lines fue la que más tardó en recuperarse: canceló cerca de 7.000 vuelos, afectó a 1,3 millones de clientes y su CEO, Ed Bastian, estimó el costo en 500 millones de dólares en 5 días. El sistema que asigna pilotos y tripulantes a cada vuelo quedó desarmado, y Delta tuvo que reiniciar a mano unos 40.000 servidores. El Departamento de Transporte investigó cómo trató Delta a sus pasajeros durante esa recuperación y cerró la investigación sin sanciones; el cierre se conoció en junio de 2026.
El incidente fue el mismo para todas. La diferencia estuvo en la recuperación de un sistema específico, el de tripulaciones, y en cuánto tiempo pudo operar la aerolínea con ese sistema caído. La atención al cliente, en cambio, funcionó: el regulador constató reembolsos rápidos y asistencia adecuada. Una organización puede tener resuelto un frente y descubrir en el incidente que el que decide su resultado es otro.
Lo que un cliente o un regulador quiere ver
La pregunta que llega hoy de un cliente grande, de un auditor o de un regulador tiene la forma de una exigencia de evidencia. Esa evidencia cubre cuatro frentes, y los cuatro se prueban con el equipo que va a responder:
- Respuesta y comunicación. Quién actúa, con qué runbook, con qué escalamiento, y cómo se informa a la organización, a los clientes y al regulador.
- Redundancia. Si la redundancia declarada existe y cubre el servicio, o si varios proveedores del registro dependen en realidad de la misma nube.
- Recuperación. En cuánto tiempo vuelve el servicio frente al tiempo que la organización comprometió.
- Operación degradada. Cómo se sigue operando con una parte de los servicios caídos, que es el estado real de las primeras horas.
El caso Delta cae casi entero en los dos últimos frentes. Son también los que un ejercicio cómodo deja afuera, porque obligan a elegir un escenario que duele.
La tecnología acelera todo. Si algo está mal, sale mal más rápido. Cada servicio que se traslada a la nube o que suma una función de inteligencia artificial en la renovación de un contrato de software agrega una dependencia que el plan de continuidad del año anterior no contempla. El plan envejece al ritmo de la tecnología, y la prueba es lo único que lo actualiza contra la realidad.
La decisión del directorio
La primera alternativa es renovar la certificación y aprobar el plan actualizado. Cuesta poco y deja evidencia de que el sistema existe. Su costo aparece después: el directorio aprueba sin saber cómo responde el servicio crítico, y esa información llega con el primer incidente.
La segunda alternativa es exigir, una vez por año, una prueba sobre el servicio crítico que mira el cliente o el regulador, con un escenario que incluya la caída de un proveedor y la operación degradada, y con un informe al comité de riesgos que registre dónde falló. Cuesta horas del equipo y expone brechas que hasta ese momento nadie había escrito.
Recomiendo la segunda, empezando por un solo servicio. Con un servicio piloto, la prueba se construye, se ejecuta y el método se corrige antes de extenderlo al resto. El riesgo residual que asumo con esa recomendación es concreto: un ejercicio de mesa verifica decisiones, tiempos y dependencias, y no reemplaza la conmutación técnica real de los sistemas, que depende del proveedor de infraestructura y se prueba aparte.
Con la prueba, el comité de riesgos recibe fallas registradas, con fecha, escenario y responsables, y el directorio aprueba el plan sabiendo qué parte funciona. DORA, el Reglamento (UE) 2022/2554, ya exige a las entidades financieras europeas un programa de pruebas de resiliencia operativa digital (artículo 24). A un proveedor de servicios de TIC de la región lo alcanza por contrato: la entidad europea tiene que incluir en el acuerdo las cláusulas del artículo 30. Si el proveedor es designado crítico, las entidades de la Unión solo pueden usar sus servicios si abre una filial en la Unión dentro de los 12 meses siguientes a la designación (artículo 31, apartado 12). La exigencia de evidencia va a llegar por contrato antes que por norma.
Un plan de continuidad que nunca se probó es solo un documento. El directorio que lo aprueba sin prueba asume el riesgo sin evidencia, y la primera prueba real llega con el incidente, delante del cliente.