Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »

1. Introduction

The implementation of the General Data Protection Regulation (GDPR) and the UK Data Protection Act 2018 requires organisations to report certain types of incidents to NHS Digital, the Department of Health and Social Care (DHSC) and the Information Commissioners’ Office (ICO) (the supervisory authority).

It is a legal obligation to notify the ICO of personal data breaches of the legislation within 72 hours where there is a ‘high risk to the rights and freedoms of individuals’.  The legislation also makes it a legal obligation to communicate the breach to those individuals affected without undue delay when it is likely to result in a high risk to individuals rights.

Occasionally things will go wrong, this document covers the process for the reporting and investigation of non clinical incidents together with the process for analysis and improvement.  We aim to establish the causes of incidents, make sure lessons are learnt, enable appropriate actions are taken and suitable improvements are made to minimise any further recurrence.

If you have an incident to report please contact our Information Governance (IG) Manager contact us.

2. What is an Incident

An incident is defined as any event or circumstance which could have resulted or did result in unnecessary damage, loss or harm to Customers, Patients, Carers, Staff, PKB Business.

Incidents may be caused by:

  • Human error.

  • Systems failure.

  • A cyber attack.

All incidents are reported to the IG Manager who will assess the risk, severity, scale and sensitivity of the incident based on all information known at the time. The IG Manager  will refer to the NHS Digital Guide to the Notification of Data Security and Protection Incidents in this assessment. The most recent version of this document can be found here https://www.dsptoolkit.nhs.uk/Help/29

Incidents include Personal Data breaches of the GDPR reported to the Information Commissioner, the Security of Network Information Systems incidents reported to the Department of Health, Social Care and Cyber Security incidents reported to NHS Digital and High Severity Service incidents relating to Online and Video Consultation Software reported to the NHS Digital Service Bridge. Organisations must maintain a local file or use an incident management system to fully record the particulars of any investigation and remedial action. Notifications should include as much detail as is available to allow a full assessment by the ICO and other regulatory organisations. 

The IG Manager, together with the appropriate internal and/or external team(s) will coordinate the investigation, response and management of the incident and document and apply remediation recommendations that may be necessary for the incident. The outcome of this assessment will govern the level to which a response is initiated together with the notification workflow adopted and the time scale of the response.

3. Guide to the Notification of Data Security and Protection Incidents

To determine the severity of any incident it must be assessed using the NHS Digital Guide to the Notification of Information Security and Protection Incidents (dated September 2018).

Following the change in data protection legislation in May 2018, Information Governance incidents are now categorised under:

  • Confidentiality Breach - unauthorised or accidental disclosure of, or access to, personal information.

  • Integrity Breach - unauthorised or accidental alteration of personal information.

  • Availability Breach - unauthorised or accidental loss of access to, or destruction of personal information.

See the below table for examples, not limited to these types of breaches:

Confidentiality 

Unauthorised or accidental disclosure of, or access to, personal information 

Data sent by email to incorrect recipient

Emails containing personal information sent to an incorrect recipient.

Not using BCC when sending email

Not using blind copy (bcc) in emails resulting in sharing of personal email address without consent.

Information sent by unsecure email

Personal or clinical information sent via unsecure email method, e.g. unencrypted.

Disclosure of access details

Sharing log-in details and passwords.

Unauthorised access or disclosure 

Disclosure of information to a third party who is not entitled to receive it.  Wilful unauthorised access to, or disclosure of personal information without consent.

Integrity

Unauthorised or accidental alteration of personal information

Accidental alteration of information

A record changed in error.

Malicious alteration of information 

To deliberately change / alter a record.

Security failure of IT systems / equipment

A cyber incident which changes the quality of information, e.g. accuracy, reliability.

Availability

Unauthorised or accidental loss of access to, or destruction of personal information 

Information uploaded or recorded to incorrect record

Leading to potential harm as information is not available in the right place at the right time.

Corruption or non-recoverable information loss

