Solutions The best route to security compliance
Platform A powerful suite of ISMS features
Resources Everything you need to know
Knowledge Base Learn more about infosec
Company Security and customers first

Information security event reporting

Annex A control 6.7 of the 2022 version of the ISO 27001 standard can be mapped to ISO 27001:2013 Annex A 16.1.2 and ISO 27001:2013 Annex A 16.1.3

Organisations must create a system too allow personnel to report information security events quickly and appropriately. This process is what is covered in ISO27001:2022 Annex A control 6.8.

Information security incidents or breaches are on the rise in both intensity and frequency, with malicious software, hackers, ransomware, unauthorised access and malignant external sources all on the rise.

Even the most secure network carries some risk of a breach. Having policies in place surrounding reporting incidents can help organisations identify potential threats before they cause harm.

Understanding information security event reporting

Reporting is a key aspect of any effective cybersecurity strategy, as it helps organisations understand what is taking place before it’s too late. Incidents, breaches, and other cyber-based events should be noted, examined, and resolved in such a way that prevents them from occurring again in the future. This requires documentation, analysis and prevention strategies.

Without reporting, organisations could never learn from potential threats, making it harder to put preventative measures in place. Incidents must be address quickly and effectively, as shorter response times mitigate the impact of a breach on the organisation.

The importance of control 6.8

Timely, effective, and consistent information security event reporting is the main priority of control 6.8, ensuring incidents are documented swiftly and accurately to improve business security both in the short and long term.

An information security event reporting programme should be put in place to detect and mitigate incidents, enabling receipt, evaluation and response to reported incidents.

Control 6.8 aims to:

  • Encourage prompt, effective and consistent information security event reporting
  • Detect unauthorised access or improper information system use proactively
  • Facilitate the creation of incident response plans
  • Establish a base for ongoing observation activities

A key part of implementing control 6.8 is to regularly review incidents to determine trends, detect issues and minimise the negative impact on the organisation.

Meeting the requirements of control 6.8

To adhere to the guidelines of control 6.8, it is vital for organisations to ensure that:

  • Obligations to report information security incidents promptly are understood by all
  • Organisations maintain a record of points of contact for reporting data security incidents, and that the process is simply, accessible, and available
  • Organisations keep a record of all incidents, such as event logs, change requests, problem reports, and system documentation

Events requiring information security reporting, according to control 6.8, include:

  • Ineffective information protection measures
  • Security expectation infringement with regards to data integrity, confidentiality, and availability
  • Human error
  • Failing to comply with the information security policy
  • Physical security measure infringement
  • Failing to submit system modifications to the change management process
  • Malware or any other unusual software or hardware system behaviour
  • Suspecting a malware infection
  • Access violations
  • Any other vulnerabilities

Personnel reporting the incident are not responsible for testing the vulnerability or effectiveness of the information security event. This should be left up to qualified personnel.

What’s changed since 2013?

Control 6.8 replaces both Annex A 16.1.2 and Annex A 16.1.3 from ISO 27001:2013. The two previous controls have been fused and redrafted with more user-friendly language. The 2022 version also includes two additional considerations which are not present in the 2013 controls.

These are: system alterations which have not been processed by the change control procedure; and suspected malware infection.