Hay un dato en el informe anual de ransomware de Sophos que en cualquier otro año habríamos celebrado sin matices: el 66% de las organizaciones a las que les cifraron datos recuperó desde sus copias de seguridad, doce puntos más que el año pasado. Es un rebote fuerte: en 2025 fue del 54%, el nivel más bajo en seis años según el propio informe. Justo al lado hay otro: el 48% pagó el rescate. Y un tercero que se lleva la discusión por delante: el coste medio de recuperarse subió un 11% hasta 1,7 millones de dólares, sin contar el rescate.
La lectura fácil es que los tres números se contradicen. Cuentan la misma historia desde tres ángulos, y es una historia que nos toca de cerca: la copia de seguridad, como pieza técnica, ha recuperado casi todo el terreno que perdió el año pasado. Alrededor de ella sigue habiendo el mismo desorden de siempre. Restaurar un volumen y recuperar una empresa son dos trabajos distintos, y solo uno de los dos aparece en el informe de estado del backup de anoche.
De dónde salen los números
Conviene saber qué se está leyendo antes de discutirlo. El estudio lo encarga Sophos y lo hace Vanson Bourne en el primer trimestre de 2026: 2.158 responsables de IT y de seguridad de organizaciones de entre 100 y 5.000 empleados, en 17 países —España entre ellos—, de quince sectores, y todas ellas víctimas de ransomware en los doce meses anteriores. Es una encuesta a víctimas, no una radiografía del mercado: los porcentajes hablan de a quién le pasó, no de la probabilidad de que te pase. Con esa cautela puesta, estas son las cifras que importan:
Quién restauró y pagó a la vez
El titular que circula estos días es que «las copias ganan la partida». Ojalá. Los dos porcentajes se calculan sobre la misma base, las víctimas a las que cifraron datos, así que 66 más 48 no caben en 100: al menos catorce de cada cien restauraron y pagaron. El informe no dice por qué, así que lo que viene es lectura nuestra. Hay explicaciones mecánicas —el descifrado parecía más rápido que la restauración, o la copia cubría unos sistemas y no otros—, y hay una que vemos más a menudo: el rescate no siempre se paga para recuperar los datos, sino para que no se publiquen.
Ya escribimos sobre esto hace unos días a cuenta de una campaña que ni siquiera se molesta en cifrar: tu copia devuelve el servicio, no la confidencialidad. Ningún backup deshace una filtración. El informe pone número a esa frontera — el 16% de las víctimas sufrió cifrado y robo a la vez—, y ese 16% es la parte más visible del problema para la que restaurar no sirve de nada, porque los robos sin cifrado ni siquiera entran en esa cuenta.
Un apunte de método, porque es fácil leerlo mal: la mediana de la petición fue de 698.000 dólares y la mediana del pago, de 769.000. Parece que la gente pagó más de lo que le pedían, y no es eso: son dos poblaciones distintas —todas las víctimas frente a solo quienes pagaron—, y quien acaba pagando suele ser quien recibió la petición más grande. Con el mismo informe diciendo que el 51% de los que pagaron negoció por debajo de la petición inicial, la conclusión honesta es la contraria: se negocia a la baja, pero los que pagan parten de cifras más altas.
El rescate baja y la factura sube
Esta es, para nosotros, la línea más importante del informe: la mediana de las peticiones de rescate ha caído un 65% en dos años y el coste medio de recuperación ha subido un 11% hasta 1,7 millones de dólares por incidente. Las dos curvas van en direcciones opuestas. Lo que se abarata es la parte que sale en los titulares; lo que se encarece es la parte que pagas tú aunque no negocies con nadie.
Y dentro de ese millón setecientos mil no hay ninguna criptomoneda. Hay horas de gente propia y de gente de fuera, hierro comprado con prisa, licencias de emergencia, forense para poder decir con seguridad qué se llevaron, semanas de trabajo manual reintroduciendo lo que se perdió entre la última copia buena y el cifrado, abogados, comunicación y clientes que llaman preguntando por qué su pedido no avanza. Nada de eso lo evita una restauración rápida. Todo eso lo reduce, y mucho, haber decidido antes en qué orden vuelve cada cosa.
«Una semana» suena rápido hasta que la pones en tu calendario
El 55% se recuperó en una semana o menos y solo el 16% en menos de un día. Dicho al revés, que es como hay que decirlo: el 45% tardó más de una semana, y el 84% tardó más de un día. Ahora coge tu propio calendario y tacha cinco días laborables seguidos. Sin facturar, sin producción, sin ERP, con el correo a medias y con toda la plantilla haciendo lo que puede en papel o en hojas de cálculo. Esa es la unidad de medida real de un plan de continuidad, y no cabe en ningún SLA de tu proveedor de copias.
Lo decíamos hace diez días a cuenta de una caída de AWS y vale igual aquí: el tiempo de recuperación no es una propiedad del backup, es una propiedad del sistema entero. Depende de cuántas máquinas hay que levantar y en qué orden, de si el directorio y el DNS vuelven antes que las aplicaciones que dependen de ellos, de cuántos megabytes por segundo saca de verdad tu almacenamiento de copias cuando restauras diez servidores a la vez en lugar de uno, y de si alguien puede afirmar sin cruzar los dedos que la máquina que acabas de devolver a la red está limpia.
El 97% tenía MFA
La otra mitad del informe explica por qué esto sigue pasando, y ahí hay un vuelco: por primera vez en cuatro años las vulnerabilidades explotadas ya no son la vía de entrada principal —caen al 18%, catorce puntos menos que el año anterior— y el 79% de los ataques arranca en una identidad. El correo malicioso (26%) y el phishing (24%) suman por sí solos la mitad de todos los incidentes. El atacante ha dejado de forzar la ventana porque tiene la llave de la puerta.
El dato que debería quitar el sueño está una línea más abajo: en el 97% de los incidentes cuya causa raíz fueron credenciales comprometidas, la organización tenía MFA desplegado de alguna forma. Ese «de alguna forma» es del propio informe, y es donde caben todas las excepciones cómodas: el usuario de servicio heredado, el protocolo antiguo que nadie se atreve a cortar, el portal que quedó fuera de la política, el segundo factor por SMS que un atacante intercepta o simplemente pide por teléfono. Sobre ese último punto ya escribimos cuando Microsoft anunció la retirada del SMS como segundo factor. Un MFA con excepciones no es un MFA: es un inventario de excepciones.
Esto tiene una consecuencia directa en el diseño de las copias, y es la razón por la que lo metemos en un post sobre recuperación: si el atacante entra con credenciales legítimas, entra con permisos. Un backup accesible con las mismas credenciales de administración que el resto del entorno no es una copia de seguridad, es otro sistema más dentro del radio de explosión. Lo vimos con todas las letras en el borrado del registro de la propiedad de Rumanía: el atacante no rompió nada, se autenticó.
Las cinco cosas que hay que cronometrar antes del día malo
Operamos copias con Proxmox Backup Server y con Veeam, con la disciplina de siempre —tres copias, dos soportes, una fuera; al menos una inmutable—, y llevamos años viendo la misma escena: el backup está verde y nadie sabe cuánto tarda la vuelta. Por eso una prueba de restauración que sirva no consiste en abrir un fichero y dar por bueno el trabajo. Estas son las cinco cosas que hay que cronometrar, y las cinco dan sorpresas la primera vez:
- ✓El orden, antes que la velocidad. Qué vuelve primero y qué depende de qué. Si el directorio, el DNS y el DHCP no están arriba, todo lo demás restaura bien y arranca mal. El inventario que mantenemos en
NetBoxnos da las máquinas y el direccionamiento; el orden de arranque hay que escribirlo aparte, y escribirlo antes. - ✓El caudal real, restaurando en paralelo. Una restauración va a la velocidad del eslabón más lento —repositorio, red, disco de destino— y ese número solo aparece cuando restauras varias máquinas a la vez. Extrapolar desde una sola VM es la forma más habitual de prometer un plazo que no se cumple.
- ✓La prueba, en las condiciones del día malo. Si el escenario es que el atacante tiene el dominio, se ensaya como se hará ese día: cuenta de emergencia separada, fuera del directorio comprometido, y la copia inmutable como origen. Y eligiendo el punto de restauración que elegirás de verdad, porque la copia de anoche puede estar dentro del incidente: saber a qué fecha se puede volver exige retención suficiente y saber cuándo empezó todo, que es trabajo de detección y no de backup.
- ✓Quién dice que la máquina está limpia. Devolver a producción un servidor restaurado sin nadie mirando qué se ejecuta en él es la vía rápida al segundo cifrado. Aquí es donde el EDR/MDR gestionado se gana la cuota: menos por bloquear que por poder afirmarlo con registros delante.
- ✓El trabajo humano de después. Entre el último punto bueno y el incidente hay pedidos, albaranes y asientos que alguien tendrá que volver a meter a mano. Ese plazo lo decide negocio, no IT, y es la parte del plan que casi nunca está escrita.
Las cinco se resuelven dedicándoles una tarde al trimestre, con el cronómetro en marcha y con alguien apuntando los tiempos en un documento que luego se pueda enseñar. Ese documento es, literalmente, tu plan de continuidad; el resto es una carpeta de copias.
Lo que nos llevamos de este informe
El informe de este año trae buenas noticias sobre las copias y malas sobre todo lo demás, y esa combinación es exactamente la que veíamos venir: la industria ha vuelto a resolver razonablemente el problema de tener el dato y sigue sin resolver el de volver a operar. Por eso el rescate baja y la factura sube. Si el año que viene quieres estar en el 16% que se recupera en menos de un día en lugar de en el 45% que tarda más de una semana, la diferencia no va a estar en el software de copias que compres este otoño: va a estar en cuántas veces hayas cronometrado la vuelta antes de necesitarla.
Fuentes (verificadas): todas las cifras proceden de The State of Ransomware 2026 de Sophos, séptima edición del estudio, realizado por Vanson Bourne en el primer trimestre de 2026 con 2.158 responsables de IT y seguridad de organizaciones de 100 a 5.000 empleados en 17 países (España incluida) y quince sectores, todas víctimas de ransomware en los doce meses previos. Datos concretos —79% de ataques originados en identidades comprometidas, 26% correo malicioso y 24% phishing, 18% vulnerabilidades explotadas, 97% de los incidentes por credenciales comprometidas con MFA desplegado, 56% de cifrado con un 16% de cifrado más robo, 48% de pago entre las víctimas cifradas, 51% que negoció por debajo de la petición inicial, mediana de petición 698.000 $ y de pago 769.000 $, caída del 65% de las medianas de petición en dos años, coste medio de recuperación de 1,7 M$ por incidente (+11%), 55% recuperado en una semana y 16% en menos de un día— publicados en la nota de prensa oficial de Sophos y en el resumen del informe (el 66% de recuperación desde copias, doce puntos más que en 2025, y el 11% de subida del coste de recuperación salen de este último). El 54% de 2025 y su condición de nivel más bajo en seis años están en la edición anterior del mismo informe: por eso hablamos de rebote y no de récord. Son lectura nuestra, y no del informe: la advertencia sobre las dos medianas (petición y pago se calculan sobre poblaciones distintas y no permiten concluir que se pagara por encima de lo pedido), el solape mínimo de catorce puntos entre quienes restauraron y quienes pagaron —y las razones que le atribuimos, que el informe no explica—, la lectura invertida del dato de recuperación (45% por encima de la semana, 84% por encima del día) y las cinco cosas que conviene cronometrar en una prueba de restauración.
¿Sabes cuánto tarda tu vuelta atrás, con cronómetro?
En everyWAN diseñamos y operamos planes de disaster recovery y copias gestionadas con Proxmox Backup Server y Veeam, con copias inmutables y con el plan de vuelta atrás escrito y probado. No vendemos licencias de una plataforma concreta: montamos el plan que se sostiene el día malo, y te decimos qué parte del tuyo no aguanta.
Hablar con everyWAN
Microsoft 365
ES 
CAT 
EN