6 cosas que todo plan de respuesta ante incidentes necesita

Era una mañana de martes de marzo cuando una empresa de logística con sede en Róterdam descubrió que sus sistemas de archivos estaban cifrados. Al mediodía, doce empleados estaban sin trabajar. A la mañana siguiente, tres envíos clave para clientes se habían retrasado. Tres semanas después, habían pagado 80.000 € a un proveedor de recuperación para restaurar el acceso parcial a sus datos, y aún estaban explicando la brecha de seguridad a un cliente importante que estaba reconsiderando la relación comercial.

En ningún momento la empresa careció de personal capacitado. Lo que les faltó fue un plan.

Esta historia es más común de lo que la mayoría de los empresarios holandeses esperarían. En 2025, más de 2.100 organizaciones holandesas se vieron afectadas por el ransomware, un aumento del 31 % con respecto al año anterior (Estadísticas de Ciberseguridad de Searchlab, Países Bajos, 2026). El tiempo medio de inactividad tras un ataque de este tipo es de 23 días. Sin embargo, los estudios demuestran sistemáticamente que una proporción significativa de las microempresas holandesas no tiene un plan de respuesta a incidentes documentado, o bien, el que tienen nunca se ha puesto a prueba.

Esto cambió significativamente el 15 de abril de 2026, cuando el Parlamento neerlandés aprobó la Ley de Seguridad Cibernética (Cyberbeveiligingswet), la transposición en los Países Bajos de la Directiva NIS2 de la UE. Esta ley introduce la notificación obligatoria de incidentes en un plazo de 24 horas, requisitos de gestión de riesgos de ciberseguridad y la responsabilidad de la dirección en materia de gobernanza de la seguridad. Para las organizaciones incluidas en su ámbito de aplicación, un plan de respuesta a incidentes ya no es opcional. Para aquellas que no están directamente incluidas en el ámbito de aplicación, los cuestionarios a proveedores de los clientes más grandes lo convierten en un requisito práctico.

A continuación, se presentan los seis elementos esenciales que todo plan de respuesta a incidentes debe tener, dirigidos a gerentes de TI y propietarios de negocios que buscan un documento que realmente funcione bajo presión, y no solo uno que quede archivado.

Cuando se produce una interrupción, lo primero que suele fallar no es la respuesta técnica, sino la humana. Ante la falta de roles definidos, personas capacitadas duplican esfuerzos en algunas áreas y descuidan tareas críticas en otras. El tiempo que debería dedicarse a la contención se invierte en determinar quién debe hacer qué.

Su plan de respuesta a incidentes debe responder a tres preguntas antes de que ocurra un incidente, no durante el mismo:

• ¿Quién tiene autoridad para tomar decisiones durante un incidente de seguridad?
• ¿Quién gestiona la comunicación interna y a quién reporta cada miembro del equipo?
• ¿Quién es el punto de contacto designado para las partes externas: su proveedor de TI, asesor legal, aseguradora cibernética y, según NIS2, el NCSC?

Un plan bien estructurado identifica a personas específicas, no solo sus cargos. También incluye personas de respaldo, ya que los incidentes rara vez ocurren cuando el contacto principal está disponible. Cada persona designada debe tener una copia impresa o digital de sus responsabilidades, dado que los incidentes suelen afectar los sistemas que se usarían para consultar dicha información.

En medio de un incidente activo, lo último que debería hacer su equipo es buscar en correos electrónicos el número de teléfono de un proveedor o intentar recordar a qué cuenta está asociada la póliza de ciberseguro. Los pequeños retrasos se acumulan rápidamente. Cada minuto dedicado a localizar un contacto es un minuto que no se dedica a la contención del incidente.

Su plan de respuesta a incidentes debe incluir, en un único lugar que no dependa de la disponibilidad de sus sistemas principales:

