Un ataque de ransomware cifra los sistemas de producción un martes a las 2 de la mañana. A las 8, el equipo directivo pregunta cuándo se puede retomar la operación. La respuesta honesta: no se sabe. Los respaldos existen, pero nadie los ha probado en dieciocho meses. El plan de continuidad menciona un tiempo de recuperación de cuatro horas, pero fue escrito antes de que la operación migrara a la nube. Y el proveedor de respaldos está en el mismo segmento de red que fue cifrado.
El plan existía. Solo que no estaba listo para este escenario.
La distancia entre tener un plan y tener resiliencia
Muchas organizaciones confunden documentar con prepararse. Un plan de continuidad de negocio es un documento hasta el momento en que se prueba. Después de probarse, se convierte en capacidad operativa. Antes de eso, es solo texto.
Según datos de IBM Security, el tiempo promedio para identificar y contener una brecha es de 258 días. Durante ese tiempo, la operación no se detiene: degrada. Los clientes siguen necesitando respuestas, los procesos críticos siguen corriendo con los recursos que quedan y el equipo toma decisiones bajo presión sin saber exactamente cuál es el estado real del entorno. Un plan de continuidad bien diseñado no elimina ese período, pero define cómo operará la organización durante él.
Los tres elementos que más fallan en la práctica
El primero son los respaldos no verificados. Casi todas las organizaciones tienen política de respaldos. Pocas prueban regularmente que esos respaldos son restaurables, que los tiempos de recuperación documentados son reales y que el proceso de restauración puede ejecutarlo el equipo disponible a las 3 de la mañana, no solo el especialista que está de vacaciones. Un respaldo que nunca se ha probado no es un respaldo: es una suposición.
El segundo son los objetivos de recuperación desactualizados. El RTO —tiempo máximo tolerable de inactividad— y el RPO —pérdida máxima de datos aceptable— deben reflejar la operación actual, no la de hace tres años cuando se escribió el plan. Si la empresa migró a cloud, añadió procesos críticos o cambió su modelo de negocio desde la última actualización del plan, esos objetivos ya no corresponden a la realidad.
El tercero es la falta de alternativas operativas para procesos críticos. ¿Qué hace el área de atención a clientes si el CRM no está disponible durante 48 horas? ¿Puede el área de finanzas procesar pagos si el ERP está cifrado? ¿Existe un proceso manual de emergencia documentado para los tres o cuatro procesos que no pueden detenerse bajo ninguna circunstancia? Cuando esas respuestas no existen, el impacto de un ataque va mucho más allá del sistema afectado.
¿Qué hacer al respecto?
El primer movimiento es verificar los respaldos esta semana, no en el próximo ciclo de auditoría. Ejecutar una restauración de prueba de al menos un sistema crítico, medir el tiempo real que toma y compararlo con el RTO documentado. Si hay diferencia significativa, el plan necesita actualizarse antes de que lo necesite un atacante.
El segundo movimiento es revisar si el RTO y el RPO del plan de continuidad reflejan la operación actual. Ese ejercicio requiere involucrar a los líderes de las áreas críticas —no solo a TI— porque son ellos quienes saben cuánto tiempo pueden operar sin un sistema antes de que el impacto sea irreversible. Esa conversación, incómoda como puede ser, es mucho mejor tenerla en una sala de juntas que durante un incidente activo.
El tercer movimiento es documentar alternativas operativas manuales para los tres o cuatro procesos de negocio que no pueden detenerse. No tienen que ser perfectas: tienen que ser funcionales el tiempo suficiente para que los sistemas se recuperen. Esa documentación básica puede ser la diferencia entre una crisis manejable y una pérdida de clientes irreversible.
Si tu organización sufriera un ataque de ransomware mañana, ¿sabrías en cuántas horas estarías operando de nuevo, con qué datos y a qué costo?
Acciones inmediatas
- Ejecuta una prueba de restauración de respaldo de al menos un sistema crítico en los próximos 30 días. No validar el proceso de backup: validar que la restauración funciona, que los datos son consistentes y que el tiempo real de recuperación coincide con el RTO documentado. Si no coincide, el plan necesita corrección antes de que lo necesites de verdad.
- Verifica que los respaldos de sistemas críticos están almacenados en un segmento de red aislado o fuera del entorno principal. Un respaldo en el mismo segmento que fue cifrado por ransomware no es un respaldo: es parte del incidente. La separación física o lógica de los respaldos es el control más básico de resiliencia ante ransomware.
- Revisa con los líderes de área cuánto tiempo pueden operar sin cada sistema crítico antes de que el impacto sea irreversible. Esa respuesta define el RTO real, no el que estimó TI cuando escribió el plan. La diferencia entre ambos números es el gap de resiliencia más importante que tienes.
- Documenta un proceso manual de emergencia para los tres procesos de negocio que menos pueden detenerse. No necesita ser complejo: quién lo ejecuta, qué información mínima necesita y cómo se registran las operaciones para sincronizar después. Ese documento, guardado fuera de los sistemas afectables, puede salvar semanas de recuperación.
- Agenda un ejercicio de simulación de continuidad que incluya un escenario de ciberataque con los líderes de área involucrados, no solo con el equipo de TI. La continuidad de negocio es una responsabilidad operativa, no técnica. Si los líderes de finanzas, operaciones y comercial no participan en el ejercicio, no sabrán qué hacer cuando el escenario sea real.
Si tu organización quiere revisar o construir un plan de continuidad de negocio que contemple escenarios de ciberataque reales, contáctanos en https://tbsek.mx/contacto/.
