All members of Equiano Group are responsible for protecting the confidentiality, integrity, and availability of data created, received, stored, transmitted, or otherwise used by the college, irrespective of the medium on which the data resides and regardless of format (e.g., electronic, paper, fax, CD, or other physical form). 

In the event the confidentiality, integrity, or availability of data is compromised, and a suspected incident has occurred, the incident should be reported immediately to the Managing Director. Reporting incidents quickly—regardless of certainty or magnitude—is critical to ensure the appropriate people can respond and contain the incident as soon as possible. 

Reason for Policy 

Incidents can occur at any time and of varying magnitude. Identifying and resolving incidents in an organized systematic way is a vital component of our overarching compliance programs. This policy provides a framework for identifying, assessing, reacting to, communicating about, and documenting an incident and corresponding remediation plans. 

Principles 

Security and privacy incidents must be (1) reported, (2) identified, (3) declared, (4) responded to, (5) remediated, and (6) resolved with adequate record-keeping. Detailed requirements for each of these steps are below. 

Report

Immediately report any suspicious 

activity or other suspected incident 

to Managing Director & SM & DPO

Identify

Inform SM or 

designee, confirm, quantify, and categorise 

incident within 3 business days

Declare

High-scale severity incidents 

within 1 business day of confirming incident

Initial incident report is drafted

Respond

Attempt to contain incident as soon 

as possible. Assign roles, bring in additional 

resources, as necessary. Develop communication plan

Remediate

Remediate and complete full 

incident report

Close

Debrief with lessons-learned 

meeting within 10 business days

Finalise documentation

Complete regulatory reporting, as 

required (within 60 days of discovery)

Reporting an Incident 

If you know or suspect any unusual or suspicious behaviour that does not match your expectation of good security or privacy management, immediately report the incident to the Managing Director. Even if you are not certain or cannot confirm the incident, it’s imperative that the incident is reported quickly so the right personnel can investigate as soon as possible. 

To report an incident:

CorporateComms@EquianoGroup.co.uk with clear email subject line: INCIDENT

If you wish to notify a compliance office directly or to report the incident anonymously, the following contacts can be used: 

Filing or reporting an incident can be done without fear or concern of retaliation. 

There are many different types of incidents that can be reported. Examples of incidents include, but are not limited to, the following: 

• misdirected or disclosed via mail, fax, verbal means 
• record documents misplaced, stolen, lost 
• documents are exposed, improperly disposed or stored  
• User accesses system or application with credentials other than his/her own 
• Unauthorised access to a system, application, or document 
• A device is lost, stolen, or otherwise unaccounted for 
• A rogue device is connected to the network which impacts or prevents others from working 
• System or individual is infected with malware or phishing (e.g., virus, ransomware) 
• Potential data loss due to a malware infection 

Identifying an Incident 

Confirmed incidents will be categorised as follows: 

1. Unauthorised or suspicious activity including systems or applications 
2. Data is lost, stolen, misdirected to, or otherwise shared with an unauthorised party  
3. A system is infected with malware or otherwise compromised, targeted, or profiled 
4. Other suspected compromise of data confidentiality, integrity, or availability 

Identifying Affected Data 

As quickly as possible, reasonable effort must be made to identify the type of data affected by the incident upon discovery and/or declaration.  

Declaring Incident 

Using the communication tools and risk assessment guides is important to determine authenticity and severity of any incident promptly. Severity judgments will be based on ongoing persistent threats, the volume of data involved, and the potential for reputational and/or financial harm to the institution, or any affected individuals. 

Low-scale severity incidents will be handled by the Managing Director. For more severe incidents, the Security Manager, the DPO and the designated IT MSP will convene into and begin drafting the initial incident report.

Coordinating Response to Incident 

Once an incident has been reported and declared, the incident must be contained to prevent further harm. By means of example, the following containment steps should be taken: 