Avoidable or foreseeable corruption of information or an issue which otherwise prevents access which has quantifiable consequences for the affected individuals. e.g. 

  • Corruption of a file which renders the information inaccessible.

  • Inability to recover a file as its method or format of storage is obsolete.

  • Loss of a password, encryption key or the poor management of access controls leading to the information becoming inaccessible.

Loss or theft of device

Loss of information contained on portable devices which may include:

  • Laptops.

  • Mobile Phones.

  • USB memory sticks.

  • Servers.

  • Hard Drives.

Insecure disposal of electronic / IT equipment

The failure to dispose of hardware containing personal information using appropriate technical and organisational means, which may include:

  • Failure to securely wipe information prior to destruction.

  • Failure to securely destroy hardware to appropriate industry standards,

  • Resale of equipment containing retrievable personal information.

  • Third party contractor failure to meet requirements for the safe removal, destruction, sale, recycling of personal information.

4. Process for Reporting an Incident

4.1 Initial Reporting.

4.2 Managing the Incident.

4.3 Investigating the Incident.

4.4 Final Reporting, Lessons Learned and Incident Closure.

4.1. Initial Reporting

Suspected Incidents

We will investigate all suspected incidents with equal commitment until a clear determination is made about the incident. 

Early Notification

Where it is suspected that a reportable incident has taken place, key staff will be notified (Chief Executive, Senior Information Risk Owner, other Directors, Head of Communications etc.) as an ‘early warning’ to ensure that they are in a position to respond to enquiries from third parties and to avoid ‘surprises’.  However, the immediate response to the incident and the escalation process for reporting and investigating will vary according to the severity of the incident. Where incidents occur out of hours, we have arrangements in place to ensure on-call Directors or other nominated individuals are informed of the incident and take action to inform and involve the appropriate staff. 

Reporting Incidents and Timescales

Incidents must be graded according to the significance of the breach and the likelihood of any serious consequences occurring and the impact on the individuals whose data is involved.  Once the incident has been assessed the assessment will be reviewed by the Data Protection Officer or the Senior Information Risk Owner when determining what the significance and likelihood of a data breach will be.

Establish the Likelihood that an Adverse Effect has Occurred

No

Likelihood

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

Where the incident is assessed as (at least) likely that some harm has occurred and that the impact is (at least) minor, the incident is reportable and full details will be automatically emailed to the ICO and the NHS Digital Data Security Centre(DHSC). The DHSC will also be notified where it is (at least) likely that harm has occurred and the impact is (at least) serious. 

The severity of an incident will be determined by the impact and likelihood that harm may have or may possibly occur to individuals whose rights have been affected. If the outcome of the assessment via the NHS Digital Data Security and Protection Incident Reporting Tool will forward to the appropriate organisation as indicated in the scoring matrix.  Additionally, these organisations may have obligations to work with agencies, such as the National Cyber Security Centre. 

Grade the Potential Severity of the Adverse Effect on Individuals

No

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 the 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 / 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 / Catastrophic Event

A person dies or suffers a catastrophic occurrence.

Both the adverse effect and likelihood values form part of the breach assessment grid.

However, not all incidents will require reporting, under the following circumstances notification may not be necessary:

  • Encryption - where the personal data is protected by means of encryption.

  • ‘Trusted Partner’ - where the personal data is recovered from a trusted partner organisation.

  • Cancel the Effect of the Breach - where the Data Controller can null the effect of any personal data breach.

Breach Assessment 

Where the incident is assessed that it is (at least) likely that some harm has occurred and that the impact is (at least) minor, the incident is reportable and full details will be automatically emailed to the ICO and the NHS Digital Data Security Centre. The DHSC will also be notified where it is (at least) likely that harm has occurred and the impact is at least serious.

Severity

(Impact)

Catastrophic

5

5

10

15

20

DHSC & ICO (24 hours)

25

Serious

4

4

8

12

16

20

Adverse

3

3

6

9

12

ICO

15

Minor

2

2

4

6

8

10

No Adverse Effect

1

1

2

3

4

5

1

2

3

4

5

Not Occurred

Not Likely

Likely

Highly Likely

Occurred

Likelihood that individuals rights have been affected (harm)

