Modelos e registos · ISO 20000 · Cláusula 8.6.1

Registo de incidentes de TI segundo a ISO 20000-1

Cada interrupção não planeada de um serviço ou perda da sua qualidade, desde que é detetada até ser encerrada, com um tratamento especial para as graves.

Numa frase

O registo de incidentes anota cada interrupção ou degradação de um serviço com a sua classificação, a sua prioridade segundo o impacto e a urgência, a escalada, as ações tomadas, a resolução e o encerramento, e trata os incidentes graves com um procedimento documentado, responsável atribuído, aviso à gestão de topo e relatório posterior, porque a cláusula 8.6.1 da ISO/IEC 20000-1 exige que cada incidente seja registado, classificado, priorizado, escalado, resolvido e encerrado.

Conteúdo revisto em 17 de outubro de 2026

Onde a norma o exige: ISO 20000 · Cláusula 8.6.1 As cláusulas são citadas com a numeração da ISO/IEC 20000-1:2018, a edição em vigor e a mesma que a Academia utiliza.
Tipo de informação: Registo obrigatório Registo de cada incidente e das ações tomadas (8.6.1)
Quem o preenche: Centro de serviço Os grupos de suporte resolvem; o gestor de incidentes graves coordena quando aplicável
Quando: Logo que é detetado ou comunicado Incluindo os detetados pela monitorização antes de o cliente os notar
Durante quanto tempo se conserva: Definido pela organização A norma pede que se controlem a conservação e a eliminação da informação documentada (7.5.3) sem fixar prazos. O habitual é cobrir pelo menos o ciclo de certificação de três anos, ou o prazo do contrato com o cliente se for maior.

O que a norma exige

O que o referencial ISO 20000 exige e o que fica ao seu critério

Os incidentes são registados e classificados, priorizados tendo em conta o seu impacto e a sua urgência, escalados se necessário, resolvidos e encerrados. O registo é atualizado com as ações tomadas.

A organização define o que é um incidente grave. Estes são geridos com um procedimento documentado: informa-se a gestão de topo, atribui-se uma pessoa responsável e, uma vez resolvidos, faz-se um relatório e revêem-se as oportunidades de melhoria.

A norma separa os incidentes dos pedidos de serviço (8.6.2): um pedido de criação de utilizador não é um incidente e não deve contar para o seu SLA.

Leia-o em contexto: Entrega e suporte do serviço, na Academia (ISO 20000)

Estrutura

Campos que o modelo deve ter

Número, data e hora de registo
Origem: utilizador, monitorização, fornecedor
Serviço e item de configuração afetados
Descrição e sintomas
Categoria
Impacto, urgência e prioridade resultante
Grupo atribuído e escaladas
Ações tomadas e comunicações ao utilizador
Resolução, causa aparente e ligação a um problema
Hora de resolução, confirmação do utilizador e encerramento
Se for grave: responsável, aviso à gestão de topo e relatório posterior

Exemplo

Exemplo: incidente grave por falha do correio eletrónico

Empresa, pessoas e números fictícios: o exemplo serve apenas para mostrar como fica um registo bem preenchido.

Campo	Conteúdo
Número	INC-26-0318 · 14 de abril de 2026, 09:02 · alerta de monitorização
Serviço	SRV-04 correio eletrónico e colaboração · item CI-MAIL-01
Sintomas	Os clientes de correio não se ligam: erro de certificado
Prioridade	Impacto alto (todos os utilizadores) · urgência alta · P1 · grave
Responsável	Gestor de incidentes graves · aviso à gestão de topo às 09:10
Resolução	Renovação do certificado às 10:20 · serviço restabelecido
Duração	78 minutos · dentro do objetivo de P1, mas afeta a disponibilidade mensal
Relatório	Relatório de incidente grave de 16 de abril · problema PRB-26-021 aberto

Na auditoria

Erros que os auditores costumam apontar

Pedidos e consultas registados como incidentes, que distorcem os indicadores.
Prioridade atribuída segundo quem liga e não segundo o impacto e a urgência.
Incidentes encerrados sem confirmação do utilizador.
Incidentes graves sem relatório posterior nem revisão de melhorias.
Os incidentes repetidos não são associados a um problema.

No Kimobox

Como se gere este registo no Kimobox

1Cada incidente é registado com a sua prioridade e o seu tempo de resolução.
2Os incidentes recorrentes são associados a um registo de problema com a respetiva análise de causa raiz.
3Os pedidos de serviço são geridos a partir do portal de clientes ou do Portal do Colaborador.
4O cumprimento face ao SLA é visível no painel de controlo.

Perguntas frequentes

O que nos perguntam antes de começar

Que diferença há entre incidente e pedido de serviço?

O incidente é uma interrupção não planeada ou uma perda de qualidade do serviço; o pedido é uma solicitação de algo que o serviço já prevê, como a criação de um utilizador ou uma mudança de palavra-passe. A ISO/IEC 20000-1 trata-os em cláusulas distintas.

Quem decide o que é um incidente grave?

A organização, com critérios documentados —por exemplo, número de utilizadores afetados ou serviços críticos em falha— e, muitas vezes, acordados com o cliente.

Faça a gestão dos registos do referencial ISO 20000 sem modelos avulsos

Mostramos-lhe o módulo a funcionar com dados semelhantes aos seus.

Pedir uma demonstração

Continue a explorar