Skip to main content

Incident Management Policy

1: Purpose

This policy explains what to do when a suspected or confirmed Security Incident or Personal Data Breach is identified in the OpenSAFELY Service. For the purpose of this Policy, a Security Incident or Personal Data Breach are collectively referred to as an “Incident”.   

1.1 For the purpose of this Policy, an Incident also includes a “Near Miss”. A Near Miss occurs when an event or situation had the potential to cause, but did not actually result in, a Security Incident and / or a Personal Data Breach.  

1.2 An Incident may, if not addressed in an appropriate and timely manner, result in a range of adverse effects for individuals, including emotional distress, and physical and material damage.  A failure to adequately respond to an Incident can also have a significant impact on the reputation of the Data Controller, the Data Processor and the OpenSAFELY Service, and the public’s trust in their ability to protect their Personal Data.  

1.3 The purpose of this Policy is to set out: 

  • How to identify an Incident; 
  • What Staff and Service Users must do when they identify an Incident, which includes when staff suspect or are unsure an Incident has occurred; 
  • The importance of timely reporting of Incidents; and
  • What happens following the report of an Incident.

1.4 This Policy supports the OpenSAFELY Data Access Agreement (DAA) and the Policies therein. 

1.5 It contains the following sections for reference:

1: Purpose

2: Scope

3: Policy requirements

2: Scope

As well as all OpenSAFELY Users (including NHS staff), all OpenSAFELY staff fall within the scope of this policy.  This includes all staff who are employed on a permanent, fixed term or zero-hours basis, including, but not limited to, contractors, temporary staff, secondees, Ph.D. Students, applicants, volunteers and directors – referred to in this policy as “Staff”. 

3: Policy requirements

3.1 What is an Incident?

For the purposes of this Policy, an Incident means a Security Incident, a Personal Data Breach, or both. References to an ‘Incident’ in this Policy are intended to include all such events unless otherwise specified.   

An Incident also includes a Near Miss.  A Near Miss is an event or situation that had the potential to cause, but did not actually result in, a Security Incident and / or a Personal Data Breach.

3.1.1 A Security Incident is an occurrence that actually or potentially jeopardises the confidentiality, integrity, or availability of the OpenSAFELY Service or the information the Service processes, or transmits or that constitutes a violation or imminent threat of violation of security policies, security procedures, acceptable use policies or applicable data protection law. 

A Security Incident can involve:

  1. Attempts to gain unauthorised access to the OpenSAFELY Service and/or to data;
  2. The unauthorised use of OpenSAFELY for the processing or storing of data;
  3. Changes to a systems firmware, software or hardware without the system owner’s consent; or
  4. Malicious disruption and / or denial of service. 

3.1.2 A Personal Data Breach is a breach of security or policies leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, Personal Data. This includes breaches that are the result of both accidental and deliberate causes. It also means that a breach is more than just about losing Personal Data. 

3.1.3 An Incident can be both a Security Incident and a Personal Data Breach. Not all Personal Data Breaches are Security Incidents and not all Security Incidents are Personal Data Breaches. For example, the disclosure of a password is a Security Incident but may not have yet led to a Personal Data Breach through unauthorised access. 

3.1.4 Examples of Incidents include:

  • The alteration of data without permission.
  • Access to the OpenSAFELY Service or data by an unauthorised third party, e.g. a cyber attack by a third party which attempts to collect, disrupt, deny, degrade, or destroy the OpenSAFELY Service and / data accessible via the Service
  • The unauthorised access and / or unauthorised use of the OpenSAFELY Service or data by a member of Staff, e.g. accessing a patient’s Personal Data for personal use
  • The deliberate theft of Personal Data
  • The disclosure of data, which has not been output checked, to an unauthorised recipient, e.g. sharing non-output checked data with another individual or organisation or placing it into the public domain
  • Making the unique VPN access available to another individual e.g. by screen-sharing or taking pictures of results.
  • Accidental deletion of data
  • Introducing data into the OpenSAFELY Service without the explicit written permission of NHS England

3.2 Potential consequences of an Incident

