Gestión de Incidentes ISO 27001: Requisitos y Marco de Respuesta

Los incidentes de seguridad de la información no son una cuestión de si ocurrirán, sino de cuándo. Una credencial comprometida expone registros de clientes. Un endpoint de API mal configurado filtra datos sensibles. Una campaña de phishing dirigida a tu equipo de finanzas tiene éxito. Cuando estos eventos ocurren, ISO 27001 requiere que tu organización los detecte rápidamente, responda de manera estructurada, contenga el daño, recupere las operaciones y aprenda de la experiencia para que la misma clase de incidente no se repita.

ISO 27001 adopta un enfoque integral para la gestión de incidentes a través tanto de sus cláusulas centrales como de un conjunto dedicado de controles del Annex A. El estándar no prescribe una pila tecnológica específica de respuesta a incidentes ni exige una estructura de equipo particular. En cambio, requiere que establezcas un marco sistemático para gestionar incidentes — uno que esté documentado, comunicado, probado y continuamente mejorado como parte de tu Sistema de Gestión de Seguridad de la Información (ISMS) más amplio.

Esta guía cubre los requisitos de ISO 27001 para la gestión de incidentes, recorre los controles relevantes del Annex A (A.5.24 a A.5.28), explica cómo construir un marco de respuesta que funcione bajo presión y aborda los desafíos específicos que enfrentan las empresas SaaS al gestionar incidentes de seguridad.

Qué Requiere ISO 27001 para la Gestión de Incidentes

ISO 27001 aborda la gestión de incidentes a través de dos mecanismos: las cláusulas centrales del sistema de gestión y los controles del Annex A. Comprender ambos es esencial para construir un programa conforme.

Requisitos de las Cláusulas Centrales

Cláusula 6.1 — Acciones para abordar riesgos y oportunidades. Tu evaluación de riesgos debe considerar escenarios de incidentes como riesgos potenciales. La probabilidad e impacto de tipos específicos de incidentes debe informar tus decisiones de tratamiento de riesgos, y los controles de gestión de incidentes deben aparecer en tu plan de tratamiento de riesgos. Si tu evaluación de riesgos identifica “acceso no autorizado a la base de datos de producción” como un riesgo alto, tu plan de tratamiento debe incluir procedimientos de respuesta a incidentes diseñados específicamente para ese escenario.

Cláusula 8.1 — Planificación y control operacional. Tus procesos de gestión de incidentes deben ser planificados, implementados y controlados. Esto significa procedimientos documentados, responsabilidades asignadas, recursos adecuados y criterios definidos para evaluar si los procesos están logrando sus resultados previstos.

Cláusula 9.1 — Seguimiento, medición, análisis y evaluación. Debes monitorear y medir la efectividad de tus procesos de gestión de incidentes. Métricas como el tiempo medio de detección, el tiempo medio de respuesta, las tasas de recurrencia de incidentes y las tasas de completación de acciones post-incidente proporcionan evidencia de que tu programa está funcionando.

Cláusula 10.1 — No conformidad y acción correctiva. Cuando los incidentes revelan fallos de control o deficiencias de procesos, estos deben tratarse como no conformidades. Las acciones correctivas deben abordar las causas raíz, no solo los síntomas. La conexión entre los incidentes y tu proceso de mejora continua es directa y obligatoria.

Controles del Annex A para la Gestión de Incidentes

La revisión de 2022 de ISO 27001 consolida los controles de gestión de incidentes bajo la sección A.5, dentro de la categoría de controles organizacionales. Cinco controles forman el marco de gestión de incidentes.

A.5.24 — Planificación y preparación de la gestión de incidentes de seguridad de la información. Este control requiere que establezcas y comuniques procedimientos de gestión de incidentes. Debes definir qué constituye un evento de seguridad de la información frente a un incidente, asignar roles y responsabilidades, establecer canales de comunicación y preparar procedimientos de respuesta antes de que ocurran los incidentes. La preparación no es opcional — es un control que los auditores probarán.

A.5.25 — Evaluación y decisión sobre eventos de seguridad de la información. Cuando se detecta un evento, debes tener un proceso para evaluar su naturaleza y gravedad y decidir si califica como un incidente de seguridad de la información. No toda alerta de seguridad es un incidente. Un solo intento de inicio de sesión fallido es un evento. Diez mil intentos de inicio de sesión fallidos contra múltiples cuentas desde una botnet es un incidente. Tus criterios de clasificación deben definir dónde cae esa línea.

