Gestión de Incidentes de Seguridad según ISO 27001

Los incidentes de seguridad son inevitables. La pregunta no es si tu organización sufrirá un incidente, sino cuándo y qué tan preparada estará para responder. Los controles A.5.24 a A.5.28 de ISO 27001:2022 establecen los requisitos para la gestión de incidentes de seguridad de la información, desde la planificación previa hasta las lecciones aprendidas.

Los cinco controles de gestión de incidentes

Control	Nombre	Descripción
A.5.24	Planificación y preparación para la gestión de incidentes	Establece el proceso antes de que ocurra un incidente
A.5.25	Evaluación y decisión sobre eventos de seguridad	Determina si un evento es un incidente real
A.5.26	Respuesta a incidentes de seguridad	Contención, erradicación y recuperación
A.5.27	Aprendizaje de los incidentes de seguridad	Lecciones aprendidas y mejora continua
A.5.28	Recopilación de evidencia	Preservación forense de evidencia

Fase 1: Planificación y preparación (A.5.24)

Antes de que ocurra un incidente, debes tener definido:

El proceso de gestión de incidentes: Procedimiento documentado con pasos claros para detectar, reportar, clasificar, responder y cerrar incidentes
El equipo de respuesta: Quién hace qué cuando ocurre un incidente (CSIRT interno o contactos externos de respuesta)
Los canales de reporte: Cómo reporta un empleado un incidente (correo, formulario, teléfono de guardia)
La clasificación de incidentes: Criterios para determinar la gravedad
Los procedimientos de escalamiento: Cuándo y a quién escalar según la gravedad
Los contactos externos: CSIRT nacional, proveedores de respuesta a incidentes, autoridades regulatorias, aseguradoras cyber

Clasificación de incidentes por gravedad

Nivel	Criterio	Tiempo de respuesta
Crítico	Afecta sistemas críticos o datos masivos; posible ransomware, exfiltración o violación regulatoria	Inmediata (30 min)
Alto	Acceso no autorizado a datos confidenciales o sistemas importantes	2 horas
Medio	Malware contenido, phishing exitoso sin exfiltración confirmada	4 horas laborales
Bajo	Violación de política sin impacto en datos, eventos sospechosos sin confirmar	Próximo día hábil

Fase 2: Detección y evaluación (A.5.25)

Un evento de seguridad es cualquier ocurrencia que indica una posible violación de la política de seguridad. Un incidente es un evento que ha causado o que podría causar un impacto negativo en la confidencialidad, integridad o disponibilidad de la información.

El proceso de evaluación determina:

¿Es este evento un falso positivo o un incidente real?
¿Qué sistemas o datos están afectados?
¿Cuál es la gravedad inicial?
¿Requiere escalamiento inmediato?

Canal de reporte claro: El control A.6.8 (controles de personas) exige que todo el personal conozca el mecanismo de reporte de eventos. Un número de teléfono, un correo dedicado y un formulario interno accesible desde cualquier dispositivo son los mecanismos más comunes.

Fase 3: Respuesta al incidente (A.5.26)

La respuesta a un incidente sigue las etapas PICERL:

Preparación

Realizada antes del incidente (ver Fase 1). Si estás en esta fase durante un incidente activo, ya es demasiado tarde para algunos elementos.

Identificación

Confirma que el evento es un incidente real. Identifica el alcance inicial: ¿qué sistemas están afectados? ¿Qué datos podrían estar comprometidos?

Contención

Detén la propagación del incidente. Esto puede incluir aislar sistemas de la red, bloquear cuentas comprometidas, bloquear direcciones IP maliciosas, suspender procesos específicos.

Erradicación

Elimina la causa raíz: eliminar malware, parchear la vulnerabilidad explotada, cerrar el acceso no autorizado, limpiar configuraciones alteradas.

Recuperación

Restaura los sistemas al estado operativo normal, verificando que el incidente está completamente resuelto antes de volver a producción. Monitorea de cerca los sistemas recuperados.

Lecciones aprendidas

Ver Fase 5.

Fase 4: Recopilación de evidencia (A.5.28)

Si hay posibilidad de acciones legales o disciplinarias derivadas del incidente, la preservación de evidencia forense es crítica. Principios básicos:

No modificar los sistemas originales antes de hacer copias forenses
Documentar la cadena de custodia de la evidencia
Capturar imágenes de memoria RAM y disco antes de apagar sistemas
Preservar logs en formatos inmutables
Documentar todas las acciones tomadas durante la respuesta con hora y responsable

Fase 5: Lecciones aprendidas (A.5.27)

Después de cada incidente significativo, realiza una reunión post-incidente (post-mortem) dentro de los 5-10 días hábiles posteriores al cierre. El resultado debe ser un informe que incluya:

Cronología del incidente
Causa raíz identificada
Impacto real (datos afectados, tiempo de inactividad, costos)
Qué funcionó bien en la respuesta
Qué se puede mejorar
Acciones correctivas con responsable y fecha

Obligaciones de notificación

Dependiendo del tipo de incidente y la regulación aplicable, puede haber obligaciones de notificación:

Ley 21.663 de Ciberseguridad: Incidentes de significación en operadores de importancia vital deben notificarse a la ANCI
Ley 19.628 y su reforma: Brechas de datos personales pueden requerir notificación a titulares y a la autoridad de control
Contratos con clientes: Muchos contratos incluyen cláusulas de notificación ante brechas de datos

Plazo crítico: La Ley de Ciberseguridad establece plazos muy acotados para la notificación de incidentes. Verifica los plazos aplicables a tu organización antes de sufrir un incidente, no durante.

Gestiona incidentes de seguridad con GRC360

GRC360 incluye un módulo de gestión de incidentes de seguridad que guía el proceso desde el reporte hasta el cierre, con registro de evidencias y generación de informes post-incidente.

Crear Cuenta Gratis

Profundiza en temas relacionados: controles tecnológicos A.8 (monitoreo), auditoría interna y Ley 21.663 de Ciberseguridad.