ISO 27001 Control 5.24: Information Security Incident Management Planning and Preparation

Alan Parker, ISO 27001 Consultant & Internal Auditor,
Helping UK SMEs hit ISO 27001 in 90 days.
B.Sc (Hons) Information Systems · Certified ISO 27001 Lead Auditor · CISMP · ITIL Expert · 30+ years in IT governance and security.
Read full bio →

Introduction

Very rarely do I find a robust incident management process in place. In small, fast-moving tech firms in particular, it can feel like a foreign concept: incidents are things that happen, people deal with them, everyone moves on. And most of the time, that works, until the day it really does not.

Control 5.24 is about deciding, before anything goes wrong, how you will handle it when it does. Who leads. Who does the technical recovery. Who talks to customers. What counts as serious enough to call everyone in. If it were my team, it would be one of the first things I put in place, if only to get the business organised.

This page covers what the control asks for, what I usually find instead, what good looks like (including a real example of a malware outbreak handled like clockwork), and a free incident log and roles sheet to get you started.

What control 5.24 actually asks for

The requirement is that the organisation plans and prepares for managing information security incidents by defining, establishing and communicating incident management processes, roles and responsibilities. In practice:

• A process covering the whole life of an incident: reporting, assessment, response, communication and learning.
• Roles and responsibilities, named in advance, including who leads and who deputises.
• Criteria for what counts as an incident and how serious it is, so people do not have to decide from scratch at the worst possible moment.
• Communication: people know the process exists, know how to report, and know their part in it.
• Contacts for the people you may need to involve: your IT provider, your insurer, the ICO, the police.

In the 2013 edition this was control A.16.1.1. The intent is unchanged; the 2022 version is clearer that planning and preparation is a control in its own right.

Where 5.24 sits among the incident controls

Incident management is spread across six controls in the 2022 edition. 5.24 is the one that prepares for all the others.

5.24 is the plan; the others are the plan in action. Get 5.24 right and reporting, assessment, response and learning each have something to follow. Get it wrong and each of them becomes improvisation.

What I usually find

When I ask a small business to show me its incident process, this is the typical picture:

• Incidents recorded ad hoc, if at all. Often via a customer service inbox, sometimes in a chat channel, occasionally in someone’s head.
• No tracking. Nobody can say who did what, or when.
• No root cause analysis. The immediate problem was fixed, so it was closed.
• No plan for a major incident. Nobody has decided who handles the technical recovery, who handles communications, or what the thresholds are for treating something as major.

The consequence is not just untidiness. When something serious does happen, a service failure or a hacking attempt, the response is chaotic. People duplicate effort, or assume someone else is dealing with it. Customers hear different things from different people. And afterwards, the post-incident review is difficult, because it lacks the detail of what actually happened during the event. The write-up to senior management, to customers, or even to the police ends up based on memory rather than fact.

Thresholds: deciding what is serious in advance

The single most useful thing you can decide before an incident is what “serious” means. Without agreed thresholds, every incident starts with a debate about how worried to be, and that debate happens precisely when you have the least time for it.

Four levels is enough for most small businesses:

• Major: ransomware or malware spreading, a compromised administrator account, loss of a core system with no workaround, or a personal data breach likely to be reportable. Everyone in their roles, immediately.
• High: a single account compromise, data sent to the wrong recipient, an outage of a key service with a workaround. An incident lead within the hour.
• Medium: an encrypted device lost, suspicious activity that was contained, a supplier incident with no confirmed impact on you. Handled by IT within a working day.
• Low: a phishing email reported and not clicked, blocked malware, a minor policy breach. Logged and closed, with trends reviewed monthly.

The exact definitions matter less than having them, and having everyone know them. Adjust the examples to your business, and write down who gets told at each level.

Roles for a major incident

In a major incident, the most important thing is that everyone knows their position. These are the roles I would always define, even in a team of ten where one person may hold two of them:

• Incident lead. Owns the incident from start to finish. Decides severity, calls in the others, makes sure the log is kept, decides when it is closed.
• Technical recovery. Contains and recovers the affected systems, and reports progress to the incident lead at agreed intervals. Often your IT provider, which is why their contact details and their obligations belong in the plan.
• Communications. The single voice to staff, customers and suppliers. Nobody else communicates externally about the incident.
• Senior management. Makes the business decisions: shutting systems down, paying for outside help, reporting to the ICO or police.
• Scribe. Writes down what happened, who did what and when, as it happens. In a small team this is often the incident lead, but it must be someone.

