What evidence do auditors commonly ask for on 5.25 Assessment and decision on information security events?

The agreed incident categorization and prioritization scheme with criteria for declaring an incident and consequence levels; Triage records showing each reported event assessed against the scheme; Detailed decision records identifying who assessed the event, the categorization and the rationale; Evidence that assessors are the designated incident coordination and response personnel; Metrics on event volumes, incidents declared and time to decision.

What is the most common gap auditors find on 5.25?

No written criteria for when an event becomes an incident, so decisions are inconsistent

ISO/IEC 27002:2022 · Organizational controls

`5.25` Assessment and decision on information security events

Each information security event is to be assessed and a decision made on whether it counts as an information security incident. Purpose: categorize and prioritize security events effectively. Guidance: an agreed scheme for categorizing and prioritizing incidents should identify an incident's consequences and priority and include the criteria for treating an event as an incident. The point of contact assesses every event against that scheme, and the people responsible for coordinating and responding to incidents carry out the assessment and take the decision. The outcome of each assessment and decision is recorded in enough detail to be referred back to and checked later. ISO/IEC 27035 carries more detail on incident management.

Source: ISO/IEC 27002:2022, 5.25. The statement above is our statement of the clause, read from the published text and cited so you can check it against the official text, not the instrument verbatim. Open ISO/IEC 27002:2022 in the compliance library.

ISO/IEC 27002 is guidance on the Annex A controls; certification is against ISO/IEC 27001. Use this set when your sheet follows the 27002 numbering.

artefacts

held by a system

at each review

hard

to go live

Document repository

where the evidence lives

teal = a system already holds it · olive = produced at each review. To go live: easy when half or more of the artefacts are already held by a system, moderate from a quarter to a half, hard below a quarter.

These are the artefacts auditors commonly ask for on this requirement, our guidance rather than text from the standard. Your assessor decides what is sufficient in your context, and asks for samples across the period when a report covers one.

system holds itEvidence a system already holds

Metrics on event volumes, incidents declared and time to decision · Policy repository / GRC workspace

periodic reviewEvidence produced at each review

Triage records showing each reported event assessed against the scheme · Document repository
Detailed decision records identifying who assessed the event, the categorization and the rationale · Document repository
Evidence that assessors are the designated incident coordination and response personnel · Document repository

governing documentDocuments that govern the control

The agreed incident categorization and prioritization scheme with criteria for declaring an incident and consequence levels · Document repository

First move

Mostly documents and reviews. Pull the 1 system-held artefact from your Policy repository / GRC workspace on a schedule; put the documents under version control with an owner and review date, and log each review as a dated record with a named reviewer.

Common gaps auditors find

No written criteria for when an event becomes an incident, so decisions are inconsistent
Events closed as non-incidents without any recorded rationale
Triage is done by whoever receives the alert rather than designated personnel
Priority is set by gut feel rather than a consequence-based scheme

Do this for your whole sheet

Paste the rows you run your controls from and get this mapping for every control at once, with the periodic-review ones flagged and a first move per row. No account for the first run.

Build my evidence sheet

5.24 Information security incident management planning and preparation · 5.26 Response to information security incidents