Contents
1 Introduction
Rotherham, Doncaster and South Humber NHS Foundation Trust (hereafter referred to as the trust) is committed to a programme of effective risk and incident management. The trust has a responsibility to ensure data breaches and or information governance incidents are reported and managed efficiently and effectively.
The general data protection regulation (GDPR) requires that where personal data breaches affect the ‘rights and freedoms of an individual,’ article 33 (of GDPR) imposes a duty to report these types of personal data breach to NHS digital and to the Information commissioner’s office (ICO). In some cases, these will also be reported to department of health and social care (DHSC). These are reported using the incident reporting tool housed in the data security and protection toolkit (DSPT).
This procedure explains the system to be used by colleagues for the recording, reporting and reviewing data security and protection breaches or incidents. This supports the trust’s overall incident reporting process which is an integral part of personal, clinical and corporate governance.
The information contained within this procedure is taken from the “guide to the notification of data security and protection incidents” produced by NHS digital (May 2018). Further detailed information about data breach reporting can be found in this document and must be referred to when reading this procedure and grading any personal data breach or incident.
It is a contractual requirement to include statistics on personal data breaches in the annual report and the statement of internal control (SIC) presented to the board and the trust must keep a record of any personal data breaches, regardless of whether it is required to notify these to the ICO. The information governance and data protection (IG and DP) department co-ordinate and maintain data security breaches or incident reporting via the Ulysses system.
2 Purpose
This document sets out the directions across the trust for the reporting and management of data security and protection breaches or incidents.
For those colleagues covered by a letter of authority or honorary contract or work experience the organisation’s policies are also applicable whilst undertaking duties for or on behalf of the trust.
Further, this procedure applies to all third parties and others authorised to undertake work or process data on behalf of the trust.
3 Scope
This document applies to and is relevant across all services, departments, or care groups.
4 Responsibilities, accountabilities and duties
4.1 Chief executive
Has ultimate responsibility for the implementation of the provisions of this policy and procedure. As the ‘accountable officer’ they are responsible for the management of the organisation and for ensuring that the appropriate mechanisms are in place to support incident reporting for data security and protection incidents.
4.2 Data protection officer (DPO)
The DPO’s role is to inform and advise the trust and its colleagues about their obligations to comply with the GDPR and other current data protection laws. They are required to monitor compliance with the GDPR and current data protection laws, including managing internal data protection activities, advise on data protection impact assessments; train colleagues and conduct internal audits. In addition they are required to be the first point of contact for supervisory authorities and for individuals whose data is processed (employees, customers etc.).
For the purposes of incident reporting the DPO will provide advice and guidance around the grading and categorisation of any data security and protection incident, and in the event of a reportable incident to the ICO, will be the point of contact.
4.3 Caldicott guardian (CG)
To review and provide feedback regarding an incident where this relates to patient data. This may involve decision making about informing patients regarding an incident or not if this would deem to cause them harm or distress
4.4 Senior information risk officer (SIRO)
To review data security and protection incidents and report issues to the finance, performance and informatics committee and senior management team and ensure that any external reporting of the incident if required is undertaken information governance and data protection department has responsibility to:
- to co-ordinate and investigate reported data and security protection incidents, maintain the trust Incident or data and security breaches via Ulysses, make recommendations and act on lessons learned
- to liaise with the trust IG lead, trust SIRO, information security officer as appropriate pertaining to data security incidents
- to escalate incidents to the trust IG lead in order to inform the SIRO, DPO, Caldicott guardian as appropriate
- to grade the incident and report it where necessary on the data and security breaches reporting toolkit incident reporting tool and local Ulysses system
4.5 Information security officer (ISO)
- To work information governance to investigate the incidents where IT and IT security input is required, make recommendations and act on lessons learned.
- To liaise with the IG and DP department as appropriate especially regarding reporting.
- To inform the senior information risk owner, DPO, Caldicott guardian as appropriate.
4.6 Line managers
Line managers are responsible for ensuring that all colleagues, particularly new staff, temporary staff, contractors and volunteers, know what is expected of them with respect to reporting data security and protection breaches or incidents.
4.7 Trust employees
Colleagues and members are responsible for maintaining the confidentiality of all personal and corporate information gained during their employment term of office with the trust and this extends after they have left the trust.
5 Procedure or implementation
All data security breaches or incidents must be reported to the trust IG Lead or DPO or IG and DP department via the IR1 reporting procedures as soon as the incident is know, following the trust’s incident reporting processes (detailed below). Colleagues should not delay the reporting of any incident even if unsure whether it may not be a breach or incident. The IG and DP department will assess the incident using the NHS digital’s guidance to grade it accordingly.
The trust will continue to utilise its own internal incident reporting procedure for the management of incidents. All incidents must be reported initially via the IR1 reporting procedure on the Ulysses system.
The immediate response to an incident and the escalation process for investigation or external reporting will vary according to the severity level of the incident.
Where incidents are identified as a data security or IG incident the IG and DP department will liaise with the DPO.
The IG and DP department will assess and grade using the breach assessment guide (appendix B).
5.1 Incident grading
Incidents are graded according to the significance of the breach on a scale of 1 to 5 (1 being the lowest and 5 being the highest) and the likelihood of those serious consequences occurring on a scale of 1 to 5 (1 being the lowest and 5 being the highest). Please note incident or breaches are graded according to the impact on the individuals it concerns and not the organisation.
Article 34 requires the trust to notify the relevant authority when an incident constitutes a high risk to the rights and freedoms of an individual. This is classified when a breach has the potential to cause one or more of the following:
- loss of control of personal data
- limitation of rights
- discrimination
- identity theft
- fraud
- financial loss
- unauthorised reversal of pseudonymisation
- damage to reputation
- loss of confidentiality of personal data protected by professional secrecy
- other significant economic or social disadvantage to individuals
The tables in appendix A set out how to grade the severity of a personal data breach or incident to see if it is high risk and be significant enough to be reported to the ICO. The breach assessment grid in appendix B ascertains when an incident is notifiable and to whom.
When incidents are notifiable, this is carried out using the NHS digital incident reporting tool housed in the data security and protection toolkit (DSPT) (opens in new window).
5.1.1 Vulnerable groups
Where a data security breach relates to a vulnerable group in society, a minimum risk assessment score of 2 for likelihood and significance is stated unless the incident has been contained.
5.1.2 Timescale for reporting
Article 33 of GDPR requires reporting of a breach within 72 hours. This is from when the trust becomes aware of the breach and may not be necessarily when it occurred. However, it is important that all colleagues report any IG incidents or breaches as soon as possible. Failure to notify promptly may result in action taken by the ICO by breaching article 33.
It is mandatory for all colleagues to report ‘near misses’ as well as actual incidents, so that we can take the opportunity to identify and disseminate any ‘lessons learned’.
5.1.3 Informing the public
Article 34 requires that the public are notified if a data security breach results in a high risk to the rights and freedoms of individuals. In summary, this notification must include a description of the breach, name and contact details of the DPO or equivalent, a description of the likely consequences of the breach and a description of the measures taken or to be taken to address and mitigate the breach and its possible adverse effects.
If the trust does not decide to notify individuals it must have a justified reason to demonstrate that the breach is unlikely to result in a risk to the rights and freedoms of individuals it concerns.
5.1.4 Containment actions which affect notification status
There may be circumstances where the trust is aware of a breach but there are containment actions that remove the need for notification to the ICO but will still be recorded locally. For example, notification may not be necessary when:
- encryption is used to protect personal data
- where personal data is recovered from a trusted partner organisation. A trusted partner is classified when the controller (RDaSH) may have a level of assurance with the recipient so that it can reasonably expect that party not to read or access the data sent in error and to comply with instructions to return it. Even if the data has been accessed, the trust could still possibly trust the recipient not to take any further action and return and co-operate with the trust’s instructions
- where the trust can null the effect of any personal data breach
5.1.5 Data security breach or incident reporting
A flowchart that sets out the overall process for reporting, managing and investigating data security and protection incidents or personal data breaches for the trust can be provided on request.
5.2 Reporting in the annual governance statement or statement of internal control
Reportable incidents that affect the rights and freedoms of an individual need to be detailed in the annual report or governance statement or statement of internal control as outlined in table 1 below.
Table 1, summary of data security and projection Incidents reported to the ICO and or department of health and social care (DHSC)
Date of incident (month), nature of incident, number affected, how patients were informed, Lessons learned.
5.3 Reporting by NHS digital
Data breaches reported via the DSPT incident reporting tool will be forwarded to the appropriate organisation indicated in the guidance such as the department of health and social care (DHSC), NHS England and the ICO. Additionally, these organisations may have obligations to work with other agencies, such as the national cyber security centre, for example, and any incident information may be shared onward. For this reason, it is prohibited to include individual information that could identify any person affected by a breach. All incidents will
be shared on a quarterly basis in aggregate form for incident monitoring and trend analysis.
5.4 STEIS reporting
If a data breach has been reported via the DSPT incident reporting tool it must also be reported via the strategic executive information system (STEIS) (NHS England, serious incident framework, supporting learning to prevent recurrence). The form at appendix E is to be completed by the person who reported the incident and forwarded to the serious incident officer within 72 hours of the incident taking place.
5.5 Reporting to the trust’s finance, performance and informatics committee
Data security breaches or incidents are reported routinely at the trust’s information governance group (via the IG compliance report) who report via the trust’s health informatics group to the finance, performance and informatics committee. Lessons learned are discussed and actioned when necessary to assist mitigation of future similar incidents.
5.6 Closure and lessons learned
It is essential that action is taken to help to minimise the risk of data breaches or IG incidents re-occurring in the future. Therefore, all data breaches or IG incidents that are reported will be logged and any associated lessons learned will be fed back to colleagues. This may be communicated via email, briefings, or team meetings.
Colleagues involved with a data breach or IG incident should consider with their line manager if additional training and support is needed. The investigation team and or IG and DP department will determine this. Line managers should contact the IG and DP department for further assistance.
6 Training implications
Line managers are responsible for ensuring that all colleagues, particularly new, temporary, contractors and volunteers, know what is expected of them with respect to confidentiality and protecting information. They are also responsible for monitoring compliance with this guideline, for example, undertake ad hoc audits to check for inappropriate disclosures, records left out, abuse of passwords etc
Colleagues are responsible for maintaining the confidentiality of all personal and corporate information gained during their employment with the trust and this extends after they have left the employ of the trust.
Individual colleagues are personally responsible for any decision to pass on information that they may make.
All colleagues are responsible for adhering to the Caldicott principles, the Data Protection Act 2018, General Data Protection Regulation, the Confidentiality Code of Conduct, the National Data Guardian Security Standards and the common law duty of confidentiality.
All colleagues are mandated to undertake data security and information governance training on an annual basis. This training should be provided within the first year of employment and then updated annually.
As a trust policy, all colleagues need to be aware of the key points that the policy covers. Colleagues can be made aware through a variety of means such as:
- all user emails for urgent messages
- continuous professional development sessions
- daily email (sent Monday to Friday)
- one to one meetings and supervision
- posters
- practice development days
- group supervision
- intranet
- local Induction
- special meetings
- team meetings
7 Monitoring arrangements
This procedure will be reviewed every two years, and in accordance with the following on an as and when required basis:
- legislative changes
- good practice guidance
- case law
- significant incidents reported
- new vulnerabilities
- changes to organisational infrastructure
7.1 IG breaches and cyber incidents are reported monthly
- How: IG compliance report
- Who by: IG lead
- Reported to: SIRO, IG lead, Caldicott guardian, board via the IG group, or FPIC
- Frequency: Monthly
7.2 Reportable breaches and incidents
- How: Exception report
- Who by: DPO
- Reported to: SIRO, IG lead, Caldicott guardian, board via the IG group, or FPIC
- Frequency: As required
8 Equality impact assessment screening
To access the equality impact assessment for this policy, please see the overarching equality impact assessment.
8.1 Privacy, dignity and respect
The NHS Constitution states that all patients should feel that their privacy and dignity are respected while they are in hospital. High Quality Care for All (2008), Lord Darzi’s review of the NHS, identifies the need to organise care around the individual, ‘not just clinically but in terms of dignity and respect’.
As a consequence the trust is required to articulate its intent to deliver care with privacy and dignity that treats all service users with respect. Therefore, all procedural documents will be considered, if relevant, to reflect the requirement to treat everyone with privacy, dignity and respect, (when appropriate this should also include how same sex accommodation is provided).
8.1.1 How will this be met
No issues have been identified in relation to this policy.
8.2 Mental Capacity Act 2005
Central to any aspect of care delivered to adults and young people aged 16 years or over will be the consideration of the individuals capacity to participate in the decision making process. Consequently, no intervention should be carried out without either the individual’s informed consent, or the powers included in a legal framework, or by order of the court.
Therefore, the trust is required to make sure that all colleagues working with individuals who use our service are familiar with the provisions within the Mental Capacity Act (2005). For this reason all procedural documents will be considered, if relevant to reflect the provisions of the Mental Capacity Act (2005) to ensure that the rights of individual are protected and they are supported to make their own decisions where possible and that any decisions made on their behalf when they lack capacity are made in their best interests and least restrictive of their rights and freedoms.
8.2.1 How will this be met
No issues have been identified in relation to this policy
9 Links to any associated documents
A set of procedural document manuals will be available via the trust’s website.
Staff will be made aware of procedural document updates as they occur via team briefs, team meetings and notification via the trust staff Intranet.
A number of other policies are related to this policy and all employees should be aware of the full range below:
- information governance policy and management framework (includes data protection policy content)
- information technology (IT) security policy
- records management policy
- confidentiality audit procedure
- counter fraud, bribery and corruption policy
10 References
- Guide to the Notification of Data Security and Protection Incidents, Reporting incidents post the adoption of GDPR 25 May 2018 and NIS Directive 10 May 2018 to September 2018.
11 Appendices
11.1 Appendix A Definition or explanation of terms used
11.1.1 Personal data breach
As per article 4(12) of the GDPR, a “personal data breach” means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed.
The traditional view that a personal data breach is only reportable when data falls into the wrong hands is now replaced by a concept of a ‘risk to the rights and freedoms of individuals’ under article 33 of GDPR. These types of breaches are graded as per the guidance from NHS Digital using a risk scoring 5 by 5 matrix and maybe notifiable to the information commissioners office (ICO) if they attain a grade as described in the guidance.
11.1.2 Personal data
This is data defined as any information relating to an identified or identifiable living individual.’ An “identifiable living individual” means a living individual who can be identified, directly or indirectly, by reference to either:
- an identifier such as a name, an identification number, location data or an online identifier
- one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of the individual.
All paper records that relate to a living individual and any aspect of digital processing such as IP address and cookies are deemed personal data. GDPR also introduces geographical data and biometric data to be classified as personal data.
11.1.3 Special categories of personal data
Under GDPR, these are:
- racial or ethnic origin
- political opinions
- religious or philosophical beliefs
- trade union membership
- the processing of genetic data
- biometric data for uniquely identifying a natural person
- data concerning health
- data concerning a natural person’s sex life or sexual orientation
For data security breach reporting purposes, special categories of data also include:
- vulnerable children
- vulnerable adults
- criminal convictions/prisoner information
- special characteristics listed in the Equality Act 2010 where not explicitly listed in this guidance and it could potentially cause discrimination against such a group or individual
- communicable diseases as defined by public health legislation
- sexual health
- mental health
11.1.4 Breach types
The article 29 working party, an advisory body made up of a representative from the data protection authority of each EU member state, the European Data Protection Supervisor and the European Commission now known as the European Data Protection Board (EDPB) under the EU General Data Protection Regulation (GDPR) from 25th May 2018 categorised data security breaches into 3 categories which were associated with confidentiality, integrity and / or availability.
A definition of each category of breach is detailed below:
- confidentiality breach, unauthorised or accidental disclosure of, or access to personal data
- availability breach, unauthorised or accidental loss of access to, destruction of personal data
- integrity breach, unauthorised or accidental alteration of personal data
Table 1 below states the ICO categorisation of data breaches in conjunction with the type of breach category as identified by the article 29 working party.
| ICO categorisation | Type of breach (article 29 working party) |
|---|---|
| Data sent by email to incorrect recipient | Confidentiality |
| Cyber security misconfiguration (for example, inadvertent publishing of data on website; default passwords) | Confidentiality |
| Cyber incident (phishing) | Confidentiality |
| Insecure webpage (including hacking) | Confidentiality |
| Loss or theft of paperwork | Availability |
| Loss or theft of unencrypted device | Availability |
| Loss or theft of only copy of encrypted data | Availability |
| Data left in insecure location | Availability |
| Cyber incident (other, DDOS etc.) | Availability |
| Cyber incident (exfiltration) | Availability |
| Cryptographic flaws (for example, failure to use HTTPS; weak encryption) | Availability |
| Insecure disposal of paperwork | Availability |
| Insecure disposal of hardware | Availability |
| Other principle 7 failure | Integrity |
| Cyber incident, unknown | Integrity |
11.2 Appendix B Guide to notification of data security and protection incidents
| Number | Effect | Description |
|---|---|---|
| 1 | Not occurred | There is absolute certainty that there can be no adverse effect. This may involve a reputable audit trail or forensic evidence |
| 2 | Not likely or any incident involving vulnerable groups even if no adverse effect occurred | In cases where there is no evidence that can prove that no adverse effect has occurred this must be selected. |
| 3 | Likely | It is likely that there will be an occurrence of an adverse effect arising from the breach. |
| 4 | Highly likely | There is almost certainty that at some point in the future an adverse effect will happen. |
| 5 | Occurred | There is a reported occurrence of an adverse effect arising from the breach. |
If the likelihood that an adverse effect has occurred is low and the incident is not reportable to the ICO, no further details will be required.
| Number | Effect | Description |
|---|---|---|
| 1 | No adverse effect | There is absolute certainty that no adverse effect can arise from the breach |
| 2 | Potentially some minor adverse effect or any incident involving vulnerable groups even if no adverse effect occurred | A minor adverse effect must be selected where there is no absolute certainty. A minor adverse effect may be the cancellation of a procedure but does not involve any additional suffering. It may also include possible inconvenience to those who need the data to do their job |
| 3 | Potentially some adverse effect | An adverse effect may be release of confidential information into the public domain leading to embarrassment or it prevents someone from doing their job such as a cancelled procedure that has the potential of prolonging suffering but does not lead to a decline in health |
| 4 | Potentially pain and suffering or financial loss | There has been reported suffering and decline in health arising from the breach or there has been some financial detriment occurred. Loss of bank details leading to loss of funds. There is a loss of employment |
| 5 | Death or catastrophic event | A person dies or suffers a catastrophic occurrence |
Both the adverse effect and likelihood values form part of the breach assessment grid.
11.3 Appendix C Breach assessment grid
This operates on a 5 by 5 basis with anything other than “grey breaches” being reportable or notifiable to the ICO or DHSC via the DSPT incident reporting tool.
Incidents where the grading results are in the red are advised to be notified within 24 hours.
5 by 5 grid, with impact value on the y-axis and likelihood harm has occurred on the x-axis. Detailed in appendix B.
No impact scores cross section as follow:
- likelihood harm has occurred, not occurred, 1, no impact has occurred
- likelihood harm has occurred, not likely, 2, no impact has occurred
- likelihood harm has occurred, likely, 3, no impact has occurred
- likelihood harm has occurred, highly likely, 4, no impact has occurred
- likelihood harm has occurred, occurred, 5, no impact has occurred
Minor scores cross section as follow:
- likelihood harm has occurred, not occurred, 2, no impact has occurred
- likelihood harm has occurred, not likely, 4, an impact is unlikely
- likelihood harm has occurred, likely, 6, reportable to the ICO
- likelihood harm has occurred, highly likely, 8, reportable to the ICO
- likelihood harm has occurred, occurred, 10, reportable to the ICO
Adverse scores cross section as follow:
- likelihood harm has occurred, not occurred, 3, no impact has occurred
- likelihood harm has occurred, not likely, 6, an impact is unlikely
- likelihood harm has occurred, likely, 9, reportable to the ICO
- likelihood harm has occurred, highly likely, 12, reportable to the ICO
- likelihood harm has occurred, occurred, 15, reportable to the ICO
Serious scores cross section as follow:
- likelihood harm has occurred, not occurred, 4, no impact has occurred
- likelihood harm has occurred, not likely, 8, an impact is unlikely
- likelihood harm has occurred, likely, 12, reportable to the ICO DHSC notified
- likelihood harm has occurred, highly likely, 16, reportable to the ICO DHSC notified
- likelihood harm has occurred, occurred, 20, reportable to the ICO DHSC notified
Catastrophic scores cross section as follow:
- likelihood harm has occurred, not occurred, 5, no impact has occurred
- likelihood harm has occurred, not likely, 10, an impact is unlikely
- likelihood harm has occurred, likely, 15, reportable to the ICO DHSC notified
- likelihood harm has occurred, highly likely, 20, reportable to the ICO DHSC notified
- likelihood harm has occurred, occurred, 25, reportable to the ICO DHSC notified
11.4 Appendix D Key contacts
11.4.1 Information Governance and Data Protection team
Caldicott Guardian, Graeme Tosh:
- Email: graeme.tosh@nhs.net
Senior Information Risk Owner (SIRO), Richard Banks
- Email: richard.banks4@nhs.net
Head of IG, Caroline J. Britten:
- Email: carolinebritten@nhs.net
Data Protection Officer, Caroline J. Britten:
- Email: rdash.dpo@nhs.net
Document control
- Version: 3.1.
- Unique reference number: 519.
- Date approved: 15 January 2024.
- Approved by: Corporate policy approval group.
- Name of originator or author: Head of IG or DPO.
- Name of responsible individual: Director of health informatics.
- Date issued: 16 January 2024.
- Review date: 31 January 2026.
- Target audience: All colleagues.
Page last reviewed: April 30, 2024
Next review due: April 30, 2025