Name a primary and a deputy for each, with phone numbers. Then print it, and keep a copy somewhere you can reach if your own systems are the thing that is down.

Record it during, not after

If there is one habit that separates a well-run incident from a chaotic one, it is this: the record is made while the incident is happening.

Times, actions, decisions and who made them, written down as they happen, even as rough notes. It feels like a distraction in the moment. It is the opposite. It stops two people doing the same thing, it tells the incident lead where things stand, and afterwards it is the difference between a post-incident review based on fact and one based on recollection.

It matters most when you have to explain yourself to someone else. A report to your board, a customer’s questions, an insurer’s claim form, an ICO notification or a police report all go much better when you can say what happened at 09:12 rather than “some time on Tuesday morning”.

What good looks like

I have worked in highly mature teams where the incident management process was down to a T, and one event in particular shows what that buys you.

A piece of malware got into the organisation and spread like wildfire. It was serious, and the full recovery took three days. But the initial control and coordination was like clockwork, because everyone knew their positions and responsibilities. Nobody stood around asking who was in charge or whether this was serious enough to escalate. The plan had already answered those questions, so people went straight to their roles.

Just as importantly, the incident was recorded well while it was happening. When the post-incident review took place, the root cause and the improvements could be found far more easily, because the detail was all there. The report to the management team about the actions taken was straightforward to write, and it was factual.

Three days of recovery was not avoidable once the malware was in. The chaos usually is. That is what this control buys you.

Who you may need to tell

Part of preparing is knowing in advance who you might have to inform, and how quickly:

• The ICO: a personal data breach likely to result in a risk to individuals must be reported without undue delay and, where feasible, within 72 hours of becoming aware of it. Record the decision either way.
• Affected individuals, where the breach is likely to result in a high risk to them.
• Your customers, under your contracts. Many commercial contracts contain incident notification obligations with their own timescales, sometimes shorter than 72 hours.
• Your cyber insurer, often before you engage outside help, or the claim may be affected. Their helpline number belongs on your roles sheet.
• Action Fraud or the police, for criminal activity such as extortion or fraud.

Put the contacts and the timescales on the same sheet as the roles, so nobody has to go looking for them in the middle of an incident.

Test it before you need it

A plan nobody has rehearsed is a document, not a capability. The simplest test is a tabletop exercise: an hour around a table, a realistic scenario (“the finance director’s mailbox has been compromised and is sending invoices to customers with new bank details”), and the team walking through what they would do, using the plan.

It always finds something: a phone number out of date, a role nobody had actually agreed to, a decision nobody knew they were allowed to make. Once a year is enough for most small businesses, and the record of the exercise is good evidence for an auditor.

Internal Audit Service

Get an independent view of your ISO 27001 ISMS before you go into an audit.

“Alan from Iseo Blue truly came to our rescue. His support ahead of our internal audit was outstanding, and he helped us get our ISMS 100% ready for the Phase 2 audit.“

– Quartile.

✓ Gain confidence
✓ Audit plan
✓ Independent view
✓ An ISO 27001 requirement

✓ Audit findings report
✓ Recommendations
✓ Review meeting
✓ Fixed price

£2,500

+ VAT where applicable

View DetailsBook a discovery call

What auditors will look for

As a Lead Auditor, this is broadly how I would work through 5.24.

1. Your incident procedure. Does it cover reporting, assessment, response, communication and learning, and does it name roles rather than just saying “IT”?
2. Roles. Who is the incident lead, and who deputises? I will usually ask someone other than the ISMS owner, to see whether they know.
3. Thresholds. How do you decide whether something is major? Show me the criteria.
4. The incident log. I will pick an incident and ask what happened, when, who did what, and what the root cause was. An empty log for a year usually means incidents are not being recorded, not that none happened.
5. Communication. How do staff know how to report an incident? I may ask a few people.
6. Testing. When was the plan last exercised, and what did you change as a result?

Common issues

• No incident process at all, or a document copied from a template that nobody has read.
• Incidents recorded ad hoc in a customer service inbox or chat channel, with no single log.
• No defined roles. Everyone assumes the technical person will handle everything, including talking to customers.
• No thresholds, so every incident starts with a debate about how serious it is.
• Records written after the event from memory, with no times and no detail.
• Incidents closed once the immediate problem is fixed, with no root cause analysis.
• Contact details for the IT provider, insurer and ICO kept only on the systems that are down.
• A plan that has never been tested.

