Tener herramientas de seguridad y copias de respaldo no basta para saber cómo actuar ante un ciberataque. Un plan de respuesta ante incidentes de seguridad debe conectar al equipo que investiga y contiene la amenaza con quienes toman decisiones sobre el negocio. ¿Qué necesita tu empresa para que esa coordinación funcione?
Un equipo puede saber cómo bloquear una cuenta. Pero si esa cuenta sostiene una aplicación crítica, la decisión también afecta al negocio. Hay que entender qué se interrumpe, qué riesgo existe si no se actúa y qué alternativa permite mantener la actividad.
Por eso, la ciberseguridad para empresas debe conectar la protección técnica con las prioridades del negocio. Un plan de respuesta ante incidentes de seguridad lleva esa conexión a la práctica: el documento organiza la actuación, el equipo de respuesta investiga y contiene, y la empresa aporta las prioridades y las autorizaciones para actuar sobre su operación.
En vuestra empresa, ¿tenéis acordado cómo actuar y contáis con un equipo que pueda hacerlo cuando sea necesario?
Qué es un plan de respuesta ante incidentes de seguridad y qué debe incluir
Un plan de respuesta ante incidentes de seguridad establece cómo una organización identifica y gestiona un incidente, quién interviene y cómo se coordinan la investigación, la contención, la recuperación y las comunicaciones.
Debe dejar previsto qué situaciones lo activan, cómo se valora su gravedad, quién coordina la respuesta y qué actuaciones están autorizadas. También necesita definir cuándo se escala, cómo se conservan las evidencias y con qué criterios se recuperan los servicios.
No se trata de anticipar todas las decisiones posibles. Se trata de resolver antes aquellas que no deberían depender de encontrar a la persona adecuada cuando el incidente ya está ocurriendo.
Ese enfoque está presente en las recomendaciones de respuesta ante incidentes del NIST, el Instituto Nacional de Estándares y Tecnología de Estados Unidos, un organismo público que desarrolla estándares y guías técnicas utilizadas como referencia en ciberseguridad.
El plan no es solo lo que hace el equipo técnico durante un ataque. Incluye el trabajo previo para que esa actuación sea posible: servicios críticos identificados, responsables disponibles, accesos preparados, proveedores coordinados y procedimientos probados.
También debe conectarse con la continuidad y la recuperación. Investigar un incidente, mantener la actividad y restaurar una aplicación son necesidades diferentes. Pueden avanzar en paralelo, pero alguien debe coordinar sus prioridades y dependencias.
Qué es un equipo de respuesta ante incidentes y qué aporta al plan
El plan puede indicar que una alerta debe investigarse. Lo que no hace por sí solo es relacionar los indicios, comprobar si existe un compromiso o determinar qué sistemas están afectados.
Ese trabajo necesita capacidad de respuesta. Un CSIRT, o Computer Security Incident Response Team, es un equipo especializado en la gestión de incidentes de seguridad informática. Puede ser interno, externo o combinar ambas opciones, según los recursos y las necesidades de la organización.
Su importancia no está únicamente en conocer las herramientas. Está en poder mantener la investigación y la actuación conectadas: interpretar lo que aparece, revisar el alcance, aplicar medidas autorizadas y explicar qué decisiones siguen pendientes.
Un caso real: cómo respondimos fuera del horario laboral
Una compañía de los sectores del ocio y la alimentación con la que trabajamos sufrió un ataque a través de un proveedor externo, que se conectó a sus sistemas desde un equipo infectado.
Durante el fin de semana, nuestro servicio de SOC / CSIRT detectó actividad sospechosa, investigó las alertas y actuó para neutralizar el ataque.
La diferencia no estuvo solo en detectar, sino en contar con un equipo disponible para interpretar la señal y responder. Esa capacidad ya estaba preparada; no hubo que organizarla cuando el incidente estaba en marcha.
Este ejemplo muestra qué debe resolver el plan: quién atiende una alerta fuera de horario, qué puede ejecutar el equipo y cuándo necesita coordinarse con la empresa.
Cómo preparar la respuesta ante incidentes con un equipo de respuesta interno o externo
No todas las empresas necesitan construir un equipo completo desde cero. Apoyarse en especialistas puede ampliar la capacidad disponible y ayudar a preparar procedimientos que sean utilizables en el entorno real.
Pero disponer de un equipo que sabe responder no equivale automáticamente a tener un plan adaptado al negocio.
El equipo necesita conocer qué servicios son críticos, qué información está en riesgo, qué accesos puede utilizar y qué medidas tiene autorizadas. La empresa debe decidir quién responde por la operación, cuándo interviene Dirección y cómo se gestionan las comunicaciones.
El equipo aporta conocimiento para responder. El plan deja acordado cómo hacerlo en el contexto de la empresa.
En Softeng, el CSIRT de respuesta y mitigación de incidentes integra capacidades de SOC, contención y mitigación, análisis forense y asistencia en la notificación de brechas. La utilidad de combinar esas capacidades está en dar continuidad al trabajo, desde la vigilancia y la investigación hasta la actuación y el aprendizaje.
Aun así, el alcance debe quedar acordado. Antes de un incidente, conviene saber cómo se activa al equipo, qué necesita para intervenir, qué puede ejecutar directamente y cómo devuelve sus conclusiones a quienes toman decisiones.
Qué debe estar acordado con un equipo externo
Si el proveedor necesita acceso a un sistema para investigar, ese acceso debe estar previsto y controlado. Si puede aislar un dispositivo ante determinadas señales, la autorización debe ser clara. Y si la medida afecta a un servicio crítico, tiene que conocer cómo escalar la decisión y a quién localizar.
También importa qué recibe la empresa durante la respuesta. No basta con saber que «el incidente sigue en investigación». El responsable necesita entender qué se ha confirmado, qué permanece incierto, qué medidas se han aplicado y qué decisión requiere atención.
Como recoge el NIST al desarrollar las responsabilidades internas y externas, la coordinación debe contemplar los flujos de información, la autoridad para actuar y los límites del proveedor.
Contar con apoyo especializado puede simplificar este trabajo. Lo que no debería hacer es ocultar responsabilidades que la empresa necesita conservar.
Quién es responsable de la respuesta ante incidentes de seguridad
Asignar un responsable parece sencillo hasta que la decisión tiene consecuencias. Un especialista puede saber cómo aislar un sistema, pero eso no significa que tenga autoridad para asumir una parada de la operación.
Por eso, el plan debe distinguir quién ejecuta una medida y quién decide sobre su impacto.
- El responsable del incidente coordina la respuesta y el escalado.
- Ciberseguridad investiga y actúa dentro de sus autorizaciones.
- IT y los propietarios de los servicios aclaran dependencias y preparan la recuperación.
- Dirección interviene cuando las consecuencias superan los límites operativos acordados.
- Legal, DPO y Comunicación participan según las obligaciones y los destinatarios afectados.
No hace falta que todos aprueben cada actuación. Eso también puede bloquear la respuesta. Una contención urgente prevista en un procedimiento autorizado no debería esperar automáticamente a reunir al comité de crisis. En cambio, una decisión que afecta de forma relevante a la operación puede requerir coordinación con sus responsables.
El plan debe concretar esa diferencia y prever suplencias. Si solo una persona puede decidir y nadie sabe cómo localizarla, la autoridad existe formalmente, pero puede no estar disponible cuando se necesita.
Esta conexión entre información técnica y capacidad de decisión es una de las ideas que desarrollamos en Softeng al explicar cómo gestionar una crisis de ciberseguridad.
Cuáles son las fases de la respuesta ante incidentes de seguridad
Preparación, detección y análisis, contención, erradicación, recuperación y aprendizaje ayudan a ordenar el trabajo. Sin embargo, un procedimiento para cada fase no demuestra que todas estén cubiertas.
- La preparación exige conocer los servicios críticos y comprobar recursos, accesos y responsabilidades.
- La detección y el análisis deben permitir confirmar indicios, estimar el alcance y priorizar.
- La contención limita el daño; la erradicación aborda lo que permite que el incidente continúe.
- La recuperación comprueba que se puede volver a operar sin reintroducir el problema.
En ese recorrido, el equipo necesita revisar sus decisiones según cambia la información. Si aparecen nuevos sistemas afectados, la contención puede tener que ampliarse. Si se identifica un acceso persistente, cerrar la alerta inicial no será suficiente.
Cambiar una contraseña, eliminar un archivo malicioso o recuperar una aplicación no demuestra por sí solo que el incidente esté resuelto. Hay que validar el alcance y el resultado de las actuaciones.
Los seis bloques anteriores son una forma práctica de explicar la respuesta, no fases lineales obligatorias de ese marco.
Tampoco todo ocurre de forma sucesiva. Se puede investigar mientras se contiene y preparar alternativas de operación mientras continúa el análisis. La comunicación y la conservación de evidencias atraviesan el proceso, no se dejan para el final.
Respuesta ante incidentes y continuidad de negocio: cómo coordinar la recuperación
Cuando un servicio crítico deja de funcionar, el negocio necesita recuperarlo. El equipo forense puede necesitar preservar los sistemas afectados para entender lo ocurrido. Si no existen alternativas previstas, ambas necesidades pueden entrar en conflicto.
Por eso conviene preguntarse antes: ¿podemos mantener o recuperar la actividad mientras continúa la investigación, sin alterar indebidamente las evidencias ni ampliar el compromiso?
Aquí se conectan el equipo de respuesta, IT y los responsables de continuidad. La respuesta organiza la gestión del incidente. La continuidad define cómo sostener funciones críticas. La recuperación establece cómo restaurar servicios. Resuelven necesidades distintas, aunque deban trabajar juntas.
Tener backup ayuda, pero no resuelve toda la situación. Los criterios de recuperación del NIST incluyen comprobar la integridad de las copias, validar los activos restaurados y confirmar el funcionamiento antes de devolver los servicios a producción.
También importa cómo se contiene. Aislar un equipo no es lo mismo que apagarlo: el apagado puede hacer perder información de memoria útil para investigar. La guía de respuesta a ransomware de CISA prioriza el aislamiento y reserva el apagado como alternativa cuando no es posible desconectar los sistemas para frenar la propagación. Es un criterio para ese contexto, no una instrucción universal.
En entornos industriales, las medidas también deben considerar la seguridad de las personas y los procesos físicos. Un procedimiento para un ordenador de oficina no debería trasladarse sin adaptación a una planta.
Como explicamos al abordar la preparación y recuperación frente al ransomware, recuperar disponibilidad no resuelve por sí solo todas las consecuencias. La vuelta a la actividad debe coordinarse con la investigación y las condiciones de seguridad.
Qué documentación y evidencias necesita el equipo de respuesta
Un análisis de riesgos aclara qué consecuencias se habían previsto. Un contrato permite saber qué puede aportar un proveedor. La documentación de sistemas explica las dependencias de un servicio.
Durante el incidente, esa información ayuda a decidir. Pero sirve de poco si nadie sabe encontrarla o si depende exclusivamente del entorno afectado.
El plan debe prever dónde consultarla, quién puede acceder y qué alternativa segura existe si los sistemas habituales no están disponibles. La preparación recomendada por CISA incluye disponer del plan y de las comunicaciones también fuera de línea, manteniendo los controles necesarios para proteger su contenido.
Además, hay que registrar lo que genera la respuesta: qué se ha observado, qué se ha decidido, quién lo ha autorizado y qué acciones se han ejecutado. Las evidencias necesitan conservación y trazabilidad específicas; no basta con reunir documentos al final.
La investigación y el registro de decisiones deben permitir explicar qué ocurrió y por qué se actuó de esa manera. También deben servir para corregir las condiciones que hicieron posible el compromiso y mejorar la siguiente respuesta.
Cómo comunicar y notificar un incidente de seguridad
Informar a Dirección, coordinar proveedores, comunicar a clientes y notificar a una autoridad son trabajos distintos. Una notificación regulatoria no sustituye la coordinación interna ni resuelve lo que deben saber las personas afectadas.
El equipo de respuesta aporta los hechos técnicos: qué se ha observado, qué alcance se conoce y qué medidas se han aplicado. Legal y el DPO valoran las obligaciones; Comunicación prepara los mensajes para cada audiencia y Dirección participa en las decisiones que afectan al negocio.
El plan debe establecer quién evalúa, quién prepara, quién valida y cómo se actualiza la información.
La guía de gestión y notificación de brechas de la AEPD permite entender un ejemplo concreto. Si hay una brecha de datos personales, el responsable debe notificar a la autoridad de control competente sin dilación indebida y, de ser posible, a más tardar en 72 horas desde que tiene constancia, salvo que sea improbable que exista riesgo para los derechos y libertades de las personas. El encargado informa al responsable sin dilación indebida. Cuando sea probable un alto riesgo, procede comunicar a los afectados, con las excepciones aplicables. Todas las brechas de datos personales deben documentarse, incluso las no notificadas.
Esto no convierte las 72 horas en una regla para cualquier ciberincidente. La Directiva NIS2 y los marcos sectoriales contemplan otras obligaciones según la entidad y la situación. Su aplicabilidad, destinatario y plazos deben revisarse con quienes tienen responsabilidad sobre cumplimiento.
También conviene distinguir el apoyo operativo de otros trámites. Como explica INCIBE-CERT sobre el alcance de su servicio de respuesta, sus pautas deben aplicarlas el personal técnico o el proveedor de la organización. Reportarle un incidente no sustituye una denuncia ni debe confundirse con cumplir cualquier obligación de notificación.
Un mensaje no debería ofrecer más certeza de la que tiene la organización. Eso exige mantener la información compartida y actualizada, sin esperar a cerrar toda la investigación para empezar a evaluar qué corresponde comunicar.
Cómo probar el plan de respuesta ante incidentes
Leer el documento ayuda a conocer las responsabilidades. No demuestra que puedan ejecutarse cuando falta información, hay presión y participan varios equipos.
Un TTX o tabletop exercise permite trabajar esa situación mediante un escenario simulado. Los participantes deben tomar decisiones, pedir información, coordinarse y comunicar, sin ejecutar acciones técnicas.
En Softeng utilizamos ejercicios TTX para practicar la gestión de crisis con perfiles tecnológicos y de negocio. El formato permite plantear dudas sobre autoridad, escalado o coordinación que una revisión documental puede dejar abiertas.
También ayuda a revisar la relación con los especialistas externos. ¿Quién los activa? ¿Qué necesitan para investigar? ¿Qué pueden ejecutar directamente? ¿Cómo comunican sus conclusiones y qué decisiones quedan en manos de la empresa?
Pero un TTX no lo prueba todo. Ensayar la decisión de restaurar no demuestra que un servicio pueda recuperarse en el tiempo que necesita el negocio. Para eso hacen falta pruebas de restauración y validación de dependencias. Del mismo modo, una prueba técnica de detección no demuestra que Dirección, Legal y Comunicación puedan gestionar juntas la situación.
La preparación debe combinar esas capacidades y convertir lo observado en cambios. Si no se localiza al responsable, puede hacer falta revisar suplencias, contactos o disponibilidad. Si una medida se bloquea porque nadie sabe quién puede autorizarla, hay que resolver esa autoridad.
El plan también debe evolucionar con la empresa. Un proveedor nuevo, una aplicación crítica o un cambio de equipo pueden dejar obsoleto un procedimiento aunque su fecha de revisión sea reciente.
Probar el plan sirve para encontrar y corregir esos bloqueos antes de que condicionen una respuesta real.
Un plan de respuesta necesita capacidad para actuar
Un plan de respuesta ante incidentes de seguridad tiene sentido cuando conecta responsabilidades, prioridades y capacidad de actuación. No evita por sí solo un ataque ni garantiza que no haya impacto.
Por eso, conviene revisar algo más que el documento: si los accesos están preparados, si las responsabilidades son claras, si los proveedores están coordinados y si la recuperación se ha comprobado.
Esta preparación forma parte de una visión más amplia de los servicios de ciberseguridad para empresas: conectar prevención, detección y respuesta con el conocimiento del entorno y las necesidades del negocio.
El plan organiza la respuesta. El equipo aporta la capacidad para ejecutarla. La empresa debe asegurar que ambos encajan con su forma de operar.
Incorpora un equipo de respuesta ante incidentes de seguridad
Te acompañamos con vigilancia, respuesta y mitigación de incidentes de seguridad para que puedas avanzar con tranquilidad.