ISO 27001:2022 - A.5 Organisational Controls (Incident Management)

Whilst many of the Annex A controls adopted by ISO 27001 focus on preventing security problems from occurring, there will be times where, despite your best efforts, your organisation needs to respond to a security incident.  This can happen to any organisation, regardless of how robust its security programme may be.  

ISO/IEC 27002:2022 (the implementation guidance standard) defines information security incidents as ‘one or multiple related and identified information security events that can harm an organisation’s assets or compromise its operations’.  The purpose of the controls addressed in this blog is to help you prepare for such incidents, and to ensure that a clear process is in place to enable your organisation to respond and recover when they occur.

According to ISO 27002:2022, the incident management controls outlined in Annex A consist of a series of corrective, detective, and preventive controls.

• Preventive controls are intended to stop an information security incident from occurring, or at least reduce the likelihood of an incident.
• Corrective controls are intended to close off or resolve a security incident or issue that has already occurred.
• Detective controls are intended to help detect an information security incident as and when it occurs.

A.5.24 – Information security incident management planning and preparation

ISO 27002 defines information security incident management as the ‘exercise of a consistent and effective approach to the handling of information security incidents’.  Control 5.24 requires you to define and document your organisation’s approach to handling security incidents, which is commonly achieved via a documented incident management policy or incident management procedure.  This document needs to cover the entire incident lifecycle, from identification, verification, containment, response, and post-review, and outline all the steps that need to be taken at each stage.

Your incident management policy or procedure also needs to describe who within your organisation is responsible for responding to information security incidents, and provide contact information for these individuals to ensure that they can be reached promptly in the event of an incident.  Additionally, the policy/procedure needs to define the responsibilities of all members of staff in relation to incident management. This may include responsibilities such as:

• Notifying a particular individual immediately when an incident occurs
• Providing accurate testimonies following the incident and when the investigation is underway as requested
• Following the instructions of the incident management team during the containment and response phases.

Finally, your incident management policy and other relevant documentation needs to be communicated to all members of staff and other interested parties, as necessary.  This will ensure that they understand how an incident must be dealt with, by whom it must be addressed, as well as their responsibilities throughout the process.

A.6.8 – Information security event reporting

In order to conform to this control, your organisation must provide users with a way to report any suspected information security events.   Common practice is to document your organisation’s point of contact within your incident management policy, as well as how they can or should be contacted (e.g., email, work phone, etc.).  It is also important that users receive regular reminders informing them of who this point of contact is and how to contact them, which can be delivered through mechanisms such as email, policy re-reads or regular awareness briefings.  Since this control requires ‘personnel’ to be aware, and not simply employees, other persons doing work for the organisation also need to be informed of this.  This includes your contractors, subcontractors, and any sole traders doing work on behalf of your organisation.  It is important for personnel to report potential incidents as quickly as possible to help prevent improper handling and reduce the potential impact.

When reporting a potential incident, users must be able to do so through channels that are easily accessible and user friendly.  Incident reporting channels also need to be secure, to prevent information about incidents from being intercepted i.e., via a manipulator-in-the-middle (MitM) attack.  Examples of such channels include a dedicated incident email address, incident chats on Microsoft Teams, service desk tickets, work phones, incident forms, or online reporting pages.  

A.5.25 – Assessment and decision on information security events

This control requires your organisation to clearly distinguish between information security incidents and information security ‘events’, which ISO 27002 refers to as ‘an occurrence indicating a possible information security breach or failure of controls’.  To ensure your users understand this distinction, it is recommended that you have a list of incident types documented in your incident management policy.  If your employees believe they may have witnessed an incident, they can then refer to your documented incident criteria to understand whether it aligns with any of the incident types.

These criteria may include incident types such as:

• Infection of a device with ransomware or another type of malware
• Intruders breaking into your organisation’s office
• Confidential business information being leaked to the public
• Clicking on a phishing link.

In addition to the above, your organisation should provide criteria for information security ‘weaknesses’, which are flaws in your security measures that could potentially lead to an information security incident in the future. Examples of such weaknesses can include (but are not limited to):

• Unpatched software
• A broken lock on a security door
• An office window left open overnight
• Misconfigured hardware
• Weak or poor data encryption
• CCTV downtime during certain hours
• Absence of a timeframe for reporting incidents
• The reception desk being unmanned at lunchtime.

Documenting incident and weakness criteria will enable members of your security team to determine whether an issue they observe qualifies as an incident or has the potential to become one, thereby helping to conserve valuable time and resources.  