This operates on a 5 x 5 basis with anything other than “grey breaches” being reportable. Incidents where the grading results are in the red are advised to notify within 24 hours.

4.2. Managing the Incident

The incident will be managed as follows:

  • Identify who is responsible for managing the incident and coordinating separate but related incidents.

  • Identify who is responsible for the investigation and performance management.

  • Identify expected outcomes.

  • Identify stakeholders.

  • Develop and implement an appropriate communications plan.

  • Preserve evidence.

  • Ensure all data provided as required to fully investigate an incident is held securely and only be accessible, where there is a need, to those involved in the investigation.

  • Investigate the incident (see below).

  • Institute formal documentation – this must incorporate version control and configuration management.

  • Maintain an audit trail of events and evidence supporting decisions taken during the incident.

  • Where appropriate the Information Commissioner, NHS Digital, and other regulators will be informed, via the Data Security and Protection Incident Tool.

  • Escalate as appropriate (Customers, Host organisations, dependent business partners or Commissioners).

  • Informing data subjects (e.g. patients, service users, and staff). Consideration should always be given to informing data subjects when personal data about them has been lost or inappropriately placed in the public domain. Where there is any risk of identity theft it is strongly recommended that this is done.

  • Identify and manage consequent risks of the incident (these may be IG-related or involve risks to patient safety, continuity of treatment etc.).

  • Commence recovery actions, where possible.

  • Invoke disciplinary procedures as appropriate and document the reasons where it is decided not to take action where such action may be viewed as relevant by external parties.

  • Institute appropriate counter-measures to prevent recurrence.

  • Identify risks and issues that, whilst not ‘in scope’ of the incident, are appropriate for separate follow-up and action.

  • Update the Data Security and Protection Incident Tool.

4.3. Investigating the Incident

The incident will be investigated as follows, with consideration given to national guidance / requirements that forensic preservation of related evidence is expected:

  • Appoint an investigating officer.

  • Engage appropriate specialist help (IG, IT, Security,).

  • Where across organisational boundaries coordinate investigations (and incident management).

  • Ensure accurate and factual evidence and interview notes are preserved, including where any staff are suspended.

  • Document investigation and findings as per the Reporting Schema described below.

  • Ensure that content is reviewed with sources for accuracy.

  • Identify improvements and lessons learnt.

  • Update the Data Security and Protection Incident Tool with accurate, factual and non personal information including the following as required by the ‘NHS Digital Guide to the Notification of Data Security and Protection Incidents’ (dated September 2018).

Reporting Schema for Data Breaches from May 2018 (new legislation introduced)

ID

Information Requested

1

Organisation Name

2

Organisation Code

3

Name of Person Submitting the Incident

4

Email Address of the Person Submitting the Incident

5

Sector

6

What has happened?

7

How did you find out?

8

Was the Incident caused by a problem with a network or an information system?

9

What is the Local Incident ID?

10

When did the Incident start?

11

Is the Incident still on-going?

12

Have Data Subject or Users been informed?

13

Is it likely that Citizens outside of England will be Affected?

14

Have you Notified any other (overseas) Authorities about this Incident?

15

Have you Informed the Police?

16

Have you Informed any other Regulatory Bodies about this Incident?

17

Has there been any Media coverage (that you are aware of) of the Incident?

18

What other actions have been taken or are planned?

19

How many Citizens are Affected?

20

Who is Affected?

21

What is the Likelihood that People’s rights have been affected?

22

What is the Severity of the Adverse Effect?

23

Has there been any potential Clinical Harm as a result of the Incident?

24

Has the Incident disrupted the delivery of Healthcare Services?

25

Which of these Services are operated by your Organisation?

4.4. Final Reporting, Lessons Learned and Closure of the incident

Incidents will be regularly reviewed by our IG Manager and updated during the course of the investigation. When the local investigation is complete and actions taken then the incident will be closed.

  • Set target timescale for completing investigation and finalising reports.

  • Produce draft final report.

  • Draft final report reviewed by appropriate persons or appraisal group.

  • Sign-off of report, change from ‘draft’ to ‘final’.

  • Send to the relevant persons and/or committee.

  • Create actions taken and improvement plan for lessons learnt and identify who is responsible for implementing and disseminating lessons learnt.

  • Close incident, only when all aspects, including any disciplinary action taken against staff, are settled.

  • Update the record on the Data Security and Protection Incident Tool - the incident record cannot be closed until all the data fields are populated including ‘Actions taken’ and ‘Lessons Learned’.