A.5.26 — Respuesta a incidentes de seguridad de la información. Una vez que un evento se clasifica como incidente, debes responder de acuerdo con procedimientos documentados. Este control cubre el ciclo completo de respuesta: contención, erradicación, recuperación y comunicación. Las respuestas deben ser proporcionales a la gravedad del incidente, y los procedimientos deben ser lo suficientemente prácticos para que tu equipo pueda ejecutarlos bajo estrés.

A.5.27 — Aprendizaje de los incidentes de seguridad de la información. Cada incidente es una oportunidad de aprendizaje. Este control requiere que analices los incidentes después de su resolución para identificar las causas raíz, evaluar la efectividad de tu respuesta y determinar si los controles necesitan ser fortalecidos. El conocimiento adquirido debe retroalimentarse en tu ISMS — a través de evaluaciones de riesgos actualizadas, controles revisados, procedimientos modificados o formación mejorada.

A.5.28 — Recopilación de evidencia. Cuando un incidente puede dar lugar a procedimientos legales, acciones regulatorias o medidas disciplinarias, debes recopilar y preservar evidencia de manera forense sólida. Este control aborda la cadena de custodia, la integridad de la evidencia y los requisitos de admisibilidad. Para las empresas SaaS, esto a menudo significa preservar logs, capturar el estado del sistema y mantener cronologías detalladas.

Para un recorrido completo de todos los controles del Annex A y cómo se interrelacionan, consulta nuestra guía de controles del Annex A de ISO 27001.

Eventos vs. Incidentes: Por Qué la Distinción Importa

ISO 27001 traza una línea deliberada entre eventos de seguridad de la información e incidentes de seguridad de la información. Comprender esta distinción es crítico porque determina tu respuesta.

Un evento de seguridad de la información es cualquier ocurrencia identificada en un sistema, servicio o estado de red que indica una posible violación de la política de seguridad de la información, fallo de controles o una situación previamente desconocida que puede ser relevante para la seguridad. Los eventos son observaciones que requieren evaluación. Ejemplos incluyen un intento de inicio de sesión fallido, un firewall bloqueando una conexión entrante, una alerta de antivirus en una estación de trabajo de un empleado o un pico inusual en el tráfico de red saliente.

Un incidente de seguridad de la información es uno o más eventos de seguridad de la información relacionados que tienen una probabilidad significativa de comprometer las operaciones del negocio y amenazar la seguridad de la información. Los incidentes requieren una respuesta coordinada. Ejemplos incluyen acceso no autorizado confirmado a datos de clientes, phishing exitoso que llevó al compromiso de credenciales, infección de malware que se propagó a múltiples sistemas o un ataque DDoS que interrumpió la disponibilidad del servicio.

El proceso de evaluación definido por el control A.5.25 se sitúa entre estos dos conceptos. Cada evento debe ser evaluado contra tus criterios de clasificación para determinar si constituye un incidente. Este proceso de triaje previene dos modos de fallo igualmente dañinos: tratar cada evento como un incidente (lo que agota a tu equipo de respuesta y los desensibiliza ante amenazas reales) y no reconocer incidentes genuinos entre el ruido de eventos rutinarios.

Criterios prácticos de triaje. Tu proceso de triaje debe evaluar los eventos contra estos factores:

Impacto en la confidencialidad: ¿Se accedió, expuso o exfiltró datos sensibles?
Impacto en la integridad: ¿Se modificaron datos o configuraciones del sistema sin autorización?
Impacto en la disponibilidad: ¿Se interrumpieron o degradaron los servicios?
Alcance: ¿El impacto se limita a un solo sistema o usuario, o afecta a múltiples sistemas, clientes o conjuntos de datos?
Amenaza activa: ¿El actor de amenaza sigue presente o la vulnerabilidad sigue siendo explotada?
Implicaciones regulatorias: ¿El evento potencialmente activa obligaciones de notificación de brecha bajo GDPR, compromisos contractuales u otros marcos regulatorios?

Si alguno de estos factores indica un impacto significativo, el evento debe escalarse al estado de incidente.

Clasificación de Incidentes y Niveles de Gravedad