The self-check

Five questions. If you cannot answer them today, an auditor will find that out for you.

• If ransomware hit your business at 10pm on a Friday, who would lead the response, and do they know it?
• Where would someone record what happened, as it happened?
• What makes an incident “major” in your business, and is that written down?
• Who is allowed to talk to customers about an incident, and who is not?
• When did you last rehearse any of this?

If the answer to the first question is a pause followed by a name, that is a plan. If it is a pause followed by “probably”, it is not one yet.

A worked example

The figures below are typical rather than drawn from a single engagement. This is a composite of what putting incident management in place looks like in a business of this size.

A 20-person SaaS start-up with an outsourced IT provider. Incidents went to the support inbox or the engineering chat channel. There was no procedure, no log and no agreed roles.

What the review found

• Eleven events in the previous six months that should have been treated as incidents, scattered across the support inbox and chat. Three involved customer data.
• One of those was a customer receiving another customer’s report by email. It had been fixed within an hour, but nobody had assessed whether it needed reporting to the ICO, and there was no record of the decision.
• During a four-hour outage the previous spring, three different people had emailed customers with three different explanations.
• Nobody knew the cyber insurer’s helpline number, or that the policy required the insurer to be called before engaging outside help.

What changed

• A three-page incident procedure, a single incident log, and four severity levels with examples.
• A one-page roles sheet: the CTO as incident lead, the IT provider for technical recovery, the CEO for communications, with deputies, phone numbers and the insurer and ICO contacts. Printed and pinned up.
• The eleven historic events logged retrospectively, with the data disclosure assessed and the decision recorded.
• A one-hour tabletop exercise, using a compromised email account scenario, which found that the IT provider’s out-of-hours number was out of date.

About two days of effort, most of it the exercise and the follow-up. Three months later a real phishing compromise was handled in under an hour, with a clean record from the first report to the root cause.

How control 5.24 links to other clauses and controls

• Control 6.8, Information security event reporting. How incidents get reported in the first place. A plan with no reporting route never starts.
• Control 5.25, Assessment and decision on information security events. Where your severity thresholds are applied.
• Control 5.26, Response to information security incidents. The plan in action: containment, recovery and communication.
• Control 5.27, Learning from information security incidents. Root cause analysis and improvement, which depend entirely on good records made during the incident.
• Control 5.28, Collection of evidence. Preserving logs and devices properly in case an incident goes legal.
• Control 5.5, Contact with authorities. The ICO, police and other authorities you may need to contact belong in your plan.
• Control 5.29, Information security during disruption. A major incident is often a continuity event too, and the two plans should agree with each other.
• Clause 9.3, Management review. Incident trends and lessons are a required input to management review.

Frequently asked questions

What is the difference between an event and an incident?

An information security event is something that might indicate a problem: a suspicious email, an alert, an unusual login. An incident is an event, or a series of them, that actually threatens or affects the security of your information. Control 5.25 is where you decide which is which, using the thresholds you set under 5.24.

Does a small business really need an incident management process?

Yes, and arguably more than a large one, because a small team has less slack to absorb a chaotic response. It does not need to be long: a short procedure, a log, severity levels and a one-page roles sheet will cover most small businesses well.

Who should lead an information security incident?

A named incident lead with the authority to make decisions and call people in, plus a named deputy. It does not have to be the most technical person; in fact it often works better if it is not, so the technical person can concentrate on recovery.

When do we have to report a breach to the ICO?

Under UK GDPR, a personal data breach that is likely to result in a risk to individuals’ rights and freedoms must be reported to the ICO without undue delay and, where feasible, within 72 hours of becoming aware of it. If you decide a breach does not need reporting, record that decision and your reasoning.

How often should we test our incident response plan?

At least once a year for most small businesses, with a short tabletop exercise based on a realistic scenario. Also test after any significant change to your systems, your IT provider or the people in key roles.

What should an incident record contain?

When it was reported and by whom, what happened, its severity, who led it, what systems or data were affected, the containment and recovery actions with times, who was notified, the root cause, and the lessons and improvements. Most of it should be written during the incident, not after.