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 organization. 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 an information asset. Examples of such events are hacks, loss of documents, a stolen laptop, but also less straight-forward events such as leaving confidential information on a screen visible to others or a power outage that knocks out the server. Incidents are, however, not the same as vulnerabilities. Vulnerabilities are weaknesses in the protection of information that can lead to an incident. In Risk Identification, the first step of risk management, vulnerabilities that can lead to an incident are identified.

Risk- and incident management are an important (and mandatory) part of a Security Verified or ISO27001 Information Security Management System (ISMS). More on other required documentation can be found in this article. For organizations new to Information Security, we recommend reading our how to get started with Information Security article.

How to handle incidents

Incidents happen, there is no way around that. Mitigation measures can be taken to lower the probability of an incident taking place, such as electronic or physical access restriction to information. Due to the inevitability of incidents, reactive measures to reduce the impact are crucial. Pre-emptive measures help, but do not suffice on their own. The most important impact reducing measure is a solid incident procedure. If an incident has happened before, there might be a pattern. This pattern can be broken by learning from the incident and preventing repetition.

An Information Security incident procedure that touches all bases contains the following steps:

1. Someone in the organization recognizes the incident
2. The IT department is notified
3. IT takes action to end the incident and informs the InfoSec team
4. The involvement of personal data is confirmed or excluded
5. If personal data was involved, the Data Protection Officer (or Privacy Officer) is notified asap
6. The InfoSec Team investigates the incident and learns from it
7. Management reviews the execution of the procedures and any business consequences

As can be seen in the figure above, the whole organization is involved in incident management but all parties in their own way and proportion. For those involved, the incident procedure needs to answer the following questions:

• The team: When is something suspicious? Who do I contact? How do I contact them? Who is the backup contact?
• IT: What channels (email, phone, Slack, etc.) can incidents be reported on? What IT member takes the lead? Which system changes can and can we not do as a measure? What information about the incident do we record, and how? How do we know whether personal data is involved? When and how do we need to contact the DPO/ PO?
• InfoSec team: Where can we find what incidents took place? How often do we review them? What do we document? Of what do we need to notify management?
• DPO / PO: How are incidents notified to me? How quick do I need to decide whether there is a personal data breach? Where can I find our personal data breach procedure?
• Management: What do IT and the InfoSec team document on incidents? How often do we review the procedure and large incidents?

Important to add to this, is that the personal data breach procedure should be a separate detailed procedure for that includes involving the Data Protection Officer, Privacy Officer, or management privacy responsible in a timely manner. The GDPR requires personal data breaches to be documented and made available to the Data Protection Authority on request. Since this Authority is not interested in non personal data related incidents and not all IT staff needs to be involved in personal data breach handling, we recommend  separating the normal incident register from the personal data breach register.

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 template incident register, which is freely available and may be distributed under the Creative Commons licence. Other free templates we created (all in Dutch) are the GDPR DPIA template, Register of Processing Activities, and Processing Agreement.

The incident registration template requires to document the following:

• What happened
• What caused the incident
• When it happened and how low it lasted
• What the current status is
• Whether personal data were involved
• What measures have been taken to regain control

With a proper incident response procedure in place that results in quickly-handled well-documented incidents, there is no incident your organization cannot handle.

For more articles about information security, visit this page.

Image credit: @Hush52 via Unsplash