Una vez que un evento se clasifica como incidente, debes asignar un nivel de gravedad que determine la velocidad y escala de tu respuesta. ISO 27001 no prescribe niveles de gravedad específicos — tú los defines según el contexto de tu organización, el apetito de riesgo y los requisitos operacionales.

Un modelo de gravedad de cuatro niveles funciona bien para la mayoría de las organizaciones SaaS:

Gravedad	Definición	Inicio de Respuesta	Escenarios de Ejemplo
Crítica (P1)	Brecha activa con exposición de datos confirmada, interrupción completa del servicio o explotación activa de sistemas de producción	Inmediata — dentro de 15 minutos	Exfiltración de datos de clientes confirmada, ransomware cifrando bases de datos de producción, plataforma completamente no disponible
Alta (P2)	Compromiso de seguridad significativo sin exposición de datos confirmada, interrupción parcial del servicio o ataque activo en progreso	Dentro de 1 hora	Acceso de administrador no autorizado detectado, servicio de autenticación degradado, ataque de fuerza bruta activo con algunos éxitos
Moderada (P3)	Evento de seguridad que requiere investigación y respuesta, impacto operacional limitado	Dentro de 4 horas	Patrones de acceso a datos sospechosos, interrupción de servicio no crítico, malware contenido en una sola estación de trabajo
Baja (P4)	Evento de seguridad menor, cuasi-incidente o violación de política con impacto mínimo	Dentro de 24 horas	Intento de phishing fallido (sin credenciales comprometidas), excepción menor de política, vulnerabilidad descubierta pero no explotada

La gravedad determina la asignación de recursos. Un incidente P1 activa todo tu equipo de respuesta a incidentes, comunicación ejecutiva y potencialmente notificación al cliente. Un incidente P4 podría ser manejado por un solo ingeniero durante el horario laboral normal. Tus procedimientos deben definir qué recursos se movilizan en cada nivel de gravedad, quién tiene autoridad para escalar o desescalar y qué cadencia de comunicación se aplica.

La gravedad puede cambiar durante un incidente. Un evento inicialmente clasificado como P3 puede escalarse a P1 cuando la investigación revela un impacto más amplio. Tus procedimientos deben definir los disparadores de escalación y asegurar que la escalación sea sin fricción — la persona investigando un P3 debe estar empoderada para escalar a P1 sin buscar aprobación de la dirección si se cumplen los criterios.

El Proceso de Respuesta a Incidentes

ISO 27001 requiere procedimientos de respuesta documentados (A.5.26) que tu equipo pueda ejecutar bajo presión. Un proceso de respuesta estructurado en cinco fases proporciona el marco.

Fase 1: Detección y Reporte

La detección es el punto de partida para cada incidente. Tu capacidad para detectar incidentes depende de las capacidades de monitoreo que hayas desplegado y de la cultura de reporte que hayas establecido.

Fuentes de detección técnica. Para las empresas SaaS, la detección típicamente proviene de:

SIEM y gestión de logs — Análisis centralizado de logs con reglas de correlación que detectan patrones indicativos de compromiso (patrones de acceso inusuales, escalación de privilegios, indicadores de exfiltración de datos)
Monitoreo de seguridad en la nube — AWS CloudTrail, GCP Audit Logs, Azure Activity Logs con alertas sobre eventos relevantes para la seguridad (cambios de IAM, modificaciones de grupos de seguridad, creación inesperada de recursos)
Monitoreo de aplicaciones — Herramientas APM que detectan anomalías en el comportamiento de la aplicación (tasas de error inesperadas, patrones de uso de API inusuales, anomalías de latencia)
Detección y respuesta en endpoints (EDR) — Monitoreo en estaciones de trabajo de empleados para malware, software no autorizado y actividad de procesos sospechosa
Escaneo de vulnerabilidades — Escaneos automatizados regulares que identifican vulnerabilidades explotables antes de que los atacantes lo hagan
Inteligencia de amenazas de terceros — Feeds que te alertan sobre amenazas dirigidas a tu industria, pila tecnológica o cadena de suministro

Reporte humano. No todos los incidentes son detectados por la tecnología. Los empleados que notan correos electrónicos sospechosos, los clientes que reportan comportamiento inesperado y los socios que observan anomalías son fuentes de detección válidas. Tus procedimientos de gestión de incidentes deben incluir un canal de reporte claro y accesible — una dirección de correo electrónico dedicada, un canal de Slack, un botón en tus herramientas internas — y los empleados deben saber cómo usarlo. Tus políticas del ISMS deben definir las obligaciones de reporte para todo el personal.

