ISO 27001 Control 5.25: Assessment and Decision on Information Security Events

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.25 sits between noticing something and doing something about it. Its job is to make sure that every event gets a decision: is this an incident, and if so, how serious?

It sounds like a formality, and it is the step most small businesses skip. In practice I see two failure modes. Either nothing gets assessed, so events pile up in logs that nobody reads until one of them turns into a real problem. Or everything gets treated as an incident, and the team ends up triggering the incident process, or worse the major incident process, for things that did not need it, until people stop taking it seriously.

This page covers the difference between an event and an incident, why somebody needs to actually look at events, how to set criteria so the decision is quick and consistent, and a story about some servers that were “just running a bit slow”.

What control 5.25 actually asks for

The requirement is that the organisation assesses information security events and decides whether they should be categorised as information security incidents. In practice:

• Criteria for what makes an event an incident, and for how serious an incident is, agreed in advance under control 5.24.
• Someone responsible for looking at events and making the call.
• A recorded decision, particularly for borderline events and anything you decide not to treat as an incident.
• Review of events over time, so trends are spotted before they become incidents.

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

Where 5.25 sits among the incident controls

Incident management is spread across six controls. 5.25 is the decision point between reporting and response.

5.25 is the gate. Events come in through reporting and monitoring. 5.25 decides which ones go through to response, and at what level, using the thresholds you set under 5.24.

Events and incidents are not the same thing

An event is something that happened. A failed login. A blocked email. A spike in CPU on a server. A user reporting a strange pop-up. Most events are harmless, and your systems generate thousands of them a day, captured in logs.

An incident is where something has gone wrong, or is likely to, and it needs human intervention. A failed login is an event. Two hundred failed logins against the finance director’s account in ten minutes, followed by a successful one from another country, is an incident.

The distinction matters for two reasons. If you treat events as incidents, you drown: the incident process is triggered constantly, the major incident process gets invoked for things that did not warrant it, and people quickly learn to ignore it. If you never look at events at all, you miss the ones that were telling you something.

Somebody has to actually look

Here is the gap I find most often. Events are captured, because systems log them automatically. Occasionally there is some automated alerting, if anything. But there is rarely any kind of human review of events. The logs exist; nobody reads them.

That matters because the most useful thing events tell you is not any single one of them. It is the trend. Five failed backups in a month. A server that keeps running out of disk space. One user’s account getting locked out every Monday. Individually each is noise. Together they are an incident waiting to happen, and without a review you will not see the pattern until it becomes an avoidable incident.

For a small business, human review does not need a security operations centre. It needs:

• A short weekly or monthly look at the alerts and summaries your main systems already produce: Microsoft 365 or Google Workspace security alerts, backup reports, antivirus or endpoint alerts, firewall summaries.
• A named person who does it, with time set aside. Often this is your IT provider, in which case it should be in their contract and you should see a summary.
• A note of what was seen and decided, even if the answer is “nothing of concern”.
• A question at each review: is anything recurring? Recurring events are your early warning.

Setting the criteria

The decision should not depend on who happens to be looking. Agree in advance what makes an event an incident, and how serious each type is. A simple set of tests works for most small businesses. Treat it as an incident if:

• Information may have been accessed, changed, lost or disclosed by someone who should not have it.
• An account may have been compromised.
• A system or service your business depends on is unavailable or not working properly, beyond a brief glitch.
• Malware has run, rather than been blocked.
• A policy breach has created a real risk, not just a technical one.
• The same event keeps recurring and nobody knows why.

Then apply your severity levels from control 5.24: major, high, medium or low, each with examples. When in doubt, log it as a low-severity incident and let the review decide. It is much easier to downgrade an incident than to explain why you did not record one.

“Just a bit slow”

I have watched this happen. A cluster of on-premises servers started showing performance problems. Nothing dramatic: things were a bit slower than usual, CPU a bit higher than it should have been. It was waved off as trivial. Probably a patch, probably a busy period, probably nothing.

It carried on, and got worse, until it was really getting out of hand. When someone finally looked properly, the servers were being used by a third party for bitcoin mining. Somebody had got in, and had been quietly using the organisation’s hardware and electricity for their own ends for some time.

Two lessons. First, performance problems are security events. Unexplained CPU load, unusual network traffic and servers that are “just a bit slow” are some of the commonest signs of compromise, and they belong in the same review as failed logins. Second, the cost of dismissing it was not the mining. It was that whoever was mining had access, and nobody knew what else they had done with it. An earlier assessment would have turned a slow server into an incident weeks sooner.

