ISO 27001 A.5.25: Assess Events and Decide on Incidents

What A.5.25 requires in practice

Control A.5.25 asks the organisation to assess information security events and decide whether each should be treated as an incident. An event is an observation that might matter, such as an alert, a complaint or something unusual a colleague noticed. An incident is an event that has been judged significant enough for response under the incident process.

In practice the control calls for criteria, people and a record. The organisation needs a consistent way to judge significance, named people who can make and escalate the decision, and a record of what was decided and why. The standard leaves the method open. A short list of categories with worked examples is one way to help assessors reach consistent decisions; a complex scoring scheme is neither required nor necessarily better.

Decide what makes an event consequential

Develop criteria that reflect confidentiality, integrity and availability consequences. A seemingly small event may affect highly sensitive information or a critical business process. Conversely, a large number of blocked attempts may not establish that information has been compromised. Technical severity and business consequence are related but different inputs.

Define who can make the initial assessment and who can escalate or revise it. The responsible person needs enough information and competence to recognise when specialist help is required. A rigid script without an escalation route can cause staff to force unfamiliar events into an unsuitable category.

Keep the criteria usable. A few well-explained categories with examples may work better than an elaborate score that responders cannot apply consistently. The standard does not prescribe a particular numerical scale. Test whether different trained assessors reach reasonably consistent decisions from the same facts.

Separate facts, assumptions and missing information

Record what is known, how it is known and what remains uncertain. A user’s statement that a file was “public” may mean that a link was created, that an unauthorised person opened it or merely that a sharing setting looked unfamiliar. Those possibilities need different investigation and response.

Do not let uncertainty become indefinite delay. Establish an interim classification and suitable protective action where justified, with a clear owner for obtaining further information. Reassess when new facts arrive. An early decision made responsibly with incomplete evidence can change without implying that the original assessor acted incorrectly.

Why event assessment matters to the business

If every alert becomes an incident, responders are overwhelmed and real problems are missed. If events are dismissed too readily, genuine breaches go unaddressed and notification duties may be overlooked. A consistent decision step protects both attention and accountability. It also gives customers and regulators a defensible account of why the organisation acted as it did. Where the same facts lead to the same decision regardless of who is on duty, response becomes predictable, resources are used sensibly and the lessons from each case are easier to compare and apply.

How to implement A.5.25

Aim for criteria that a trained person can apply quickly and consistently. A workable sequence is outlined below. A decision step is only as good as the people applying it, so keep criteria short and teach them through real examples from your own services. Give assessors permission to escalate when unsure, and make clear that an interim decision is acceptable while facts are gathered. Review a sample of past decisions occasionally to see whether different people would reach the same answer, and adjust the criteria if not.

1. Define what makes an event significant in terms of confidentiality, integrity and availability.
2. Write a few clear categories with examples drawn from your own services.
3. Name who makes the first assessment and who may escalate or revise it.
4. Record what is known, how it is known and what is still uncertain.
5. Set an interim classification and protective action when facts are incomplete.
6. Reassess when new information arrives.
7. Test consistency by giving different assessors the same scenario.

Evidence an auditor expects for A.5.25

Auditors want to see the decision step working on real events. Typical evidence includes:

• records of recent events showing how each was assessed and categorised
• the criteria assessors use, with examples
• interviews with the people who make the first assessment, asked how they decide and when they escalate
• observation of an event being logged and judged
• records of reassessment when facts changed
• examples of events judged not to be incidents, with the reasoning

A sample drawn across different reporters and times shows whether decisions are consistent.

Common nonconformities with A.5.25

Findings tend to show a decision made informally or not recorded. Findings tend to show a decision made informally or not recorded. An auditor may select a few recent events and ask who judged them, using what criteria, and where that judgement was written down.

• No criteria, so each person decides differently on similar events.
• Events logged without any record of the assessment or reasoning.
• Everything treated as an incident, or nothing categorised at all.
• Initial assessments never revisited after new facts emerged.

Illustrative IT example: an alert on an unused account

Illustrative construction example: an unexpected drawing revision

A hypothetical construction team finds a drawing revision in its portal that nobody on the project recognises. Staff initially assume an ordinary document-control error. Assessment checks who authorised the change, which copies were distributed and whether work has relied on the altered information.

The organisation determines the security significance alongside the operational implications and coordinates the appropriate response. The example concerns integrity rather than a conventional cyberattack. A triage scheme limited to malware or data disclosure would risk missing the relevant consequence.

Prioritise action without suppressing reports

Assessment needs a reliable queue and acknowledgement route. Reports should reach someone who can act, including when the usual owner is absent. Different priorities can justify different response arrangements, but lower priority should not mean ownerless or forgotten.

Provide appropriate feedback to reporters. Explain whether further information is needed and avoid penalising people for good-faith concerns that turn out not to be incidents. If staff believe only confirmed breaches should be reported, the organisation will receive information too late to assess it effectively.

Make the decision traceable

Useful records include the initial event, relevant facts, assessment, decision-maker, priority and subsequent changes. The level of detail should support later verification and learning. A.5.25 does not require one named ticket system, but a decision visible only in someone’s memory is difficult to evaluate.

Sample both incidents and events closed without incident classification. Can another competent person understand why the decision was reasonable? Review repeated low-priority events for patterns. Individually minor signals may reveal a shared weakness when considered together.

Common failures include blindly adopting a tool’s severity score, treating missing evidence as proof of no impact and closing a report because responsibility is disputed. Another weakness is recording only the final label, with no reasoning or trail of reassessment.