Cuatro. De más de ochocientas. Ese es el número de intervenciones en las que la empresa atacada llegó cerca del objetivo de recuperación que ella misma tenía escrito —las clásicas 24 o 48 horas—, según el primer informe anual de una firma estadounidense que se dedica a eso y solo a eso. Y ninguna de las más de ochocientas, dice el mismo informe, recuperó su capacidad operativa completa hasta varias semanas después. El número no dice que esas empresas no tuvieran copias. Dice algo peor: que el plan estaba midiendo algo que no era lo que pasó.
De dónde sale el número, y qué no demuestra
Del State of Recoverability 2026 de Fenix24, publicado el 15 de septiembre de 2026. Son datos de campo, no respuestas de encuesta: más de 500 recuperaciones de ransomware y 800 intervenciones con clientes. La frase, traducida, es que «solo cuatro se acercaron al objetivo de tiempo de recuperación de 24 a 48 horas típicamente documentado de antemano» (only four came close to the 24- to 48-hour recovery time objective typically documented in advance).
La muestra está sesgada por definición: son empresas que tuvieron que llamar a un equipo externo de recuperación, los peores días del sector y no una radiografía del tejido empresarial. Y Fenix24 vende recuperación, así que un informe donde casi nadie sabe recuperarse le viene de cara. Las dos cosas empujan el número en la misma dirección.
Dicho eso, el sesgo no da para tanto. Para que un cuatro sobre ochocientas fuera ruido estadístico habría que creer que las empresas que sí cumplen su RTO documentado nunca necesitan ayuda externa, y no es así como va esto: cuando te cifran la producción llamas a alguien aunque tengas el plan impecable. El sesgo explicaría un 30% en vez de un 60%. No explica un 0,5%.
Dos columnas: lo que se declara y lo que se encuentra
El mismo asunto, medido por una encuesta y medido en campo:
Antes de restar: las dos columnas no miden lo mismo ni preguntan a la misma gente. El 60% son organizaciones ya atacadas contándole a un encuestador si su plan de crisis incluye un procedimiento de Active Directory. El 99,2% son los clientes que llegan a una recuperación concreta con un equipo externo delante y la carpeta abierta. La tabla es un contraste de método —declarado frente a observado—, no una resta.
La tentación es leer esto como que la gente miente en las encuestas. Lo que ocurre es que bajo la misma pregunta —¿tenéis un procedimiento de recuperación de identidad?— viven tres preguntas distintas, y solo la tercera sirve de algo: ¿existe un documento?, ¿está donde se puede leer cuando el directorio ya es del atacante? y ¿lo ha ejecutado alguien de principio a fin? La primera se responde que sí con toda la buena fe del mundo. Las otras dos casi nunca se preguntan. Es el mismo mecanismo que ya nos encontramos leyendo el informe de caídas del Uptime Institute: lo que falla no es la ausencia de documentación, es un procedimiento que nadie ha ensayado.
El reloj no empieza en la copia. Empieza en la identidad
Un quinto de las primeras 48 horas de una intervención típica se va en el plano de identidad y en nada más. Levantar una fuente de autenticación lo bastante sana como para poder demostrar que el control es tuyo otra vez. Una, no el directorio entero.
Tiene toda la lógica del mundo cuando lo piensas en orden. Mientras no hay una identidad limpia no se puede autorizar nada: ni montar un repositorio de copias, ni dar acceso a un técnico que llega de fuera, ni aprobar un cambio de emergencia, ni confiar en que la cuenta con la que estás restaurando sea tuya y no suya. La identidad no es un sistema más de la lista. Es la pieza de la que cuelga el permiso para hacer todos los demás. Y es, muy a menudo, de la que cuelga también el servidor de copias: el servidor de copias metido en el dominio es la dependencia circular que convierte un incidente en una semana.
Haz la resta con tu propio número. Si tu RTO escrito son 24 horas y la experiencia de campo dice que un quinto de las primeras 48 —unas nueve horas y media, si se repartieran por igual— se va solo en identidad, el plan no se incumple por lentitud del restore ni por falta de ancho de banda. Se incumple en la primera página, antes de tocar un dato. Y el mismo informe pone el suelo de lo que viene después: reconstruir la infraestructura hasta una viabilidad mínima lleva 72 horas o más.
La copia estaba entera y aun así no sirvió
La inmutabilidad tampoco cierra el problema: en el 38% de las intervenciones en las que las copias sobrevivieron al ataque prácticamente intactas, las copias no pudieron sostener la recuperación igualmente. Los motivos que da son cuatro: demasiado antiguas, incompletas, del tipo equivocado, o más lentas de restaurar que reconstruir el sistema desde cero.
La cuarta es la que más escuece, porque es la única de las cuatro que no se ve mirando la consola de copias. Que restaurar sea más lento que reinstalar es un dato que solo conoces si alguna vez has cronometrado una restauración completa de verdad, con el reloj en la mano y sobre hierro que no es el original. Si nadie lo ha hecho, el número del plan es una estimación que nunca ha pasado por un cronómetro. Sobre de dónde sale ese número cuando se calcula bien, escribimos esto en agosto: cómo se calculan de verdad el RTO y el RPO.
El plan está bien escrito y mide lo que no toca
Aquí entra el segundo informe, que mira lo mismo desde el otro lado. Cohesity publicó el 23 de septiembre de 2026 su Global Cyber Resilience Report, hecho por Vanson Bourne con 3.200 responsables de TI y seguridad de doce países y organizaciones de más de mil empleados, con trabajo de campo en julio de 2026. Su hallazgo principal reencuadra la pregunta: el 78% orienta la recuperación a restaurar sistemas en lugar de a sostener la operación del negocio durante el ataque.
Son dos objetivos distintos y producen dos planes distintos. Uno ordena por sistemas y pregunta ¿cuándo vuelve todo?; el otro ordena por procesos y pregunta ¿qué tiene que seguir funcionando mientras tanto? El informe le pone nombre al segundo: empresa mínima viable, el acotado de lo que debe restaurarse primero para que el negocio no se pare. Lo tiene documentado el 37%. Documentado y probado, el 22%.
La grieta entre el 37 y el 22 es la misma que separaba las dos columnas de la tabla de arriba: muy distinta en tamaño, idéntica en causa. De los que lo documentaron y lo probaron, el 92% dice que influyó en sus prioridades de recuperación —dato autodeclarado, con el matiz de siempre: quien ha hecho el esfuerzo tiende a decir que valió la pena—.
Qué es una empresa mínima viable cuando sois cuarenta
Las definiciones de los informes están pensadas para organizaciones de más de mil empleados, así que conviene bajarlas. En una empresa de cuarenta personas, una empresa mínima viable no es una lista de servidores. Es una lista de cuatro o cinco procesos —facturar, cobrar, entregar lo que vendes, atender al cliente que ya tienes— y, por cada uno, tres cosas: de qué fuente de identidad depende, de qué dato depende y de qué tercero depende.
La primera vez que alguien rellena esa tabla casi siempre pasa lo mismo: la columna de identidad sale idéntica en las cinco filas. Un único inquilino y una única forma de entrar. Eso no está mal por sí solo —es lo razonable de montar— pero significa que los cinco procesos tienen un solo punto de fallo compartido, y que el orden de recuperación no lo decides tú: lo decide esa columna.
Y luego está la parte que nadie quiere escribir, que es la que de verdad define el documento: una empresa mínima viable es, sobre todo, la lista de lo que has decidido NO recuperar primero. Por eso cuesta tanto, y por eso no es un ejercicio técnico: se trata de decidir a quién le vas a decir que espere, y de que esa decisión la tome el dueño del proceso y no el técnico que esté de guardia.
El alcance crece mientras lo estás escribiendo
Un detalle del informe de Cohesity que conviene meter en el diseño desde el principio: entre las organizaciones que llegaron a sufrir un ataque con impacto material, al 70% le creció el perímetro de sistemas afectados por encima de la valoración inicial. El día uno no sabes todavía qué está tocado. Y de ese mismo grupo, el 60% tuvo problemas de identidad y acceso después de restaurar: la misma historia del plano de identidad, contada por una muestra completamente distinta.
La consecuencia práctica es poco intuitiva: el orden de recuperación no se escribe por criticidad, se escribe por dependencia. Un plan ordenado por criticidad —lo más importante primero— se rompe en cuanto el perímetro crece, porque lo más importante resulta depender de algo que aún no sabías que estaba cifrado. Un plan ordenado por dependencia aguanta, porque cada paso solo necesita que esté hecho el anterior.
Y falta la otra mitad, que ya lo contamos hace una semana con los datos de Semperis: recuperar rápido y expulsar al atacante no son la misma tarea, y hacer la primera sin la segunda es firmar el segundo ataque. La empresa mínima viable dice qué levantas primero; no dice que puedas levantarlo antes de saber que la casa es tuya.
Las seis líneas que pedimos antes de hablar de RTO
Es lo que ponemos encima de la mesa en la primera sesión, y cabe en una hoja. No sustituye a un plan de continuidad; sirve para saber si el que tienes mide algo:
- Los cuatro o cinco procesos que, parados una semana, se llevan el año por delante. Con el nombre de la persona que lo afirma, no el del departamento. Si salen doce, no has priorizado: has hecho un inventario.
- De qué fuente de identidad depende cada uno. Si la respuesta es la misma en todas las filas, ese es tu cuello de botella y el primer tramo de tu reloj.
- Para cada proceso, cómo se hace a mano y cuántos días aguanta así. Facturar a mano aguanta unos días; entregar software, no. Si un proceso no tiene modo degradado, escríbelo igualmente: esa respuesta es la que explica tu RTO real.
- Cuánto tardó la última restauración completa que cronometraste. La cronometrada, no la estimada, y sobre hierro distinto del original. Sin ese número no hay RTO.
- Dónde se lee el plan si el directorio ya es del atacante. Papel, otro inquilino, una copia fuera de banda. Un PDF en el SharePoint corporativo no cuenta: vive dentro de lo que se ha caído.
- Y quién autoriza un cambio de emergencia cuando no se puede verificar la identidad de nadie. Hace falta un nombre y un suplente, localizables por un canal que no pase por la red que acaba de caerse.
Las seis se contestan en una sola sesión. La que más tarda es la cuarta, y no porque sea difícil de medir: porque suele ser la primera vez que alguien pregunta si está medida.
Cuándo esto NO es tu problema
Si sois diez personas, todo está en Microsoft 365 y tenéis una aplicación de negocio, no necesitáis un programa de continuidad. Necesitáis tres cosas: una copia que alguien haya restaurado de verdad alguna vez, el teléfono de quien la restaura, y una cuenta de administración de emergencia que no dependa del flujo normal de acceso. Montar ahí un ejercicio formal de empresa mínima viable es papeleo con nombre bonito, y se nota a la primera página.
La cosa cambia cuando hay producción propia, cuando el cliente firma un acuerdo de nivel de servicio o cuando una semana parado te cuesta el contrato del año. Ahí el ejercicio se paga solo. Y lo decimos sabiendo perfectamente que lo segundo es lo que facturamos nosotros: por eso conviene que quede escrito también el caso en el que no hace falta.
Dónde encaja esto en lo que hacemos
Llevamos copias gestionadas con Proxmox Backup Server y Veeam, con la filosofía 3-2-1 y copias inmutables. La parte de nuestro trabajo que más se parece a este artículo es la conversación previa, la de decidir qué tiene que seguir en pie. Eso es cumplimiento y continuidad —el plan, el alcance, el ensayo y la prueba de que existe—, y su otra mitad es disaster recovery, que es la que pone el hierro y los minutos. Si quieres que miremos contigo esas seis líneas sobre tu caso concreto, escríbenos. La cuarta la medimos nosotros si hace falta.
Fuentes. Los datos de campo (cuatro de más de 800 intervenciones cerca del objetivo de 24-48 horas, 99,2% sin plan documentado de recuperación de identidad, un quinto de las primeras 48 horas en el plano de identidad, 72 horas o más hasta la viabilidad mínima de la infraestructura y 38% de copias intactas que no pudieron sostener la recuperación) son del informe The State of Recoverability 2026 de Fenix24, construido sobre más de 500 recuperaciones de ransomware y 800 intervenciones con clientes: nota de prensa del 15 de septiembre de 2026 (el PDF del informe está en fenix24.com, pero su servidor nos devolvió un 403 al intentar descargarlo el 27 de octubre, así que enlazamos solo la nota). Los datos de encuesta (78% que orienta la recuperación a restaurar sistemas, 37% con empresa mínima viable documentada, 22% documentada y probada, 92% de esos que dice que influyó en sus prioridades, 70% con crecimiento del perímetro sobre la valoración inicial y 60% con problemas de identidad y acceso tras restaurar) son del Global Cyber Resilience Report de Cohesity, publicado el 23 de septiembre de 2026, realizado por Vanson Bourne con 3.200 responsables de TI y seguridad de doce países en organizaciones de más de 1.000 empleados, trabajo de campo de julio de 2026. Ojo al denominador: el 70% y el 60% no son del total de la muestra, sino de las organizaciones que sufrieron un ataque con impacto material. El 60% de procedimientos documentados de recuperación de Active Directory es del Ransomware Risk Report 2026 de Semperis (1.200 profesionales de nueve países, todos de organizaciones ya atacadas con éxito), que usamos en el post enlazado del 20 de octubre. Aviso sobre la comparación: las tres fuentes miden poblaciones distintas —intervenciones de recuperación, grandes organizaciones y víctimas de ransomware— y dos de las tres son de fabricantes que venden en este mercado; los porcentajes no son directamente comparables entre sí y la tabla de dos columnas se ofrece como contraste de método (declarado frente a observado), no como una resta. Las nueve horas y media del cálculo son nuestras: salen de aplicar el quinto de 48 horas que publica Fenix24, que no da esa cifra en horas. Lo nuestro —las seis líneas, el criterio de ordenar por dependencia en vez de por criticidad y el caso en el que no hace falta el ejercicio— es nuestra forma de trabajar, no una recomendación de ninguno de los informes citados. Foto: «EmergencyPowerGenerator.jpg» de Raysonho @ Open Grid Scheduler / Grid Engine, Wikimedia Commons, CC0 1.0, recortada por nosotros.
Microsoft 365
ES 
CAT 
EN