Según el informe O Estado do Ransomware no Brasil 2026, de Sophos, publicado en julio de 2026 con 71 empresas brasileñas afectadas por un secuestro de datos, el 58% de ellas volvió a operar en una semana o menos. Otro 18% tardó entre uno y seis meses. La copia de seguridad existía en los dos grupos: el 85% la usó para recuperar los archivos cifrados. Lo que separó a las que volvieron rápido de las que quedaron meses paradas no fue tener backup. Fue cuánto tiempo tomó traer ese backup de vuelta.
Esto no es solo sobre ataques. Un disco que muere, un servidor que no enciende más, alguien que borra la carpeta equivocada: cualquiera de estos motivos pone a la empresa en la misma fila: buscar la copia, traer de vuelta el volumen de datos, reinstalar lo necesario, verificar que todo esté correcto antes de liberar el uso. El incidente cambia; la cuenta de tiempo es la misma.
Para quien decide, esa cuenta suele aparecer en el peor momento. La empresa sabe que tiene backup y asume que "volver" es cuestión de minutos, como abrir un archivo. Nadie midió cuánto tiempo lleva de verdad, hasta que alguien tiene que medirlo bajo presión, con la operación parada y una pérdida que crece cada hora.
Cuánto tiempo lleva de verdad
En el informe global de Sophos, el tiempo promedio para que una empresa se recupere totalmente de un ataque de secuestro de datos fue de tres semanas, el mismo nivel que el año anterior, pero por debajo de las cinco semanas registradas en 2024. Mirando la distribución: el 55% de las empresas volvió a operar en una semana o menos (el 16% en menos de un día), el 83% en un mes o menos, y solo el 3% tardó más de tres meses.
Ese promedio de tres semanas esconde una variación grande, y no es cuestión de suerte: depende del volumen de datos que hay que traer de vuelta y de la velocidad con que puede circular. Traer de vuelta algunos gigabytes por una conexión común es cuestión de minutos. Traer algunos terabytes por esa misma conexión —la que la empresa usa todos los días para correo y navegación, no una línea dedicada a mover un volumen grande— puede tomar horas solo en la descarga, antes de que cualquier sistema vuelva a funcionar.
Dónde está guardada la copia también entra en esa cuenta. Una copia dentro del edificio suele volver más rápido, porque no depende del enlace a internet. Una copia en la nube es más segura ante un incendio o un robo en el local, pero traer de vuelta un volumen grande de ella depende por completo de la velocidad de bajada de esa conexión, y la mayoría de los enlaces empresariales se contrató pensando en el uso diario, no en traer terabytes de una sola vez.
Después de que el dato llega, el reloj no se detiene. Todavía falta reinstalar el sistema cuando el equipo también tuvo que reemplazarse, reconectar cada software con lo que integra, reactivar licencias y verificar que cada información volvió íntegra antes de liberarla al equipo de trabajo. En qué orden vuelve cada sistema es otra decisión, importante, pero es tema para otro día; aquí lo que importa es que cada una de esas etapas consume tiempo real, medido en horas, no en minutos.
El costo promedio para que una empresa brasileña se recupere de un ataque de secuestro de datos, sin contar un eventual rescate pagado, fue de US$ 1,05 millones en 2026, según la misma encuesta de Sophos: tiempo de inactividad, horas de personal, equipos, red y oportunidades perdidas sumados. Cuanto más largo el plazo de restauración, más crece esa cuenta.
Por qué la forma habitual no resuelve
La forma habitual es configurar el backup, ver que corre todas las noches sin error, y detenerse ahí. La copia existe, está íntegra, el informe de la noche anterior muestra éxito, y la empresa concluye, sin haberlo probado nunca, que "restaurar" es cuestión de apretar un botón.
Solo que nadie cronometró cuánto tiempo lleva traer de vuelta un volumen real de datos por la conexión real que tiene la empresa. El número que la dirección imagina —"algunas horas", "un día como máximo"— nunca se midió; se calculó por optimismo. Descubrir que el plazo real es de días, no de horas, en medio de una operación parada, es el peor momento posible para esa sorpresa.
Otra versión del mismo problema es guardar la copia solo donde es más barato almacenar, sin preguntar cuánto tiempo tomaría traerla de vuelta desde ahí. Almacenamiento y velocidad de restauración son cosas distintas: un lugar puede ser excelente para guardar y pésimo para devolver rápido un volumen grande.
Lo que tiene que existir en la práctica
Un entorno preparado para ese momento trata el tiempo de restauración como un número medido, no como una suposición.
Un simulacro de restauración cronometrado, no solo una copia que "corre sin error". Es la única forma de saber cuántas horas —o días— tarda en volver el volumen real de datos de la empresa por su conexión real.
Un plan que diga, por escrito, en cuánto tiempo la empresa vuelve a operar. No una esperanza verbal repetida en una reunión, un número que sobrevivió a una prueba.
Conexión y capacidad dimensionadas para el volumen de hoy, no para el volumen de cuando se configuró el backup: la empresa crece, su volumen de datos crece con ella, y el enlace muchas veces se queda atrás.
Más de un lugar guardando la copia, con al menos uno fuera del local físico de la empresa, equilibrando la protección contra incendio o robo con la velocidad de traer el dato de vuelta cuando haga falta.
Un responsable y un instructivo escritos para la restauración, en vez de depender de una persona que "sabe hacerlo" de memoria y puede estar de vacaciones el día de la falla.
Así es como trabaja Skills IT: con simulacros periódicos de recuperación y un plan que registra, por escrito, cuánto tiempo lleva de verdad una restauración.
La ganancia para la empresa
La ganancia de medir ese plazo antes no es que el desastre nunca ocurra: es que la empresa deja de improvisar durante él. Cuando el tiempo de restauración ya es un número conocido, quien decide sabe si ese plazo es aceptable para el negocio o si conviene invertir en un enlace mejor, en una copia local además de la que está en la nube, o en un plan de contingencia para operar de otra forma mientras los datos regresan.
Las organizaciones que mantuvieron sistemas de backup robustos recuperaron datos cifrados a tasas casi récord en el último año.
Sin ese número medido, cada decisión durante la falla se toma a ciegas: prometerle al cliente un plazo que nadie verificó, decidir en el momento si conviene esperar o migrar a otra estructura, calcular de memoria cuánto cuesta cada hora parada. Con el número en la mano, la misma decisión se toma en minutos, y el equipo de operación queda libre para trabajar en vez de intentar adivinar cuánto falta.
También es dinero: cuanto antes la empresa conozca el plazo real, antes podrá comparar ese costo con el de invertir en un enlace más rápido o en una segunda copia más accesible, una cuenta que sale más barata fuera de la presión del incidente que en medio de él.
Preguntas para llevar a la próxima reunión
- ¿Alguien ya cronometró una restauración completa, con el volumen de datos que la empresa tiene hoy? Si la respuesta es "nunca lo probamos", el plazo que todos imaginan es una suposición.
- ¿La conexión usada para restaurar soporta ese volumen, o es la misma que atiende el correo y la navegación del día a día? Enviar un adjunto es una cosa; traer de vuelta terabytes es otra.
- ¿Existe más de una copia, en lugares distintos, o todo depende de un único punto? Un incendio o un robo en el local no puede ser el fin de la única copia que existía.
- ¿El plazo de restauración está escrito en algún lugar, o solo en la cabeza de quien hoy se ocupa de la TI? Si esa persona sale de vacaciones o cambia de trabajo, el número no puede irse con ella.
- Si la peor falla ocurriera mañana, ¿la empresa sabe en cuántos días —no en cuántas horas de optimismo— estaría de vuelta? Esa es la pregunta que vale la pena responder antes, no durante.
