Information security event reporting

What the requirement 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. In the ISMS the control is compared with the controls determined in risk treatment and recorded in the Statement of Applicability as included or excluded, with the reason and the implementation status.

What the guidance adds

Event reporting works only when it is easy and safe. The guidance asks for the channel, the response, the protection for the reporter and the record.

What good looks like

Put the control in the Statement of Applicability with an owner, a status and the risk it treats. Then keep A documented reporting procedure naming the point of contact and the channels available, such as a portal, hotline or mailbox and one live sample together.

Evidence an assessor asks for

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

The question an assessor will ask

An assessor will ask for A documented reporting procedure naming the point of contact and the channels available, such as a portal, hotline or mailbox, then trace it to the system it protects. For A.6.8 the test is whether that record ties to a live sample, not whether the control is named in a policy.

Common 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

Before the next audit

Before the next audit, check one live sample for this gap: staff do not know where or how to report, so events surface late.