Auditing Incident Management Under ISO 27001

Five controls carry incident management, and they are sequential: planning and preparation, deciding whether an event is an incident, the response, the learning, and the collection of evidence. Auditing them is unusual in one respect: everything else in the annex can be tested on demand, and this can only be tested on what has already happened.

The organisation in the worked finding on this page is invented, and so is the finding.

The five ISO 27001 incident management controls, in the order they operate

A sixth control sits just outside the group. A.6.8 covers the mechanism through which personnel report events, and it belongs to the people theme rather than this one. It is the front door; these five are what happens after somebody comes through it.

Start at the Statement of Applicability. All five are controls the organisation selected at Clause 6.1.3, and what it claims about each is your first criterion. A.5.28 is the one most often marked applicable on a justification about legal or regulatory need, with nothing behind it.

The decision the ISO 27001 incident controls turn on

A.5.25 is the control auditors most often skip and the one that carries the most weight. Its subject is the moment an organisation decides whether something is an incident, and that decision determines whether any of the rest of the group ever engages.

It matters for a reason that is easy to miss. An organisation with very few incidents is either well run or not deciding. Those look identical in a register, and the only way to tell them apart is to look at what was assessed and not categorised as an incident, which most registers do not record at all.

So the useful questions are about the boundary rather than about the entries.

What is the definition of an event, and what is the definition of an incident, in this organisation’s own documents?

Who makes the call, and against what?

Where do the events that were assessed and not categorised as incidents go?

An organisation that cannot show the third has no evidence for A.5.25 at all — not because the decisions are wrong, but because there is no record that they were made.

A worked ISO 27001 finding on Annex A.5.28

Sennen Marine Chandlery operates a documented incident procedure with defined severity levels, a register in use, and a response team that meets and records decisions.

Note that the finding cites the absence of the procedures, not the loss of any evidence. Whether anything valuable was destroyed is unknowable and not the requirement. The control asks for procedures to be established and implemented; they are not. A finding that claimed evidence had been lost would be asserting something the audit cannot know, and the auditee would be right to challenge it.

One discipline in writing any of these. Record what you were told where it establishes how far the failure reaches; keep your own view of why it happened out of the finding. The response team lead’s account that preservation is decided case by case is recorded because it establishes that the gap is the organisation’s arrangement rather than an oversight in three particular incidents.

What an ISO 27001 incident register can and cannot prove

The incident register is the first thing you will be given and the most over-read document in this area.

The gap in the right-hand column is why the reporting route matters. A register is only as complete as what reaches it, and what reaches it is governed by A.6.8, which requires a mechanism through which personnel can report observed or suspected information security events through appropriate channels in a timely manner. That control sits in the people theme and is a requirement in its own right.

The audit trail for ISO 27001 incident management

Read the procedure and the definitions first. They become your criteria, including the severity levels and any timescales the organisation has set itself. The standard sets none, so these are the only measure there is.

Then look for where the decisions are recorded. A.5.25 asks for events to be assessed and a decision taken on whether each is an incident. The decisions that produced an entry are usually visible; the ones that did not are the harder half, and an organisation that keeps no record of them has no evidence for the control.

Then read what you do have against the procedure — against the organisation’s own severity definitions and timescales, not against your view of good incident handling, which is not audit criteria.

And ask what evidence arrangements exist. A.5.28 names four activities — identification, collection, acquisition and preservation — and an organisation can have arrangements for one and none for the others.

Where the ISO 27001 incident controls meet the clauses

One connection is worth stating carefully, because it is a common miscitation. An information security incident is not automatically a nonconformity, and Clause 10.2 is not the incident control. Clause 10.2 engages when a requirement of the ISMS has not been met. An incident may reveal that; it may equally be something the ISMS anticipated, treated as a risk and handled as designed. Which of the two you are looking at is a question about the evidence, and a finding that treats every incident as a nonconformity will not survive being asked why.

The other connections are shorter. Clause 7.4 covers determined communications, which is where external notification about an incident belongs. A.5.5 covers contact with authorities, which is what a notification obligation needs behind it. Clause 9.1 is where incident data becomes performance information, if the organisation has decided to use it that way.

Major or minor in an ISO 27001 incident finding

Major territory: no process at all, or one that names nobody; a control marked implemented with no procedure behind it; a category of event that reaches nothing.

Minor territory: a severity level recorded inconsistently in a process that is otherwise followed; one entry missing a field the procedure requires; evidence arrangements that cover some of A.5.28’s four activities and not all.

Escalation: a register with almost nothing in it, in an organisation whose other evidence suggests otherwise, is worth pursuing at A.5.25 and at the reporting route rather than accepted as a clean record.

And the criteria are the standard and the organisation’s own procedure, severity definitions and timescales — not your view of how an incident should have been handled. This is the area where an auditor with operational experience is most likely to start auditing against it.

Frequently asked questions about auditing incident management under ISO 27001

The other ISO 27001 control areas

auditing cloud services

auditing access control

auditing backup and recoverability

auditing supplier and third-party security

For the controls behind these areas, the four Annex A theme pages set out what each group requires: the A.5 organizational controls, the A.6 people controls, the A.7 physical controls, the A.8 technological controls.

3FOLD TRAINING is a CQI and IRCA Approved Training Partner, ATP number 6039853. Its ISO 27001 Lead Auditor training course is the CQI and IRCA Certified ISO/IEC 27001:2022 Lead Auditor (Information Security Management Systems) Training Course. The course identification number is 2889. Both the partner approval and the course certification are on 3FOLD TRAINING’s Approved Training Partner record, and any provider’s certified courses can be looked up in CQI and IRCA’s own directory of certified courses and approved training partners. The course page carries the schedule and what the course includes. If you would rather ask a person first, use the course enquiry form.