Further information will become available as the investigation takes place and the NHS Digital Data Security and Protection Incident Reporting Tool record will be regularly updated as appropriate by the IG Manager.  Any significant updates regarding the breach type, severity details and media awareness will trigger a notification from the system to other agencies, such as the National Cyber Security Centre, and any incident may be shared with other relevant National regulatory bodies as deemed necessary, such as the Information Commissioners’ Office. 

5. Publishing Reportable Incidents in our Annual Report or Statement of Internal Control 

Incidents reportable to the Information Commissioners’ Office and/or the Department of Health and Social Care should be included in our Annual Report in the below format:

Summary of Data Security and Protection Incidents reported to the ICO and/or DHSC 

Month of 

Incident

Nature of Incident 

Numbers 

Affected

Number of  Patients Informed

Lessons Learned

Statement of Internal Control (SIC) Guidance

The Statement of Internal Control should explicitly include in the description of the risk and control framework, how risks to information are being managed and controlled and will be reflected in our Annual Report. 

6. Examples of Notification (ref: NHS Digital Guide to the Notification of Data Security and Protection Incidents - September 2018)

Q. A loss of one patient’s scanned case notes which is likely to lead to problems in treating that patient.

A. Yes as it has caused harm to that individual from a problem in treatment that has arisen from the unavailability of the case notes.

Q. A cyber incident similar to the WannaCry incident of 2017, where there is a determination no data has been lost but encrypted and it affects clinical services.

A. Yes as it affects availability and has an ICO effect on individuals which is likely to result in a risk to individuals from cancelled appointments and operations which may prolong the pain and suffering of the patient. 

Q. 10 DNA profiles (biometric data) with names sent to the wrong email address.

A. Yes as it may cause harm to the individual unless it is a trusted source or encrypted. The biometric data is a special category of data under GDPR and the combination of a name makes it personal data.

Q. A log of IP addresses and user-names who have accessed a patient portal accidentally backed up to a cloud provider in Canada.

A. No. As the user name could be identifiable and IP addresses are classified as personal data it is a personal data breach. It may score as a non ICO notifiable personal data breach as there is a low risk to the rights and freedoms of individuals.

Q. A medical record of a safeguarded child in a mental health unit are sent to the wrong department of the same hospital trust. No serious adverse effect to the rights and freedoms of the child are reported and at no time has the medical record been unaccounted for or any non ‘trusted’ person had the opportunity to access the record.

A. No. Although there has been an error and the medical records have not been sent to the correct department this does not need reporting because the department is considered ‘trusted’. If the records were sent to another organisation that does not meet the definition of ‘trusted’ it would be notifiable. An investigation must still be performed, and measures introduced to prevent a further breach.

Q. A set of case notes found in a bin outside a supermarket.

A. Yes a data breach is still a breach irrespective of media. It is not restricted to digital information and continues to include paper-based records.

Q. A single ward handover sheet is found in the hospital car park identifying patients and conditions. It is found by a staff member and is classed as ‘trusted’ and the breach has been contained.

A. Yes as there is a potential breach of patient confidentiality that may have occurred during the time it has been left unattended it just may not be notifiable to the ICO. An organisation must investigate the breach and promote measures, so the breach does not occur again such as training for the team that has been responsible for the breach.

Q. A pathology system has gone down and test results are not available leading to a potential of cancelled operations. No reported harm has occurred yet.

A. Yes the significance of a loss of test results may cause harm to an individual through a cancelled operation. Even if none are reported the NIS threshold means that the pathology system is a key system for the NHS and is reportable. The notification tool will ask additional questions to determine that the pathology system is a critical system for NIS purposes.

  • No labels

0 Comments

You are not logged in. Any changes you make will be marked as anonymous. You may want to Log In if you already have an account.