Modelos e registos · ISO 27001 · Cláusula A.5.24 a A.5.28

Modelo de registo de incidentes de segurança ISO 27001

A cronologia de cada evento de segurança, desde que alguém o comunica até ser encerrado e dele se tirarem lições, com as evidências preservadas.

Numa frase

O registo de incidentes de segurança documenta cada evento comunicado, a decisão sobre se é um incidente, a resposta, as evidências conservadas e as lições aprendidas; a ISO/IEC 27001 não o designa como registo obrigatório, mas é a evidência com que se demonstram os controlos 5.24 a 5.28 e 6.8 do Anexo A.

Conteúdo revisto em 17 de outubro de 2026

Onde a norma o exige: ISO 27001 · Cláusula A.5.24 a A.5.28 As secções seguem a ISO/IEC 27001:2022; as que começam por «A.» são controlos do Anexo A, exigíveis na medida em que a declaração de aplicabilidade os inclua.
Tipo de informação: Boa prática Evidência dos controlos 5.24 a 5.28 e 6.8 do Anexo A
Quem o preenche: Qualquer pessoa comunica; a segurança gere O responsável de segurança decide se o evento é um incidente e coordena a resposta
Quando: A partir da comunicação do evento A cronologia completa-se durante a resposta; as lições, no encerramento
Durante quanto tempo se conserva: Definido pela organização A ISO/IEC 27001 não fixa prazos: pede que se decida a conservação e a eliminação da informação documentada (7.5.3). Abranger o ciclo de certificação de três anos permite mostrar o histórico na renovação.

O que a norma exige

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

O Anexo A dedica cinco controlos ao ciclo do incidente: preparar a gestão (5.24), avaliar os eventos e decidir se são incidentes (5.25), responder segundo procedimentos (5.26), aprender com o que aconteceu (5.27) e recolher e preservar evidências (5.28). O controlo 6.8 pede um canal para que o pessoal comunique os eventos.

Nenhum diz «registo», mas nenhum se pode demonstrar sem ele. O auditor pede para ver incidentes concretos, com a sua cronologia, e verificar que a aprendizagem chegou à análise de riscos.

Quando o incidente afeta dados pessoais, o mesmo registo deve permitir cumprir o prazo legal de notificação à autoridade de controlo.

Leia-o em contexto: Operacionalização, na Academia (ISO 27001)

Estrutura

Campos que o modelo deve ter

Número, data e hora da comunicação, e quem a fez
Descrição do evento e sistemas afetados
Avaliação: é um incidente? Classificação e gravidade
Afeta dados pessoais? Decisão sobre a notificação
Cronologia da resposta: contenção, erradicação, recuperação
Evidências recolhidas e onde estão guardadas
Causa e lições aprendidas
Ações daí decorrentes e atualização da análise de riscos
Data de encerramento

Exemplo

Exemplo: credenciais roubadas por phishing

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

Campo	Conteúdo
Número e data	INC-2026-012 · 14 de abril de 2026, 09:40
Comunicado por	Uma técnica de suporte, depois de introduzir a sua palavra-passe num site falso
Avaliação	Incidente · gravidade média · sem acesso a dados de clientes segundo os registos
Dados pessoais	Não afetados · não há lugar a notificação · decisão fundamentada no registo
Resposta	09:55 bloqueio da conta · 10:20 revisão dos acessos das últimas 48 h · 11:00 conta restabelecida com novo segundo fator
Evidências	Registos do fornecedor de identidade exportados e guardados no processo
Lição	O segundo fator por SMS não travou a tentativa: é substituído por chave física para o pessoal de suporte
Riscos	Reavalia-se o risco R-03 de acesso indevido

Na auditoria

Erros que os auditores costumam apontar

Só se registam os incidentes graves: os eventos descartados não deixam rasto.
Não consta porque é que um incidente com dados pessoais não foi notificado.
As lições aprendidas não mudam nada na análise de riscos.
As evidências ficam guardadas no portátil de quem investigou.

No Kimobox

Como se gere este registo no Kimobox

1Cada incidente de segurança é registado com a sua classificação, a sua cronologia e o seu encerramento com evidência.
2Se exigir ação corretiva, é aberto como não conformidade com causa raiz obrigatória.
3A revisão pela gestão chega com os incidentes já pré-carregados.

Perguntas frequentes

O que nos perguntam antes de começar

Que diferença há entre evento e incidente?

Um evento é qualquer facto que possa afetar a segurança; um incidente é o evento que, depois de avaliado, compromete ou pode comprometer a informação ou o serviço. Ambos se registam: o evento descartado demonstra que o controlo 5.25 funciona.

É o mesmo que uma não conformidade?

Não. O incidente é um facto de segurança; a não conformidade, o não cumprimento de um requisito. Um incidente pode revelar uma não conformidade —um procedimento que não foi seguido— e, nesse caso, abre-se também a respetiva ação corretiva.

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

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

Pedir uma demonstração

Continue a explorar

Páginas relacionadas

Fontes

De onde vem cada dado

Referências ao texto oficial em vigor. Se uma norma for revista, esta página é atualizada e a data de revisão reflete-o.

ISO/IEC 27001:2022 — Sistemas de gestão da segurança da informação. Requisitos ISO/IEC · 25 de outubro de 2022
ISO/IEC 27002:2022 — Controlos de segurança da informação ISO/IEC · Fevereiro de 2022
Regulamento (UE) 2016/679, Regulamento Geral sobre a Proteção de Dados EUR-Lex · 27 de abril de 2016