ISO 27001 Control 5.27: Learning From 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

It is a cliché in helpdesk and IT environments: the incident record closed with two words in the notes. “Fixed it.” Or “Resolved.” Nothing about what happened, why, or what has changed so it does not happen again.

Control 5.27 exists to stop that. It asks you to take what you learn from incidents and use it to strengthen your controls. In my experience most root cause analysis is poorly done, and without it, the same thing is very likely to come back and bite you again.

I have run a lot of major incident reviews over the course of my career. This page covers when root cause analysis should happen (not during the incident), why it so often goes wrong, who should lead it, and a simple template to make it stick.

What control 5.27 actually asks for

The requirement is that knowledge gained from information security incidents is used to strengthen and improve the information security controls. In practice:

• A review of significant incidents once they are over, covering what happened and why.
• A root cause, supported by evidence, not just a description of the symptom.
• Actions that change something: a control, a process, a configuration, training.
• Follow-through, so the actions are completed and checked.
• Trends across incidents, not just each one in isolation, reported into management review.

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

Where 5.27 sits among the incident controls

5.27 closes the loop.

5.27 is what makes incident management improve over time. Without it, response keeps fixing the same symptoms, and the criteria in 5.25 never get sharper.

Recover first, root cause later

During an incident, the focus should be on recovering the service as quickly as possible, not on working out the root cause. People under pressure who are trying to diagnose and fix at the same time tend to do neither well, and the incident lasts longer.

Root cause analysis happens afterwards, when things have settled down. That separation matters in both directions. It lets the response concentrate on recovery. And it gives the review the time and calm it needs to get the cause right, instead of settling for the first plausible explanation reached at two in the morning.

What makes the later review possible is the record kept during the incident. If the timeline, the actions and the observations were written down as they happened, the review starts from facts. If not, it starts from people’s memories, which are already disagreeing.

Why root cause analysis goes wrong

Post-incident investigations into root causes can be tricky. People are working out why something happened, often about systems that are complicated and changes that were made by someone else. In the reviews I have run and sat in on, the commonest problems are:

• Huge assumptions. Someone states the cause with confidence in the first five minutes, and the rest of the review sets out to confirm it.
• Poor thinking. Stopping at the symptom (“the server ran out of disk”) rather than asking why that was possible (“nothing alerts when disk is above 90%, and nobody owns capacity”).
• Blame. The cause becomes a person, and once a person is the cause, the system that let them make the mistake is never looked at.
• No evidence. Causes accepted because they sound right, not because the logs show them.
• Actions nobody owns. A good analysis ending in a list of “we should” statements with no names and no dates.

None of this does anybody any favours. A wrong root cause is worse than none, because it produces actions that fix the wrong thing and leaves everyone believing the problem is solved.

Who should lead the review

This is the single change that improves reviews most. Have someone with a clear head, who is good at analytical thinking, lead the process, even if they are not the person who did the technical work.

In fact, it often works better if they were not. The engineer who fixed the problem is too close to it, and is often the one with the strongest assumption about the cause. A review lead who asks good questions, insists on evidence and keeps the discussion on the system rather than on people will get to the real cause faster. Asking the right questions can save a lot of time and effort.

Questions that help:

• How do we know that? What does the log actually show?
• What else could explain the same symptoms?
• What made this possible, not just what happened?
• Why did we not notice sooner?
• If we fix this, what stops the same thing happening another way?

A simple “five whys” exercise, where you keep asking why until you reach something you can actually change, is a good structure, as long as every answer is tested against evidence.

What good looks like

I recently saw a really good post-incident follow-up report, and it is worth describing what made it good. It had a clear timeline taken from records made during the incident. It separated what was known from what was assumed. It identified a root cause backed by evidence, and the contributing factors that let it happen. And it ended with a short list of actions, each with an owner and a date, and a follow-up date to check they had worked.

It was not long. It did not apportion blame. It was the sort of document you could hand to a board, a customer or an auditor and it would answer their questions. That is the standard to aim for.

Making it stick

