How do You Develop and Implement an Incident Management Plan?

|
|
PUBLISHED on
20 Jul
2022

Table of Contents

Due to the increased use of information technologies and the ‘human’ involvement (both malicious, accidental and incompetent!), it is inevitable we are all going to face more and more information security incidents in the future.

The challenge for all of us is minimising the likelihood of an incident occurring, whilst also preparing for the inevitable and minimising the negative impact when an incident does occur.  

You can achieve the latter best by implementing a customised incident management plan (IMP).  Not only does it make sense from a common-sense perspective, but also because it is a legal requirement and the absence of one is an indication of lack of organisational corporate social responsibility.  In this blog, we will examine some of the key things you should be thinking about when developing and implementing an IMP.

Who is responsible of managing incidents?

OK, let’s start with a definition from our trusty friend, ISO/IEC 27000:2013.  The Standard defines an information security incident as ‘a single or a series of unwanted or unexpected information security events that have a significant probability of compromising business operations and threatening information security’.  Next, where do you start in developing an IMP?  While it is impossible to prepare for every eventuality, putting a structure in place that defines who in your organisation is responsible for what in the event of disruption is a good starting point.

Need to define high risk

In day-to-day operations, unless you are extremely unlucky or massively accident-prone, your information security IMP plan will not be invoked daily.  The incident planning should predominantly focus on ‘high-risk’ incidents that could jeopardise business operations, and it’s for you to decide what is ‘high-risk’ to your organisation.  It’s important to understand that the definition of high-risk is subjective and will vary from one organisation to another.  

This is where you need to get the appropriate decision-makers together and agree on your organisation’s risk appetite.  The escalation mechanism should form an integral part of your incident management planning process.  On many occasions, incidents are discovered by accident, where a staff member reports a seemingly innocuous event, an occurrence or a changing set of circumstances.

However, during the evaluation process, the reported event may be escalated to a more serious category.  The identification, escalation and prioritisation phases are all key components of an IMP.

IMP Frameworks

For the purpose of constructing an incident management plan, you may wish to opt for a framework, such as:

  • ISO/IEC 27001
  • Payment Card Industry Data Security Standard (PCI DSS)
  • National Institute of Standards and Technology (NIST)
  • Control Objectives for Information and Related Technologies (COBIT)
  • U.S. Health Insurance Portability and Accountability Act (HIPAA)

The selected framework naturally needs to be relevant and appropriate to your organisation.  Using the chosen framework, you should aim to produce an incident management plan that:

  • Is adequate and appropriate for your organisation
  • Clearly allocates roles and responsibilities
  • Specifies the escalation steps
  • Addresses the containment of an incident
  • Includes a resolution section
  • Always focuses on lessons learned.

Don’t forget the process components

Different frameworks require varying degrees of granularity in incident management planning.  The criteria are usually agnostic and should fit your organisation.  In the process of establishing your incident management plan, don’t forget to include process components while meeting the aforementioned criteria.

Using this approach, you will be able to come up with a tailor-made incident management plan that will set processes for ‘detecting, reporting, assessing, responding to, dealing with, and learning from information security incidents’ (as per ISO/IEC 27000).  A generic approach for defining an incident management process is depicted in Annex A.

Practice makes perfect!

For the incident management plan to work, it needs to be tested, and you don’t want to wait for an actual high-risk incident to occur to check it out.  You need to develop scenarios (ideally risk-based), scrutinise, challenge, gather feedback and adjust your plan accordingly.  Adopting this approach, you will be in a far better state of readiness to deal with the real thing!  As the adage goes ‘Train hard, fight easy!’.

Do you need any help with ISO 27001 certificate?

URM can help you achieve ISO 27001 certification
Thumbnail of the Blog Illustration
Information Security
Published on
27/7/2022
What is the Difference Between IT and Information Governance?

In this blog, we are going to look at governance. We are regularly asked, ‘is information governance the same as IT governance?’

Read more
Thumbnail of the Blog Illustration
Information Security
Published on
3/7/2023
ISO 27001 vs SOC 2 - Part 2

2nd part of question and answer session where URM compared and contrasted 2 of the world’s leading information security standards, ISO 27001 and SOC 2.

Read more
Thumbnail of the Blog Illustration
Information Security
Published on
8/3/2024
Lessons Learnt from Early ISO 27001:2022 Transitions

URM’s blog, produced in collaboration with BSI, discusses common mistakes we have seen in early ISO 27001:2022 transitions, and how to avoid them.

Read more
It was an interesting presentation since we had the updated standard released last week. Thanks
Webinar 'Abriska 27001 Risk Assessment'
contact US

Let us help you

Let us help you in your compliance journey by completing the form and letting us know how we can best support you.