Information security event reporting

What the control asks

A mechanism is to be provided so personnel can report information security events they notice or suspect, promptly and through the right channels. Purpose: support reporting of events that personnel can spot in a timely, consistent and effective way. Guidance: all personnel and users should know they must report events as fast as possible so incidents can be prevented or their effects limited, and should know the reporting procedure and the contact point. The mechanism should be as simple, accessible and available as possible. Events include incidents, breaches and vulnerabilities, and situations worth reporting include controls that do not work, breaches of expected confidentiality, integrity or availability, human error, non-compliance with policies or standards, physical security breaches, system changes that bypassed change management, software or hardware malfunctions and anomalous behaviour, access violations, vulnerabilities and suspected malware. People should be told not to try to prove a suspected vulnerability, because testing it can look like misuse, can damage systems or services, can spoil or hide digital evidence and can expose the tester to legal liability. See the ISO/IEC 27035 series.

Purpose in the standard’s terms, in our words: Supports timely, consistent and effective reporting of events personnel can identify.

Attribute values in one line: Detective; Confidentiality, Integrity, Availability; Detect; Information security event management; Defence.

The five attribute values

These are the published values for this control, from ISO/IEC 27002:2022 clause 4.2 and Annex A Table A.1. Where your own value differs, record the difference and the reason in the same row rather than replacing the published value.

Evidence an auditor asks for

The attribute is a claim about how the control behaves. The evidence is what proves it operates. Keep both, and keep them together.

• A documented reporting procedure naming the point of contact and the channels available, such as a portal, hotline or mailbox
• Awareness material telling personnel and users what to report, how quickly and where
• Records of events reported by personnel, with time from observation to report
• Guidance instructing people not to test suspected vulnerabilities themselves
• Evidence the reporting channel is available outside working hours where needed
• Metrics or reviews showing reports are received across the range of event types

Where audits commonly find gaps

• Staff do not know where or how to report, so events surface late
• The channel is a single person's inbox with no cover
• Users try to verify suspected vulnerabilities themselves
• Human errors and near misses go unreported because reporting is seen as blame

What ISO/IEC 27028 changes for this control

It carries a single control type, detective, which sets what the evidence has to prove. Its earlier numbering (16.1.2, 16.1.3) is kept in the register so an older audit file can still be traced.

The guidance expands how the five values are used; it does not change the control or add a requirement. A register that carries the values and the evidence can answer the attribute question for this control without a new document. A register that does not can add the columns at the next SoA version, with an owner and a review date.

Controls that share its values

• 5.25 Assessment and decision on information security events
• 8.15 Logging
• 8.16 Monitoring activities

Read the five attributes All 93 controls