ISO27001:2022 - A5.27 Learning from information security incidents

In life, some of the best lessons come from experience. This is what this ISO27001 control is all about. It's linked to a number of other controls, so make sure to review the following controls if you haven't already.

A5.24 - Information security incident management planning and preparation.
A5.25 - Assessment and decision on information security events.
A5.26 - Response to information security incidents.
A5.28 - Collection of evidence.
A5.29 - Information security during disruption.
A5.30 - ICT Readiness for Business Continuity.

The handy guide to all ISO27001:2022 Annex A Controls

What does the standard require?

The standard states that “Knowledge gained from information security incidents shall be used to strengthen and improve the information security controls.” (A5.27 - Learning from information security incidents).

Why is this required?

Everything in life teaches you lessons, if you are willing to learn, and this control is all about learning from the security incidents we experience. Security incidents are valuable opportunities to learn more about ourselves and then improve.

By assessing a security incident you can identify vulnerabilities and the security controls to implement, which will then address them in future. This bolsters your approach to risk management and may improve your approach and response to future incidents.

For example, following an incident, if you review how your team responded you may identify gaps in the team, either in the people involved or in their knowledge or skills. You can then look to address these gaps, so that any future incidents will be handled more effectively.

What the auditor is looking for

The auditor will want to see how you approach any post incident reviews and assessments, and will expect to see some form of corrective action log or reports. This could include minutes from meetings that you held, and any corrective action plans or change records. If changes are made then an updated Incident Response Plan or Business Continuity Plan will be a good indicator to the auditor that you have improved your response to future incidents.

What do you need to do?

We believe there are two aspects to learning from security incidents, where one focuses on what happened and the other focuses on how the incident was handled.

Following a significant security incident, you should ensure that you conduct a Post Incident Review (PIR) and a Root Cause Analysis (RCA). This should be carried out as soon as practicable, but no more than 1 week following the closing of the incident. This is because memories are short, and you need to capture a lot of information about what happened and how it was handled.

Post Incident Review (PIR)

The purpose of the PIR is to discuss the timeline of the incident, not to discuss why the incident happened in the first place. That is for the RCA review you’ll conduct later. What you’re looking to establish in the PIR is how the incident was handled by those involved in the Incident Response Plan.

You’re trying to establish;

A timeline of the incident management, from start to finish
Who was first notified?
How was this escalated?
Who was in the communication chain?
What went well?
What could be improved?

The PIR is about what happened, so that you can improve your response to any future incidents. You can capture this information in a Word document, which will act as minutes for your meeting. Any improvements should be added to your action or change control log.

The next meeting you have will take place following an investigation into what happened

Root Cause Analysis (RCA)

The RCA can be a tricky review to undertake because it can feel like you’re trying to attribute blame to the incident. Although this is not the case, this is often how they can come across. Although you’re not looking to apportion blame, questions are often phrased in a way which make it feel this way. For example, consider these questions and see if they sound like an attempt to apportion blame;

Did someone make a change that was unplanned?
Who left the device unprotected from malware?
Who sent the accounts details to the wrong email address?

These questions focus on the ‘who’ not the ‘why’ or ‘how’, which the RCA should focus on. Please be aware that the RCA can still be a difficult process, but if this is the case then there is more of an issue related to the culture in the business that can’t be addressed here. That’s the topic for another day.

Following an incident you should collect information from those directly involved in the recovery to understand why the incident happened. Sometimes this may seem relatively obvious, but never take things on first glance. For example, someone making a change that was unplanned may appear to be the root cause of an incident, but is it? Is the real root cause because they hadn’t been trained on change management? Was it an emergency change, demanded by an overbearing manager or client?

We recently conducted a RCA meeting with a client who had experienced flooding from a nearby river. The RCA could easily be completed by stating that severe or abnormal rain fall was the cause. But following further assessment and analysis, we discovered that the local council had blocked an outlet for the river, for health and safety reasons. This in fact was the cause of the river breach, and after some discussions the council amended their approach and the cover was removed. This is the true purpose of an RCA.

You should document the RCA meeting and capture any findings in your action log. You may also need to update your risk register with any additional risks (such as “Breach of change control processes due to unplanned changes that do not follow our processes.”)

The handy guide to all ISO27001:2022 Annex A Controls

Q & A

How can we conduct an effective RCA?

Hold a meeting with all interested parties, and explain that this is not about apportioning blame. Focus on the ‘why’ and ‘what’ not the ‘who’ of the incident.

You might want to use the ‘5 whys’ or fishbone approach to getting to the root cause of the incident.

Your emotional intelligence will be tested during this process, as you’ll need to pick up on the verbal and non-verbal ques that people are feeling threatened or an attempt to place the fault at the door of one person or function.

Do we need to do a PIR and RCA for every incident?

No, you don’t need to do this for every incident. For example, if someone loses a laptop, you wouldn’t run a full PIR and RCA. But you will certainly want to gather information on the communication process, the promptness of informing the Data Protection Officer (DPO), and the actions that were taken. You might not hold a formal meeting to capture this, but on your incident log, capture lessons learned and track any actions taken.

Difficulty rating

We rate this a 3 out of 5 difficulty rating. This control requires no real technical skills to put together, but can be difficult to implement. You’re going to have to employ your emotional intelligence, and be conscious of people’s emotions during this process. You’ll also find that people will want to get on and move forward, rather than spending time looking at an event that happened in the past. You will need to employ all your people and communication skills here, which is what can make this more difficult for some to complete.

Consultants Like Us