Requisitos de reporte. Cada evento detectado debe registrarse con:

Fecha y hora de detección
Fuente de detección (alerta del sistema, reporte humano, notificación externa)
Descripción del comportamiento observado
Sistemas o datos potencialmente afectados
Evaluación inicial de gravedad
Nombre e información de contacto de la persona que reporta

Fase 2: Evaluación y Triaje

Una vez que se reporta un evento, debe ser evaluado contra tus criterios de clasificación para determinar si constituye un incidente y, de ser así, qué nivel de gravedad aplica.

El triaje inicial debe ser rápido. Para eventos detectados por sistemas automatizados, el triaje inicial debe ocurrir en minutos. El ingeniero de guardia o analista de seguridad evalúa la alerta, busca evidencia corroborante y toma una decisión de clasificación inicial. Este no es el momento para una investigación profunda — es una evaluación rápida para determinar si el evento merece una respuesta a nivel de incidente.

Lista de verificación de triaje. Dentro de los primeros 30 minutos de recibir un reporte:

¿El evento está confirmado (verdadero positivo) o puede descartarse (falso positivo)?
¿Qué sistemas, datos o servicios están afectados o potencialmente afectados?
¿La amenaza sigue activa? ¿La vulnerabilidad sigue siendo explotada?
¿Los datos de clientes están potencialmente en riesgo?
¿Cuál es el radio de impacto — un solo sistema, un solo cliente, todos los clientes, todos los sistemas?
¿Esto activa alguna obligación de notificación regulatoria (ej., notificación de brecha GDPR)?

Decisión: escalar o cerrar. Basándose en el triaje, el evento se clasifica como incidente (con un nivel de gravedad asignado) y se escala al equipo de respuesta a incidentes, o se cierra como no-incidente con documentación explicando por qué. Cerrar un evento no significa ignorarlo — el registro del evento debe capturar el análisis de triaje y la justificación de la decisión de cierre.

Fase 3: Contención

La contención evita que el incidente empeore. El objetivo es limitar el daño mientras se preserva tu capacidad de investigar la causa raíz.

Contención a corto plazo se enfoca en acciones inmediatas:

Aislar los sistemas afectados de la red (sin apagarlos, para preservar el estado forense)
Revocar las credenciales comprometidas y rotar las claves API y tokens afectados
Bloquear direcciones IP maliciosas, dominios o agentes de usuario en el firewall o WAF
Deshabilitar las cuentas de usuario comprometidas
Aplicar restricciones de acceso de emergencia para limitar la exposición

Contención a largo plazo establece medidas sostenibles mientras te preparas para la erradicación:

Desplegar parches temporales o cambios de configuración para cerrar la vulnerabilidad explotada
Implementar monitoreo adicional en el vector de ataque
Establecer controles compensatorios para mantener la seguridad mientras se reconstruyen los controles primarios
Redirigir el tráfico lejos de los componentes comprometidos hacia sistemas conocidos como seguros

Consideraciones de contención específicas para SaaS:

Aislamiento multi-tenant. Si el incidente afecta a un tenant, verifica que tus controles de aislamiento de tenants impidieron el movimiento lateral a otros tenants. Si los controles de aislamiento pueden haber sido violados, trata a todos los tenants como potencialmente afectados.
Rotación de claves API. Las claves API comprometidas pueden estar incrustadas en aplicaciones de clientes. Coordina con los clientes afectados antes de rotar las claves para evitar interrupciones de servicio en cascada.
Entornos de infraestructura como código. Si el atacante modificó las configuraciones de infraestructura, tu contención debe incluir la reversión de los cambios de infraestructura y asegurar que el atacante no introdujo mecanismos de acceso persistente en tus repositorios de IaC.
Compromiso del pipeline CI/CD. Si el pipeline de compilación o despliegue fue comprometido, todos los artefactos producidos por ese pipeline durante la ventana de compromiso deben considerarse contaminados.

