ISO 27001 – Annex A.16: Information Security Incident Management

What is the objective of Annex A.16.1?

Annex A.16.1 is about management of information security incidents, events and weaknesses. The objective in this Annex A area is to ensure a consistent and effective approach to the lifecycle of incidents, events and weaknesses. ISO 27001:2013 addresses the lifecycle clearly through A.16.1.1 to A.16.1.7 and it’s an important part of the information security management system (ISMS) especially if you’d like to achieve ISO 27001 certification. Let’s understand those requirements and what they mean in a bit more depth now.

A.16.1.1 Responsibilities & Procedures

A good control describes how management establish responsibilities and procedures in order to ensure a quick, effective and orderly response to address weaknesses, events and security incidents. In simple terms an incident is where some form of loss has occurred around confidentiality, integrity or availability.

An example is where a window was left open and a thief stole an important file sitting on the desk… Following that thread, an event is where the window was left open but nobody stole the file. A weakness is that the window is easily broken or old and could be an obvious place for break-in. A weakness is also a common risk management or improvement opportunity.

The procedures for incident, event and weakness response planning will need to be clearly defined in advance of an incident occurring and been approved by your leadership. Those procedures are pretty easy to develop because the remainder of this Annex A control spells them out. Your auditor will expect to see all of these formal, documented procedures in place, and evidence that they are working.

A.16.1.2 Reporting Information Security Events

A good control here ensures that information security incidents and events can be reported through suitable management channels as soon as possible.

Employees and associated interested parties (e.g. suppliers) need to be made aware of their obligations to report security incidents and you should cover that off as part of your general awareness and training. In order to do this well they will need to have awareness of exactly what constitutes an information security weakness, event or incident so be clear about that, based on the simple example above. If an information security event occurs or is thought to have occurred, it must be reported immediately to the nominated information security administrator and that needs to be documented accordingly.

Some of the possible reasons for reporting a security incident include; ineffective security controls; assumed breaches of information integrity or confidentiality, or availability issues e.g. not being able to access a service.

The auditor will want to see and will be sampling for evidence of awareness of what constitutes a weakness, event or incident amongst general staff, and the awareness of incident reporting procedures and responsibilities.

A.16.1.3 Reporting Information Security Weaknesses

This control simply builds on incidents and events but might be treated slightly differently once reported (see A.16.1.4) It is essential for employees to be aware of the fact that when discovering a security weakness, they must not attempt to prove that weakness, as testing it may be interpreted as a misuse of the system, whilst also risking damaging the system and its stored information, causing security incidents!

A.16.1.4 Assessment of & Decision on Information Security Events

Information security events must be assessed and then it can be decided if they should be classified as information security incidents, events of weaknesses. Once a security event has been reported and subsequently logged, it will then need to be assessed in order to determine the best course of action to take. This action must aim to minimise any compromise of the availability, integrity or confidentiality of information and prevent against further incidents. Ideally it will have minimum impact to other users of the services. Consideration of exactly who needs to be made aware of the incident, internally, customers, suppliers, regulators can take place in this part of the lifecycle too.

GDPR and the Data Protection Act 2018 means that some information security incidents relating to personal data need to be reported to the Supervisory Authority too, so your controls should also tie in these considerations to meet regulatory requirements and avoid duplication or gaps in work.

A.16.1.5 Response to Information Security Incidents

It is always good to assign owners, be clear on actions and timescales, and as with everything for ISO 27001, retain the information for audit purposes (also essential if you have other stakeholders and regulators to consider). The individual placed in charge of dealing with the security event will be responsible for restoring a normal level of security whilst also;

• collecting evidence as soon as possible after the occurrence;
• conducting an information security forensics analysis (grand term but at least being clear on root cause and related aspects or what happened and who was involved, why etc);
• escalation, if required, for example to relevant regulators;
• ensuring all that all involved response activities are properly logged for later analysis;
• communicating the existence of the information security incident or any relevant details to the leadership for them to be further communicated to various individuals or organisations on a need-to-know basis; and
• dealing with information security weaknesses found to cause or contribute to the incident.

A.16.1.6 Learning from Information Security Incidents

This is an importance control, and your policy needs to demonstrate that knowledge gained from analysing and resolving information security incidents will be used to help reduce the likelihood or impact of any future incidents. As part of the commitment to continuous service improvement, you should ensure that you learn from the lessons of any security incident to therefore help evolve and adapt the ISMS to meet the changing landscape that is worked in.

Once an incident has been resolved, it should be placed into a status of review and learning, where the lead responder for that incident will discuss any changes required to the processes of the ISMS policies as a result. Any relevant recommendations should then be put to the ISMS Board for further discussion. Once the review and learning has been completed, updates have been made to the policies as required, the relevant staff must be notified and re-trained if required, and the cycle of information security awareness and education continues.

A.16.1.7 Collection of Evidence

The organisation has to define and apply controls for the identification, collection, acquisition and preservation of information, which can be used as evidence, especially if there is criminal or civil proceedings likely to happen from the incident.

Where the organisation suspects or knows that a security incident may result in legal or disciplinary action, they should carry out the collection of evidence carefully, ensure a good chain of custody and avoid any threat of being caught out by poor management.

It’s sensible to tie information security incident management clearly to disciplinary procedures too. Everyone should know to take precautions whilst also being clear on the consequences for those who fail to take it seriously.