El simulacro terminó a las 11:30. El servicio fue recuperado dentro del RTO, los responsables ejecutaron correctamente sus procedimientos, las comunicaciones funcionaron y el informe final concluyó que la organización estaba preparada.

Resultado: 100 % satisfactorio. Seis meses después ocurre un incidente real.

El responsable principal está de vacaciones. La persona que debía reemplazarlo no tiene acceso a una aplicación. El proveedor tarda cuarenta minutos en responder. Nadie sabe quién puede autorizar una decisión urgente y el procedimiento contiene teléfonos que ya no existen.

¿Qué ocurrió? Probablemente el simulacro anterior no demostró que la organización era resiliente. Demostró que podía ejecutar correctamente un escenario que todos conocían de antemano.

El problema de diseñar pruebas para aprobarlas

En muchas organizaciones, los ejercicios de continuidad siguen una lógica bastante previsible. Se define el escenario semanas antes. Se comunica la fecha. Los participantes conocen qué sistemas serán afectados. Los responsables revisan previamente sus procedimientos. Tecnología prepara los ambientes.

Los proveedores son advertidos. Y todos llegan al día del ejercicio sabiendo, en mayor o menor medida, qué va a ocurrir.

Desde el punto de vista de capacitación, esto puede tener sentido. Desde el punto de vista de validación de resiliencia, tiene limitaciones importantes. Porque una crisis real no envía una invitación de calendario.

Capacitar y probar no son exactamente lo mismo

Aquí conviene hacer una distinción, un ejercicio anunciado no es inútil, pero puede ser excelente para entrenar personas, familiarizar equipos con procedimientos, comprobar comunicaciones o enseñar cómo utilizar una estrategia de recuperación.

El problema aparece cuando utilizamos ese resultado para concluir que la capacidad de respuesta ha sido validada. Entrenar una capacidad y someterla a prueba son objetivos diferentes. En entrenamiento podemos ayudar. En una prueba necesitamos introducir suficiente incertidumbre para observar cómo responde realmente la organización.

El Comité de Basilea plantea precisamente que las entidades deben realizar ejercicios de continuidad bajo una variedad de escenarios severos pero plausibles, incluyendo operaciones críticas y sus interconexiones y dependencias.

La pregunta, por tanto, no debería ser solamente: ¿Ejecutamos el plan?

Debería ser: ¿El plan funcionó cuando las condiciones dejaron de ser las esperadas?

La crisis que sigue exactamente el guion no existe

Supongamos que queremos probar la indisponibilidad de un centro de procesamiento.

El escenario tradicional podría indicar: A las 09:00 se declara indisponible el centro principal. Se activa el DRP y se recuperan las aplicaciones en el sitio alterno.

Ahora cambiemos algunas condiciones.

A las 09:25, mientras se realiza la recuperación, el equipo descubre que el responsable de una aplicación crítica no está disponible.

A las 09:40, el proveedor informa que necesita autorización adicional para ejecutar una actividad.

A las 10:05, aparece un problema de integridad en la última copia de información.

A las 10:20, comienzan a llegar reclamos de clientes.

A las 10:35, una autoridad solicita información sobre el incidente.

El escenario dejó de ser una secuencia técnica. Ahora estamos observando cómo decide la organización bajo presión, y eso se parece bastante más a una crisis real.

La inyección de eventos cambia completamente la prueba

Una práctica útil consiste en incorporar event injects: situaciones adicionales que el equipo desconoce y que aparecen durante el ejercicio.

Por ejemplo:

• Indisponibilidad del responsable principal.
• Falla del mecanismo alternativo.
• Información contradictoria sobre el incidente.
• Caída de un proveedor crítico.
• Saturación del canal de atención.
• Problemas de integridad de datos.
• Filtración del incidente en redes sociales.
• Solicitud urgente del supervisor.
• Necesidad de decidir sin contar con toda la información.

No se trata de convertir el ejercicio en una película de desastre. La finalidad es comprobar algo mucho más importante: la capacidad de adaptación.

También deberíamos probar la ausencia de personas

Uno de los errores más frecuentes consiste en realizar los ejercicios con todos los especialistas disponibles. Eso facilita la ejecución, pero elimina una variable crítica.