Cuándo poner los servicios fuera de línea. Esta es una de las decisiones más difíciles durante un incidente. Poner un servicio fuera de línea detiene el ataque pero también detiene las operaciones de tus clientes. Considera poner los servicios fuera de línea cuando la exfiltración activa de datos está ocurriendo y no puede detenerse de otra manera, cuando el atacante tiene acceso persistente que no puede ser contenido en su lugar, o cuando continuar operando pondría en riesgo datos adicionales de clientes.

Fase 4: Erradicación y Recuperación

Una vez que el incidente está contenido, elimina la causa raíz y restaura las operaciones normales.

Análisis de causa raíz. Determina exactamente cómo ocurrió el incidente. Las causas raíz comunes en incidentes SaaS incluyen:

Vulnerabilidades sin parchear en el código de la aplicación, frameworks o infraestructura
Recursos en la nube mal configurados (políticas IAM excesivamente permisivas, buckets de almacenamiento públicos, configuraciones de red inseguras)
Credenciales comprometidas, a menudo por reutilización de credenciales, phishing o credential stuffing
Dependencias de terceros vulnerables
Validación de entrada insuficiente que permite ataques de inyección
Ingeniería social que eludió la formación en concienciación de seguridad

Acciones de erradicación. Basándose en la causa raíz:

Parchear la vulnerabilidad explotada en todos los sistemas afectados
Eliminar todos los mecanismos de acceso no autorizado (puertas traseras, claves SSH no autorizadas, roles IAM no autorizados, código malicioso)
Reconstruir los sistemas comprometidos a partir de imágenes conocidas como buenas o despliegues limpios en lugar de intentar limpiar los sistemas comprometidos in situ
Rotar todas las credenciales que puedan haber sido expuestas, incluyendo cuentas de servicio, claves API, credenciales de base de datos y claves de cifrado
Actualizar las reglas del firewall, configuraciones de WAF y ajustes de grupos de seguridad para prevenir el mismo vector de ataque

Validación de la recuperación. Antes de declarar el incidente resuelto y restaurar el servicio completo:

Verificar que la vulnerabilidad está completamente parcheada en todos los sistemas y entornos afectados
Confirmar que todos los mecanismos de acceso no autorizado han sido eliminados
Validar la integridad de los datos comparando con copias de respaldo limpias
Ejecutar escaneos de seguridad en los sistemas restaurados
Confirmar que el monitoreo y las alertas están operativas en los sistemas restaurados
Verificar que todas las credenciales han sido rotadas y las credenciales antiguas están completamente invalidadas

Período de monitoreo intensificado. Después de la recuperación, mantén un monitoreo mejorado durante al menos 30 días. Los atacantes sofisticados a menudo establecen múltiples mecanismos de persistencia, y erradicar uno no garantiza que los demás hayan sido encontrados. Vigila los indicadores de re-compromiso: patrones de autenticación inusuales, ejecución de procesos inesperada, tráfico de red anómalo o cambios de configuración no autorizados.

Fase 5: Revisión Post-Incidente

El control A.5.27 requiere que aprendas de los incidentes. La revisión post-incidente es donde ocurre ese aprendizaje, y es uno de los elementos que los auditores examinan más cuidadosamente porque conecta la gestión de incidentes con tus procesos de mejora continua.

Temporización. Realiza la revisión post-incidente dentro de los 5 días hábiles posteriores a la resolución del incidente mientras los detalles aún están frescos. Para incidentes P1, considera programar una breve revisión inicial dentro de 24-48 horas, seguida de un análisis más exhaustivo una vez que el equipo haya tenido tiempo de compilar datos.

Cultura sin culpas. La revisión debe enfocarse en factores sistémicos, no en culpa individual. Si las personas tienen miedo de ser honestas sobre lo que sucedió y lo que hicieron o dejaron de hacer, la revisión perderá las perspectivas que previenen futuros incidentes. Documenta los factores contribuyentes, no la persona que hizo clic en el enlace de phishing.

Qué documentar:

