Durante años, la planificación de la Recovery siguió un patrón habitual: elaborar el plan, documentar los pasos y dar por hecho que funcionaría cuando fuera necesario. Durante mucho tiempo, ese enfoque funcionó. Fallos de hardware, interrupciones aisladas, incluso desastres naturales… eran situaciones que las organizaciones podían anticipar y para las que podían planificar con cierto grado de confianza. Pero la situación ha cambiado.
En este episodio de STRIVE, he hablado con Jason Cray, responsable principal de experiencia de producto de Commvault, para analizar una realidad que seguimos viendo en organizaciones de todos los tamaños: la mayoría no fracasa porque le falte un plan de recuperación. Fracasa porque nunca ha comprobado que ese plan vaya a funcionar bajo presión real. Mira elepisodio completo.
Puntos clave: Por qué fracasan los planes de recuperación
- Un plan documentado no es lo mismo que uno que haya demostrado su eficacia. Si no se ha probado en condiciones reales, sigue siendo solo una suposición.
- La recuperación es un trabajo en equipo. La seguridad, la infraestructura y las operaciones deben estar coordinadas; si no, la recuperación se ralentiza.
- La mayor parte de la inversión sigue realizándose «antes de que llegue el auge». La prevención es importante, pero a menudo se pasa por alto la preparación para la recuperación.
- Las pruebas sacan a la luz las carencias y generan confianza. Sin ellas, las organizaciones se quedan solo con la esperanza.
- La resiliencia es una disciplina operativa. Requiere iteración, comunicación y mejora continua.
El problema con eso de «debería funcionar»
Sobre el papel, la recuperación parece sencilla. Tienes que definir hasta qué punto quieres recuperar, qué es lo que hay que recuperar y dónde debe restaurarse. El proceso parece lógico, estructurado y fácil de gestionar. Pero, como señala Jason, esa sencillez rara vez se mantiene en las condiciones del mundo real.
Los planes se redactan en entornos controlados, pero se ejecutan en medio del caos. Cuando se produce un incidente, los equipos no revisan tranquilamente la documentación: reaccionan, resuelven problemas e intentan coordinarse en tiempo real. Ahí es donde surge la brecha. No entre las herramientas y la tecnología, sino entre las expectativas y la ejecución.
Avance: ¿Por qué fracasan los planes cuando hay presión?
En este fragmento de la conversación, Jason y yo analizamos por qué no basta con tener un plan, y qué hace falta realmente para saber que un plan funcionará cuando sea necesario.
Ya hemos visto esto antes
Lo curioso es que este problema no es nuevo; es algo que ya conocemos, solo que en un contexto diferente. Si nos remontamos a los inicios de la recuperación ante desastres, las organizaciones seguían un patrón similar. Los planes existían, pero las pruebas eran, en el mejor de los casos, irregulares. Jason compartió un ejemplo en el que pasó toda una noche ayudando a un cliente a superar una prueba de recuperación ante desastres para la que creían estar preparados. El plan parecía sólido. La ejecución contó una historia diferente.
Con el tiempo, las organizaciones se fueron adaptando. Empezaron a hacer pruebas con más frecuencia, introdujeron simulacros de conmutación por error y, en algunos casos, incluso ejecutaron operaciones de producción desde entornos secundarios para demostrar que estaban preparadas. Ese cambio de las suposiciones a la validación es precisamente lo que exige ahorauna ciberresiliencia.
El primer problema: la comunicación
Si hay un tema que siempre sale a colación, ese es la comunicación. En muchas organizaciones, las responsabilidades están bien definidas: el equipo de seguridad se encarga de la prevención, el de infraestructura gestiona los sistemas y el de operaciones se ocupa de la recuperación. Por separado, puede que cada equipo esté haciendo exactamente lo que se supone que debe hacer. Pero la recuperación no se produce de forma aislada. Depende de lo bien que trabajen juntos esos equipos cuando algo sale mal.
Como describe Jason, con demasiada frecuencia se convierte en un modelo de traspaso de responsabilidades: «Ya hemos hecho nuestra parte, ahora le toca a otro». Ese enfoque genera retrasos, confusión y, en última instancia, riesgo. Durante un incidente cibernético, la coordinación es más importante que la atribución de responsabilidades.
El problema de «Left of Boom»
Otra tendencia que seguimos observando es el desequilibrio en cuanto a dónde centran sus esfuerzos las organizaciones. Se está invirtiendo mucho en prevención: herramientas de seguridad, plataformas de detección y estrategias defensivas diseñadas para detener un ataque antes de que se produzca. Esa inversión es necesaria y desempeña un papel fundamental. Pero se le presta mucha menos atención a lo que pasa después del evento.
Se parte de la base de que, si se dedica suficiente esfuerzo a la prevención, Recovery pasa a un segundo plano. En realidad, ocurre justo lo contrario. En algún momento, algo acaba colándose. Y cuando eso ocurre, Recovery se convierte en el factor determinante de cómo responde una organización.
De la esperanza a la evidencia
Aquí es donde hay que cambiar de mentalidad. No se trata de añadir más herramientas ni de reescribir la documentación. Se trata de pasar de un modelo basado en la esperanza a otro basado en la evidencia.
Jason destaca una observación clave: las organizaciones que gestionan bien las situaciones de crisis no son las que evitan los incidentes, sino las que sufren un menor impacto cuando estos se producen. Han puesto a prueba sus procesos. Han validado sus hipótesis. Saben dónde están sus carencias. Y lo más importante de todo es que se han ganado la confianza, no por creer que el plan va a funcionar, sino por demostrarlo.
Empieza poco a poco y ve cogiendo impulso
Para muchos equipos, el reto no es entender el problema, sino saber por dónde empezar. La clave no está en cambiarlo todo de golpe. Está en empezar poco a poco y seguir avanzando a partir de ahí.
Céntrate en uno o dos servicios críticos. Entiende qué se necesita para recuperarlos. Reúne a los equipos responsables de esos sistemas y prueba el proceso de principio a fin. A partir de ahí, amplía el alcance y sigue perfeccionándolo. Este enfoque no solo mejora la recuperación, sino que también fomenta la coordinación, refuerza la comunicación y sienta las bases para una resiliencia más amplia.
La realidad: ningún plan sobrevive al primer contacto
Uno de los momentos más sinceros de nuestra charla fue este: ni siquiera el mejor plan va a salir exactamente como está previsto. Eso no es un fallo, es lo que se espera. Jason lo explica de forma sencilla: si no tienes un plan, fracasarás. Pero, aunque lo tengas, no todo saldrá a la perfección en el momento.
Lo que importa es hasta qué punto tus equipos están preparados para adaptarse. Las pruebas fomentan esa adaptabilidad. Desarrollan la memoria muscular necesaria para responder con eficacia cuando las condiciones no se ajustan a las expectativas.
La conclusión más importante de este debate es que la criptografía poscuántica ya no es un reto tecnológico del futuro.
Se está convirtiendo en un debate sobre la resiliencia en el presente.
Las organizaciones no tienen por qué entrar en pánico ni necesitan renovar todos los sistemas de la noche a la mañana. Pero sí deben empezar a actuar, para aprovechar al máximo el tiempo del que disponen para prepararse.
Las organizaciones que superen con éxito esta transición no serán necesariamente aquellas que cuenten con la criptografía más sofisticada. Serán aquellas que hayan empezado a formarse una idea del tema antes de que llegara la certeza.
Y así es, a menudo, como funciona la resiliencia.
En esta charla de STRIVE hablamos de muchas más cosas, entre ellas:
- ¿Por qué los planes de recuperación suelen fracasar a pesar de estar bien documentados?
- ¿Qué diferencia a las organizaciones que se recuperan de forma eficaz?
- Cómo afectan las deficiencias en la comunicación a la ejecución.
- ¿Por dónde empezar a mejorar la preparación para la recuperación?
- Por qué las pruebas son la base de la resiliencia.
Ver ahora. Si alguna vez te has preguntado si tu plan de recuperación funcionaría de verdad, esta conversación te va a merecer la pena.
Preguntas frecuentes
P: ¿Por qué no basta con tener un plan de recuperación?
R: Porque la mayoría de los planes nunca se ponen a prueba en condiciones reales. Sin pruebas, no dejan de ser suposiciones en lugar de estrategias contrastadas.
P: ¿Qué hace que los planes de recuperación fallen?
R: Los problemas más habituales en los planes de recuperación son la falta de pruebas, la mala comunicación entre equipos y las discrepancias entre los procesos documentados y la ejecución real.
P: ¿Qué significa «a la izquierda de la pluma»?
R: «A la izquierda de la pluma» se refiere a centrarse en prevenir los incidentes antes de que se produzcan. Muchas organizaciones invierten mucho en esto, pero no lo suficiente en las capacidades de recuperación.
P: ¿Con qué frecuencia se deben probar los planes de recuperación?
R: Los planes de recuperación deben someterse a pruebas periódicas y en condiciones variadas. Las pruebas deben simular situaciones reales, no solo ejercicios controlados.
P: ¿Por dónde deberían empezar las organizaciones?
R: Empieza con un pequeño conjunto de servicios críticos, coordina a los equipos responsables y prueba la recuperación de principio a fin antes de ampliarla.
P: ¿Cuál es el cambio de mentalidad clave?
R: Pasar de una planificación basada en la esperanza a una validación basada en la evidencia.
Chris Mierzwa es director sénior de marketing de cartera en Commvault.
