Introduction to ISO/IEC 27035 – the ISO Standard on Incident Handling


In the series of articles titled “Incident Response Life Cycle in NIST and ISO standards” I review incident response life cycle, as defined and described in NIST and ISO standards related to incident management.

I introduced these standards in the first article in this series and later in this article I started reviewing the incident response life cycle of NIST SP 800-61.

In this article, I start discussing ISO/IEC 27035, the ISO standard on information security (cybersecurity) incident management.

ISO/IEC 27035

ISO/IEC 27035 was initially published as ISO/IEC TR 18044, I had the pleasure to be the first project editor of this standard at ISO/IEC JTC1 Subcommittee 27. It was decided later by ISO that it fits into so-called „27000” group of international standards  (of which main one and most widely recognized one is ISO/IEC 27001). So ISO/IEC 27035 was revised and renumbered.

Lately, it was divided into three parts:

  • Principles of incident management (ISO/IEC 27035-1);
  • Guidelines to plan and prepare for incident response (ISO/IEC 27035-2);
  • Guidelines for incident response operations (ISO/IEC 27035-3).

ISO/IEC 27035-1

The first part of ISO/IEC 27035 reviews principles of incident management.

It starts with definitions which are important if we are to understand and make good use of this standard. The incident response team is named IRT in ISO/IEC 27035 (Incident Response Team). The definition of the IRT says it is a “team of appropriately skilled and trusted members of the organization”. It worth noting that a word “trusted” is used here. It is important to remember (and use) this definition because incident response team members often handle sensitive information and sensitive events. So they should not only be skilled and trained. They also need to be trusted to act appropriately in sensitive situations.

Next, the standard recalls basic general concepts related to information security management. These concepts are illustrated with a diagram, which, in my opinion, should be printed out and pinned in all IT and information security rooms, because often these notions and concepts are mixed by security personnel.

Definitions of a vulnerability, threat, event and incident are recalled. (BTW, ask yourself this question: can I pinpoint the key difference between a vulnerability and a threat? Or between event and incident?)

Objectives of structured incident management

ISO/IEC 27035-1 lists the following objectives of planned and structured incident management:

  1. effective detection of information security events;
  2. appropriate assessment of such events;
  3. efficient incident response;
  4. minimization of adverse effects of incidents on business operations;
  5. supportive vulnerability management;
  6. learning from incidents.

It is important to see incident response not as an IT process or IT security process. It should be seen as a process that helps sustain bloodstream of business operations. ISO/IEC 27035-1 underscores this by mentioning “business operations” in objective 4 above. It is also a good practice to mention that during internal meetings and trainings of the incident response team.

In terms of information processing security, incident management can and should be used to eliminate as many vulnerabilities uncovered by incidents as possible. But please remember that vulnerability management is not the main task of an incident response team. Vulnerability management is a risk management task and it’s a part of the information security risk management process and should be dealt with by information security team. Sometimes most urgent vulnerabilities are patched by the incident response team and that’s OK. But any non-critical incident-related vulnerability management should be passed to information security team and become a part of the information security management process.

With objectives 1-4 we are dealing with “now”. Objectives 2-4 are future-related. Their goal is to minimize the probability of similar incidents occurring in future (and generally, to minimize the number of incidents in future).

Benefits of ISO/IEC 27035 approach

Nice thing about ISO/IEC 27035 is that it not only outlines and details the incident management approach, allowing an organization to fully plan and execute incident management based on that, but it also explains benefits of the given approach.

These are:

  • improving information security;
  • reducing business impacts;
  • strengthening focus on prevention;
  • improving prioritization of actions;
  • improving the quality of evidence;
  • contributing to budget and resource justification;
  • improving risk management;
  • improving security awareness;
  • improving security policies and procedures.

Think about it for a moment: this is a very important list – thanks to it ISO/IEC 27035 shows how strongly cybersecurity incident management is related to other activities of an organization and how strongly it can – if properly managed – improve these activities, and, thanks to that, improve execution of business goals of an organization (public and private one).

Some of these benefits are obvious for cybersecurity practitioners. I will not discuss all of these benefits here, but I would like to share with you my thoughts on a couple of them.

Prevention focus

Why and how proper incident management can help focus on prevention? We often see incident management as a reactive activity, so correlating it to prevention might sound counterintuitive. But this depends on whether we learn from incidents and treat incident management as a linear or cyclic activity. If we properly execute all objectives of incident management listed in ISO/IEC 27035, including the last one – learning from incidents, then we should and will be focused on prevention – i.e. preventing similar incidents from occurring in future. It is even better to try to minimize the risk of occurrence of the whole class of similar incidents. For example, if the incident response team has contained specific incident related to USB drives (e.g. stolen USB drive with sensitive data), then, in the “learn” phase, all kinds of USB-related incidents should be considered (e.g. malware, data leakage, unauthorized data movement etc.) by cybersecurity team and proper procedures, technical solutions and awareness activities should be planned.

What next?

In next article in this series, I will introduce the incident management cycle of ISO/IEC 27035.

References and further reading

ISO/IEC 27035-1 (Principles of incident management)
ISO/IEC 27035-2 (Guidelines to plan and prepare for incident response)
Introduction to Incident Response Life Cycle of NIST SP 800-61


No comments yet. Be the first to chime in!