Cronología — Una reconstrucción detallada y con marcas de tiempo del incidente desde el primer indicador hasta la resolución completa. Incluye cuándo se detectó el evento, cuándo se clasificó como incidente, cuándo se logró la contención y cuándo se confirmó la recuperación.
Causa raíz — La causa raíz técnica y los factores contribuyentes que la permitieron (brechas de procesos, puntos ciegos de monitoreo, deficiencias de formación, debilidades arquitectónicas).
Evaluación de impacto — Cuantifica el impacto: número de registros expuestos, número de clientes afectados, duración de la interrupción del servicio, costo financiero (directo e indirecto), implicaciones regulatorias.
Efectividad de la respuesta — ¿Qué salió bien? ¿Qué podría haberse hecho más rápido o mejor? ¿Los procedimientos fueron adecuados? ¿El equipo tenía las herramientas y la información que necesitaba?
Elementos de acción — Mejoras específicas, asignadas y con plazos definidos. Cada elemento de acción debe tener un propietario y una fecha límite. Los elementos de acción que nunca se completan son peores que no tener elementos de acción — señalan a los auditores que tu proceso de mejora es performativo en lugar de genuino.

Retroalimentar los hallazgos en el ISMS. Los hallazgos post-incidente deben fluir de vuelta a múltiples procesos del ISMS:

Actualizar tu evaluación de riesgos si el incidente reveló riesgos previamente no identificados o demostró que los riesgos existentes fueron calificados demasiado bajo
Revisar controles y procedimientos basándose en las debilidades identificadas
Actualizar el contenido de formación para abordar las brechas de habilidades o concienciación reveladas por el incidente
Considerar si el incidente afecta tu Declaración de Aplicabilidad o la selección de controles

Procedimientos de Reporte y Escalación

ISO 27001 requiere que definas y comuniques procedimientos de escalación para que los incidentes lleguen a las personas correctas en el momento adecuado.

Escalación Interna

Matriz de escalación basada en gravedad. Define quién es notificado en cada nivel de gravedad:

Gravedad	Notificación Inmediata	Dentro de 1 Hora	Dentro de 4 Horas
P1	Equipo de Respuesta a Incidentes, CISO/Líder de Seguridad, CTO	CEO, Asesor Legal, Líder de Éxito del Cliente	Junta (si se confirma brecha de datos)
P2	Equipo de Respuesta a Incidentes, Líder de Seguridad	Gerente de Ingeniería, Asesor Legal	CISO, CTO
P3	Analista de Seguridad de Guardia	Líder de Seguridad	Gerente de Ingeniería
P4	Analista de Seguridad de Guardia	Líder de Seguridad (siguiente día hábil)	—

Autoridad de escalación. Cualquier persona en la organización debe poder reportar un evento de seguridad. Sin embargo, la autoridad para declarar un incidente (activando los procedimientos formales de respuesta) y para escalar la gravedad debe estar definida. Típicamente, el analista de seguridad o ingeniero de guardia puede declarar incidentes P3 y P4, mientras que las declaraciones P1 y P2 requieren confirmación del líder de seguridad o comandante de incidentes. Fundamentalmente, la escalación nunca debe retrasarse porque la autoridad designada no está disponible — define autoridades de respaldo para cada rol.

Reporte Externo

Notificación regulatoria. Si el incidente involucra datos personales de residentes de la UE, el Artículo 33 del GDPR requiere notificación a la autoridad supervisora dentro de las 72 horas de haberse dado cuenta de la brecha. El Artículo 34 puede requerir notificación directa a los individuos afectados si la brecha plantea un alto riesgo para sus derechos y libertades. Tus procedimientos de respuesta a incidentes deben incluir pasos específicos para evaluar las obligaciones de notificación del GDPR y ejecutar las notificaciones dentro de los plazos requeridos. Consulta nuestra guía completa de notificación de brecha de datos GDPR para requisitos detallados.

Notificación al cliente. Para las empresas SaaS, la notificación al cliente es a menudo tanto una obligación contractual como un imperativo de confianza. Tus procedimientos deben definir:

Criterios para determinar qué clientes deben ser notificados
Plazos de notificación (a menudo definidos en tu DPA o acuerdo de servicio — consulta nuestra guía de DPA GDPR)
Canales de comunicación (correo electrónico, página de estado, notificación en la aplicación, teléfono para cuentas críticas)
Requisitos de contenido (qué sucedió, qué datos fueron afectados, qué estás haciendo al respecto, qué deben hacer los clientes)
Cadencia de comunicación de seguimiento

Fuerzas del orden. Algunos incidentes pueden justificar la participación de las fuerzas del orden — particularmente si se sospecha actividad criminal (ransomware, robo deliberado de datos, amenaza interna). Tus procedimientos deben definir los criterios para la notificación a las fuerzas del orden e identificar quién dentro de tu organización tiene autoridad para contactar a las fuerzas del orden.

