Learn the difference between incidents and events as well as how different ISO standards (e.g. ISO 27001, ISO 20000, ISO 22301,…etc.) approach incident management

Management system standards, especially those dealing with security and interruptions of business processes use the term incident management. As these management system standards deal with different aspects of managing business processes (IT Service Management, Information Security, Business Continuity, Supply Chain Security, and possibly others) the term is widely used but possesses a different meaning, depending on the context. On top of that, many of the standards also use the term “event”.

From Events to Incidents

In order to simplify things, let us try to explain the relationship between “event” and ”incident”. ISO/IEC Guide 73 (an ISO risk management vocabulary) defines an event as: occurrence that would change a particular set of circumstances. As this is not clear, ISO 22301:2012 uses as much as four notes in order to better explain the definition of an event. The authors of this definition probably thought of events being a kind of (sudden) changes without a negative outcome. For example, an event may not have negative implications at all – just something changes (e.g. one out of three air conditioning packs is switched off because of maintenance).

As such, the term event might be used as a neutral expression. Incidents, on the contrary, might possess a negative meaning, according to their definition in different ISO standards For example, if the switching off of the third air conditioning pack immediately overloads and shuts down the remaining two packs, the event developed into an incident.

Incidents in IT Service Management

The ISO/IEC standard on IT Service Management (ISO/IEC 20000-1:2011), in its definition 3.10 underlines the two faces of incidents. While there are certainly incidents which are connected to an unplanned interruption to a service (negative impact to one or more users), an indication that one of the hard drives of an array of mirrored disks has developed a fault might be a kind of incident without an immediate negative impact, according to the above definition: “…a reduction in the quality of service…that has not yet impacted the service to the customer”. However, in IT service management incidents are being connected to interruptions or a reduction in the quality of services to users. These incidents need to be taken care by a properly set up incident management structure.

Also, ISO 20000 considers, in addition to “normal” incidents, so-called information security incidents. As mentioned in definition 3.12: “…unexpected security events …significant probability…threatening information security”. These are incidents which are directly related to security issues, in contrast to incidents which, for example, are related to system interruptions.

We need to remember that not all incidents in IT service management are security related. For example, the loss of a printer an incident, but might not be related to security issues.

Incidents in Information Security

ISO/IEC 27000:2016, in its definition 2.36 (information security incident) underlines the impact on business operations with respect to information security. As such, all three dimensions of information security – confidentiality, integrity and availability – might be affected. For example, confidential documentation might have become exposed, malware might have corrupted data, or systems might have been put out of operation due to a cyber-attack.

In order to deal with these types of incidents an information security incident management structure needs to be in place. Annex A of ISO/IEC 27001:2013 calls for such a structure in section A.16. It also lists a number of controls which need to be in place.

See also the article how to handle incidents according to ISO 27001 A.16, to learn more about security incidents.

Incidents in Security Management for the Supply Chain

In the family of standards for security management for the supply chain, incident management is also of importance. For example ISO 28003:2007 (governing the certification of supply chain security management systems) even asks auditors to know how to respond to security incidents.

Incidents in Business Continuity and Resilience

ISO 22301:2012, in its definition 3.19, which is based on ISO 22300:2012, clearly puts a negative interpretation on the definition of an incident. The authors use the expression “disruptive incident” in many parts of the standard. This is to underline that in business continuity, serious consequences may develop as results of business disruptions. The consequences might be much graver as compared to typically smaller incidents in IT service management.

Typical consequences of these types of disruptive incidents – according to this definition – are process disruptions, losses of human life and assets, emergencies or crises. Disruptions might have a wide range of causes and might not just impact information technology assets, but any assets of the organization. Essentially, business continuity prepares for such incidents (which might develop into full-blown emergencies) and to properly react to disruptions. Like with an ISMS, organizations might become certified against the requirements of ISO 22301:2012.

Be aware of the context

Mostly, “incidents” carry a negative meaning, but this is not always the case. Also, every definition is a compromise and may not exactly describe the term to be defined. As such, we need to be actively aware of the context we are operating in.

For example, take the three standards ISO 22301, ISO 27001 and ISO 20000. If you have started with one of these frameworks and have learned to interpret the definition of an “incident” in the specific context of one framework, you need to understand that the definition of an ”incident” in another ISO standard might be somewhat different. Maybe you need to more precisely specify the type of incidents by introducing and using terms like: disruptive incident, information security incident, IT service management incident to avoid ambiguities.

We have to live with approximations, and need to engage in a dialogue. This blog post serves to initiate such a dialogue.