Templates and records · ISO 27001 · Clause A.5.24 a A.5.28
ISO 27001 information security incident log template
The timeline of every security event, from the moment someone reports it until it is closed and learned from, with the evidence preserved.
In one sentence
The security incident log documents every event reported, the decision on whether it is an incident, the response, the evidence preserved and the lessons learned; ISO/IEC 27001 does not name it as a mandatory record, but it is the evidence used to demonstrate Annex A controls 5.24 to 5.28 and 6.8.
- Where the standard requires it
- ISO 27001 · Clause A.5.24 a A.5.28 Clauses follow ISO/IEC 27001:2022; those beginning with “A.” are Annex A controls, required to the extent that the statement of applicability includes them.
- Type of information
- Good practice Evidence for Annex A controls 5.24 to 5.28 and 6.8
- Who fills it in
- Anyone reports; security manages The information security manager decides whether the event is an incident and coordinates the response
- When
- From the moment the event is reported The timeline is completed during the response; the lessons, at closure
- How long it is kept
- Set by the organisation ISO/IEC 27001 sets no periods: it asks you to decide on the retention and disposition of documented information (7.5.3). Covering the three-year certification cycle lets you show the history at recertification.
What the standard requires
What ISO 27001 demands and what it leaves to your judgement
Annex A devotes five controls to the incident lifecycle: planning and preparing for incident management (5.24), assessing events and deciding whether they are incidents (5.25), responding according to procedures (5.26), learning from what happened (5.27) and collecting and preserving evidence (5.28). Control 6.8 calls for a channel through which staff can report events.
None of them says “log”, but none can be demonstrated without one. The auditor asks to see specific incidents with their timeline and checks that the lessons reached the risk assessment.
When the incident affects personal data, the same log must make it possible to meet the legal deadline for notifying the supervisory authority.
Structure
Fields the template should include
- Reference number, date and time reported, and who reported it
- Description of the event and systems affected
- Assessment: is it an incident? Classification and severity
- Does it affect personal data? Decision on notification
- Response timeline: containment, eradication, recovery
- Evidence collected and where it is held
- Cause and lessons learned
- Resulting actions and update of the risk assessment
- Closing date
Example
Example: credentials stolen through phishing
Company, people and figures are fictitious: the example only shows what a properly completed record looks like.
| Field | Content |
|---|---|
| Reference and date | INC-2026-012 · 14 April 2026, 09:40 |
| Reported by | A support technician, after entering her password on a fake website |
| Assessment | Incident · medium severity · no access to customer data according to the logs |
| Personal data | Not affected · no notification required · reasoned decision in the log |
| Response | 09:55 account locked · 10:20 review of access over the last 48 h · 11:00 account restored with a new second factor |
| Evidence | Identity provider logs exported and held in the case file |
| Lesson | SMS-based second factor did not stop the attempt: replaced with a hardware key for support staff |
| Risks | Risk R-03 of unauthorised access is reassessed |
At the audit
Mistakes auditors commonly flag
- Only serious incidents are logged: discarded events leave no trace.
- There is no record of why an incident involving personal data was not notified.
- Lessons learned change nothing in the risk assessment.
- Evidence is kept on the investigator’s laptop.
In Kimobox
How this record is kept in Kimobox
- 1Each security incident is logged with its classification, its timeline and its closure with evidence.
- 2If it requires corrective action, it is opened as a nonconformity with root cause mandatory.
- 3The management review arrives with the incidents already preloaded.
Frequently asked questions
What people ask us before getting started
What is the difference between an event and an incident?
An event is anything that could affect security; an incident is an event that, once assessed, compromises or may compromise information or the service it supports. Both are logged: a discarded event shows that control 5.25 is working.
Is it the same as a nonconformity?
No. An incident is a security occurrence; a nonconformity is a failure to meet a requirement. An incident may reveal a nonconformity —a procedure that was not followed— and in that case its corrective action is opened as well.
Keep your ISO 27001 records without loose templates
We'll show you the module running with data similar to yours.
Keep exploring
Related pages
ENS incident log template
How to log incidents under the ENS: classification, escalation, reporting to the competent CERT, response…
ISO 9001 nonconformity report template
What an ISO 9001 nonconformity report (10.2) must record: description, correction, root cause, corrective…
Operation
Operation turns risk analysis into real controls: access, encryption, backups and a clear procedure for when…
ISO 27001 statement of applicability template
What the ISO 27001 statement of applicability (6.1.3 d) must contain: necessary controls, justification…
Sources
Where each figure comes from
References to the official text in force. If a standard is revised, this page is updated and the review date says so.
- ISO/IEC 27001:2022 — Information security management systems. Requirements ISO/IEC · 25 October 2022
- ISO/IEC 27002:2022 — Information security controls ISO/IEC · February 2022
- Regulation (EU) 2016/679, General Data Protection Regulation (GDPR) EUR-Lex · 27 April 2016