Preservación de Evidencia

El control A.5.28 aborda específicamente la recopilación y preservación de evidencia. Para las empresas SaaS, esto es particularmente importante porque tu infraestructura existe en entornos de nube donde la evidencia puede ser efímera.

Principios de preservación de evidencia:

Recopila temprano. Comienza la recopilación de evidencia tan pronto como se sospeche un incidente, no después de que se confirme. La evidencia que no se recopila no puede analizarse después.
Mantén la cadena de custodia. Documenta quién recopiló cada pieza de evidencia, cuándo, cómo y dónde fue almacenada. Si la evidencia puede usarse en procedimientos legales, la documentación de la cadena de custodia debe ser rigurosa.
Preserva la integridad. No modifiques la evidencia durante la recopilación. Usa herramientas de imagen forense que creen copias exactas. Calcula y registra valores hash (SHA-256) para toda la evidencia recopilada para probar que no fue alterada después de la recopilación.
Almacenamiento seguro. Almacena la evidencia en una ubicación accesible solo para personal autorizado. La evidencia almacenada en el mismo entorno que fue comprometido no es segura.

Tipos de evidencia específicos de SaaS a preservar:

Logs de auditoría en la nube — CloudTrail, GCP Audit Logs, Azure Activity Logs. Estos logs pueden tener límites de retención — asegúrate de preservarlos antes de que roten.
Logs de aplicación — Logs de acceso a API, logs de autenticación, logs de autorización, logs de errores. Centralízalos antes de que sean sobrescritos por la rotación normal de logs.
Logs de auditoría de base de datos — Logs de consultas que muestran qué datos fueron accedidos, por quién y cuándo.
Logs de flujo de red — Logs de flujo de VPC, logs del balanceador de carga, logs de WAF mostrando patrones de tráfico.
Logs de contenedores y orquestación — Logs de auditoría de Kubernetes, logs de contenedores Docker, registros de despliegue.
Historial de infraestructura como código — Historial de Git para Terraform, CloudFormation u otros repositorios de IaC mostrando cualquier modificación no autorizada.
Registros de correo electrónico y comunicaciones — Relevantes para incidentes de ingeniería social. Preserva el correo electrónico de phishing, los encabezados del mensaje y cualquier comunicación que el atacante tuvo con los empleados.
Estado del sistema — Volcados de memoria, imágenes de disco, listas de procesos en ejecución, estados de conexión de red. En entornos de nube, crea snapshots de las instancias afectadas antes de terminarlas.

Esquema de Plantilla de Política de Gestión de Incidentes

Tu política de gestión de incidentes es un documento requerido dentro de tu ISMS. Debe ser revisada y aprobada por la alta dirección, comunicada a todo el personal relevante y revisada al menos anualmente. Aquí hay un esquema estructural alineado con los requisitos de ISO 27001.

1. Propósito y alcance — Define el objetivo de la política (gestión sistemática de incidentes de seguridad de la información) y su alcance (todos los sistemas, datos y personal dentro del alcance del ISMS).

2. Definiciones — Define evento de seguridad de la información, incidente de seguridad de la información y niveles de gravedad de incidentes. Usa las definiciones de ISO 27000 como punto de partida y adáptalas al contexto de tu organización.

3. Roles y responsabilidades — Define los roles del equipo de respuesta a incidentes (Comandante de Incidente, Líder Técnico, Líder de Comunicaciones, Escriba), identifica quién llena cada rol y establece asignaciones de respaldo. Define responsabilidades para todos los empleados (obligaciones de reporte, preservación de evidencia).

4. Clasificación de incidentes — Documenta tus niveles de gravedad (P1-P4), los criterios para cada nivel y los requisitos de escalación y respuesta asociados con cada uno.

5. Procedimientos de respuesta — Referencia tus guías de respuesta detalladas para cada tipo de incidente. La política establece el marco; las guías proporcionan procedimientos paso a paso.

6. Comunicación y notificación — Define las vías de escalación interna, obligaciones de notificación externa (regulatoria, cliente, fuerzas del orden), plantillas de comunicación y flujos de aprobación para comunicaciones externas.

7. Manejo de evidencia — Define los procedimientos de recopilación de evidencia, requisitos de cadena de custodia, ubicaciones de almacenamiento seguro y períodos de retención.

