Purpose

When an incident occurs which affects the confidentiality, integrity, and availability of Evercam's or our Clients' information and associated assets, a fast, practiced response is critical to minimising the potential impact of the incident. A failure to properly plan for, and respond to, incidents may put our services, and the information of our employees, customers, and third-parties, at risk, resulting in reputational damage and potential financial loss. This document details how our organisation responds to incidents.

Scope

This procedure shall be applied to all information security incidents that may impact the information and information systems that fall within the scope of our ISMS.

Audience

All employees, contractors, and third-parties who have a role in identifying and responding to incidents that impact our information and information systems shall follow this Incident Response Procedure. These people include, but may not be limited to:

• Senior management

• Managers

• Department heads

• System administrators

• Network engineers

• System & asset owners

• Contractors

• IT support

• IT service providers

• Data protection professionals

• Security professionals

For the purposes of this document, the employees, contractors, and third-parties who have a role in our incident response procedures shall be collectively referred to as "incident responders".

Communication

This Incident Response Procedure shall be communicated to all employees and agency staff as part of the relevant department training programme, and periodically following any changes to the procedure, or prior to any incident response training exercises. All contractors and third-parties providing IT and operations services, or outsourced incident monitoring and response, shall be provided with a copy of this procedure as part of the process for contracting services. Contractors and third-parties shall be re-issued with updated versions of this procedure periodically, and following any changes. Contractors and third-parties shall also be re-issued with the latest version of this procedure when engaging in incident response training exercises. Members of the Incident Response Team (IRT) shall retain offline copies of this document for reference in the event that our information systems become unavailable during an incident.

Disciplinary Process

Where an incident responder identifies a potential incident and knowingly ignores an incident, or fails to respond to the incident in breach of this Incident Response Procedure, they shall be subject to the disciplinary process documented in the Company Manual, or the applicable service contract.

Improvement

This document is reviewed for improvement in several ways. They are:

• Management review on an annual basis to determine if the procedure continues to meet the requirements of the organisation

• Independent review of our organisation's ISMS which may identify areas of non-conformance or opportunity for improvement

• The procedure is to be updated based on the tests results from incident response and BCB exercises

Management also endeavours to plan incident response procedures so that our information and information systems are not misused or compromised during a security incident, either intentionally or unintentionally. This is done by identifying and assigning separate duties and responsibilities to guard against damaging insider activities. Where an incident responder identifies potential conflicts in the carrying out of incident response activities, incident responders should raise their concern immediately with their line manager, or the ISMS Manager.

Procedure

The Incident Response Procedure has been developed based on best practice principles for responding to information security incidents. Briefly, the primary stages of incident response are:

• Preparation

• Identification

• Containment

• Eradication

• Recovery

• Lessons learned

The diagram below illustrates our Incident Response Procedure:

Reporting

Incident responders may become aware of potential incidents from various sources, including customers and third-parties. Our employees, contractors, and third-parties are prepared to report incidents as follows:

• Users report directly to IT or their line managers in line with our Information Security Policy and Security Awareness Training Course/training programmes;

• Administrators report directly to the IRT in line with our Information Systems Security Policy.

First Response

Once an incident responder has been made aware of a potential incident, they shall prepare for possible escalation of the incident by:

• Carrying out a preliminary assessment of the incident to determine if it is a potential security incident;

• Notifying the Incident Response Lead immediately where it is confirmed to be a potential security incident;

• Assisting the incident reporter in performing initial containment activities, such as disconnection from the network;

• Avoiding making any changes to affected information and information systems, where possible;

• Ensuring that any users or other third-parties do not touch or remove affected equipment, where possible.

Mobilising the Incident Response Team

Once the Incident Response Lead has been alerted to a potential information security incident, they shall:

• Refer to the Incident Response Contact Sheet and contact IRT members and organise an initial meeting to confirm that the incident is a security incident, and determine an initial criticality level for the incident.

• This can be via conference call or a face-to-face team meeting, as appropriate.

• Open an Incident Report once the security incident is confirmed and record the initial meeting details. Contact senior management or relevant department heads to notify them of the incident.

• Call a formal "War Room" meeting of the IRT. Depending on the criticality of the incident, not all IRT members may be required for the meeting.

Meeting security considerations

To minimise the risk of unofficial communication of the incident, the venue should not be in a public area. The venue should also not be located in an area with limited access to communications. Alternatively, the meeting may be held via conference call or other web-based conferencing services. Where there is a need to use conferencing services outside of the provided business services, the Incident Response Lead shall ensure that meeting invites to the conference or video call require authentication to join, and that the service is secure in line with our Information Systems Security Policy.

Determining incident criticality

Determining a criticality level for the security incident assists the IRT in deciding who to notify, and what resources are necessary to resolve the incident. For example, where the criticality is low, notifying all members of the management team may not be required. In situations where more than one incident may be occurring, prioritising the incidents will allow them to be handled in the correct order. Our organisation uses the below criteria to help determine the criticality of the security incident. They should be used as guidance only, and should not be considered exhaustive:

Assessment

Once the IRT is formally assembled, they shall perform the following activities:

• Determine if the incident is ongoing, and what steps can be taken towards containing it;

• Determine the possible cause of the incident.

• Where the cause is known this may also assist with containment.

