Accessibility statement

Method statement – Data loss and information security breach management

1. Introduction

1.1 This method statement describes elements to consider and address in the event of an information security breach. It will assist the University in determining appropriate courses of action if a security incident involving personal or confidential data occurs and dealing with any security incident effectively. It forms part of the University’s Information Security and Data Protection policies.

1.2 Information security incidents can happen for a number of reasons and occur in different contexts. An incident may be:

  • accidental or deliberate; e.g. a user falling for drive-by phishing or a targeted compromise of a member of staff;
  • against a service impacting availability and accessibility (denial of service) to stop internal or external users accessing services;
  • targeting various or specific types of information; ransomware tends not be specific,encrypting what it can find, whilst other attacks may be targeting specific services or information such as personal data, intellectual property, financial information or other confidential information. 

An information security incident may encompass multiple aspects from the above examples and one type of incident may be reconnaissance for further, more sophisticated or specific, attacks. 

1.3 The University must take appropriate measures against accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. An incident management policy constitutes one of these measures and supports the University’s obligations under principle 5 (1) (f) of the UK GDPR.

1.4 Breaches of information security, duties of care, confidentiality and integrity (including inappropriate access to or loss of research data) constitute unacceptable research conduct, as governed by the University’s Policy on Research Integrity and its research and academic misconduct policies.

1.5 The method statement should be used alongside policy and guidelines issued by the University of York.

2. Information security incident response

2.1 Information security incidents must be reported as soon as discovered and notified in accordance with the reporting protocols and principles given in the University’s Incident Management Policy (see 4.1). Contacts for reporting are:

Please do not delay by informing your Head of Department, colleagues or members of staff.

2.2 The University security incident response is based upon the National Cyber Security Centre (NCSC) guidance and falls under the University’s Major IT Incident Plan.

Decorative image, see the text below for what is included in this flow chart

1. Triage - Understanding the severity and type of incident allows us to determine how urgent our response is and ensures that we get the correct people informed and involved from the outset. There are two aspects to look at when assessing an incident: 

    • Severity assessing the impacts to Confidentiality, Integrity and Availability; and
    • Category or type of incident.

2. Analyse - Undertaken both internally on the incident and externally with partners, staff, students and the wider public:

a. We will perform technical analysis on the incident, understanding the nature and persistence of the incident, also refining impacts and continuing to inform decision makers appropriately.

b. The priority is to understand enough to take containment/mitigation actions and ultimately remediate the incident.

c. We will also be monitoring and updating external relations and a wider public response.

It is important to ensure tasks are prioritised carefully, reduce where possible pressure on single or similar resources,  and that findings are constantly reviewed and correlated, as these may lead to new tasks.

3. Contain/Mitigate - Informed by Analysis but not dependent on if being fully complete we must take steps to reduce the impact of the incident and prevent things from getting worse.

a. This usually involves such things as blocking activity, isolating systems and resetting accounts.

b. It may also involve non-technical actions such as media handling.

c. This stage may require critical decisions such as taking a core business system offline. It is important to consider the consequences of any such actions, both good and bad.

d.  You should also evaluate the possibility that the attacker might react to your actions, or bury themselves more deeply in the network (often in the case of targeted attacks).

In some cases, when we undertake any containment action we will monitor and analyse further before mitigation action is taken. The process of Analyse, Contain and Mitigate can be cyclical based on the evolution of any incident.

4. Remediate/Eradicate - The aim of this stage is to fully remove the threat from your network and systems. This often involves similar actions to containment but is sometimes coordinated so that all actions are carried out simultaneously. It is important to confirm that remediation has been successful before moving to the recovery stage - this may involve analysing and monitoring for a period to assess further issues or incidents.

5. Recovery - At this point, systems are returned to 'business as usual'. Clean systems and data are put back online and in some cases, final actions are taken to handle regulatory, legal, or PR issues.

6. Review - The preparation and presentation of the Post-Incident Review to the Information Security Board and tracking of recommendations by the Board.

2.3 Actions and points for consideration by the incident response lead when are given in the supporting guidance: Checklist for information security breaches.

2.4 University Officers, Heads of Departments and Section Heads will work with relevant stakeholders, data protection and security specialists and the Information Security Board, where appropriate, to investigate any reported incident in their area of responsibility. They will assist in the timely reporting of incidents as above and update on the remedial actions to the Director of IT Services, The Senior Information Risk Owner and Information Security Board.

2.5 Departments holding data supplied by a third-party organisation, where there is a contractual duty to report an incident to that organisation within a particular time frame, must respect the reporting timescales and guidelines agreed in the governing agreement or terms of use, having first consulted the Director of IT Services and Senior Information Risk Owner..

2.6 The Director of IT Services and the Senior Information Risk Owner will have oversight and monitoring of in going incidents and will update the University Executive Board as required.

2.7 The Data Protection Officer will determine notification to the Information Commissioner’s Office.

2.8 The Information Security Board will assess the Post-Incident Review to identify recurring  areas of risk,  recommendation or requirements for new or changed policies or procedures and any other relevant controls. 

3. Oversight

3.1 The Information Security Board, chaired by the Director of Technology, Estates and Facilities, will monitor the effectiveness of this method statement and carry out regular reviews.

4. Policy and implementation documents

4.1 Information Security Policy – Incident management policy

4.2 Guidance - Checklist for information security breach

Document history and status

26 March 2014 Approved by Information Policy Executive
24 April 2014 Approved by Information Security Board
29 January 2016 Reviewed and approved by Information Security Board
23 March 2017 Reviewed and approved by Information Security Board
3 July 2017 Addition of 2.7 approved by Information Security Board
20 June 2018 Reviewed and approved by Information Security Board
4 March 2021 Reviewed and approved by Information Security Board
21 June 2023 Review and approved by Information Security Board

Status

Review cycle: Annual

Date of next review: July 2024