8. Revisión post-incidente — Requiere revisiones post-incidente para todos los incidentes P1 y P2, define el proceso de revisión y establece la conexión entre los hallazgos de la revisión y las acciones correctivas.

9. Pruebas y ejercicios — Define la frecuencia y tipos de pruebas de respuesta a incidentes (ejercicios de mesa, simulaciones, ejercicios de equipo rojo) y el requisito de documentar los resultados de las pruebas y las mejoras.

10. Métricas e informes — Define los KPI de gestión de incidentes que se reportan a la dirección y se revisan como parte del proceso de revisión por la dirección.

Esta política debe integrarse con tu marco de políticas del ISMS más amplio y ser referenciada en tu lista de verificación de certificación.

Ejercicios de Mesa

Los ejercicios de mesa son la forma más práctica de probar tus procedimientos de respuesta a incidentes sin impactar los sistemas de producción. Los auditores de ISO 27001 ven favorablemente a las organizaciones que regularmente ejercitan sus capacidades de respuesta.

Estructura de un ejercicio de mesa:

Briefing del escenario — El facilitador presenta un escenario de incidente realista relevante para tu organización. Para empresas SaaS, los escenarios deben estar basados en incidentes del mundo real en tu industria.
Inyecciones por fases — El facilitador revela nueva información en etapas, simulando cómo un incidente se desarrolla en la realidad. Cada inyección obliga al equipo a reevaluar, tomar decisiones y ejecutar acciones.
Discusión del equipo — En cada fase, el equipo de respuesta discute qué haría, a quién contactaría, qué información necesita y qué decisiones necesita tomar. Esto revela brechas en los procedimientos, responsabilidades poco claras y capacidades faltantes.
Debriefing — Después de que concluye el escenario, el equipo revisa qué funcionó, qué no y qué necesita cambiar. Esto produce una lista de acciones similar a una revisión post-incidente.

Escenarios de ejercicio de mesa recomendados para empresas SaaS:

Brecha de datos de clientes — Un atacante explota una vulnerabilidad de inyección SQL para exfiltrar registros de clientes. Prueba procedimientos de detección, contención, notificación al cliente y notificación de brecha GDPR.
Ransomware — El ransomware cifra las bases de datos de producción y el atacante exige pago. Prueba procedimientos de respaldo y recuperación, continuidad del negocio, toma de decisiones ejecutivas y comunicación con clientes.
Compromiso de cadena de suministro — Se descubre que una dependencia de código abierto ampliamente utilizada contiene código malicioso que ha estado presente en tu entorno de producción durante semanas. Prueba la evaluación de vulnerabilidades, el análisis del radio de impacto y la remediación a escala.
Amenaza interna — Se descubre que un empleado que se va ha estado exfiltrando datos propietarios durante meses. Prueba procedimientos de revisión de acceso, capacidades de investigación forense, coordinación legal e involucramiento de RRHH.
Compromiso de infraestructura en la nube — Un atacante obtiene acceso a tu consola de gestión en la nube a través de una cuenta de servicio comprometida. Prueba procedimientos de respuesta específicos de la nube, verificación de integridad de infraestructura como código y validación de aislamiento multi-tenant.
Ataque DDoS — Un ataque DDoS sostenido satura tu aplicación, haciéndola no disponible para los clientes. Prueba procedimientos de incidentes de disponibilidad, conmutación por error de CDN/WAF, comunicación con clientes y evaluación de impacto en SLA.

Frecuencia y documentación. Realiza ejercicios de mesa al menos dos veces al año, rotando entre diferentes escenarios. Documenta cada ejercicio: el escenario presentado, participantes, decisiones tomadas, brechas identificadas y elementos de acción resultantes. Esta documentación sirve como evidencia de auditoría de tu programa de pruebas.

Escenarios de Incidentes Específicos de SaaS

Las empresas SaaS enfrentan tipos de incidentes que las organizaciones tradicionales on-premises pueden no encontrar. Tu marco de gestión de incidentes debe dar cuenta de estos.

Exposición de Datos Multi-Tenant

Un defecto de código o una mala configuración causa que un tenant vea los datos de otro tenant. Este es uno de los incidentes más dañinos para una empresa SaaS porque socava la confianza fundamental de que los datos del cliente están aislados.