A las 8:17, el equipo de administración intenta abrir el ERP y solo ve una nota de rescate. A las 8:25, alguien propone apagarlo todo. A las 8:32, dirección pide una respuesta inmediata. En ese momento, tener un ejemplo de respuesta a incidente ransomware deja de ser un documento de cumplimiento y pasa a ser una herramienta para proteger operación, dinero y reputación.
Para una pyme, el problema no es solo el cifrado. El verdadero riesgo aparece cuando cada área actúa por su cuenta: sistemas desconecta sin preservar evidencias, finanzas pregunta si conviene pagar, dirección quiere comunicar algo rápido y legal pide datos que nadie ha confirmado. Una respuesta eficaz no depende de improvisar rápido, sino de seguir un criterio claro bajo presión.
Qué debe cubrir un ejemplo de respuesta a incidente ransomware
Un buen modelo de respuesta no es una lista genérica de tareas. Debe ordenar decisiones en el momento en que la empresa tiene menos claridad. Eso implica definir quién decide, qué sistemas se priorizan, cómo se confirma el alcance y qué condiciones deben cumplirse antes de volver a operar.
También debe asumir una realidad incómoda: no todos los incidentes de ransomware son iguales. A veces el atacante solo cifra archivos. Otras veces roba información antes de cifrarla y añade presión con amenaza de filtración. En algunos casos, la infección se limita a un equipo. En otros, compromete credenciales, servidores, copias de seguridad y servicios críticos. Por eso un ejemplo útil no promete recetas absolutas. Ofrece una secuencia de actuación adaptable.
Ejemplo de respuesta a incidente ransomware paso a paso
1. Confirmación inicial del incidente
La primera hora no debería usarse para adivinar. Hay que confirmar si se trata realmente de ransomware, qué síntomas existen y qué activos parecen afectados. La evidencia típica incluye archivos renombrados o cifrados, notas de rescate, procesos inusuales, cuentas ejecutando acciones anómalas y fallos simultáneos en varios equipos o servidores.
En esta fase conviene nombrar un responsable del incidente. No hace falta una estructura compleja, pero sí una voz de coordinación. Si cinco personas deciden a la vez, la contención suele empeorar.
2. Contención inmediata sin destruir evidencias
Aquí aparece uno de los errores más comunes: apagar sistemas de forma masiva. A veces es necesario aislar, pero no siempre conviene cortar todo sin criterio. Lo prioritario es impedir la propagación. Eso suele implicar desconectar de la red los equipos comprometidos, deshabilitar accesos remotos sospechosos, bloquear cuentas afectadas y segmentar sistemas críticos si aún no muestran indicios.
La diferencia entre aislar y apagar importa. Un servidor encendido puede conservar rastros valiosos para entender el vector de acceso, el movimiento lateral y la persistencia. Si se apaga sin análisis, se pierde contexto. Dicho esto, si el cifrado sigue activo y amenaza sistemas esenciales, el corte inmediato puede estar justificado. Depende de la velocidad del ataque y de la visibilidad disponible.
3. Activación del comité de respuesta
Dirección, TI, seguridad, legal y comunicación deben alinearse pronto, aunque sea con un grupo reducido. No se trata de convocar una reunión larga, sino de acordar tres cosas: alcance provisional, impacto en operación y siguiente ventana de decisión.
En una pyme, este punto suele resolverse con pragmatismo. La misma persona puede cubrir varias funciones. Lo importante es que alguien gestione lo técnico, alguien valide decisiones de negocio y alguien controle la comunicación interna y externa. Si hay proveedor de TI o ciberseguridad, este es el momento de integrarlo, no cuando el daño ya se extendió.
4. Preservación de evidencias
Antes de limpiar o restaurar, hay que recoger información básica: equipos afectados, usuarios comprometidos, hora estimada de inicio, registros disponibles, nota de rescate, extensiones de archivos alteradas y cambios recientes en privilegios o accesos. Si la empresa cuenta con EDR, SIEM o copias de logs, deben asegurarse de inmediato.
Este paso suele parecer secundario cuando la operación está detenida, pero tiene dos ventajas prácticas. La primera es facilitar el análisis forense y evitar reinfecciones. La segunda es preparar a la empresa ante posibles obligaciones legales o contractuales si hubo exfiltración de datos.
5. Evaluación de impacto real
No basta con saber qué está caído. Hay que saber qué duele más. Un incidente puede afectar veinte equipos y apenas rozar la operación, o comprometer un solo servidor y paralizar facturación, inventario o atención al cliente.
Conviene clasificar el impacto en cuatro frentes: operación crítica, datos sensibles, alcance técnico y dependencia de terceros. Si el ransomware alcanzó compartidos de red pero no sistemas financieros, la prioridad cambia. Si también tocó respaldos o credenciales de administrador, el incidente entra en otra dimensión y la recuperación será más lenta.
Qué hacer con el rescate
Esta es la pregunta que más presión genera y la que peor se responde en caliente. Pagar no garantiza recuperación, ni evita una filtración posterior, ni impide que la organización vuelva a ser objetivo. Además, puede introducir riesgos legales y financieros adicionales.
Eso no significa que la decisión sea trivial. Hay empresas que evalúan el pago cuando no tienen respaldos viables, el tiempo de parada compromete su continuidad y la información es irremplazable. Aun así, esa decisión debe tomarse con asesoramiento técnico y legal, entendiendo que pagar es una apuesta, no una solución fiable.
Desde una perspectiva operativa, el foco debería estar en verificar si existen copias íntegras, sistemas alternos, capacidad de reconstrucción y trazabilidad del acceso inicial. Si esos elementos existen, la recuperación controlada suele ser mejor camino que negociar bajo presión.
Recuperación: restaurar no es volver a encender
6. Erradicación antes de restauración
Recuperar demasiado pronto es una forma común de reinfectarse. Antes de restaurar datos o reactivar servicios, debe confirmarse que el vector de entrada está cerrado. Eso puede implicar parchear vulnerabilidades, cambiar credenciales privilegiadas, revocar sesiones activas, revisar políticas de acceso remoto y eliminar mecanismos de persistencia.
Si la intrusión se produjo por credenciales comprometidas, restaurar el servidor sin rotar contraseñas solo devuelve el problema a producción. Si entraron por RDP expuesto o por un firewall mal configurado, el sistema seguirá abierto aunque los archivos vuelvan desde copia.
7. Restauración por prioridades
La recuperación debe seguir el orden del negocio, no el del organigrama. Primero los servicios que sostienen ingresos, operaciones y atención al cliente. Después, los sistemas de soporte y, por último, los equipos individuales menos críticos.
Aquí las copias de seguridad marcan la diferencia entre un incidente grave y una crisis prolongada. Pero no basta con tener backups. Deben ser verificables, estar aislados y permitir restauraciones limpias. Muchas empresas descubren demasiado tarde que sus respaldos también fueron cifrados o que nunca probaron una recuperación completa.
8. Monitorización reforzada tras la vuelta
Cuando los sistemas regresan, el incidente no ha terminado. Las siguientes horas y días requieren vigilancia intensiva. Hay que revisar intentos de autenticación, creación de cuentas, tráfico extraño, tareas programadas, servicios nuevos y actividad en endpoints restaurados.
En esta etapa conviene ser conservador. Es preferible volver por fases que reactivar toda la operación en bloque. La presión del negocio existe, pero una segunda caída suele costar más que una recuperación gradual.
Un modelo breve de respuesta para una pyme
Si una pyme necesita un marco claro, este ejemplo de respuesta a incidente ransomware puede funcionar como base operativa: confirmar el incidente, aislar sin perder evidencias, activar responsables, preservar registros, medir impacto, decidir comunicación, erradicar el acceso inicial, restaurar por prioridades y mantener supervisión reforzada.
Parece lineal, pero en la práctica varias fases se solapan. Mientras un equipo contiene, otro evalúa impacto y dirección prepara mensajes internos. Esa coordinación es justo lo que evita decisiones impulsivas.
Errores que encarecen el incidente
El primero es pensar que el problema es solo técnico. Un ransomware afecta continuidad de negocio, obligaciones con clientes y tiempos de respuesta internos. El segundo es comunicar demasiado pronto algo que luego cambia. Decir “solo afecta a un servidor” sin confirmación puede complicar la gestión posterior. El tercero es restaurar desde copias no verificadas. El cuarto es no revisar credenciales administrativas ni accesos remotos.
También conviene evitar el exceso contrario: paralizar toda decisión hasta tener certeza absoluta. En un incidente real, casi siempre se actúa con información parcial. Lo sensato no es esperar datos perfectos, sino documentar supuestos, decidir con criterio y ajustar conforme aparece evidencia.
Cómo preparar la respuesta antes de que ocurra
La mejor respuesta a ransomware empieza semanas antes del ataque. Una pyme necesita al menos un inventario razonable de activos, copias de seguridad probadas, segmentación básica, multifactor en accesos críticos, registro centralizado cuando sea posible y un protocolo de escalado que no dependa de una sola persona.
También ayuda hacer simulacros sencillos. No hace falta un ejercicio complejo. Basta con plantear un escenario realista: “el servidor de archivos aparece cifrado y hay usuarios bloqueados”. Esa práctica revela muy rápido quién decide, qué falta y dónde están las dependencias ocultas. Para muchas empresas de Ciudad de México y Naucalpan, ese tipo de preparación marca la diferencia entre un incidente contenido y varios días de interrupción.
Cuando la respuesta está pensada de antemano, el equipo deja de reaccionar por intuición y empieza a actuar con orden. Y en ransomware, el orden no elimina el daño, pero sí reduce de forma clara su alcance, su coste y el tiempo que la empresa tarda en recuperar el control.