• Determine the impact of the incident by identifying:

  • Any information that may be compromised or at risk, and any controls in place to protect the data such as encryption, backups, etc. Affected infrastructure e.g. servers, communications equipment, cloud-based infrastructure, computers, office locations, etc.

  • Affected services e.g. intranet, CRM, etc. Affected customers.

  • Affected departments.

  • How long services have been unavailable for, where relevant.

• Based on the impact assessment, determine any additional resources required to resolve the incident.

• Determine if digital forensics will be required, and what evidence may need to be collected.

• Determine if third-party support is required for containment, eradication, recovery, and/or forensics activities and initiate contact.

• Determine the relevant authorities and third-parties that may need to be notified, such as law enforcement, data protection supervisory authorities, customers, service providers, etc. and initiate contact.

• Record all meeting minutes and assessment information directly to the Incident Report, where available.

Containment, Eradication, & Recovery

Once the security incident has been assessed, and all necessary resources mobilised to resolve the incident, the IRT shall:

• Oversee all steps taken to contain, eradicate, and recover from the threat, ensuring that relevant decisions and actions taken are recorded for inclusion in the Incident Report

• Ensure that potential evidence is identified, and that all incident responders are informed of the correct handling procedures

• Ensure that any changes raised to resolve the incident, such as emergency vulnerability patching, are made in line with our Change Control Procedure

• Ensure that any business continuity activities performed to recover services are done in line with our Business Continuity Plan

Handling potential evidence

Where forensic investigation of the incident is required, our organisation shall appoint a qualified third-party to carry out the investigation. However, incident responders may still need to handle and secure potential evidence. Incident responders shall: Avoid making any changes to data, or accessing the original system, where possible. Avoid powering off affected endpoints, where possible. This will allow volatile data to be preserved. Keep a record of what they did and when they didn’t i.e. from arriving on scene, to handling equipment, to performing any containment tasks, to securing equipment, etc. Ensure that any users or other third-parties do not touch or remove affected equipment. Take photos or video of the equipment or area where this may be helpful to do so. Ensure that any photos, video, equipment or other evidence is stored securely and only accessible to authorised persons. Where evidence may need to be accessed, moved, or transferred, ensure that chain of custody is recorded. Where evidence is collected by the third-party forensic investigator, ensure that any Chain of Custody Form(s) are completed, signed, and stored securely

Communication

Communication is a key element of effective incident response. Without it, incident responders may not know how or when to act, key decision-makers may not have all the necessary information required to make effective decisions, third-parties and customers may not know when to expect services to be re-established, communications officers may not know what to communicate to the public, and authorities may not be properly notified in line with legal requirements.

The IRT shall be responsible for maintaining effective communications throughout the incident by:

• Ensuring approved means of internal communication are established so that all required incident responders are contactable, taking into consideration the availability of company systems, equipment, and mobile phones.

• Ensuring that relevant department heads or line managers are delegated to pass on all necessary communications to employees, contractors, and third-parties they are responsible for.

• Ensuring that communications are accurately tracked and documented for reporting purposes. Where legal action may result from the incident, it may be advisable to take audio recordings of important communications. These audio recordings shall be handled as evidence in line with section 1.5.1 of this document.

• Ensuring that details of the security incident are not communicated to unauthorised persons.

• Ensuring external stakeholders such as customers, regulatory authorities, law enforcement, suppliers, etc. are notified of the incident, as required.

• Ensuring that all calls regarding the incident are properly directed e.g. where the media may make contact, this should be directed to the line manager or department head responsible for public communications. Liaising with the public communications team to ensure all public communications are approved prior to release.

Incident Conclusion

While some aspects of recovery may still be ongoing, it may no longer be necessary to have the IRT mobilised. At this point, the Incident Response Lead shall: Determine if the security incident has been resolved to an acceptable degree. Review the Incident Report and other relevant documentation to ensure all necessary information is recorded, accurate, and appropriately secured. Schedule follow-up meetings where required, such as in situations where recovery is ongoing. Inform management and other relevant department heads that the IRT is no longer required for the incident and will be ceasing immediate incident response activities. Schedule a lessons-learned session for post-incident analysis.

Lessons Learned

While the handling and resolution of a security incident can be a stressful event, it is crucial that the IRT and other relevant incident responders take time to carry out post-incident analysis. Analysing the incident will allow the IRT to identify possible improvements, both in the handling of the incident, and in current security controls. The IRT shall:

Carry out a post-incident analysis at a scheduled date; Identify possible improvements; Identify possible outstanding risks, such as areas that may be impacted by a similar incident occurring;

Carry out a risk assessment in line with our Risk Management Process;

Ensure all improvements are recorded to the Improvement Register, where required;

Ensure all risks are recorded to the Risk Register, where required;

Ensure the lessons learned are recorded to the Incident Report; Close the incident, and record this in the Incident Report.

Roles & Responsibilities

The roles and responsibilities required for carrying out our Incident Response Procedure are defined below. There may be situations where roles may be combined, or they may be carried out by the same person. The below roles and their descriptions should not be considered exhaustive:

—————————————————————

Created by: COO (ISMS team)

Creation Date: 12.05.2023

Last modification date: 27.11.2025

Document approver: Head of Compliance