• For IT security-related incidents, such as an infected system, any network cables should be disconnected immediately, and the system should remain powered on to allow for further investigation. 
• For incidents involving protected health information in paper form, immediate efforts should be made to retrieve any copies or gain assurances that all records are accounted for. 

Effective containment stops damage from being done and allows assessment of the scope of the incident and the initiation of remediation activities. 

• Ensure the incident has been properly contained 
• Ensure appropriate stakeholders are designated specific roles and responsibilities 
• Include additional resources as appropriate 
• Leads the incident responders to consensus on taking action or making decisions during the incident 
• Establishes out of band communication channels, as appropriate 
• Coordinates all meetings, including place, time, attendees, conference bridges, etc. 
• Ensures interview communication plans are established 
• Establishes a response timeline
• Collect and preserve any physical evidence in a forensically-sound manner 
• Adhere to appropriate chain of custody procedures 
• Perform searches for various keywords, timelines. 
• Document any relevant findings and provide to the incident coordinator  
• Maintain awareness of the incident status throughout the investigation 
• Plan for controlled notifications to internal and external parties, letters, website materials, or other notifications 

Remediating Incident 

An informed parties log may be kept to document the degree and reason to which all parties have been informed about the incident. 

Throughout all communications, be reminded of the confidentiality of the incident and that information must not be shared outside the response team unless warranted. 

Incident Report 

The initial incident report must be presented and reviewed and the incident report must contain the following attributes: 

• Incident name 
• Incident number 
• Incident description and type 
• Date and time declared 
• Date and time discovered/reported 
• Date and time occurred 
• Date and time contained 
• Date and time remediated 
• Assets or systems involved 
• Data involved, including data type, and independent verification 
• Individual(s) involved 
• Individual(s) affected 
• Root cause analysis 
• Containment steps and verification 
• Comprehensive response steps/action log 
• Remediation steps 
• Communications plan
• Regulatory reporting requirements 
• Lessons learned 

Closing Incident 

Closing an incident indicates that the incident has been completely contained, remediated, and properly reported. In order to close an incident, all attributes in the incident report must be completed, as defined in Incident Report. 

Incidents can only be closed by consensus of the senior management team and the designated IT MSP.

All documentation and evidence pertaining to the incident must be stored in a secure location approved by the Security Manager.

A post-mortem lessons learned meeting should be held within twelve business days to review the incident and adherence to this policy for any future modifications. 

1. Principles 

Security and privacy incidents must be (1) reported, (2) identified, (3) declared, (4) responded to, (5) remediated, and (6) resolved with adequate record-keeping. Detailed requirements for each of these steps are below. 

Report

Immediately report any suspicious 

activity or other suspected incident 

to Managing Director & SM & DPO

Identify

Inform SM or 

designee, confirm, quantify, and categorise 

incident within 3 business days

Declare

High-scale severity incidents 

within 1 business day of confirming incident

Initial incident report is drafted

Respond

Attempt to contain incident as soon 

as possible. Assign roles, bring in additional 

resources, as necessary. Develop communication plan

Remediate

Remediate and complete full 

incident report

Close

Debrief with lessons-learned 

meeting within 10 business days

Finalise documentation

Complete regulatory reporting, as 

required (within 60 days of discovery)

Reporting an Incident 

If you know or suspect any unusual or suspicious behaviour that does not match your expectation of good security or privacy management, immediately report the incident to the Managiing Director. Even if you are not certain or cannot confirm the incident, it’s imperative that the incident is reported quickly so the right personnel can investigate as soon as possible. 

To report an incident:

CorporateComms@EquianoGroup.co.uk with clear email subject line: INCIDENT

If you wish to notify a compliance office directly or to report the incident anonymously, the following contacts can be used: 

Filing or reporting an incident can be done without fear or concern of retaliation. 

There are many different types of incidents that can be reported to ITS. Examples of incidents include, but are not limited to, the following: 