• Liderazgo interno: personas identificadas con números de teléfono móvil, no extensiones de oficina.
• Su proveedor de servicios de TI gestionados o responsable interno de TI: con un contacto fuera del horario laboral.
• Proveedores clave de software e infraestructura: especialmente proveedores de servicios en la nube, ERP y sistemas de copia de seguridad.
• Proveedor de ciberseguro: número de póliza, contacto para reclamaciones y si requieren notificación de incidentes dentro de un plazo específico.
• Asesor legal con experiencia en filtraciones de datos.
• Notificación de incidentes de ciberseguridad del NCSC (si es una entidad esencial según la Ley de Ciberseguridad).
• Socios comerciales o clientes clave que puedan necesitar notificación.

Conserve una copia impresa de esta lista de contactos, almacenada de forma segura fuera de la empresa o con una persona de confianza ajena a ella. Un ataque de ransomware que cifra sus sistemas de archivos también cifra cualquier lista de contactos almacenada en ellos. Muchas empresas holandesas lo aprendieron por las malas.

En la planificación de incidentes, se suele asumir que las herramientas de comunicación permanecerán disponibles. Sin embargo, a menudo no es así. El correo electrónico podría no estar disponible si su entorno de Exchange o Microsoft 365 se ve afectado. Las herramientas de mensajería interna podrían dejar de funcionar. Su sistema VoIP podría quedar inaccesible.

Su plan debe definir canales de comunicación que funcionen independientemente de los sistemas que podrían verse comprometidos, y establecer expectativas sobre qué se comunica, a quién y cuándo.

• Defina un canal de respaldo: un grupo compartido de WhatsApp para el personal clave, una cadena telefónica previamente acordada o un punto de encuentro designado para el equipo principal.
• Defina quién notifica al personal y qué información debe proporcionar. La falta de claridad en la comunicación interna durante un incidente genera rumores y ansiedad, lo que dificulta la gestión de la situación.

• Comunicación con el cliente: ¿cuándo se notifica a los clientes y qué se les comunica? Un mensaje de espera enviado con prontitud casi siempre es mejor que el silencio.
• Comunicación regulatoria: según el RGPD (Reglamento General de Protección de Datos), una violación de datos personales debe notificarse a la Autoridad de Protección de Datos (Autoriteit Persoonsgegevens) en un plazo de 72 horas desde su detección. Según la Ley de Seguridad Cibernética (Cyberbeveiligingswet), las entidades esenciales deben notificar al Centro Nacional de Ciberseguridad (NCSC) los incidentes significativos en un plazo de 24 horas. Ambos plazos comienzan a contar de inmediato.
• Comunicación con los medios y el público: en la mayoría de los casos, no se debe hacer ninguna declaración pública hasta que el departamento legal y la dirección hayan acordado el mensaje. Es fundamental definir quién está autorizado a comunicarse externamente.

No todos los sistemas tienen la misma importancia. Una interrupción que afecte al software interno de RR. HH. es un inconveniente. Sin embargo, una interrupción que afecte al procesamiento de pagos, al portal de atención al cliente o a la base de datos operativa principal tiene consecuencias financieras y de reputación inmediatas.

Su plan de respuesta a incidentes debe incluir un mapa documentado de:

• Qué sistemas son esenciales para las operaciones principales de su negocio.
• Cuál es el tiempo de inactividad aceptable para cada uno (su Objetivo de Tiempo de Recuperación, o RTO).
• Qué pérdida de datos es tolerable: hasta qué punto se puede restaurar y cuál es el costo de la restauración en comparación con la pérdida de esos datos (su Objetivo de Punto de Recuperación, o RPO).
• El orden de prioridad para la restauración si varios sistemas se ven afectados simultáneamente.

Esta es la sección de la mayoría de los planes de respuesta a incidentes que, o bien falta por completo, o está redactada con tal nivel de detalle técnico que solo una persona en la organización puede seguirla. Ambas versiones fallan bajo presión. Los procedimientos de recuperación deben ser lo suficientemente específicos para ser prácticos y lo suficientemente claros para que los pueda seguir alguien que esté bajo estrés, trabajando con plazos ajustados y que quizás no sea la persona habitual en este puesto.