Having documented these criteria and communicated them to your users, you will need to assign an individual with the responsibility for declaring that an incident has occurred and document this responsibility in your incident management policy.  This role could be fulfilled by your CISO, security manager, incident manager, or anyone else in your incident management team.

Once a security event has been declared an incident, it should be promptly logged as such in your security incident log.

A.5.26 – Response to information security incidents

Control 5.26 requires that information security incidents be ‘responded to in accordance with the documented procedures’.  So, when taking actions to address a security incident, you need to ensure that these actions align with the steps required in your documented incident management policy.

To facilitate this, all staff responsible for addressing incidents will need to read and acknowledge the policy to ensure they are fully aware of their responsibilities.  Meanwhile, once incidents have been closed out, you need to record the steps and actions taken during the investigation in an incident report or on your incident log.  It is also recommended that these findings be presented at the next management review meeting, or at the next security team or incident team meeting.  If you identify that the incident management policy was not fully adhered to, the owner(s) of the policy should work with the incident management team to review and, if necessary, amend the policy or make it more flexible, depending on the requirements.

Depending on the resources available within your organisation, it may be beneficial to implement documented response plans for specific incident types.  It is recommended that you prioritise the response plans you decide to create based on the results of your risk assessments (i.e., prioritising those risks with a high impact or likelihood score).  Having such plans in place enables your organisation to respond more swiftly and consistently to incidents by following a well-developed, predetermined process, as well as allowing you to test them in advance, thus helping you to better prepare for these incidents before they occur (as per Control 5.24).

A.5.27 – Learning from information security incidents

One of the few benefits of experiencing a security incident is that it can provide a great deal of information on how and by whom your information assets have been compromised.  This information can be very useful.  It helps you understand which threat paths were used, decide where to focus your resources to manage the risks, and get a better overall picture of the security threats you might face in the future.

To achieve conformance to this control, your organisation needs to regularly use information about incidents you have faced to determine whether any new security controls need to be implemented or existing controls improved to prevent recurrence of similar incidents.  As discussed in the previous section, this information can be captured in an incident report or in your organisation’s incident log.

The information you document about previous incidents should include what has occurred, how it occurred, what the response was, and how your information security controls can be improved to reduce the impact or likelihood of such incidents in the future.  These findings can then be presented at management reviews or at meetings of your security team, incident management team, or security committee, as well as other meetings where key decision makers are involved.  When conducting these meetings, it is good practice to take minutes or recordings of discussions as evidence of lessons learned.

A.5.28 – Collection of evidence

If a security incident or near-miss occurs, one thing to consider is whether legal or disciplinary action needs to be taken against the perpetrators.  This should take into account the type of incident that has (or may have) occurred, its overall impact, any legal or business violations resulting from it, as well as the organisation’s ability to take such action.  If considered necessary, evidence may need to be gathered to help confirm the accuracy and integrity of the information related to the event.

Control 5.28 helps you to achieve this by ensuring that evidence is properly identified, securely collected, acquired and preserved.  When managing this evidence, you will need to identify what types of evidence are needed, how they will be collected and stored, by whom, and how a chain of custody will be established.  You will also need to consider whether your focus is on recovering from an incident or identifying the threat actors behind it.  If the former, evidence collection may not be necessary or appropriate.  In some cases, this decision may be made for you (especially if legislation or your insurance provider’s rules require it), however your organisation should make this decision for itself wherever it is able to do so.  This will ensure that neither too much nor too little of your organisation’s resources are spent collecting evidence, as well as helping to ensure a proportionate approach to this practice.

When collecting and storing the evidence, you should have measures in place to prove that evidence hasn’t been tampered with, and to prove that the systems from which evidence is taken were working at the time of collection.  Such evidence can come in a variety of forms, but may include:

• Photographs
• Documents and records (both hardcopy and digital)
• Screenshots
• Incident reports
• Incident log.

However, in some circumstances it may not be possible for your organisation to collect the evidence it needs. This may be due to a lack of skills or experience required to do so, or due to a lack of technology suitable for evidence collection.  In this case, it may be necessary to seek third-party support, particularly when dealing with sophisticated, technology-based incidents.

Information security incidents can have serious operational, reputational, financial and even legal consequences, depending on their nature and severity.  By adopting a robust strategy for managing information security incidents throughout their lifecycle, your organisation can reduce the impact and likelihood of those consequences, and restore the confidentiality, integrity and availability of your information assets quickly and efficiently.