All types Page Article White Paper Download
Solutions The best route to security compliance
Hicomply Privacy™ ISO 27001 ISO 9001 ISO 14001 SOC 2 NHS DSPT NIST 800-53 Hicomply GRC™ Services & Customer Support
Platform A powerful suite of ISMS features
Dashboard ISMS Scoping Policy Management Risk Management Information Asset Management Task Management Integrations Hicomply for Enterprises Trust Centre Controls Monitor Hicomply AI SCIM Integration
Resources Everything you need to know
Knowledge & Insights Resources Hub Case Studies Sectors Glossary News ROI Calculator
Knowledge Base Learn more about infosec
ISO 27001 Knowledge Base SOC 2 Knowledge Base NHS DSPT Knowledge Base PCI DSS Knowledge Base NIST 800-53 Knowledge Base DORA Knowledge Base
Company Security and customers first
About News Partners Contact

ISO 27001 Annex A.16: Information Security Incident Management

The objective of this main control is to implement a process to manage security incidents effectively


A.16.1 Managing infosec incidents, events and weaknesses

A.16.1.1 Responsibilities and procedures

We’d all like to go along believing that we’re completely covered against threats but the bad news is that no one is immune to security incidents. Organisations are prone to experience at least a few security violations throughout their tenure.

Therefore it’s only wise to create a strategy to detect system weaknesses and soften the blow of an incident when it hits.

We recommend the following type of approach:

  • Detect a threat, An employee may notice a weakness or impeding threat within the ISMS and they will notify authorized personnel of the issue in different manners (i.e. Helpdesk, emails or personally informing them)
  • Classify the incident, upon notification, the authorized administrator will evaluate the threat and classify it based on criteria already established by the company risk management policies.
  • Treat the incident, authorised staff (technical and/or management) will use incident classification criteria to rate the incidents risk level, and propose a solution to the impeding threat.
  • Close the incident, all details of the incident must be logged and stored and a company records the resolution and possible lessons learned and notify the party who informed you that the incident is closed.

A.16.1.2 Reporting information security events

All employees and interested parties can report any security incidents or events to authorized personnel in the system and there should be a clear process as to how this is done and what the responses will involve.

As part of your training and awareness programme you should define and give examples of possible weaknesses, events or incidents that are cause for concern as well as how the process works. Weaknesses could be a sign of ineffective policy controls, issues with system availability or data breaches and therefore must be reported and dealt with urgently before their impact grows.

A.16.1.3 Reporting information security weaknesses

AIl employees find a weakness then they should report it internal contacts and .not verify the weakness using the defined process as to how this is done and what the responses will involve.

As part of your training and awareness programme you should define and give examples of possible weaknesses, events or incidents that are cause for concern as well as how the process works. Weaknesses could be a sign of ineffective policy controls, issues with system availability or data breaches and therefore must be reported and dealt with urgently before their impact grows.

A.16.1.4 Assessment of and decision on information security events

The relevant incident responder will examine any reported issues and then decide whether they can be classified as a weakness event or incident and then the team can decide on an incident plan.

The plan should aim to resolve the issue without as little impact on the company’s activities as possible.

A.16.1.5 Response to information security incidents

The incident responder in charge of resolving the information security incident will also be required to:

  • Gather evidence of the incident in a timely manner
  • Determine the root cause of the issue and the individuals directly involved
  • Inform authorised regulators if necessary
  • Verify that all incident data is appropriately logged in the system
  • Notify top management of the incident, who will then pass on the message to other interested parties
  • Rectify the information security weakness that signalled the incident.

A.16.1.6 Learning from information security incidents

Your policy and process must reflect that your incident analysis results will be used to improve the ISMS and prevent a repetition of the incident learning from the incident.

Every incident offers a lesson in disguise, smart companies will carry their experiences under their belt for the future. After recovery, the incident is logged for review and a learning exercise conducted, such as the team will make suggestions to remediate vulnerabilities, amend the ISMS policies and strengthen its data security. Once the amendments have been approved, staff may need to be retrained to keep up to date with their new policies.

A.16.7 Collection of evidence

Some incidents render the need to exercise criminal or civil action and resolution so company policy should reflect best practices for safe identification retrieval and preservation of evidence from the scene. These processes will ensure that management and staff understand how to implement these practices and preserve evidence that can be in these actions.