Modelos y registros · ISO 27001 · Apartado A.5.24 a A.5.28
Modelo de registro de incidentes de seguridad ISO 27001
La cronología de cada evento de seguridad, desde que alguien lo comunica hasta que se cierra y se aprende de él, con las evidencias preservadas.
En una frase
El registro de incidentes de seguridad documenta cada evento comunicado, la decisión de si es un incidente, la respuesta, las evidencias conservadas y las lecciones aprendidas; ISO/IEC 27001 no lo nombra como registro obligatorio, pero es la evidencia con la que se demuestran los controles 5.24 a 5.28 y 6.8 del Anexo A.
- Dónde lo pide la norma
- ISO 27001 · Apartado A.5.24 a A.5.28 Los apartados siguen ISO/IEC 27001:2022; los que empiezan por «A.» son controles del Anexo A, exigibles en la medida en que la declaración de aplicabilidad los incluya.
- Tipo de información
- Buena práctica Evidencia de los controles 5.24 a 5.28 y 6.8 del Anexo A
- Quién lo rellena
- Cualquiera comunica; seguridad gestiona El responsable de seguridad decide si el evento es un incidente y coordina la respuesta
- Cuándo
- Desde la comunicación del evento La cronología se completa durante la respuesta; las lecciones, al cerrar
- Cuánto se conserva
- Lo fija la organización ISO/IEC 27001 no da plazos: pide decidir la conservación y la eliminación de la información documentada (7.5.3). Cubrir el ciclo de certificación de tres años permite enseñar el histórico en la renovación.
Qué pide la norma
Lo que exige ISO 27001 y lo que deja a tu criterio
El Anexo A dedica cinco controles al ciclo del incidente: preparar la gestión (5.24), evaluar los eventos y decidir si son incidentes (5.25), responder según procedimientos (5.26), aprender de lo ocurrido (5.27) y recoger y preservar evidencias (5.28). El control 6.8 pide un canal para que el personal comunique los eventos.
Ninguno dice «registro», pero ninguno se puede demostrar sin él. El auditor pide ver incidentes concretos, con su cronología, y comprobar que el aprendizaje llegó al análisis de riesgos.
Cuando el incidente afecta a datos personales, el mismo registro debe permitir cumplir el plazo legal de notificación a la autoridad de control.
Estructura
Campos que debe tener el modelo
- Número, fecha y hora de comunicación, y quién lo comunica
- Descripción del evento y sistemas afectados
- Evaluación: ¿es un incidente? Clasificación y gravedad
- ¿Afecta a datos personales? Decisión sobre la notificación
- Cronología de la respuesta: contención, erradicación, recuperación
- Evidencias recogidas y dónde se custodian
- Causa y lecciones aprendidas
- Acciones derivadas y actualización del análisis de riesgos
- Fecha de cierre
Ejemplo
Ejemplo: credenciales robadas por suplantación
Empresa, personas y cifras inventadas: el ejemplo solo enseña cómo queda un registro bien cumplimentado.
| Campo | Contenido |
|---|---|
| Número y fecha | INC-2026-012 · 14 de abril de 2026, 09:40 |
| Comunicado por | Una técnica de soporte, tras introducir su contraseña en una web falsa |
| Evaluación | Incidente · gravedad media · sin acceso a datos de clientes según los registros |
| Datos personales | No afectados · no procede notificar · decisión razonada en el registro |
| Respuesta | 09:55 bloqueo de la cuenta · 10:20 revisión de accesos de las últimas 48 h · 11:00 cuenta restablecida con nuevo segundo factor |
| Evidencias | Registros del proveedor de identidad exportados y custodiados en el expediente |
| Lección | El segundo factor por SMS no frenó el intento: se sustituye por llave física para el personal de soporte |
| Riesgos | Se revalora el riesgo R-03 de acceso indebido |
En la auditoría
Errores que suelen señalar los auditores
- Solo se registran los incidentes graves: los eventos descartados no dejan rastro.
- No consta por qué un incidente con datos personales no se notificó.
- Las lecciones aprendidas no cambian nada en el análisis de riesgos.
- Las evidencias se guardan en el portátil de quien investigó.
En Kimobox
Cómo se lleva este registro en Kimobox
- 1Cada incidente de seguridad se registra con su clasificación, su cronología y su cierre con evidencia.
- 2Si exige acción correctiva, se abre como no conformidad con causa raíz obligatoria.
- 3La revisión por la dirección llega con los incidentes ya precargados.
Preguntas frecuentes
Lo que nos preguntan antes de empezar
¿Qué diferencia hay entre evento e incidente?
Un evento es cualquier hecho que podría afectar a la seguridad; un incidente es el evento que, tras evaluarlo, compromete o puede comprometer la información o su servicio. Ambos se registran: el evento descartado demuestra que el control 5.25 funciona.
¿Es lo mismo que una no conformidad?
No. El incidente es un hecho de seguridad; la no conformidad, un incumplimiento de un requisito. Un incidente puede revelar una no conformidad —un procedimiento que no se siguió— y entonces se abre también su acción correctiva.
Lleva los registros de ISO 27001 sin plantillas sueltas
Te enseñamos el módulo funcionando con datos parecidos a los tuyos.
Sigue explorando
Páginas relacionadas
Modelo de registro de incidentes según el ENS
Cómo registrar los incidentes según el ENS: clasificación, escalado, notificación al CERT competente…
Modelo de informe de no conformidad ISO 9001
Qué debe recoger un informe de no conformidad según ISO 9001 (10.2): descripción, corrección, causa raíz…
Operación
La operación traduce el análisis de riesgos en controles reales: accesos, cifrado, copias de seguridad y un…
Modelo de declaración de aplicabilidad ISO 27001
Qué debe recoger la declaración de aplicabilidad de ISO 27001 (6.1.3 d): controles necesarios…
Fuentes
De dónde sale cada dato
Referencias al texto oficial vigente. Si una norma se revisa, esta página se actualiza y la fecha de revisión lo refleja.
- ISO/IEC 27001:2022 — Sistemas de gestión de la seguridad de la información. Requisitos ISO/IEC · 25 de octubre de 2022
- ISO/IEC 27002:2022 — Controles de seguridad de la información ISO/IEC · Febrero de 2022
- Reglamento (UE) 2016/679, general de protección de datos EUR-Lex · 27 de abril de 2016