ISO 27001 Control 5.26: Response to Information Security Incidents

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

Control 5.26 is the incident in action: containing it, recovering from it, and communicating about it, according to the procedure you prepared under 5.24.

Like any triage process, the first hour is critical. The technical side tends to get the attention, and in my experience it is rarely the thing that goes most wrong. What goes wrong is communication. Either somebody puts out an unauthorised message that turns out to be incorrect, or nothing goes out at all because “we’re going to fix it in a minute, so let’s wait”. And when an outside IT provider is involved, the first hour can be lost to a different problem entirely: each side pointing at the other.

This page covers what the control asks for, how to run the first hour, how to communicate without making things worse, and how to work with your IT provider rather than against them.

What control 5.26 actually asks for

The requirement is short: information security incidents are responded to in accordance with the documented procedures. In practice an auditor is looking for:

• A documented response procedure, covering containment, eradication, recovery and communication.
• Evidence it was followed in real incidents: records of what was done, by whom and when.
• Escalation where the severity called for it.
• Communication to the people who needed to know, internally and externally, including any regulatory notification.
• A clean handover into learning (5.27) and, where needed, evidence preservation (5.28).

In the 2013 edition this was control A.16.1.5. The intent is unchanged.

Where 5.26 sits among the incident controls

5.26 is where the plan meets reality.

5.26 is only as good as 5.24. If the roles, thresholds and contacts were sorted out in advance under control 5.24, the response can start immediately. If not, the first hour is spent deciding who is in charge.

The first hour

Once an incident has been declared, the first hour sets the tone for everything after it. A simple order of work:

1. Confirm who is leading. One incident lead, named, with authority to make decisions. Everyone else knows who that is.
2. Start the log. Time, what is known, what has been done. Someone writes it down from now on.
3. Contain. Stop it getting worse: isolate the affected device, disable the compromised account, revoke sessions, block the sender. Contain before you investigate.
4. Assess the scope. What is affected, what data is involved, is it still happening?
5. Decide on communication. Who needs to know now, who will be told later, and who is saying it. See below.
6. Call in help if needed: your IT provider, your insurer’s helpline, a specialist. Earlier is cheaper.
7. Preserve evidence if there is any chance this ends up in a dispute, claim or police report. Do not wipe or rebuild anything until that decision is made.

Recovery comes after containment, and the root cause comes after recovery. The job during the incident is to restore the service safely, not to work out why it happened. That is what control 5.27 is for.

Communication: the thing that goes most wrong

In my experience, once an incident is declared, communication is where it most often goes wrong, in one of two directions.

Unauthorised communication

Somebody, with the best of intentions, tells a customer what they think has happened. Or posts in a shared channel. Or answers a journalist’s call. And what they say turns out to be wrong, because in the first hour nobody really knows yet. Now you have an incident and a correction to manage, and the correction is always more damaging than the original silence would have been.

No communication at all

The opposite failure. “We’re going to fix it in a minute, so let’s wait.” Then the minute becomes an hour, then a morning. Customers notice the outage before you tell them, staff start guessing, and by the time a message goes out, it reads like you were hiding something.

What works

• One voice. A named communications role. Nobody else communicates externally about the incident.
• Say something early, even if it is only what you know: “We are aware of a problem affecting X. We are investigating and will update you by 11:00.” That buys time honestly.
• Commit to update times, and keep them even when there is nothing new.
• Say only what you know. Never speculate about cause or impact in the first hour.
• Prepare templates in advance for the obvious scenarios: an outage, a suspected data breach, a phishing campaign using your name. Filling in a template under pressure beats writing from scratch.
• Know your obligations: contractual notification timescales to customers, and the ICO’s 72-hour window for reportable personal data breaches.

Working with your IT provider

Most small businesses rely on an outside provider for some or all of the technical response. The handover between the business and the provider is where I have most often seen things go wrong.

The pattern is depressingly familiar: fingers pointing both ways. “It’s not our fault, it must be yours.” The provider blames a change the business made; the business blames something the provider did. It is a dangerous position to be in, because eventually somebody will be proven wrong, and in the meantime it actively hinders the investigation. Conclusions get reached rapidly, before the evidence is in, and people defend them rather than test them.

What helps:

• Agree the roles in advance. Who leads the incident (usually someone at your end), who does the technical recovery (often the provider), and what the provider is expected to do and how fast. Put it in the contract.
• Have the provider’s out-of-hours number and escalation contacts in your plan, and check them once a year.
• Ban blame during the incident. Say it out loud if you have to: the cause will be found in the review, not now. The only question for the next hour is how we contain and recover.
• Share the log. One record, visible to both sides, with times and actions. It removes a great deal of argument about who did what.
• Keep conclusions open until the evidence supports them. A rapid assumption about cause can send the recovery in the wrong direction.

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.26.

