ENS desde dentro (XXVII): Registro de gestión de incidentes (op.exp.9) — qué campos tiene que tener un ticket de seguridad, y qué pasa con él cuando se cierra

Qué exige realmente op.exp.9 del ENS: qué campos mínimos debe tener el registro de un incidente, cuáles se completan al tratarlo, cuánto tiempo se conserva y cómo se demuestra que un incidente repetido genera una acción correctiva.

Gestionar un incidente es lo que haces en el momento. Registrarlo bien es lo que un auditor puede comprobar dos años después.

Este artículo forma parte de la serie ENS desde dentro.

👉 Puedes ver la guía completa aquí:

https://www.handersonboratto.com/ens-desde-dentro/

👉 Si es tu primera vez en la serie, empieza por aquí:

https://www.handersonboratto.com/blog/que-es-ens/

👉 O continúa con el artículo anterior:

https://www.handersonboratto.com/blog/ens-registro-actividad-usuario-op-exp-8/

En op.exp.7 vimos cómo se detecta, clasifica y escala un incidente. En op.exp.8 vimos los registros de actividad que permiten investigarlo. op.exp.9 cierra el círculo: qué queda escrito cuando todo ha terminado. Es el control que convierte una anécdota ("el EDR bloqueó algo el martes") en un expediente.

Qué exige realmente el control

El registro de cada incidente tiene dos momentos. En el primero, al abrirlo, hay un mínimo que no se puede dejar vacío: la clasificación, la fecha y hora de detección, la fecha y hora de notificación, la persona que lo recibe y el estado en que se encuentra.

El segundo momento es el del tratamiento. A medida que el incidente avanza se van completando las dimensiones de seguridad afectadas, la fecha y hora de cierre, las acciones realizadas, los efectos causados, el proceso de recuperación si hizo falta, la peligrosidad, el impacto potencial y el número y tipo de sistemas afectados.

Hay tres exigencias que casi nadie recuerda hasta que llegan a la auditoría. Primera: el incidente se sigue hasta su resolución, no hasta que se envía el primer correo. Segunda: si el incidente es repetitivo o relevante, se abre una acción correctiva por el procedimiento de gestión de no conformidades, no basta con cerrar el ticket. Tercera: los registros de incidentes se conservan, como mínimo, los últimos dos años.

El registro en la práctica

En la práctica, el registro es una tabla con una fila por incidente. Las columnas siguen casi literalmente la lista anterior: identificador, clasificación, fecha y hora de apertura, quién lo notifica, estado, fecha y hora de cierre, efectos, dimensiones afectadas, peligrosidad, impacto potencial, sistemas afectados, acciones llevadas a cabo y descripción del proceso de recuperación.

Lo útil es que casi todas las columnas son listas desplegables con valores cerrados: la clasificación sale de la taxonomía oficial, el estado solo puede ser abierto, pendiente de confirmar o cerrado, la peligrosidad va de baja a crítica y el impacto potencial se elige con los criterios de la tabla de impacto a la vista. Eso evita que dos personas clasifiquen el mismo incidente de forma distinta y hace que el registro se pueda filtrar y contar.

Los incidentes que acaban ahí suelen ser pequeños y reales: un fichero sospechoso en cuarentena automática, un proceso que intenta tocar la configuración del EDR, un correo de suplantación de identidad que el filtro de correo ha frenado. Pocos son dramáticos. Precisamente por eso el registro tiene que ser fácil de rellenar: si cuesta más registrarlo que resolverlo, no se registra.

Cómo se demuestra: la evidencia mínima

La evidencia que pide el control es doble y sencilla de reunir. Por un lado, una captura de pantalla de un ticket de incidente de seguridad real, con los campos visibles. Por otro, el propio registro de incidentes mantenido y actualizado.

Lo que mira un auditor cuando abre ese registro no es que existan filas, sino que estén completas y sean coherentes. Los fallos más habituales son tres. La columna de dimensiones afectadas, que se deja en blanco porque parece obvia. Las fechas sin hora, que impiden calcular cuánto tardó el cierre. Y los incidentes casi idénticos que aparecen dos o tres veces con la misma causa y la misma solución, sin ninguna acción correctiva que lo ataje.

Si hay un incidente de seguridad que afecta a datos personales o que requiere comunicación externa, el registro debe enlazar también con la notificación al DPD o a los organismos competentes. Y si hubo que recoger evidencias, la custodia —copias bit a bit, cadena de custodia, firmas forenses si se contrataron— tiene que poder reconstruirse.

La lección práctica

Si algo me llevo de este control es que un incidente bien resuelto pero mal registrado, a efectos de auditoría, es un incidente que no ocurrió. Y un incidente que se repite sin acción correctiva demuestra que el registro se usa como archivo, no como herramienta de mejora.

Mi recomendación: revisa tu registro una vez al trimestre con un solo criterio: busca causas repetidas. Si el mismo tipo de incidente aparece más de una vez, abre la acción correctiva y enlázala desde el propio registro. Ese solo gesto cambia el registro de un archivo muerto a la evidencia de que tu sistema de gestión aprende.

Este post forma parte de la serie "ENS desde dentro", donde comparto cómo se implementan y auditan en la práctica las medidas del Esquema Nacional de Seguridad. Si te está siendo útil, puedes suscribirte a la newsletter para recibir cada entrega, o descargar el checklist "Documentación para una auditoría ENS" con los 8 bloques de evidencia que un auditor va a pedirte.