Information Security – Incident management & template incident register

Information Security is a continuous effort; staff handling information needs to be trained regularly, systems need updating to remain secure, assets and risks change, and incidents need addressing. A complete risk register gives you a good idea of what might happen, but without a plan for both anticipated and unanticipated incidents, there is a good chance an adverse event will cause serious damage to the organisation. In this article, we explain how to handle incidents and provide a template for structured incident registration.

Incidents

An incident in the sense of information security is an adverse event that affects the confidentiality, integrity or availability of information. Examples are ransomware, a phishing attack that leads to a hacked email account, a breach at a cloud supplier and a stolen laptop. Less obvious examples are confidential data pasted into a public AI tool, or a power outage that knocks out a server.

Not every event is an incident. A phishing email that someone reports without clicking is an event; once someone enters their password, it becomes an incident. Incidents are also not the same as vulnerabilities. Vulnerabilities are weaknesses that can lead to an incident and are identified in the first step of risk management.

Incident management is a mandatory part of an ISO 27001, NEN 7510 or Security Verified information security management system (ISMS). In ISO 27001:2022, it is covered by Annex A controls 5.24 to 5.28 and 6.8. More on other required documentation can be found in this article. For organisations new to information security, we recommend our article on how to get started with information security.

How to handle incidents

Incidents happen; there is no way around that. Preventive measures lower the chance of an incident, but they do not suffice on their own. The most important measure to reduce the impact is a solid incident procedure. An incident procedure that touches all bases contains the following steps:

1. Prepare: assign roles and keep a contact list that also works when email is down, including your IT supplier, DPO, management and cyber insurer.
2. Report: anyone who notices something suspicious reports it straight away through a known channel.
3. Assess: IT or the security officer decides whether it is an incident, how serious it is, and whether personal data are involved.
4. Contain and recover: stop the damage, preserve evidence, and restore systems.
5. Notify: inform management and, if personal data are involved, the Data Protection Officer (or Privacy Officer). Make any legally required reports (see below).
6. Learn: find the root cause and take measures to prevent repetition. Management reviews larger incidents and the procedure itself.

The whole organization is involved in incident management, but each party in its own way. For those involved, the procedure needs to answer the following questions:

• The team: When is something suspicious? Who do I contact, and how? Who is the backup contact?
• IT or IT supplier: Through which channels (email, phone, Teams, etc.) can incidents be reported? Who takes the lead? Which system changes may we make as a measure? What do we record, and where? When do we contact the security officer and DPO?
• Security officer: Where can we find which incidents took place? How often do we review them? When must we report an incident externally?
• DPO / Privacy Officer: How are incidents reported to me? How quickly do I need to decide whether there is a personal data breach? Where can I find our data breach procedure?
• Management: Who decides on external reporting? How often do we review the procedure and large incidents? Under the Cbw, directors are responsible for this themselves.

The personal data breach procedure should be a separate, detailed procedure that involves the DPO, Privacy Officer or the manager responsible for privacy in time. The GDPR requires personal data breaches to be documented and made available to the Autoriteit Persoonsgegevens on request. Since the regulator is not interested in incidents without personal data, and not all IT staff need to be involved in breach handling, we recommend keeping the data breach register separate from the general incident register.

Finally, test the procedure. A short exercise once a year, walking through a scenario such as ransomware on a Friday evening, shows whether everyone knows what to do.

Reporting incidents

Depending on the incident and your organization, you may have to report it externally. The deadlines start when you become aware of the incident.

• GDPR: personal data breaches that pose a risk to people must be reported to the Autoriteit Persoonsgegevens within 72 hours, and to the people affected if the risk is high. This applies to almost every organization.
• Cbw (NIS2): since 15 August 2026, essential and important entities must report significant incidents via mijn.ncsc.nl: an early warning within 24 hours, a notification within 72 hours and a final report within one month.
• Cyber Resilience Act: since 11 September 2026, manufacturers of software and connected products must report actively exploited vulnerabilities and severe incidents in their products within 24 hours.

One incident can trigger more than one of these duties. And even if none apply to you, your customers’ contracts may require you to inform them quickly.

Incident register template

To make sure incidents are properly handled, can be learned from, and are available for audits, a complete incident register is indispensable. ICT Institute has created a template incident register, which is freely available and may be distributed under the Creative Commons licence. It has separate tabs for incidents, data breaches, nonconformities and audit observations.

For each incident, the template records:

• What happened, and when it started and ended
• Whether it is an incident or just an event
• What the current status is
• Whether personal data were involved
• What measures have been taken to regain control
• What caused the incident, and how to prevent repetition
• For large incidents, a link to the evidence

With a tested incident procedure and a well-kept register, your organization will handle incidents faster, limit the damage, and be able to show auditors and regulators what it did.

Other free templates we created are the GDPR DPIA template, Register of Processing Activities and Processing Agreement.

For more articles about information security, visit this page.

Image credit: @Hush52 via Unsplash