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!’.
If your organisation has received a request for a SOC 2 report and is looking to meet all the necessary requirements, URM can offer you informed guidance and practical support.
URM can help you achieve ISO 27001 certification
URM can provide a range of ISO 27002:2022 transition services including conducting a gap analysis, supporting you with risk assessment and treatment activities as well as delivering a 2-day transition training course.
Annex A of ISO 27001 comprises 114 controls which are grouped into the following 14 control categories.
When managing the security of your organisation’s information assets, you will need to consider the scope of what you are doing.
We are going to explore why the focus on a risk-based approach has helped turn ISO 27001, the International ISM Standard, into such a world-beater.