Cómo crear un plan de recuperación ante ransomware que funcione de verdad

La mayoría de los planes de recuperación ante ransomware son un PDF que nadie ha abierto desde el día en que se escribió. Se leen bien en una revisión de cumplimiento y luego se derrumban la primera vez que un atacante real toca producción. Un plan que funciona es diferente: está ensayado, es medible y es aburrido, porque cada paso ya se ha probado bajo presión.

Esta guía explica cómo crear ese tipo de plan en 2026, cuando los atacantes roban los datos antes de cifrarlos y tus copias de seguridad son lo primero que van a buscar.

Por qué fallan la mayoría de los planes de recuperación

El fallo rara vez se debe a una herramienta que falta. Casi siempre se reduce a una de estas tres carencias.

• Restauraciones no probadas. Los equipos hacen copias de seguridad religiosamente y nunca ejecutan una sola restauración completa. Cuando por fin lo intentan, la copia está corrupta, incompleta o tarda cuatro días en rehidratarse.
• Copias de seguridad accesibles. Si tu sistema de copias usa las mismas credenciales, la misma red y la misma consola de administración que producción, un atacante que controla el dominio también controla tus copias. Los grupos de ransomware modernos borran o cifran primero las copias de seguridad y luego detonan.
• Sin responsable de decisión. En la segunda hora de un incidente, alguien tiene que decidir si aislar toda la red, si pagar y quién habla con los clientes. Si esa persona no está designada de antemano, las primeras horas se pierden discutiendo.

Un plan de recuperación no es una política de copias de seguridad. Es un manual operativo que parte de que la prevención ya falló y plantea una pregunta más difícil: cómo volver a poner el negocio en marcha, de forma segura, y con qué rapidez.

Define tus objetivos de recuperación antes que nada

Dos cifras determinan todas las demás decisiones. Acuérdalas con la dirección, no solo con TI.

• Objetivo de tiempo de recuperación (RTO): cuánto tiempo puede tolerar el negocio que un sistema determinado esté caído. Un pago de comercio electrónico podría ser de 1 hora. Un wiki interno podría ser de 3 días.
• Objetivo de punto de recuperación (RPO): cuántos datos puedes permitirte perder, medidos en tiempo. Un libro mayor de pagos podría ser de 5 minutos. Un sitio de marketing podría ser de 24 horas.

Son decisiones de negocio con compensaciones de coste. Un RPO de 5 minutos para cada sistema es técnicamente posible y financieramente absurdo. Según nuestra experiencia, el ejercicio útil es escalonar por niveles: clasifica los sistemas en tres o cuatro niveles, asigna a cada uno un RTO y un RPO, y diseña la frecuencia de las copias y la infraestructura en consecuencia. El nivel 1 recibe replicación continua e instantáneas inmutables. El nivel 4 se conforma con una copia nocturna y nadie entra en pánico si tiene un día de antigüedad.

La arquitectura de copias que sobrevive a un ataque

La antigua regla del 3-2-1 (tres copias, dos tipos de medios, una fuera del sitio) sigue siendo el mínimo, pero los ataques de 2026 exigen más. Apunta al 3-2-1-1-0.

• 3 copias de tus datos.
• 2 tipos de almacenamiento diferentes.
• 1 copia fuera del sitio.
• 1 copia inmutable o aislada físicamente (air-gapped), de modo que no pueda alterarse ni borrarse ni siquiera por un administrador de dominio.
• 0 errores, verificado mediante pruebas de restauración periódicas.

La copia inmutable es lo que te salva. El bloqueo de objetos en almacenamiento en la nube, las instantáneas de escritura única o una copia genuinamente sin conexión funcionan todos. La propiedad clave es que las credenciales que ejecutan producción no pueden borrarla. Si un atacante con control total del dominio sigue sin poder tocar esa copia, tienes una vía de recuperación. Si puede, tienes una falsa sensación de seguridad.

Importan dos decisiones de diseño más. Primero, mantén el catálogo de copias y el plano de gestión en una infraestructura de identidad separada, idealmente un proveedor de identidad separado o, como mínimo, cuentas privilegiadas separadas con claves de hardware. Aquí es donde una arquitectura zero trust más amplia rinde frutos directamente, porque elimina la red plana y de confianza que permite que un solo portátil comprometido llegue a todo. Segundo, conserva suficiente historial. Los atacantes suelen permanecer en una red durante semanas antes de detonar, de modo que una copia de hace tres días puede contener ya su punto de apoyo. Conserva puntos de restauración que se remonten lo suficiente como para encontrar uno limpio.

Crea el manual operativo, no solo la política

Un manual operativo es una secuencia de acciones concretas que una persona cansada puede seguir a las 3 de la madrugada. Escríbelo para quien no diseñó el sistema. Aquí tienes un esqueleto probado en el campo que puedes adaptar.