Recording the decision

For every event that gets a proper look, record the decision. Incidents go into the incident log with a severity. Borderline events, and anything you decided was not an incident, get a one-line note of what it was and why.

That note protects you. If something later turns out to have been the start of a bigger problem, you can show what was known at the time and why the call was made. And for personal data breaches, recording a decision not to report to the ICO is expected, not optional.

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

1. Your criteria. How do you decide whether something is an incident, and how serious? Show me where that is written.
2. Who assesses events. A named person or provider, and how often they look.
3. Evidence of review. A note, a report, a ticket: something showing events were looked at and decisions made.
4. Borderline decisions. Pick an event that was not treated as an incident. Why not, and is that recorded?
5. Consistency. Are similar events treated the same way? Two phishing clicks a month apart logged at different severities with no reason is a finding waiting to happen.
6. Trends. Is anything recurring, and has anyone noticed?

Common issues

• Logs collected but never reviewed by a human.
• Automated alerts going to an inbox nobody monitors.
• No criteria, so whether something becomes an incident depends on who noticed it.
• Everything treated as an incident, so the process is ignored.
• The major incident process triggered for minor problems, and then not trusted when it matters.
• Performance problems treated as purely operational when they may be security events.
• No record of decisions not to treat something as an incident, including ICO reporting decisions.
• Recurring events nobody connects until they cause an outage.

The self-check

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

• Who looks at your security alerts and logs, and when did they last do it?
• What makes something an incident in your business, and where is that written?
• What happened to the last alert you received from Microsoft 365 or Google Workspace?
• Is anything recurring in your logs right now that nobody has explained?
• Would a server that was “just a bit slow” be looked at as a possible security event?

A worked example

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

A 30-person firm on Microsoft 365 with an outsourced IT provider. Security alerts went to a shared mailbox. Nobody owned it.

What the review found

• Around 400 alerts in the mailbox over six months, unread.
• Among them: 14 “impossible travel” sign-in alerts, three of which turned out on investigation to be real compromised accounts with mailbox forwarding rules still in place.
• Repeated backup failure notices for one server, going back eleven weeks.
• The IT provider assumed the business was reading the alerts. The business assumed the IT provider was.

What changed

• The IT provider took ownership of alert review, written into their contract, with a monthly one-page summary to the operations lead.
• Criteria and four severity levels agreed, with examples taken from the actual alerts.
• The three compromised accounts treated as incidents, contained and reviewed; the forwarding rules removed.
• The backup failures fixed and a recurring-event check added to the monthly summary.

About a day to set up. The three compromised accounts had been sitting in plain sight for months.

How control 5.25 links to other clauses and controls

• Control 5.24, Information security incident management planning and preparation. Where your criteria and severity levels are defined.
• Control 6.8, Information security event reporting. How events reach the people assessing them.
• Control 5.26, Response to information security incidents. What happens once an event is declared an incident.
• Control 8.15, Logging. The logs that events come from.
• Control 8.16, Monitoring activities. The monitoring that turns logs into alerts someone can assess.
• Control 5.7, Threat intelligence. Knowing what current attacks look like helps you recognise them in your events.

Frequently asked questions

What is the difference between an information security event and an incident?

An event is something that happened that may be relevant to security, such as a failed login or a blocked email. An incident is an event, or series of events, where something has gone wrong or is likely to, and human intervention is needed. Most events are harmless; control 5.25 is about deciding which ones are not.

Who should assess security events?

A named person with the knowledge to judge them and the time to do it. In many small businesses this is the IT provider, in which case the responsibility should be in their contract and you should receive a regular summary of what they saw and decided.

How often should we review security logs and alerts?

Alerts that indicate a likely compromise need prompt attention, ideally the same day. A broader review of logs and summaries, looking for trends, is reasonable weekly or monthly for most small businesses. Choose a frequency you will actually keep.

Do we have to record events that are not incidents?

Not every event, no. But borderline events that were looked at and judged not to be incidents should be noted with the reason, and any decision not to report a personal data breach to the ICO must be recorded.

Can performance problems be security incidents?

Yes. Unexplained high CPU, unusual network traffic and systems that are slow for no clear reason are common signs of compromise, including cryptocurrency mining by an intruder. They should be assessed against your incident criteria, not dismissed as purely operational.