• Pasos iniciales de contención: cómo aislar los sistemas afectados sin destruir la evidencia necesaria para la investigación.
• A quién notificar en cada etapa de la respuesta y en qué orden.
• Pasos para activar las copias de seguridad, incluyendo dónde se almacenan las credenciales de copia de seguridad y cómo se verifica la restauración.
• Un procedimiento de escalamiento claro: qué sucede si la respuesta inicial no logra contener el incidente dentro de un plazo definido.
• Requisitos de documentación: qué se debe registrar durante el incidente y por qué (preservación de evidencia para fines legales y de seguros).

Según AVG y la Ley de Seguridad Cibernética (Cyberbeveiligingswet), las organizaciones podrían tener que demostrar qué sucedió, cuándo y cómo respondieron. El registro en tiempo real durante un incidente no es intuitivo: las personas se centran en solucionar el problema, no en documentarlo. Asigne a una persona específicamente para mantener un registro de incidentes, aunque solo sean notas con fecha y hora en una libreta física.

Un plan de respuesta ante incidentes que nunca se ha puesto a prueba es solo un documento, no un plan. La diferencia entre ambos solo se hace evidente en el peor momento posible.

Las pruebas tienen dos propósitos. Primero, revelan deficiencias que no son obvias en el papel: un número de contacto desactualizado, un proceso de restauración de copias de seguridad que tarda tres veces más de lo previsto, una descripción de funciones que dos personas creían que les correspondía a cada una. Segundo, desarrollan la capacidad de reacción necesaria para que las personas respondan con rapidez y serenidad cuando ocurre un incidente real, en lugar de leer el plan por primera vez bajo presión.

• Un ejercicio de simulación al menos una vez al año: un análisis estructurado de un escenario de incidente simulado con las personas clave mencionadas en el plan. No es necesario modificar ningún sistema; basta con conversar sobre «¿qué haríamos si esto ocurriera?».
• Una prueba de restauración de copias de seguridad al menos dos veces al año: ¿es posible restaurar desde la copia de seguridad más reciente y cuánto tiempo tarda?
• Una revisión de la lista de contactos cada seis meses: ¿alguien ha cambiado de puesto, ha dejado la empresa o ha cambiado su número de teléfono móvil?
• Una revisión posterior a cualquier incidente real, por leve que sea: ¿qué funcionó, qué no y qué cambios son necesarios en el plan?

Según la Ley de Ciberseguridad (Cyberbeveiligingswet), las entidades esenciales deben demostrar que las medidas de ciberseguridad —incluida la respuesta a incidentes— se implementan y se someten a pruebas. Esto implica mantener registros de las pruebas, los simulacros y las revisiones de planes. Un plan con historial de revisiones y registro de pruebas es mucho más sólido que uno creado hace tres años sin evidencia de actualizaciones.

Un buen plan de respuesta ante incidentes no previene los incidentes. Lo que hace es acortar el tiempo entre la detección y la contención, reducir el coste de la recuperación y proporcionar a su equipo una guía cuando la situación es demasiado estresante para pensar con claridad.

Para las empresas neerlandesas, la urgencia ha aumentado. La Ley de Seguridad Cibernética (Cyberbeveiligingswet) ya está en vigor. Las obligaciones de notificación de incidentes de la NIS2 están vigentes. Los cuestionarios de los proveedores de los clientes más importantes preguntan directamente si usted cuenta con procedimientos de respuesta ante incidentes documentados y probados. La cuestión ya no es si se debe tener un plan, sino si el suyo abarca los seis aspectos que realmente importan cuando algo sale mal.

La mayoría de las empresas que cuentan con un plan de respuesta ante incidentes descubren deficiencias la primera vez que lo ponen a prueba. Aquellas que descubren deficiencias durante un incidente real pagan mucho más para subsanarlas.

Sin jerga técnica. Sin compromiso. Simplemente una visión clara de la situación actual de su plan y de lo que, en su caso, necesita reforzarse.