1. A real incident, traced. Show me the record from first report to closure: who led, what was contained and when, how it was recovered.
2. The procedure against the record. Was the documented procedure actually followed? If not, why not, and was that captured?
3. Communication. Who was told, by whom, and when? Was any notification to customers or the ICO considered and decided?
4. Escalation. Was the severity right, and did escalation happen when it should have?
5. The IT provider’s role. How did the handover work, and is the provider’s responsibility written down?
6. Evidence. If the incident could have gone legal, was anything preserved before systems were rebuilt?

Common issues

• No incident lead, so decisions are made by whoever is loudest.
• Investigation before containment, so the damage keeps spreading while people work out what happened.
• Unauthorised external communication that later has to be corrected.
• No communication at all, because “it’ll be fixed in a minute”.
• Business and IT provider blaming each other while the incident continues.
• Rapid conclusions about the cause that send the recovery the wrong way.
• Records written afterwards from memory, with no times.
• Systems wiped and rebuilt before anyone decided whether evidence was needed.

The self-check

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

• If an incident started now, who would lead it, and who would talk to customers?
• Do you have a holding message ready for an outage or a suspected data breach?
• What is your IT provider expected to do in an incident, and is it written in their contract?
• In your last incident, what was contained first, and how long did it take?
• Would anyone think to preserve evidence before rebuilding an affected machine?

A worked example

The figures below are typical rather than drawn from a single engagement. This is a composite of a response that went wrong, and what changed afterwards.

A 25-person online retailer. A Monday morning outage of the order system, which turned out to be caused by an expired certificate on a payment integration.

What happened

• For the first 90 minutes, the business and its hosting provider argued about whether a weekend change on either side had caused it.
• A customer service agent told several customers on live chat that “we’ve been hacked”, which was not true, and one of those customers posted it on social media.
• No status update went to customers for three hours, because the team expected a fix at any moment.
• Once the certificate was identified, the fix took twelve minutes.

What changed

• A named incident lead and communications role, with the rule that only the communications role speaks to customers about an incident.
• Three holding message templates (outage, suspected breach, phishing using the company name) prepared and stored with the roles sheet.
• The hosting provider’s responsibilities and out-of-hours contacts added to the contract, and a no-blame rule agreed for the duration of any incident.
• Certificate expiry dates added to the monthly event review, which would have caught this one weeks in advance.

The technical fault took twelve minutes to fix. The response around it cost three hours of sales and a social media correction.

How control 5.26 links to other clauses and controls

• Control 5.24, Information security incident management planning and preparation. The procedure, roles and contacts that the response follows.
• Control 5.25, Assessment and decision on information security events. Decides that a response is needed and at what level.
• Control 5.27, Learning from information security incidents. The root cause work that happens after the response, not during it.
• Control 5.28, Collection of evidence. What must be preserved before recovery destroys it.
• Control 5.29, Information security during disruption. A major incident is often a continuity event as well.
• Control 5.5, Contact with authorities. The ICO, police and others you may need to contact during the response.
• Control 5.22, Monitoring, review and change management of supplier services. How your IT provider performs in an incident belongs in their review.

Frequently asked questions

What should an incident response procedure include?

Who leads, how to contain, how to recover, who communicates and to whom, when to escalate, when to call outside help, how to preserve evidence, and how the incident is recorded and closed. For most small businesses it fits on three or four pages.

Should we contain an incident or investigate it first?

Contain first. Stop the damage spreading, then investigate. The exception is evidence: if the incident might lead to a dispute, claim or police report, preserve evidence as you contain, and do not wipe or rebuild anything until that decision is made.

Who should communicate with customers during an incident?

One named person, the communications role, and nobody else. They should say something early, say only what is known, and commit to regular updates. Prepared templates for likely scenarios make this much easier under pressure.

When do we need to tell customers about an incident?

When it affects them, and in any case within whatever timescale your contracts require, which may be shorter than you expect. If personal data is involved and the breach is likely to result in a high risk to individuals, UK GDPR may also require you to tell the individuals affected.

What if our IT provider and our team disagree about the cause?

Park it. During the incident the only question is how to contain and recover. Agree that the cause will be established in the post-incident review, on the evidence, and keep one shared log so the facts are not in dispute later.