October 2026. Auditors and regulators often ask for the incident register first. It shows at a glance whether incident management works: are reports recorded, handled and evaluated? ISO 27001 (controls 5.24 to 5.28) and NIS2 build on it. Background at incident management.
Which fields to record
Keep it compact and consistent: date and time of report and discovery, reporter, short description, affected systems or data, severity and classification, people involved, measures taken, status, closing date, and whether an external notification was required. Add one field for the cause and one for the improvement action.
Watching notification deadlines
Under NIS2, significant incidents require an early warning within 24 hours, a notification within 72 hours and a final report within a month. For personal data the GDPR has its own 72-hour deadline for notifying the supervisory authority. Add columns per incident for ‘notification required?’ and ‘sent on’. See notification duty in practice.
Classify without getting stuck
Use a simple scale with three or four levels and a fixed question list to decide whether an incident is significant. Doubt is resolved by escalating, not by waiting. Also record the level at which decision-makers are brought in.
From closing to learning
For every incident above a certain severity, schedule a short evaluation: what happened, what worked, what did not, and what improvement follows. Register the improvement action with an owner and due date and reference it from the incident. That closes the loop towards the management review.
What auditors check
They take one or two incidents and follow them from report to closure. Small reports count too, such as a phishing email someone flags. An empty register is suspicious: it suggests reports are not being recorded. Practise with a tabletop if you want to see whether the process works.