• Decide which incidents get a full review. All major and high incidents, as a minimum. For lower-severity ones, a line of root cause in the log is enough.
• Do not close an incident without a root cause. If it is not known yet, the incident stays open or a review is scheduled.
• Turn findings into control changes, and say which controls changed. That is the evidence this control asks for.
• Follow up. Check the actions were done and worked.
• Look across incidents. Once a quarter, read the log as a whole. Three different incidents with the same contributing factor is the most valuable thing a log can tell you.
• Report to management review. Incident trends and lessons are a required input under clause 9.3.

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

1. A significant incident and its review. Show me the root cause and how you established it.
2. Closure notes. I will look at a sample of closed incidents. “Fixed” or “resolved” with no cause is the classic finding.
3. Actions and follow-up. Were the actions from the last review completed, and how do you know they worked?
4. Control changes. Which controls changed as a result of incidents in the last year?
5. Trends. Has anyone looked across incidents for patterns?
6. Management review. Do incident lessons reach management, and is there a record of them being discussed?

Common issues

• Incidents closed as “fixed it” or “resolved” with no cause recorded.
• Root cause analysis attempted during the incident, slowing recovery and producing a rushed answer.
• Causes based on assumption rather than evidence.
• Reviews led by the person who fixed the problem, who already knows what they think the cause is.
• Blame directed at an individual, so the system that allowed the mistake is never fixed.
• Actions with no owner, no date and no follow-up.
• The same type of incident recurring, with nobody connecting them.
• Lessons never reaching management review.

The self-check

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

• Pick your last three closed incidents. Is a root cause recorded for each?
• For your last significant incident, what changed as a result, and is it finished?
• Who led the review, and were they the person who fixed the problem?
• Has the same kind of incident happened more than once this year?
• When did incident lessons last appear in your management review?

A worked example

The figures below are typical rather than drawn from a single engagement. This is a composite of a root cause analysis that went wrong, then right.

A 40-person software company. A customer’s data was briefly visible to another customer in the web application after a release.

The first review

• Led by the developer who had fixed it, the evening it happened.
• Root cause recorded as “developer error in release”, with the developer named.
• Action: “be more careful with releases”.
• Six weeks later, a similar exposure happened in a different part of the application.

The second review

• Led by the operations manager, who had not been involved in either fix, a week after the second incident.
• Built from the release logs and test records, not memory.
• Found that both releases had bypassed the automated test suite, because a configuration change three months earlier had made the tests optional when a deadline flag was set.
• Root cause: the release pipeline allowed untested code into production under time pressure. Contributing: no alert when tests were skipped.
• Actions: tests made mandatory, skipped-test alert added, both owned and dated, and checked a month later.

No further exposures since. The first review blamed a person and fixed nothing. The second asked better questions and fixed the system.

How control 5.27 links to other clauses and controls

• Control 5.26, Response to information security incidents. The records made during the response are the raw material for the review.
• Control 5.25, Assessment and decision on information security events. Lessons often sharpen the criteria for spotting the next one earlier.
• Control 5.24, Information security incident management planning and preparation. The procedure itself should improve from each review.
• Control 5.28, Collection of evidence. Good evidence handling makes root cause analysis possible.
• Clause 10.2, Nonconformity and corrective action. Root cause analysis and corrective action are the same discipline, applied to incidents.
• Clause 9.3, Management review. Incident trends and lessons are a required input.

Frequently asked questions

When should root cause analysis be done?

After the incident, once the service is restored and things have settled. During the incident the priority is recovery. Trying to find the root cause at the same time slows recovery and tends to produce a rushed, assumption-led answer.

Does every incident need a full post-incident review?

No. Major and high-severity incidents should get a full review. Lower-severity incidents need a root cause recorded in the log, and should be looked at together periodically for trends.

Who should lead a post-incident review?

Someone with a clear head and an analytical approach, who asks good questions and insists on evidence. It often works better if they were not the person who did the technical work, because that person tends to be too close to it.

What is the five whys technique?

A simple way of getting from a symptom to a root cause by repeatedly asking why something happened, until you reach something you can change. Each answer should be backed by evidence, otherwise it becomes a chain of assumptions.

How is 5.27 different from corrective action under clause 10.2?

They are closely related. Clause 10.2 covers nonconformities with your ISMS generally; control 5.27 applies the same thinking specifically to security incidents. Many organisations use one process for both, which is perfectly sensible.