1. Detectar y declarar. Define qué desencadena un incidente de ransomware (cambios masivos de archivos, nota de rescate, alerta de EDR) y quién tiene la autoridad para declararlo formalmente. Declarar pronto casi siempre es lo correcto.
2. Aislar, no apagar. Desconecta los segmentos afectados de la red para detener la propagación, pero evita cortar la alimentación de las máquinas infectadas, porque la memoria volátil contiene evidencias y a veces claves de descifrado. Aísla las copias de seguridad de inmediato para que no puedan alcanzarse.
3. Reunir al equipo de respuesta. Roles con nombre: comandante de incidentes, responsable técnico, responsable de comunicación y contacto jurídico o de cumplimiento. Una persona por rol, más un suplente designado para cada uno.
4. Evaluar el alcance. Qué sistemas están cifrados, a qué datos se accedió o se exfiltraron y a qué nivel pertenece cada sistema. La exfiltración importa desde el punto de vista legal aunque restaures a la perfección.
5. Contener la causa raíz. Identifica y cierra el punto de entrada (phishing, RDP expuesto, VPN sin parchear) antes de restaurar, o simplemente volverás a infectarte. Aquí es donde una prueba de penetración previa demuestra su valor, porque ya conoces tus puntos débiles.
6. Restaurar desde un punto limpio verificado. Empieza por los sistemas de nivel 1. Restaura en un entorno reconstruido y parcheado, no en el comprometido. Valida la integridad antes de reconectar.
7. Rotar todos los secretos. Da por hecho que todas las contraseñas, claves de API y tokens están comprometidos. Rota credenciales, certificados y cuentas de servicio en todos los ámbitos.
8. Reconectar por etapas. Devuelve los sistemas al servicio nivel por nivel, vigilando de cerca las señales de persistencia o reinfección.
9. Comunicar. Notifica a clientes, reguladores y personal conforme a tus obligaciones legales y a tus plantillas redactadas de antemano. El silencio daña la confianza más rápido que la interrupción.
10. Analizar tras el incidente. En un plazo de dos semanas, realiza una revisión posterior al incidente sin culpables y reincorpora cada lección aprendida al plan.

Imprime este manual operativo. Guarda una copia en papel y una copia digital sin conexión, porque si tus servidores de archivos están cifrados, un manual almacenado solo en ellos también habrá desaparecido.

La parte que todos se saltan: las pruebas

Un plan que no has probado es una hipótesis. Conviértelo en hecho con tres niveles de ejercicio.

• Simulacros de restauración (mensuales). Elige una copia de seguridad al azar y restáurala de principio a fin. Mide cuánto tardó y si los datos estaban intactos. Sigue esa tendencia con el tiempo.
• Ejercicios de mesa (trimestrales). Guía verbalmente al equipo de respuesta a través de un escenario realista. Sin tocar ningún sistema, solo decisiones. Estos ejercicios revelan a bajo coste las carencias del tipo "¿quién decide?".
• Simulación completa de conmutación por error (anual). Recupera realmente un sistema crítico en un entorno aislado bajo presión de tiempo. Es la única prueba que valida tu RTO real.

La métrica que importa no es "¿tenemos copias de seguridad?". Es "¿cuántos minutos tardó nuestra última restauración completa del sistema de pagos y estuvo limpia?". Si no puedes responder a eso con una cifra reciente, tu plan no está probado.

Pagar o no pagar

Esta es una decisión de negocio y legal, no técnica, y debe decidirse de antemano. Pagar no es una estrategia de recuperación: los descifradores suelen ser lentos o defectuosos, pagar te marca como un objetivo dispuesto y, en algunas jurisdicciones, los pagos a grupos sancionados son ilegales. La posición más sólida es aquella en la que nunca tienes que planteártelo, porque cuentas con una copia de seguridad limpia e inmutable y una vía de restauración probada. Construye hacia esa posición en lugar de presupuestar un rescate.

Cómo puede ayudar Innovation T

La resiliencia ante el ransomware no es un producto que se compra una vez. Es una arquitectura y un hábito. En Innovation T, nuestros ingenieros de nube y seguridad ayudan a los equipos a diseñar sistemas de copias con verdadera inmutabilidad, a escalonar sus sistemas frente a objetivos de RTO y RPO de negocio reales, y a convertir una política que acumula polvo en un manual operativo que el equipo ha ensayado de verdad. Ejecutamos los ejercicios de mesa, construimos la automatización de la restauración y validamos que una recuperación limpia funciona realmente antes de que un atacante fuerce la prueba.

Si tu última restauración completa fue una hipótesis y no un hecho medido, esa es la carencia que conviene cerrar primero. Explora nuestros servicios para ver cómo abordamos la resiliencia en la nube, la ingeniería de seguridad y la consultoría de TI, o ponte en contacto para repasar tu postura de recuperación actual. El mejor momento para probar tu plan es un martes tranquilo, no la mañana en que aparece la nota de rescate.