ESTRATEGIA · LIDERAZGO · CONTINUIDAD OPERACIONAL
Hay una pregunta que le he hecho, de formas distintas, a varios profesionales de TI en los últimos años. La pregunta es simple: ¿cuándo fue la última vez que probaron el plan de continuidad con una interrupción real? No una revisión del documento. No una presentación al directorio sobre qué dice el plan. Una prueba real, con sistemas apagados, con el equipo ejecutando los procedimientos bajo condiciones de falla.
La respuesta más frecuente no es "nunca." La respuesta más frecuente es "lo tenemos agendado para el próximo trimestre." Y ese próximo trimestre lleva, en algunos casos, varios años llegando.
No es negligencia. No es ignorancia. Es una decisión organizacional que tiene una lógica interna bastante coherente, y eso es exactamente lo que la hace peligrosa.
LAS JUSTIFICACIONES QUE SIEMPRE SON RAZONABLES
Las razones para postergar un simulacro de continuidad nunca son malas razones. Son razones completamente válidas dentro del contexto operacional de cualquier organización mediana en la región.
No es buen momento porque el equipo está sobrecargado con el cierre de trimestre. No es conveniente hacerlo en temporada alta. Hay un proyecto de migración en curso que no puede interrumpirse. El proveedor de servicios gestionados necesita coordinarse con anticipación y eso tarda semanas. El presupuesto para el ejercicio no está aprobado. La gerencia general no quiere interrupciones justo antes de la auditoría.
Cada una de esas razones es legítima. Ninguna es inventada. El problema no está en la validez de cada justificación individual; está en que siempre hay una justificación disponible. Cuando la postergación es siempre posible y siempre razonable, la prueba nunca ocurre.
Y si la prueba nunca ocurre, el plan de continuidad es un documento. No un plan.
¿EL COSTO QUE SE ESTÁ CALCULANDO MAL?
Hay una asimetría en cómo las organizaciones calculan el costo del simulacro versus el costo del incidente que el simulacro debería preparar.
El costo del simulacro es concreto, visible e inmediato. Cuatro horas de interrupción controlada en un sábado. El tiempo del equipo técnico. La coordinación con proveedores. La posible incomodidad de usuarios que no entienden por qué los sistemas están caídos si "no pasó nada." Ese costo se puede presupuestar, se puede calcular, y sobre todo, se puede criticar. Alguien tiene que firmar la autorización para interrumpir la operación aunque sea de forma controlada, y esa firma tiene un costo político interno que no aparece en ninguna planilla.
El costo del incidente es abstracto, invisible y futuro. Todavía no ocurrió. Puede que nunca ocurra. Y si ocurre, quien firmó la autorización del simulacro que nunca se hizo ya no estará en ese cargo, o el contexto habrá cambiado suficiente para que la responsabilidad quede difusa.
Esta no es una observación cínica. Es una descripción bastante precisa de cómo funciona la toma de decisiones bajo incertidumbre en organizaciones reales. El dolor cierto y próximo siempre pesa más que el riesgo incierto y lejano, aunque el riesgo lejano sea objetivamente más costoso. Los economistas del comportamiento llevan décadas documentando este patrón. Las organizaciones no son la excepción.
El simulacro que nadie autoriza no es el resultado de mala gestión. Es el resultado de una lógica de decisión que optimiza el corto plazo de forma completamente racional, y que solo se rompe cuando el incidente hace que el costo de no haber probado sea imposible de ignorar.
LO QUE LA POSTERGACIÓN DICE SOBRE LA ORGANIZACIÓN
Cuando un plan de continuidad nunca se prueba, hay algo más relevante que la calidad técnica del documento. Hay una señal sobre cómo la organización entiende el riesgo y quién tiene la autoridad real para actuar sobre él.
En la mayoría de los casos que he visto, el responsable de TI sabe perfectamente que el plan necesita ser probado. Lo sabe desde hace tiempo. El problema no es el conocimiento técnico; es que probar el plan requiere autorización de personas que no están en TI, que no tienen visibilidad del riesgo operacional con el nivel de detalle que tiene el equipo técnico, y que perciben el simulacro principalmente como una interrupción del negocio, no como una inversión en resiliencia.
Esa brecha entre quien conoce el riesgo y quien tiene la autoridad para actuar sobre él es uno de los problemas de gobernanza más frecuentes en organizaciones medianas de la región. No es exclusiva de la continuidad; aparece también en decisiones de inversión en infraestructura, en renovación de equipos EOL, en implementación de controles de seguridad. Pero en el caso de la continuidad tiene una consecuencia particular: la organización descubre la brecha en el peor momento posible.
En Chile y en la región en general, ese momento llegó para varias organizaciones durante los años de pandemia, cuando la continuidad del trabajo remoto se convirtió en un requisito de supervivencia con horas de anticipación. Los que habían probado sus planes tuvieron una transición difícil. Los que no los habían probado descubrieron en tiempo real qué partes del plan eran teoría y qué partes eran operación real.
¿QUÉ SIGNIFICA ESTO EN PRODUCCIÓN?
Un plan de continuidad que no se ha probado tiene partes que funcionan y partes que no. El problema es que nadie sabe cuáles son cuáles hasta que hay un incidente.
La arquitectura Fortinet de una organización puede estar perfectamente configurada para conmutación automática entre data center primario y espejo. Los procedimientos de activación del plan pueden estar documentados paso a paso. El RTO puede estar definido en cuatro horas. Y aun así, cuando llegue el momento real, puede descubrirse que el proceso de notificación interna tarda el doble de lo estimado, que el proveedor de telecomunicaciones tiene un procedimiento de escalación que nadie en el equipo conoce, que las credenciales de acceso al sistema de backups están desactualizadas, o que el procedimiento de recuperación del FortiManager requiere una secuencia específica que no estaba documentada.
Esas brechas no aparecen en la revisión del documento. Aparecen en la ejecución bajo presión. Y la única forma de encontrarlas antes del incidente es probar.
TechCorp Latam tenía documentación de continuidad antes del ransomware. Lo que esa documentación no podía garantizar es que el equipo técnico, a las 4 de la mañana con los sistemas comprometidos, pudiera ejecutarla con la velocidad y la precisión que el plan asumía. Esta semana voy a desarrollar en detalle qué pasó esa noche entre lo que el plan decía y lo que el equipo pudo hacer realmente, y qué cambió después.
DECISIÓN QUE DEBE TOMAR EL CIO
La pregunta no es si el plan de continuidad está bien redactado. La pregunta es quién en la organización tiene la autoridad y la voluntad de interrumpir la operación de forma controlada para saber si el plan funciona.
Si esa persona no existe, o si esa autorización no se puede obtener sin un incidente que la justifique, el plan de continuidad tiene un supuesto implícito que nadie ha validado: que todo lo que está escrito realmente funciona. Y ese supuesto vale exactamente lo que vale cualquier supuesto que nunca se ha probado.
La decisión de probar no es técnica. Es política. Requiere que alguien, con nombre y apellido, diga: vamos a interrumpir de forma controlada para asegurarnos de que podemos recuperarnos de una interrupción no controlada. Esa persona tiene que estar dispuesta a asumir el costo visible del simulacro para reducir el costo invisible del incidente.
En organizaciones donde esa persona no existe o no tiene la autoridad para hacerlo, el plan de continuidad es, en el mejor de los casos, un buen punto de partida para el momento en que todo falle.
Si esta semana te preguntaran cuándo fue la última vez que probaron el plan de continuidad, y la respuesta honesta es "próximo trimestre", ya sabes cuál es la decisión que está pendiente, y por qué nadie la está tomando.
Esta semana en el blog: cinco días desarrollando por qué las organizaciones no prueban su continuidad y qué cuesta esa decisión cuando el incidente llega. Mañana: qué significa operacionalmente "no haber probado" cuando el plan tiene que ejecutarse bajo presión real.
#ContinuidadOperacional #BCP #PlanDeContinuidad #Ciberseguridad #CIO #ITManager #GestiónDeRiesgos #Fortinet #Cisco #WatchGuard #TechCorpLatam #CyberLeadership #Liderazgo #Chile #Resiliencia #NISTCSF #ISO22301
Comentarios
Publicar un comentario