Modelos y registros · ISO 20000 · Apartado 8.6.1
Registro de incidencias TI según ISO 20000-1
Cada interrupción no planificada de un servicio o pérdida de su calidad, desde que se detecta hasta que se cierra, con un tratamiento especial para las graves.
En una frase
El registro de incidencias anota cada interrupción o degradación de un servicio con su clasificación, su prioridad según impacto y urgencia, el escalado, las acciones tomadas, la resolución y el cierre, y trata las incidencias graves con un procedimiento documentado, responsable asignado, aviso a la dirección e informe posterior, porque el apartado 8.6.1 de ISO/IEC 20000-1 exige registrar, clasificar, priorizar, escalar, resolver y cerrar cada incidencia.
- Dónde lo pide la norma
- ISO 20000 · Apartado 8.6.1 Los apartados se citan con la numeración de ISO/IEC 20000-1:2018, la edición vigente y la misma que usa la Academia.
- Tipo de información
- Registro obligatorio Registro de cada incidencia y de las acciones tomadas (8.6.1)
- Quién lo rellena
- Centro de servicio Los grupos de soporte resuelven; el gestor de incidencias graves coordina cuando aplica
- Cuándo
- En cuanto se detecta o se comunica Incluidas las detectadas por la monitorización antes de que las note el cliente
- Cuánto se conserva
- Lo fija la organización La norma pide controlar la conservación y la eliminación de la información documentada (7.5.3) sin fijar plazos. Lo habitual es cubrir al menos el ciclo de certificación de tres años, o el plazo del contrato con el cliente si es mayor.
Qué pide la norma
Lo que exige ISO 20000 y lo que deja a tu criterio
Las incidencias se registran y clasifican, se priorizan teniendo en cuenta su impacto y su urgencia, se escalan si es necesario, se resuelven y se cierran. El registro se actualiza con las acciones tomadas.
La organización define qué es una incidencia grave. Estas se gestionan con un procedimiento documentado: se informa a la alta dirección, se asigna una persona responsable y, una vez resueltas, se hace un informe y se revisan las oportunidades de mejora.
La norma separa incidencias de peticiones de servicio (8.6.2): una solicitud de alta de usuario no es una incidencia y no debe contar para su SLA.
Estructura
Campos que debe tener el modelo
- Número, fecha y hora de registro
- Origen: usuario, monitorización, proveedor
- Servicio y elemento de configuración afectados
- Descripción y síntomas
- Categoría
- Impacto, urgencia y prioridad resultante
- Grupo asignado y escalados
- Acciones tomadas y comunicaciones al usuario
- Resolución, causa aparente y enlace a problema
- Hora de resolución, confirmación del usuario y cierre
- Si es grave: responsable, aviso a dirección e informe posterior
Ejemplo
Ejemplo: incidencia grave por caída del correo
Empresa, personas y cifras inventadas: el ejemplo solo enseña cómo queda un registro bien cumplimentado.
| Campo | Contenido |
|---|---|
| Número | INC-26-0318 · 14 de abril de 2026, 09:02 · alerta de monitorización |
| Servicio | SRV-04 correo y colaboración · elemento CI-MAIL-01 |
| Síntomas | Los clientes de correo no conectan: error de certificado |
| Prioridad | Impacto alto (todos los usuarios) · urgencia alta · P1 · grave |
| Responsable | Gestor de incidencias graves · aviso a dirección a las 09:10 |
| Resolución | Renovación del certificado a las 10:20 · servicio restablecido |
| Duración | 78 minutos · dentro del objetivo de P1, pero afecta a la disponibilidad mensual |
| Informe | Informe de incidencia grave del 16 de abril · problema PRB-26-021 abierto |
En la auditoría
Errores que suelen señalar los auditores
- Peticiones y consultas registradas como incidencias, que distorsionan los indicadores.
- Prioridad asignada por quién llama y no por impacto y urgencia.
- Incidencias cerradas sin confirmación del usuario.
- Incidencias graves sin informe posterior ni revisión de mejoras.
- No se vinculan las incidencias repetidas a un problema.
En Kimobox
Cómo se lleva este registro en Kimobox
- 1Cada incidencia se registra con su prioridad y su tiempo de resolución.
- 2Las incidencias recurrentes se vinculan a un registro de problema con su análisis de causa raíz.
- 3Las peticiones de servicio se gestionan desde el portal de clientes o de empleados.
- 4El cumplimiento frente al SLA se ve en el cuadro de mando.
Preguntas frecuentes
Lo que nos preguntan antes de empezar
¿Qué diferencia hay entre incidencia y petición de servicio?
La incidencia es una interrupción no planificada o una pérdida de calidad del servicio; la petición es una solicitud de algo que el servicio ya prevé, como un alta de usuario o un cambio de contraseña. ISO/IEC 20000-1 las trata en apartados distintos.
¿Quién decide qué es una incidencia grave?
La organización, con criterios documentados —por ejemplo, número de usuarios afectados o servicios críticos caídos— y, a menudo, acordados con el cliente.
Lleva los registros de ISO 20000 sin plantillas sueltas
Te enseñamos el módulo funcionando con datos parecidos a los tuyos.
Sigue explorando
Páginas relacionadas
Entrega y soporte del servicio
Este bloque cubre la operación diaria: la resolución de incidencias, la gestión de problemas y la atención…
Modelo de catálogo de servicios TI según ISO 20000-1
Qué debe incluir el catálogo de servicios que pide ISO/IEC 20000-1: descripción, resultados previstos…
Modelo de acuerdo de nivel de servicio (SLA) ISO 20000-1
Qué debe recoger un SLA según ISO/IEC 20000-1 (8.3.3): servicios, objetivos de nivel, límites de carga…
Modelo de informe de nivel de servicio ISO 20000-1
Qué debe contener el informe de servicio que pide ISO/IEC 20000-1: cumplimiento de SLA, carga, incidencias…
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 20000-1:2018 — Gestión del servicio. Requisitos del sistema de gestión del servicio ISO/IEC · Septiembre de 2018