• misdirected or disclosed via mail, fax, verbal means 
• record documents misplaced, stolen, lost 
• documents are exposed, improperly disposed or stored  
• User accesses system or application with credentials other than his/her own 
• Unauthorised access to a system, application, or document 
• A device is lost, stolen, or otherwise unaccounted for 
• A rogue device is connected to the network which impacts or prevents others from working 
• System or individual is infected with malware or phishing (e.g., virus, ransomware) 
• Potential data loss due to a malware infection 

Identifying an Incident 

Confirmed incidents will be categorized as follows: 

1. Unauthorised or suspicious activity including systems or applications 
2. Data is lost, stolen, misdirected to, or otherwise shared with an unauthorised party  
3. A system is infected with malware or otherwise compromised, targeted, or profiled 
4. Other suspected compromise of data confidentiality, integrity, or availability 

Identifying Affected Data 

As quickly as possible, reasonable effort must be made to identify the type of data affected by the incident upon discovery and/or declaration.  

Declaring an Incident 

Using the commuication tools and risk assessment guides is imporrtant to determine authenticity and severity of any incident promptly. Severity judgments will be based on ongoing persistent threats, the volume of data involved, and the potential for reputational and/or financial harm to the institution, or any affected individuals. 

Low-scale severity incidents will be handled by the Managing Director. For more severe incidents, the Security Manager, the DPO and the designated IT MSP will convene into  and begin drafting the initial incident report.

Coordinating a Response to an Incident 

Once an incident has been reported and declared, the incident must be contained to prevent further harm. By means of example, the following containment steps should be taken: 

• For IT security-related incidents, such as an infected system, any network cables should be disconnected immediately and the system should remain powered on to allow for further investigation. 
• For incidents involving protected health information in paper form, immediate efforts should be made to retrieve any copies or gain assurances that all records are accounted for. 

Effective containment stops damage from being done and allows assessment of the scope of the incident and the initiation of remediation activities. 

• Ensure the incident has been properly contained 
• Ensure appropriate stakeholders are designated specific roles and responsibilities 
• Include additional resources as appropriate 
• Leads the incident responders to consensus on taking action or making decisions during the incident 
• Establishes out of band communication channels, as appropriate 
• Coordinates all meetings, including place, time, attendees, conference bridges, etc. 
• Ensures interview communication plans are established 
• Establishes a response timeline
• Collect and preserve any physical evidence in a forensically-sound manner 
• Adhere to appropriate chain of custody procedures 
• Perform searches for various keywords, timelines. 
• Document any relevant findings and provide to the incident coordinator  
• Maintain awareness of the incident status throughout the investigation 
• Plan for controlled notifications to internal and external parties, letters, website materials, or other notifications 

Remediating an Incident 

An informed parties log may be kept to document the degree and reason to which all parties have been informed about the incident. 

Throughout all communications, be reminded of the confidentiality of the incident and that information must not be shared outside the response team unless warranted. 

Incident Report 

The initial incident report must be presented and reviewed and the incident report must contain the following attributes: 

• Incident name 
• Incident number 
• Incident description and type 
• Date and time declared 
• Date and time discovered/reported 
• Date and time occurred 
• Date and time contained 
• Date and time remediated 
• Assets or systems involved 
• Data involved, including data type, and independent verification 
• Individual(s) involved 
• Individual(s) affected 
• Root cause analysis 
• Containment steps and verification 
• Comprehensive response steps/action log 
• Remediation steps 
• Communications plan3 
• Regulatory reporting requirements4 
• Lessons learned 

Closing an Incident 

Closing an incident indicates that the incident has been completely contained, remediated, and properly reported. In order to close an incident, all attributes in the incident report must be completed, as defined in Incident Report. 

Incidents can only be closed by consensus of the senior management team and the designated IT MSP.

All documentation and evidence pertaining to the incident must be stored in a secure location approved by the Security Manager.

A post-mortem lessons learned meeting should be held within twelve business days to review the incident and adherence to this policy for any future modifications.