Un plan de respuesta a incidentes no es un documento para el auditor: es lo que decide si una empresa para dos días o dos semanas. Y el 81 % de las compañías españolas atacadas con éxito reconoce haberlo sido más de una vez.
Tener un plan y tener un plan que funcione no es lo mismo
El informe anual de ransomware de Semperis, difundido el 16 de octubre, deja una cifra incómoda para cualquier dirección: el 81 % de las empresas españolas atacadas con éxito admite haberlo sido en múltiples ocasiones, el 29 % pagó el rescate y el 48 % de las afectadas se encontró después con el ciberseguro cancelado o encarecido.
No es un problema de herramientas. La mayoría de esas organizaciones tenía algo parecido a un plan de respuesta a incidentes: teléfonos, un contrato de soporte y una copia que figuraba como correcta. Lo que no tenía era un plan probado.
El contexto acompaña: según el informe ThreatLabz 2026 de Zscaler, las víctimas de ransomware en España crecieron un 19 % interanual hasta 160 casos, con un rescate medio de 431.995 dólares. Para una pyme la cifra que duele no es el rescate: es la parada.
Qué debe contener un plan de respuesta a incidentes en una pyme
INCIBE ordena la gestión de incidentes en seis fases: preparación, identificación, contención, mitigación, recuperación y recapitulación. Buen armazón, pero en una empresa de 20 o 200 personas el plan se cae por otro sitio: las decisiones que nadie ha repartido.
Un plan de respuesta a incidentes útil cabe en pocas páginas y responde, antes que nada, a cinco preguntas:
- Quién decide. Nombre y suplente de quien puede ordenar aislar equipos, parar producción y hablar con terceros. Sin esa línea, la primera media hora se va en consultas.
- Qué se considera incidente. Un criterio de gravedad sencillo —tres niveles bastan— ligado a quién se activa en cada uno.
- A quién se llama y en qué orden. Soporte, perito, aseguradora, asesoría jurídica y autoridad. Con teléfonos reales y alternativa fuera de horario.
- Qué se preserva antes de tocar nada. Discos, registros del cortafuegos y del correo, comunicaciones del atacante: es lo que sostendrá una reclamación o una denuncia, y competencia del peritaje informático.
- Quién habla. Un único portavoz y un mensaje acordado para clientes y empleados.
Lo operativo del primer día lo detallamos en qué hacer tras un ciberataque en las primeras 24 horas. El plan es el paso anterior: lo que permite ejecutar aquello sin improvisar.
El punto ciego que casi nadie cubre: la identidad
Aquí está el hallazgo más accionable del informe de Semperis: el 87 % de los ataques se dirigió a sistemas de identidad —Active Directory, Entra ID, Okta—, y aun así el 60 % de los planes de recuperación no incluye ningún procedimiento para recuperarla.
La consecuencia es concreta: se pueden restaurar los servidores y seguir sin poder trabajar, porque nadie inicia sesión. Y si el directorio está comprometido, restaurarlo tal cual devuelve las puertas que dejó el atacante. Un plan de respuesta a incidentes que no diga cómo se levanta el directorio desde una copia limpia está incompleto.
Qué exigen el ENS y la ISO/IEC 27001
Para quien trabaja con administraciones no es opcional. El Real Decreto 311/2022 del Esquema Nacional de Seguridad exige en su artículo 25 procedimientos de gestión de incidentes, detección, criterios de clasificación y registro de las actuaciones; y en el artículo 26, copias de seguridad y medios para mantener la operación si se pierden los habituales.
La ISO/IEC 27001:2022 va en la misma dirección con su control 5.24, dedicado a la planificación y preparación de la gestión de incidentes: roles asignados por nombre, criterios de severidad, preservación de evidencias y pruebas periódicas.
Y si hay datos personales en juego, el plan debe fijar de antemano quién evalúa el riesgo y quién firma el aviso a la AEPD, con un plazo de 72 horas desde que se tiene constancia.
Un plan de respuesta a incidentes se prueba o no existe
Nuestra recomendación, después de acompañar incidentes reales: el valor del plan no está en el documento, está en el ensayo. Media hora de simulación en comité de dirección —«son las 7 de la mañana, el ERP no arranca, ¿qué hace cada uno?»— encuentra más agujeros que una revisión documental completa.
Dos pruebas para este trimestre: una restauración cronometrada, para saber cuántas horas se tarda de verdad en volver; y comprobar que el plan existe en papel, fuera de los sistemas que el ataque va a cifrar. Un plan guardado solo en el servidor desaparece justo cuando hace falta. Y como la primera fase la ejecuta un empleado y no un técnico, ayuda la concienciación con simulaciones de phishing.
Qué hacer ahora
Cuatro medidas que convierten el plan de respuesta a incidentes en algo que funciona de verdad, y que caben en dos semanas:
- Escribe la cadena de decisión en una hoja. Quién ordena aislar, parar y comunicar, con suplente y móviles. Impresa y fuera de la red.
- Añade la identidad al plan. Cómo se recupera el directorio desde una copia limpia y quién lo hace. Es el hueco del 60 % de los planes.
- Cronometra una restauración completa. No que la copia figure como correcta: recupera un servicio y mide las horas. Ese número es tu ventana de parada real.
- Ensáyalo una vez al año en dirección. Treinta minutos, un escenario y acta de lo que falló: es lo que pedirán la aseguradora y el auditor.
En ISAIG Tecnología ayudamos a pymes y administraciones a preparar y ensayar su plan de respuesta a incidentes, y a sostenerlo con una figura que ya conoce la red y decide en el minuto uno: el servicio de CISO as a Service. Estamos certificados en ISO/IEC 27001 y somos conformes con el ENS en categoría Alta: lo que recomendamos nos lo aplicamos.
Si quieres revisar tu plan de respuesta a incidentes con nosotros, escríbenos a comercial@isaig.com o llámanos al 91 036 99 89.
