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 e 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, director de experiencia de producto de Commvault, para analizar una realidad que seguimos observando en organizaciones de todos los tamaños: la mayoría no fracasa por carecer de un plan de recuperación. Fracasa porque nunca ha comprobado que ese plan vaya a funcionar bajo presión real. Mira el episodio 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; de lo contrario, 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 solo cuentan 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. Hay que definir hasta qué punto se quiere 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é se necesita 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, esporádicas. 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 fueron adaptándose. Empezaron a realizar pruebas con mayor frecuencia, introdujeron simulacros de conmutación por error y, en algunos casos, llegaron incluso a ejecutar 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 ahora la 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 presta mucha menos atención a lo que ocurre tras el incidente.
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 impacto
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 cabe esperar. 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. Los simulacros fomentan esa adaptabilidad. Desarrollan la memoria muscular necesaria para responder con eficacia cuando las condiciones no se ajustan a las expectativas.
Mira el episodio completo
En esta charla de STRIVE hablamos de muchas más cosas, entre ellas:
- ¿Por qué suelen fracasar los planes de recuperación 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?
Échale un vistazo 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 son más que 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 deben probarse 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.