An Incident can potentially have a range of significant adverse effects on our individuals which can result in physical, material or non-material damage.  It can include a loss of control over their Personal Data, can impact their rights, nation, identity theft or fraud, financial loss, unauthorised reversal of pseudonymisation, damage to reputation, and loss of confidentiality of Personal Data protected by professional secrecy. It can also include any other significant economic or social disadvantage to those individuals.

3.2.1 Under the UK GDPR, a data controller must report a Personal Data Breach to the Information Commissioner’s Office (ICO) within 72 hours of becoming aware of the Breach where there is a likely risk to the rights and freedoms of individuals (who could be patients, NHS staff or other individuals). The ICO is the UK’s data protection regulator.   

If the data controller fails to notify the ICO within the required time limit, the ICO may take regulatory action against them which risks significantly damaging the data controller [NHS England], data processor [University of Oxford] and the OpenSAFELY service’s reputation and public trust.   

Under the UK GDPR Article 33(2), the data processor [University of Oxford] must notify the data controller [NHS England] without undue delay (as soon as the data processor becomes aware).

3.3 Taking personal responsibility when identifying an Incident and the role of the OpenSAFELY Incident Team

When an incident is discovered or suspected to have occurred, the individual who identified it must report it immediately via incidents@opensafely.org stating their concerns. This email address provides a single reporting route for all OpenSAFELY Users, from any organisation, including NHS, to report an Incident or suspected Incident. The email inbox is monitored regularly during office hours by staff suited to the task of Incident management. The individual should make their line manager aware of the incident.

In addition to reporting the Incident via incidents@opensafely.org, the individual must take all reasonable steps within their control to contain and recover from the Incident and state the actions taken and any known outcomes to incidents@opensafely.org. All OpenSAFELY project-related processing by the individual and their project team must cease until the individual is notified by the OpenSAFELY Incident Team, via the above email address, that they are permitted to resume their project work within OpenSAFELY. In the first instance, this may assist in reducing the risk arising from the Incident.

The individual must promptly comply with any instructions, including answering questions, provided to them by the OpenSAFELY Incident Team in order to assist with containing the Incident and mitigating any resulting risks. For the purpose of this Policy, the ‘OpenSAFELY Incident Team’ refers to members of staff who oversee the management of any Incident within the OpenSAFELY Service.

3.3.1 Where an Incident is discovered outside of normal office hours, the requirements set out in section 3.4 must still be followed (as is reasonably possible).

3.3.2 To reduce the likelihood of further risk, the Incident must not be discussed with any persons other than members of the OpenSAFELY Incident Team who are managing the Incident.

3.3.3 The OpenSAFELY Incident Team will coordinate the onward sharing of the Incident to the data controller, NHS England, and PHC, via the agreed routes. 

3.4 The role of NHS England (the OpenSAFELY Service Data Controller)

NHS England may require further details of the incident in order to:

  • Determine whether an Incident has occurred
  • Evaluate the potential risk to individuals as a result of the Incident. NHS England provides a risk matrix to assist with a risk assessment. See Figure 2 in this link.
  • Advise on steps required to mitigate the risks to individuals, to the data controller and the OpenSAFELY Service.

3.4.1 The OpenSAFELY Incident Team will endeavour to assist the data controller in bringing the Incident to a timely and appropriate conclusion and will liaise with the data controller as required. The individual will be informed by the OpenSAFELY Incident Team when the Incident has been closed.

3.5 Notifying others of an Incident

The NHS England Data Protection Officer (DPO) is responsible for assessing the risk arising from an Incident and for determining whether notification to the ICO and/or affected individuals is required. Where an Incident is likely to result in a risk to an individual’s rights and freedoms, the NHS England DPO will notify the ICO within 72 hours of becoming aware of the Incident. Any communication with affected individuals will be coordinated by the NHS England Incident Management Team following the advice of the NHS England DPO.

3.6 Following the Incident

Following the initial response to an Incident, the NHS England DPO will advise the OpenSAFELY Incident Team of any further actions and recommendations that will work towards future Incident prevention, including a review of procedures, an addition to current procedures or some specialist training.