Tu respaldo corre en verde: por qué eso no prueba que puedas recuperar la información

Es uno de los controles más comunes de un sistema de seguridad de la información, y uno de los que más engañan: el respaldo de la información. Casi toda organización lo tiene, casi todas revisan que corra todas las noches, y casi todas dan por hecho que, si algo pasa, la información se puede recuperar. El error que ISO/IEC 27001 Lead Implementer pide reconocer y corregir tiene nombre propio: evidencia de ejecución en lugar de evidencia de recuperación.

Qué pide ISO/IEC 27001 sobre la continuidad de la información

ISO/IEC 27001 incluye, entre sus controles, la protección de la información contra pérdida a través de copias de respaldo y su verificación periódica. La palabra clave es verificación: la norma no se conforma con que el respaldo exista y corra según lo programado. Pide evidencia de que, si se necesitara, la información realmente se podría recuperar en un estado utilizable, dentro de un tiempo razonable para la operación del negocio.

El error: evidencia de ejecución en lugar de evidencia de recuperación

El error ocurre cuando la organización confunde dos cosas que suenan parecido pero no lo son. La evidencia de ejecución es el registro de que el proceso de respaldo corrió: un log en verde, una notificación de «respaldo completado», un reporte automático cada mañana. La evidencia de recuperación es la prueba de que, a partir de ese respaldo, alguien pudo restaurar la información completa y usarla. La primera es fácil de generar y casi siempre está disponible. La segunda requiere un esfuerzo deliberado que muchas organizaciones nunca hacen, porque el respaldo «siempre ha corrido bien».

Por qué pasa

Ocurre porque el respaldo se convierte en una rutina invisible. Corre de madrugada, nadie lo supervisa en tiempo real, y el único contacto humano con el proceso es un reporte automático que dice «éxito». Nadie tiene un incentivo claro para interrumpir la operación y probar una restauración completa, porque hacerlo toma tiempo, puede requerir un ambiente de prueba, y no muestra ningún problema... hasta que se hace. El costo de no probarlo es invisible hasta el día en que hace falta de verdad.

Cómo se hace bien

La corrección no elimina la automatización del respaldo; agrega la disciplina de probarlo:

• Calendario de restauraciones probadas. Con una frecuencia definida según el riesgo del sistema, no solo cuando se implementa por primera vez.
• Registro de cada prueba. Qué se restauró, en qué ambiente, cuánto tardó y quién lo verificó.
• Objetivo de tiempo de recuperación explícito. No basta con «se puede restaurar»; se necesita saber en cuántas horas, y si eso es suficiente para la operación del negocio.
• Revisión de lo que falló. Cuando una prueba de restauración encuentra un problema —una carpeta excluida, una contraseña perdida—, ese hallazgo se corrige y se documenta como una mejora del control, no como un incidente que se oculta.

Un ejemplo: la restauración que tardó tres días

Una empresa de manufactura sufre una falla en su servidor principal. El equipo de tecnología confirma, aliviado, que los respaldos corrieron sin problema todas las noches del último mes. El problema aparece al intentar restaurar: la contraseña de cifrado del respaldo la conocía solo una persona que había dejado la empresa dos meses antes, y nadie más la tenía registrada en un lugar seguro. La restauración que debía tomar horas tardó tres días, mientras el área de sistemas reconstruía el acceso por otras vías. El respaldo había corrido en verde cada noche de esos dos meses. Nadie lo había intentado restaurar ni una sola vez.