¿Qué ocurre si la persona que mejor conoce el proceso no está?

¿Qué sucede si el líder del Comité de Crisis no puede participar?

¿Existe sucesión de autoridad?

¿El reemplazo tiene realmente acceso, conocimiento y capacidad de decisión?

Basilea incluye expresamente dentro de la planificación de continuidad la necesidad de establecer roles, responsabilidades y sucesión de autoridad cuando una interrupción afecta personal clave.

Por eso, algunas pruebas deberían comenzar precisamente diciendo: “Para este ejercicio, el responsable principal no está disponible.”

La reacción inicial puede ser incómoda.

Pero probablemente genere más aprendizaje que repetir por quinta vez un escenario perfectamente controlado.

¿Qué significa realmente “simulacro satisfactorio”?

Este es otro punto que merece revisión. En algunas organizaciones, el resultado se reduce a:

Satisfactorio / No satisfactorio.

Eso aporta muy poca información. Un ejercicio debería tener criterios objetivos definidos antes de comenzar.

Por ejemplo:

Tiempo: ¿el servicio permaneció dentro de la tolerancia establecida?

Capacidad: ¿qué porcentaje de la operación normal pudo mantenerse?

Decisión: ¿las decisiones críticas fueron tomadas dentro del tiempo requerido?

Escalamiento: ¿los responsables correctos fueron involucrados?

Comunicación: ¿la información llegó oportunamente a clientes, autoridades y partes interesadas?

Dependencias: ¿los terceros respondieron según lo esperado?

Recuperación: ¿la información recuperada fue validada antes de volver a operar?

Adaptación: ¿el equipo pudo responder ante situaciones no previstas?

Ahora sí podemos hablar de evidencia.

Una prueba que encuentra problemas puede ser una excelente prueba

Existe cierta resistencia organizacional a reportar simulacros con resultados negativos. Nadie quiere presentar al Comité que el RTO no fue cumplido o que un procedimiento falló. Pero ese razonamiento pierde de vista el propósito del ejercicio:

Si una prueba descubre que el proveedor tarda seis horas cuando esperábamos dos, acabamos de obtener información extraordinariamente valiosa.

Si descubrimos que el reemplazo del responsable no tiene accesos, podemos corregirlo.

Si comprobamos que el procedimiento manual soporta solamente el 25 % del volumen habitual, ahora conocemos nuestra capacidad real.

Es mucho mejor descubrir estas brechas un martes durante un ejercicio que un domingo durante un ataque. El simulacro no debería diseñarse para demostrar que estamos preparados. Debería diseñarse para descubrir dónde todavía no lo estamos.

El Comité de Riesgos debería cambiar algunas preguntas

En lugar de preguntar: ¿Se ejecutó el programa anual de pruebas?

Podría preguntar: ¿Qué aprendimos que no sabíamos antes del ejercicio?

Y agregar:

• ¿Qué supuestos demostraron ser incorrectos?
• ¿Qué dependencia falló?
• ¿Qué RTO no fue alcanzado?
• ¿Qué decisiones tardaron demasiado?
• ¿Qué ocurrió cuando eliminamos al responsable principal?
• ¿Qué controles no funcionaron como esperábamos?
• ¿Qué brechas continúan abiertas?
• ¿Cuándo volveremos a probarlas?

Ese cambio modifica completamente la conversación.

La verdadera prueba empieza cuando algo sale mal

Una organización resiliente no es aquella cuyos simulacros siempre terminan en verde. Es aquella que utiliza los ejercicios para desafiar sus propias certezas.

Necesitamos pruebas anunciadas para entrenar. Pero también necesitamos escenarios parcialmente desconocidos, inyección de eventos, fallas simultáneas, indisponibilidad de personas, participación real de terceros y criterios objetivos de evaluación.

Porque cuando absolutamente todos los simulacros salen perfectamente bien durante años, quizás deberíamos dejar de felicitarnos y comenzar a preocuparnos.

La resiliencia no se demuestra cuando todo ocurre según el guion. Se demuestra cuando el guion deja de funcionar y la organización todavía sabe qué hacer.