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
Incident response testing and training exercises conducted at planned intervals

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.

1. 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:

1.1 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.

1.2 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.

1.3 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.

1.3.1 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.

1.3.2 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:

Criticality	Description
Low	Less than 5 user laptops or computers infected with malware Data breach of some information classified as “Internal” Data breach of 1 person’s personal data Unauthorised access of a user to a non-critical information system Successful phishing attack on 1 user Unavailability of a non-critical information system which doesn’t impact customers
Medium	1 or more departments with laptops or computers infected with malware Data breach of some information classified as “Confidential” Data breach of personal data impacting up to 10 people Unauthorised access of a user to a critical information system Successful phishing attack on up to 5 users Unavailability of several non-critical information systems causing disruption to business operations
High	Most departments and endpoints impacted by malware Data breach impacting Customer Data Data breach of “Highly Confidential” data Data breach impacting the personal data of more than 10 people Unauthorised access of a malicious attacker to critical information systems Successful phishing attack which has resulted in financial loss Unavailability of critical information systems impacting customers

1.4 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.

1.5 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

1.5.1 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

1.6 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.

1.7 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.

1.8 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.

2. 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:

Role	Descriptions and Responsibilities
Incident Response Lead	The Incident Response Lead is the first point-of-contact for the IRT. The Incident Response Lead should be a person with suitable authority, organisational and technical skills, and have a strong understanding of information security controls and requirements. The Incident Response Lead is responsible for: Mobilising the IRT Opening the Incident Report Notifying management of the incident, and providing them with regular updates Ensuring decisions are made and recorded Managing the IRT to conclusion Ensuring any lessons learned are recorded to the Incident Report, and that the incident is formally closed
Incident Response Coordinator	The Incident Response Coordinator assists the Incident Response Lead in coordinating communications and recording information during the incident. The Incident Response Coordinator should be a person with good communication and organisational skills. The Incident Response Coordinator is responsible for: Minuting IRT meetings Recording required information in the Incident Report as directed by the Incident Response Lead Maintaining records of any supporting documentation and their locations Contacting and briefing relevant resources such as external stakeholders, authorities, suppliers, and staff, as directed by the Incident Response Lead Monitoring contact from the media or other external third-parties and ensuring they are redirected to staff responsible for public communications
First Responder	The member of staff to first be alerted to the potential security incident. This may be any incident responder, but will typically be a member of IT. The first responder is responsible for: Escalating the incident to the Incident Response Lead Gathering information from the incident reporter Attending the site of the incident, where possible and necessary Ensuring that potential evidence is handled in line with section 1.5.1 of this procedure Performing initial containment steps, if possible
Technology Lead	The Technology Lead provides technical guidance and information about the potentially impacted information systems, and the current continuity plans for these. The Technology Lead should be a person with suitable authority and expertise in the operations team, and should also be able to facilitate emergency access to systems and technology resources, should this become necessary during the incident. The Technology Lead would typically be the Operations Director or COO.
Information Security Lead	The Information Security Lead provides guidance and information regarding our businesses requirements for information security, and assists with identifying potential risks, and remediation activities. The Information Security Lead would typically be the ISMS Manager, but may also be a Security Officer or CISO.
Data Protection Lead	The Data Protection Lead provides guidance and information regarding our regulatory requirements for reporting potential personal data breaches. The Data Protection Lead would typically be the DPM, but may also be a legal advisor with expertise in data privacy law.
HR Lead	The HR Lead provides guidance and information regarding safety and disciplinary matters. The HR Lead should be a person with suitable authority in the HR department, and should have expert knowledge of staff health, safety, and contractual requirements.
Facilities Lead	The Facilities Lead manages the physical security of our offices, and may be required to provide secure areas for operation of the IRT and storage of evidence. The Facilities Lead may also need to advise on physical security and access requirements should the incident involve physical compromise of our offices. The Facilities Lead should be a person with the appropriate levels of authority in their area so that emergency access is facilitated, where required.
Legal Lead	The Legal Lead provides guidance and information on legal and regulatory matters to ensure we remain compliant. The Legal Lead may also provide key advise, such as whether legal action may need to be taken. The Legal Lead should be a person who is qualified in their area.