Un plan de respuesta a incidentes es un documento corto y ensayado que dice quién decide, a quién se llama, qué se hace en las primeras horas y qué se notifica cuando ocurre un ataque o una fuga de datos. Para una empresa mediana o pequeña basta con una página principal más playbooks para cinco escenarios probables: ransomware, cuenta comprometida, fuga de datos, llave de API filtrada y mal uso de un asistente de IA. Lo que lo hace útil no es su extensión, sino que el equipo lo haya practicado antes de necesitarlo.
Qué es un plan de respuesta a incidentes y por qué lo necesitas
Un plan de respuesta a incidentes es el conjunto de roles, procedimientos y criterios que una organización sigue para detectar, contener, erradicar y recuperarse de un incidente de seguridad, y para aprender de él. Sin plan, las primeras horas se pierden en discusiones: quién tiene la clave del firewall, si se apaga el servidor, si se avisa a los clientes. Esas horas son justo las que determinan cuánto daño hace el atacante.
En Ecuador hay además una razón legal: la LOPDP obliga a notificar las vulneraciones de seguridad de datos personales en plazos cortos, y es muy difícil cumplirlos si nadie sabe quién decide notificar ni cómo se redacta el aviso.
El ciclo de vida según NIST SP 800-61 Rev. 3
La referencia internacional más usada es la publicación NIST SP 800-61. Su Revisión 3, publicada en abril de 2025, reemplazó a la Revisión 2 de 2012. La versión anterior describía un ciclo de cuatro fases: preparación; detección y análisis; contención, erradicación y recuperación; y actividad posterior al incidente. La Rev. 3 lo reorganiza como un perfil del NIST Cybersecurity Framework (CSF) 2.0 y alinea la respuesta a incidentes con sus seis funciones:
| Funciones CSF 2.0 | Papel en la respuesta a incidentes |
|---|---|
| Govern, Identify, Protect | Preparación: políticas, roles, inventario de activos, controles preventivos. Son actividades amplias de gestión de riesgos que sostienen la respuesta. |
| Detect | Descubrir y analizar eventos que pueden ser incidentes. |
| Respond | Gestionar, analizar, contener, comunicar y erradicar. |
| Recover | Restaurar operaciones y comunicar la recuperación. |
| Identify (Mejora) | Las lecciones aprendidas de todas las actividades alimentan la categoría de mejora, que a su vez informa a todas las funciones. |
La idea práctica: la respuesta a incidentes deja de ser un procedimiento aislado y pasa a formar parte de la gestión de riesgos. Si ya trabajas con ISO 27001, encaja con sus controles de gestión de incidentes.
Roles y lista de contactos
En una empresa pequeña una persona puede tener varios roles, pero cada rol debe tener titular y suplente:
- Líder del incidente: coordina, decide prioridades y lleva la bitácora. No necesita ser el más técnico.
- Responsable técnico: TI interna o proveedor; ejecuta contención y recuperación.
- Dirección: aprueba decisiones de negocio (desconectar sistemas, comunicar, contratar ayuda externa).
- Asesor legal y delegado de protección de datos: evalúa obligaciones de notificación y redacta avisos.
- Comunicación: mensajes a empleados, clientes y, si aplica, medios.
La lista de contactos debe existir fuera de los sistemas que pueden caer (impresa o en un canal alternativo): proveedor de seguridad, proveedor de nube, banco, aseguradora, asesor legal, EcuCERT y la Superintendencia de Protección de Datos Personales. Si no tienes un proveedor de respuesta, acuérdalo antes del incidente; nuestro equipo de ciberseguridad puede cumplir ese rol.
Clasificación de severidad
| Nivel | Criterio | Respuesta |
|---|---|---|
| Crítico | Operación detenida, cifrado masivo o fuga confirmada de datos personales o financieros | Activación inmediata del equipo completo y la dirección; evaluar notificación legal |
| Alto | Cuenta privilegiada comprometida, malware activo en varios equipos, secreto de producción expuesto | Equipo técnico y líder en menos de una hora |
| Medio | Cuenta de usuario comprometida sin evidencia de acceso a datos sensibles | Atención el mismo día |
| Bajo | Phishing reportado sin clics, escaneos bloqueados | Registro y seguimiento normal |
Playbooks para los cinco incidentes más probables
Ransomware
Aislar equipos sin apagarlos, coordinar por teléfono, proteger los backups, preservar evidencia y decidir sobre la restauración. El detalle está en nuestra guía de ransomware en pymes.
Cuenta comprometida (correo o nube)
Revocar sesiones activas, cambiar la contraseña, revisar y reforzar el MFA, buscar reglas de reenvío creadas por el atacante, revisar qué datos se consultaron y si se enviaron correos fraudulentos a clientes o proveedores.
Fuga de datos
Cerrar la vía de exposición (bucket público, endpoint sin autenticación), determinar qué datos y de cuántas personas, durante cuánto tiempo, y activar de inmediato al asesor legal por los plazos de notificación.
Llave de API o secreto filtrado
Revocar y rotar primero, investigar después. Revisar los logs del proveedor por uso de la llave desde la filtración, eliminarla del historial del repositorio y añadir escaneo de secretos al pipeline, como explicamos en DevSecOps en CI/CD.
Mal uso de un asistente o agente de IA
Si un chatbot o agente reveló datos, ejecutó acciones no autorizadas o fue manipulado mediante prompt injection: desactivar las herramientas o integraciones afectadas, conservar las conversaciones y trazas como evidencia, rotar las credenciales que usaba el agente y revisar sus permisos. Las defensas están en nuestra guía de prompt injection en agentes de IA.
Preservación de evidencia
- No apagues ni reinstales equipos antes de capturar lo necesario; prioriza aislar.
- Exporta logs de firewall, EDR, correo, nube e identidad antes de que roten.
- Haz copias y registra quién las obtuvo, cuándo y cómo (cadena de custodia), sobre todo si podría haber denuncia ante la Fiscalía.
- Lleva una bitácora con hora, acción, responsable y decisión. Sirve para la notificación, el seguro y la revisión posterior.
Comunicación: interna, clientes y autoridad
Internamente, usa un canal alternativo si el correo puede estar comprometido y limita los detalles a quien los necesita. Con clientes, comunica hechos verificados, qué estás haciendo y qué deben hacer ellos; evita especular sobre causas o alcance antes de tener evidencia.
Con la autoridad, la LOPDP establece que el responsable del tratamiento notifique la vulneración de seguridad de datos personales a la Superintendencia de Protección de Datos Personales tan pronto sea posible y a más tardar en el término de cinco días desde que tuvo constancia (art. 43), salvo que sea improbable un riesgo para los derechos de las personas. Si hay riesgo para los titulares, debes notificarles sin dilación, dentro de tres días (art. 46). Un proveedor que trate datos por tu cuenta debe avisarte en dos días. La Superintendencia ha emitido normativa técnica sobre el procedimiento de notificación; confirma con tu asesor el canal y formato vigentes. Lo desarrollamos en nuestra guía técnica de la LOPDP.
Simulacros y revisión posterior al incidente
Un ejercicio de mesa (tabletop) es una sesión de una o dos horas en la que el equipo recorre un escenario realista paso a paso, sin tocar sistemas. Revela rápido los vacíos: el contacto del proveedor que ya no existe, el backup cuya contraseña tenía una persona que se fue, la duda de quién autoriza desconectar la tienda en línea. CISA publica paquetes gratuitos de escenarios, incluido ransomware, que puedes adaptar. Haz al menos uno al año.
Tras cada incidente relevante, una revisión post-incidente sin culpables, dentro de las dos semanas siguientes: cronología, qué funcionó, qué no, causa raíz y acciones con responsable y fecha. Esas acciones son la categoría de mejora que plantea NIST.
Plantilla de una página
- Alcance y definición: qué cuenta como incidente y cómo se reporta (correo, teléfono, canal).
- Roles: líder, técnico, dirección, legal, comunicación, con suplentes.
- Contactos de emergencia: internos y externos, fuera de los sistemas principales.
- Severidad: tabla de cuatro niveles con tiempos de respuesta.
- Primeros 60 minutos: aislar, avisar al líder, abrir bitácora, preservar evidencia.
- Playbooks: enlaces a los cinco escenarios.
- Notificación: criterios y plazos LOPDP, responsables de redactar y aprobar.
- Recuperación: orden de restauración de sistemas críticos.
- Mejora: fecha del próximo simulacro y de la próxima revisión del plan.
Preguntas frecuentes
¿Qué debe incluir un plan de respuesta a incidentes?
Como mínimo: definición de incidente y cómo reportarlo, roles con suplentes, lista de contactos de emergencia, criterios de severidad, pasos para la primera hora, playbooks por escenario, reglas de preservación de evidencia, criterios y plazos de notificación legal, orden de recuperación y un proceso de revisión posterior. Todo debe caber en un documento que se pueda leer bajo presión.
¿Qué cambió en NIST SP 800-61 Rev. 3?
Publicada en abril de 2025, reemplaza a la Rev. 2 de 2012 y alinea la respuesta a incidentes con las seis funciones del CSF 2.0. Govern, Identify y Protect cubren la preparación como parte de la gestión de riesgos; Detect, Respond y Recover cubren la respuesta; y las lecciones aprendidas alimentan una categoría de mejora continua que informa a todas las funciones.
¿En cuánto tiempo debo notificar una fuga de datos en Ecuador?
Según el artículo 43 de la LOPDP, el responsable debe notificar a la autoridad tan pronto sea posible y a más tardar en el término de cinco días desde que tuvo constancia de la vulneración. Si existe riesgo para los derechos de los titulares, el artículo 46 exige avisarles dentro de tres días. Valida con tu asesor el procedimiento vigente de la Superintendencia.
¿Cada cuánto hay que probar el plan?
Al menos un ejercicio de mesa al año y siempre que cambie algo importante: nuevo sistema crítico, cambio de proveedor de TI o de nube, o rotación de las personas clave. Los contactos conviene verificarlos cada trimestre. Un plan que no se ha practicado suele fallar en detalles básicos como accesos o teléfonos desactualizados.
¿Necesito un proveedor externo de respuesta a incidentes?
Para una pyme suele ser lo más realista: pocas empresas pequeñas tienen capacidad forense propia. Lo importante es acordarlo antes del incidente, con contacto, tiempos de respuesta y condiciones definidas, en lugar de buscar ayuda en medio de la crisis. Si tienes seguro cibernético, revisa si la póliza exige usar proveedores específicos.
Conclusión
Un buen plan de respuesta a incidentes es corto, tiene dueños claros, incluye playbooks para los escenarios probables, cumple los plazos de la LOPDP y se practica al menos una vez al año. El marco NIST SP 800-61 Rev. 3 te da la estructura; el simulacro te dice si funciona.
En MisterProSoft te ayudamos a redactar el plan y sus playbooks, facilitamos ejercicios de mesa y reforzamos los controles que reducen la probabilidad de un incidente. Conoce nuestro servicio de ciberseguridad o agenda una consulta gratuita.
Fuentes y referencias
- NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- NIST Cybersecurity Framework (CSF) 2.0
- CISA Tabletop Exercise Packages
- Ley Orgánica de Protección de Datos Personales (MINTEL)
- EcuCERT: Centro de Respuesta a Incidentes Informáticos de ARCOTEL