FOI REQUEST NUMBER 144 2016 - Norfolk and …nsft.nhs.uk/About-us/Documents/144.pdf · FOI REQUEST...

Compliance Team – Health Records Kestrel House

Hellesdon Hospital Drayton High Road

Norwich Norfolk

NR6 5BE

Tel: 01603 421687 Fax: 01603 421411

FOI REQUEST NUMBER 144 2016

Request:

1a. Approximately how many members of staff do you have? 1b. Approximately how many contractors have routine access to your information? (see www.suresite.net/foi.php for clarification of contractors if needed) 2a. Do you have an information security incident/event reporting policy/guidance/management document(s) that includes categorisation/classification of such incidents? 2b. Can you provide me with the information or document(s) referred to in 2a? (This can be an email attachment of the document(s), a link to the document(s) on your publicly facing web site or a 'cut and paste' of the relevant section of these document(s)) 3a. Do you know how many data protection incidents your organisation has had since April 2011? (Incidents reported to the Information Commissioners Office (ICO) as a Data Protection Act (DPA) breach) Answer: Yes, No, Only since (date): 3b. How many breaches occurred for each Financial Year the figures are available for? Answer FY11-12: FY12-13: FY13-14: FY14-15: 4a. Do you know how many other information security incidents your organisation has had since April 2011? (A breach resulting in the loss of organisational information other than an incident reported to the ICO, eg compromise of sensitive contracts or encryption by malware. ) Answer: Yes, No, Only since (date): 4b. How many incidents occurred for each Financial Year the figures are available for? Answer FY11-12: FY12-13: FY13-14: FY14-15: 5a. Do you know how many information security events/anomaly your organisation has had since April 2011? (Events where information loss did not occur but resources were assigned to investigate or recover, eg nuisance malware or locating misfiled documents.) Answer: Yes, No, Only since (date): 5b. How many events occurred for each Financial Year the figures are available for? Answer FY11-12: FY12-13: FY13-14: FY14-15: 6a. Do you know how many information security near misses your organisation has had since April 2011? (Problems reported to the information security teams that indicate a possible technical, administrative or procedural issue.) Answer: Yes, No, Only since (date): 6b. How many near-misses occurred for each Financial Year the figures are available for? Answer FY11-12: FY12-13: FY13-14: FY14-15:

Response:

The answers to your request are as follows:- 1a. Please see attached spreadsheet 1b. Approx. 100 (this is a best guess are it is so varied) 2a. Yes, IG9-1 Investigating and Reporting Policy 2b. Please see attached policy 3a. Yes - NSFT was formed in Jan 2012 so Financial Year data is only available since April 2012 3b. 11-12 =N/A 12-13 = 0 13-14 = 1 14-15 = 1 4a. Yes - NSFT was formed in Jan 2012 so Financial Year data is only available since April 2012 4b. NSFT would only classify the lower level incidents in one group and are reported as such. Therefore, and as suggested, Q4-6 is answered as one in Q4. 11-12 = N/A 12-13 = 6 13-14 = 12 14-15 = 30 5a. See Q4 5b. See Q4 6a. See Q4 6b. See Q4 The Trust provides a complaints procedure to deal with complaints about the Trust's handling of requests for information. If you feel you need to make a complaint, in the first instance, you should contact a Non-Executive Director via the Chair of the Trust. If you feel you have exhausted our internal complaints procedure, you also have the right and may feel you wish to write to the Information Commissioner who can be contacted on telephone number 01625 545740 or at www.ico.gov.uk.

Norfolk and Suffolk NHS Foundation Trust IG9-1 IG Investigating and Reporting Policy Version 04 Page 1 of 20

Title:

Information Governance and Cyber Incident Investigations and Reporting

Outcome Statement: The purpose of this document is to establish the parameters for investigation and reporting of Information Governance (IG) incidents

Written By:

Sahra Smith, Information Governance Officer

Reviewed By: IG Committee members

In consultation with:

IG Committee members

Approved by and Date:

IG Committee members April 2015

With Reference to:

Information Governance Toolkit Checklist Guidance for Reporting, Managing and Investigating Information Governance Serious Incidents Requiring Investigation (IG SIRI) - v7.0 February 2015 IG Incident Reporting Tool User Guide v2.0 v12 2 051114 Final

Associated Policies: C10 Confidentiality Policy Disciplinary Policy (HRP016) All ISMS and Information Governance Policies

Applicable to:

All Trust Staff and users of Trust ICT Systems

For Use by:

All Trust Staff and users of Trust ICT Systems

Reference Number:

IG9-1

Version:

04

Published Date:

April 2015

Review Date:

April 2018

Impact Assessment:

Yes

Implementation Routine distribution procedures (publication on the Trust intranet, email notification to identified senior staff for distribution throughout the team and inclusion in the weekly Trust Update e-bulletin).


Review and Amendment Log

Version Number

Reasons for Development/Review Date Description of Change(s)

01 To document the new process across NSFT.

March 2013 Revised Policy

02 Inclusion of new HSCIC/IG Toolkit guidance October 2013 Revised Policy

03 Inclusion of new HSCIC/IG Toolkit guidance November 2014 Revised Policy

04 Inclusion of new HSCIC/IG Toolkit guidance (Cyber SIRI)

April 2015 Revised Policy

Contents

1.0 Introduction 3

2.0 Purpose and Objectives 3

2.1 Definitions 3

3.0 Applicability for the Policy 3

4.0 Confidentiality 3

5.0 Information Governance Incidents 3

6.0 IG Investigations and Reporting 4

6.1 Initial Counter Compromise Actions 4

6.2 Assessing the Severity of the Incident 4

7.0 Investigation Procedure 6

8.0 IG Investigation Reports 6

8.1 Sensitivity and Distribution 6

8.2 Initial Report 6

8.3 Final Report 7

9.0 Monitoring 7

Annex A Sensitivity Factor Guide

Annex B Example; Incident Classification Scoring using the sensitivity factors

Annex C Breach type defined

Annex D Security Factor Guide for Cyber SIRIs

Annex E Example; Incident Classification Scoring of Cyber SIRIs using the sensitivity factors

Annex F Breach type defines (Cyber SIRI’s)


1.0 Introduction The British Standard of Information Security Management (ISO27000 series) states that organisations should implement policies for responding to security incidents, so that organisations can learn from these incidents and hope to reduce the impact or risk of future occurrences. This policy sits within the Information Governance and Information Security Management System (ISMS). 2.0 Purpose and Objectives The purpose of this document is to establish the parameters for investigating and reporting of Information Governance (IG) and Cyber incidents. In addition this document covers the reporting arrangements and actions need to be taken in relation to communication and follow up of when a serious incident occurs. 2.1 Definitions

Term Definition

ICT Information and Communications Technologies

IG Information Governance

SUI Serious Untoward Incident

SIRI Serious Incident Requiring Investigation

IG Cyber SIRI A Cyber-related incident is anything that could (or has) compromised information assets within Cyberspace. “Cyberspace is an interactive domain made up of digital networks that is used to store, modify and communicate information. It includes the internet, but also the other information systems that support our businesses, infrastructure and services. ” Source : UK Cyber Security Strategy, 2011

3.0 Applicability for the Policy This policy applies to all members of staff (including substantive, temporary, student, honorary staff etc.) and all other third party users of Norfolk and Suffolk NHS Foundation Trust ICT systems based, either on Trust’s premises, or at any other location. Generically, they will be referred to as members of staff or users within this document. A breach of, or refusal to comply with this policy, is a disciplinary offence, which may lead to disciplinary action, up to and including, in appropriate circumstances, dismissal without notice. Any such disciplinary action is to be taken in accordance with the current Trust disciplinary policy. In certain cases, the Trust may refer any incident to the NHS Counter Fraud Services and/or the Police for formal criminal investigation. Additionally, the use of any, or all, ICT service(s) may be suspended pending any investigation into an alleged misuse or breach of this policy. 4.0 Confidentiality All members of staff are reminded that they are to abide with the Trust’s Confidentiality Policy (C10) and by the common law duty to maintain confidentiality concerning the data and information used as part of their everyday work within the Trust. Under the Data Protection Act 1998, members of staff must not disclose or share any personal information with parties unless they have the appropriate permission or consent to do so. This disclosure is extended to cover any other confidential information relating to any aspect of the business of the Trust.


5.0 IG and Cyber Incidents Periodically the Trust may suffer either:

The compromise of its Person Identifiable Data or other confidential information

The loss or theft of information assets, e.g. computers, removable media and Trust mobile phones

Disruption to any, or all of its ICT systems or applications

Breaches of its IG Policies

Compromise of Information Technology systems and information assets within cyberspace. (IG/Cyber SIRI) An IG/Cyber SIRI could include:

• Denial of Service attacks • Phishing emails • Social Media Disclosures • Web site defacement • Malicious Internal damage • Spoof website • Cyber Bullying

When reported these incidents will be investigated, but some outcomes of these IG/Cyber investigations may differ from an investigation initiated solely by the Trust’s disciplinary policy. IG/Cyber investigations will dependent upon the incident, focus on:

Recovering the lost, stolen or compromised information or assets

Indentify the compromise of information, and initiate any counter-compromise action

Identify any failing in procedures or systems that enables members of staff to work as normally as possible during, and then fully recover from, any disruptions to ICT Services

Make recommendations for improvements to local procedures or policies 6.0 IG/Cyber Investigations and Reporting 6.1 Initial Counter Compromise Actions When an adverse IG/Cyber incident is identified, it is important that members of staff take the following immediate actions to minimise the risk of compromise:

Prepare brief notes of the incident, including details of the assets involved and initial circumstances to assist in any future investigation

Report the incident on Datix

Inform their line manager

Inform the ICT Service Desk for all ICT related incidents

Inform the Health Records Manager for any health records related incidents


Take any obvious actions that will prevent an immediate reoccurrence of the incident, e.g. stopping the collection of internal mail or the emptying of waste paper bins, after a suspected incident involving the loss of paper records

Follow any advice given by ICT and IG staff

6.2 Assessing the Severity of the Incident The Trust is required to use the IG Toolkit Incident Reporting Tool to report Level 2 IG/Cyber SIRIs to the Department of Health, Information Commissioners Office and other regulators. When assessing the severity of an IG/Cyber incident, investigators are to refer to the Health & Social Care Information Centre (HSCIC) IG SIRI Checklist Guidance v 7.0 27th February 2015. Although the primary factors for assessing the severity level are the numbers of individual data subjects affected, the potential for media interest, and the potential for reputational damage, other factors may indicate that a higher rating is warranted, for example the potential for litigation or significant distress or damage to the data subject(s) and other personal data breaches of the Data Protection Act. As more information becomes available, the IG/Cyber SIRI level should be re-assessed. Where the numbers of individuals that are potentially impacted by an incident are unknown, a sensible view of the likely worst case should inform the assessment of the SIRI level. When more accurate information is determined the level should be revised as quickly as possible.

All IG/Cyber SIRIs entered onto the IG Toolkit Incident Reporting Tool, confirmed as severity level 2, will trigger an automated notification email to the Department of Health, Health and Social Care Information Centre and the Information Commissioner’s Office, in the first instance and to other regulators as appropriate. The IG Toolkit Incident Reporting Tool works on the basis that there are 2 factors which influence the severity of an IG/Cyber SIRI; scale & sensitivity. 6.2.1 Scale Factors Whilst any IG/Cyber SIRI is potentially a very serious matter, the number of individuals that might suffer distress, harm or other detriment is clearly an important factor. The scale (noted under step 1 below) provides the base categorisation level of an incident, which will be modified by a range of sensitivity factors. 6.2.2 Sensitivity Factors Sensitivity in this context may cover a wide range of different considerations and each incident may have a range of characteristics, some of which may raise the categorisation of an incident and some of which may lower it. The same incident may have characteristics that do both, potentially cancelling each other out. For the purpose of IG/Cyber SIRIs sensitivity factors may be:

Low – reduces the base categorisation

High – increases the base categorisation 6.2.3 Categorising SIRIs Both IG and Cyber SIRIs are determined by the context, scale and sensitivity. Every incident can be categorised as level:

Level 0 or 1 confirmed IG/Cyber SIRI but no need to report to ICO, DH and other central bodies/regulators.


Level 2 confirmed IG/Cyber SIRI that must be reported to ICO, DH and other central bodies/regulators.

Step 1a: Establish the scale of the IG incident using the following table:

Baseline Scale

0 Information about less than 11 individuals

1 Information about 11-50 individuals





3 Information about 1,001-5000 individuals

3 Information about 5,001-10,000 individuals

3 Information about 10,001-100,000 individuals

3 Information about 100,001 + individuals

Step 1b: Establish the scale of the cyber incident using the following table:

Cyber Baseline Scale

0 No impact: attack(s) blocked

0 False alarm

1 Individual, internal group(s), team or department affected

2 Multiple departments or entire organisation affected

Step 2a: For an IG Incident - Identify which sensitivity characteristics apply and adjust baseline scale point accordingly:

Low: For each of the following factors reduce the baseline score by 1

-1 for each

(A) No sensitive personal data (as defined by the Data Protection Act 1988) at risk; not data to which a duty of confidence is owed

(B) Information readily accessible or already in the public domain or would be made available under access to information legislation e.g. Freedom of Information Act 2000

(C) Information unlikely to identify individual(s)

High: For each of the following factors increase the baseline score by 1

+1 for each

(D) Detailed clinical information at risk e.g. clinical/ care case notes, social care notes

(E) High risk confidential information (F) One or more previous incidents of a similar type in past 12 months

(G) Failure to implement, enforce or follow appropriate organisational or technical safeguards to protect information

(H) Likely to attract media interest and/or a complaint has been made directly to the ICO by a member of the public, another organisation or an individual

(I) Individuals affected are likely to suffer substantial damage or distress, including significant embarrassment or detriment

(J) Individuals affected are likely to have been placed at risk of or incurred physical harm or a clinical untoward incident


Step 2b: For a Cyber Incident - Identify which cyber sensitivity factors apply and adjust baseline scale point accordingly:

Low: For each of the following factors reduce the baseline score by 1

-1 for each (1) A tertiary system affected which is hosted on infrastructure outside health and social care networks

High: The following factors increase the baseline score by 1

+1 for each

(2) Repeat Incident (previous incident within last 3 months)

(3) Critical business system unavailable for over 4 hours

(4) Likely to attract media interest

(5) Confidential information release (non-personal)

(6) Require advice on additional controls to put in place to reduce reoccurrence

(7) Aware that other organisations have been affected

(8) Multiple attacks detected and blocked over a period of 1 month

Step 3: Verify the Final Score

Where the adjusted score indicates a level 2 IG/Cyber SIRI it must be entered onto the IG Incident Reporting Tool. This reporting is only to be undertaken by the Senior Information Risk Owner (SIRO) or the Security and Governance Manager (IG Lead).

Final Score Level of SIRI

1 or less Level 1 IG/Cyber SIRI (Not Reportable)

2 or more Level 2 IG/Cyber SIRI (Reportable)

8.0 IG/Cyber Investigation Procedure Following the report of an IG/Cyber incident, the following actions will occur:

The Incident will be recorded in the Investigations Register that is to be maintained by the Security and Governance Manager. This register will collate all IG/Cyber investigations and give clear details as to their progress and status

A suitable investigator will be appointed and the investigation commenced

The investigator will submit timely written reports relating to the incident in accordance with this policy

8.0 Reporting Timescales All Organisations processing Health, Public Health and Adult Social Care personal data are required to use the IG Toolkit Incident Reporting Tool to report level 2 IG/Cyber SIRIs to the Department of Health, Information Commissioners Office and other regulators. This has been a requirement since 1st June 2013. The expectation is for serious incidents to be reported as soon as possible (usually within 24 hours of a breach being notified/identified locally) and with as much information as can be ascertained at the time. It is understood that further information will become available once an investigation has been conducted and the IG Incident Reporting Tool should be kept up to date with regards to any developments or further detail about the incident. A full record of the incident should be complete within 5 working days from when the incident was initially reported. 8.0 IG/Cyber Investigation Reports 8.1 Sensitivity and Distribution


IG/Cyber reports are used to bring to the attention of, or update, the appropriate managers of IG/Cyber Incidents that have occurred within the Trust. All reports are to be clearly marked CONFIDENTIAL, and are to be sent to:

Senior Information Risk Owner

Security and Governance Manager

Chair – Investigation Review Panel

Director and/or Senior Manager directly affected (for information )

Where appropriate, as determined by the nature of the incident, the following staff should also receive a copy of the report:

Caldicott Guardian

Compliance Manager (Data Protection & Freedom of Information)

Head of ICT Services 8.2 Initial Report Content An initial report is used to bring an IG/Cyber incident to the appropriate managers within the Trust. It is likely to consist of a single page and it will contain:

A basic outline of the incident giving a summary of facts surrounding the incident including dates and times

Cross references to Datix or other incident numbers

Actions taken to date, including an initial assessment of compromise and details of any counter-compromise action

Any actions the investigator proposes to take

An initial assessment as to the level of Information Governance/Cyber Serious Incident 8.3 Final Report Content A final report is used to provide the appropriate managers with a full account of an incident. It will contain:

Detail the persons, information or assets concerned

A full account of the circumstances and evidence relevant to the incident

Cross references to Datix or other incident numbers

Copies of all statements and other Annexes

A full assessment of compromise and details of counter-compromise action

The final assessment as to the level of Information Governance/Cyber Serious Incident

Detail any additional external reporting of the incident


Conclusions based upon the investigators findings

Make direct recommendations for the improvement of IG/Cyber standards, including whether the incident should be included in the Trusts risk register

If requested, make recommendations for any disciplinary or administrative action.

9.0 Monitoring

Aspects of the policy to be monitored

Monitoring method:

Individual/team with responsibility for the monitoring:

Frequency Findings: Group/Committee that will receive the findings/ monitoring report

Action: Group/Committee responsible for ensuring actions are in place:

Report content and submission

Review the content of all IG reports

Security and Governance Manager

Ongoing Routinely reported to IG Committee meetings

IG Committee


Annex A Sensitivity Factor Guide – IG Incident

(A) No sensitive personal data (as defined by the Data Protection Act 1998) at risk nor data to which a duty of confidence is owed

Example: The data involved in the incident does not contain information that includes:

Racial or ethnic origin of data subjects

Political opinions of data subjects

Data subjects religious beliefs or other beliefs of a similar nature.

Details as to whether the data subjects are members of a trade union (within the meaning of the Trade Union and Labour Relations (Consolidation) Act 1992.

The physical or mental health or condition of data subjects

Sexual life of data subjects

The commission or alleged commission by a data subject of any offence; or

Any proceedings for any offence committed or alleged to have been committed by a data subject, the disposal of such proceedings or the sentence of any court in such proceedings.

Confidential information includes clinical records or any data that would enable someone to learn something confidential about someone that they didn’t already know.

Data that is neither confidential nor sensitive will be demographic data that isn’t readily available in the context e.g. an individual’s name in the context of who was present at a hospital on a particular day.

(B) Information readily accessible or already in the public domain or would be made available under access to information legislation e.g. Freedom of Information Act 2000

Example: The data involved in the incident is already accessible in the public authorities Publication Scheme or otherwise available on the public authorities website. This could be copies of business meeting minutes, copies of policies and procedures that may contain the name of a senior officer or members of staff responsible for signing off such material where they have an expectation that their names and job titles would be accessible. Example: Non confidential information e.g. information from telephone directory which includes data items to which we do not owe a duty of confidence.

(C) Information unlikely to identify individual(s)

Example: Information is likely to be limited demographic data where the address and/or name of data subjects is not included. For example: lists of postcodes within political wards Examples include soundex codes, weakly pseudonymised personal data, and Hospital ID number.

(D) Detailed information at risk e.g. clinical/care case notes , social care notes

Example: This would include Social Worker case notes, Social Care Records, Information extracted from core Social Care systems, Minutes of Safeguarding Review Meetings, Hospital discharge data details, observations of service users, clinical records etc.

(E) High risk confidential information

Example: This would include information where disclosure has been prohibited by Order of a Court and may also include information which its disclosure/handling is governed by statutory requirements, guidance or industry practice. This may include information processed under the following, but not limited to, publications: Information classed as particularly sensitive information: Sexually Transmitted Disease (STD), rape victims, child safeguarding data which would cause considerable distress and damage if it got into the public domain.


(F) One or more previous incidents of a similar type in the past 12 months

Example: More than one incident where an email containing sensitive or confidential data identifying a living individual, has been sent to the wrong recipient. One or more incidents of Social Workers leaving their case recording books with a User of a service. One or more incident of a fax being sent to the wrong fax number or sensitive prints being left on a printer. Could include multiple incidents of the same type which have occurred within a specific department or unit or organisation. Specify within the incident details in terms of whether it is a reoccurring problem within a team, department or throughout the organisation.

(G) Failure to implement, enforce or follow appropriate organisational or technical safeguards to protect information

Example: Data has been transferred onto an unencrypted USB device in breach of organisational policy and subsequently lost. Disclosure of information as a result of not complying with an organisations mobile device guardianship policy e.g. left in the car overnight. Example: GP transferring clinical records on unencrypted CD’s. Organisations should have policies in place which reduce the risk of data breaches and to ensure that avoidable risks do not occur or re-occur.

(H) Likely to attract media interest and/or a complaint has been made directly to the ICO by a member of the public, another organisation or an individual

Example: Loss of large volumes of personal identifiable data being shared between a public authority and an outsourced/commissioned provider. Disclosure of information relating to sex offenders or vulnerable adults. Where a complaint has been made to the ICO. They are duty bound to investigate if a data breach has taken place. This type of incident would often receive more attention than would otherwise be the case due to the route by which the breach was raised.

(I) Individuals affected are likely to suffer substantial damage or distress, including significant embarrassment or detriment

Example: Substantial damage would be financial loss e.g. the loss of Bank Account details of service users, likely resulting in the actual loss of funds of a data subject. Substantial distress would be a level of upset, or emotional or mental pain, that goes beyond annoyance or irritation e.g. loss of entire historical record relating to a previously looked after child. Example: Details of individual in witness protection program or individual asked for their ID to be protected.

(J) Individuals affected are likely to have been placed at risk of or incurred physical harm or a clinical untoward incident

Example: Loss of personal information relating to Vulnerable Adults identifying their location, key safe details, reasons for vulnerability. Disclosure of information relating to Data Subjects located in refuge houses, Disclosure of information relating to location of offenders being rehabilitated in the community. Example: Loss of the sole copy of a clinical or social care record. Information where there is no duplicate or back up in existence, so prejudicing continuity of care.


Annex B Examples of IG Incident Classification scoring using the Sensitivity Factors

A Ward handover sheet containing sensitive personal details of 15 patients from a mental health inpatient ward was found by a member of the public and handed back into the Trust. The gentleman who found the handover sheet said that he found it on the road outside his house. The sheet contained the patient's full name, hospital number and a brief description of their current condition. Baseline scale factor 0 Sensitivity factors +1Detailed information at risk; clinical/care notes, social care. +1 High Risk Confidential Information +1 failure to implement, enforce of follow appropriate organisational safeguards to protect information +1 Individuals affected are likely to suffer substantial damage or distress, including significant embarrassment or detriment Final Scale point 3 so this is level 2 reportable SIRI

A member of staff reports that the complete paper health records of two of his patients have been inadvertently disposed of. He was working on the records at home when the envelope they were in was thrown into the recycling bin by accident. The bin has been emptied. The clinician works for the Child and Adolescent Mental Health Service. Baseline scale factor 0 Sensitivity factors +1Detailed information at risk; clinical/care notes, social care. +1 High Risk Confidential Information +1 failure to implement, enforce of follow appropriate organisational safeguards to protect information Final scale point 3 so this is a level 2 SIRI and reportable

A member of staff reports that they have been robbed and their unencrypted laptop has been taken from them. The laptop contained letters to about 25 patients as well as mental health care plans for another 10 patients. The clinician’s paper diary was also taken. It contains notes about numerous patients, but not their names. The laptop case also contained their smartcard, ID badge and remote access token. Baseline scale factor 0 Sensitivity factors +1Detailed information at risk; clinical/care notes, social care. +1 High Risk Confidential Information +1 failure to implement, enforce of follow appropriate organisational safeguards to protect information Final scale point 4 so this is a level 2 reportable SIRI


Annex C Breach type defined Notes for users: These more detailed definitions and examples should help IG Incident Reporting Users select the most appropriate ‘Breach Type’ category when completing the IG SIRI record on the online tool. However, it is recognised that many data incidents will involve elements of one or more of the following categories. For the purpose of reporting, the description which best fits the key characteristic of the incident should be selected.

Breach Type

Examples / incidents covered within this definition

Lost in Transit

The loss of data (usually in paper format, but may also include CD’s, tapes, DVD’s or portable media) whilst in transit from one business area to another location. May include data that is; - Lost by a courier; - Lost in the ‘general’ post (i.e. does not arrive at its intended destination); - Lost whilst on site but in situ between two separate premises / buildings or departments; - Lost whilst being hand delivered, whether that be by a member of the data controller’s staff or a third party acting on their behalf Generally speaking, ‘lost in transit’ would not include data taken home by a member of staff for the purpose of home working or similar (please see ‘lost or stolen hardware’ and ‘lost or stolen paperwork’ for more information).

Lost or stolen hardware

The loss of data contained on fixed or portable hardware. May include; - Lost or stolen laptops; - Hard-drives; - Pen-drives; - Servers; - Cameras; - Mobile phones containing personal data; - Desk-tops / other fixed electronic equipment; - Imaging equipment containing personal data; - Tablets; - Any other portable or fixed devices containing personal data; The loss or theft could take place on or off a data controller’s premises. For example the theft of a laptop from an employee’s home or car, or a loss of a portable device whilst travelling on public transport. Unencrypted devices are at particular risk.

Lost or stolen paperwork

The loss of data held in paper format. Would include any paper work lost or stolen which could be classified as personal data (i.e. is part of a relevant filing system/accessible record). Examples would include medical files, letters, rotas, ward handover sheets, employee records The loss or theft could take place on or off a data controller’s premises, so for example the theft of paperwork from an employee’s home or car or a loss whilst they were travelling on public transport would be included in this category. Work diaries may also be included (where the information is arranged in such a way that it could be considered to be an accessible record / relevant filing system).


Disclosed in Error

This category covers information which has been disclosed to the incorrect party or where it has been sent or otherwise provided to an individual or organisation in error. This would include situations where the information itself hasn’t actually been accessed. Examples include:

Letters / correspondence / files sent to the incorrect individual;

Verbal disclosures made in error (however wilful inappropriate disclosures / disclosures made for personal or financial gain will fall within the s55 aspect of reporting);

Failure to redact personal data from documentation supplied to third parties;

Inclusion of information relating to other data subjects in error;

Emails or faxes sent to the incorrect individual or with the incorrect information attached;

Failure to blind carbon copy (‘bcc’) emails;

Mail merge / batching errors on mass mailing campaigns leading to the incorrect individuals receiving personal data; Disclosure of data to a third party contractor / data processor who is not entitled to receive it

Uploaded to website in error

This category is distinct from ‘disclosure in error’ as it relates to information added to a website containing personal data which is not suitable for disclosure. It may include;

Failures to carry out appropriate redactions;

Uploading the incorrect documentation;

The failure to remove hidden cells or pivot tables when uploading a spread-sheet;

Failure to consider / apply FOIA exemptions to personal data

Non-secure Disposal – hardware

The failure to dispose of hardware containing personal data using appropriate technical and organisational means. It may include;

Failure to meet the contracting requirements of principle seven when employing a third party processor to carry out the removal / destruction of data;

Failure to securely wipe data ahead of destruction;

Failure to securely destroy hardware to appropriate industry standards;

Re-sale of equipment with personal data still intact / retrievable;

The provision of hardware for recycling with the data still intact

Non-secure Disposal – paperwork

The failure to dispose of paperwork containing personal data to an appropriate technical and organisational standard. It may include;

Failure to meet the contracting requirements of principle seven when employing a third party processor to remove / destroy / recycle paper;

Failure to use confidential waste destruction facilities (including on site shredding);

Data sent to landfill / recycling intact – (this would include refuse mix up’s in which personal data is placed in the general waste);


Technical security failing (including hacking)

This category concentrates on the technical measures a data controller should take to prevent unauthorised processing and loss of data and would include:

Failure to appropriately secure systems from inappropriate / malicious access;

Failure to build website / access portals to appropriate technical standards;

The storage of data (such as CV3 numbers) alongside other personal identifiers in defiance of industry best practice;

Failure to protect internal file sources from accidental / unwarranted access (for example failure to secure shared file spaces);

Failure to implement appropriate controls for remote system access for employees (for example when working from home)

In respect of successful hacking attempts, the ICO’s interest is in whether there were adequate technical security controls in place to mitigate this risk.

Corruption or inability to recover electronic data

Avoidable or foreseeable corruption of data or an issue which otherwise prevents access which has quantifiable consequences for the affected data subjects e.g. disruption of care / adverse clinical outcomes. For example:

The corruption of a file which renders the data inaccessible;

The inability to recover a file as its method / format of storage is obsolete;

The loss of a password, encryption key or the poor management of access controls leading to the data becoming inaccessible

Unauthorised access/ disclosure

The offence under section 55 of the DPA - wilful unauthorised access to, or disclosure of, personal data without the consent of the data controller. Example (1) An employee with admin access to a centralised database of patient details, accesses the records of her daughter’s new boyfriend to ascertain whether he suffers from any serious medical conditions. The employee has no legitimate business need to view the documentation and is not authorised to do so. On learning that the data subject suffers from a GUM related medical condition, the employee than challenges him about his sexual history. Example (2) An employee with access to details of patients who have sought treatment following an accident, sells the details to a claims company who then use this information to facilitate lead generation within the personal injury claims market. The employee has no legitimate business need to view the documentation and has committed an offence in both accessing the information and in selling it on.


Other

This category is designed to capture the small number of occasions on which a principle seven breach occurs which does not fall into the aforementioned categories. These may include:

Failure to decommission a former premises of the data controller by removing the personal data present;

The sale or recycling of office equipment (such as filing cabinets) later found to contain personal data;

Inadequate controls around physical employee access to data leading to the insecure storage of files (for example a failure to implement a clear desk policy or a lack of secure cabinets).

This category also covers all aspects of the remaining data protection principles as follows:

Fair processing;

Adequacy, relevance and necessity;

Accuracy;

Retaining of records;

Overseas transfers


Annex D Sensitivity Factor Guide for Cyber SIRIs

(1) A tertiary system affected which is hosted on infrastructure outside health and social care networks

Example: A staff discount site (that does not contain personal details), an externally hosted training website, an external forum site, an outsourced externally hosted estates management system. Does not include any key information assets (irrespective of hosting arrangements).

(2) Repeat Incident (previous incident within last 3 months

Example: A 2nd denial of service attack occurs at an organisation within 3 months of the 1st.

(3) Critical business system unavailable for over 4 hours

Examples of critical information systems could include electronic patients record systems, key departmental systems e.g. Theatres Management, file storage, network and telephone infrastructure, Infrastructure services (active directory, dhcp, dns etc) and critical firewalls. N.B. These can include key information assets but also encompass key infrastructure services.

(4) Likely to attract media interest

Example: Any Cyber incident that leads to compromised systems within the health and social care sectors is likely to be of media interest due to increased focus on all things Cyber.

(5) Confidential information release (non-personal)

Examples: Non-personal confidential information could include unabridged board meeting meetings, corporate financial planning information and planned service transformation information (restricting, closure and merger of services).

(6) Require advice on additional controls to put in place to reduce reoccurrence

Example: Where a Cyber incident has occurred and appropriate control(s) (physical, administrative or technical) may well be available however the organisation may need consultation and resources to action them. Such as patching, a system which is utilised by several organisations.

(7) Aware that other organisations have been affected

Example: A shared infrastructure Cyber incident (e.g. a local healthcare economy COIN) , a mass malicious spam which is known to have effected multiple organisations or a social engineering attack with telephone callers impersonating the local IT section in order for users to take compromising actions reported at multiple organisations.

(8) Multiple attacks detected and blocked over a period of 1 month

Example: A significant number of unknown source IP’s trying to access a known destination and service blocked by a firewall/IPS. Malicious and repeated spam emails being blocked at an email gateway. The volume of attempts/attacks reporting threshold should be a reflective of the type and nature organisation and there is no desire to report per event.


Annex E: Example Incident Classification scoring using the sensitivity factors (Cyber SIRI)

A trust’s twitter and Facebook accounts are compromised and posts made by a group with forthright views on healthcare provision. The trust knows a neighbouring provider has also had issues with their social media accounts. Although it is easy to change the accounts password the trust is unsure how to prevent reoccurrence. Baseline Scale Factor 1 Sensitivity Factors +1 Likely to attract media interest +1 Require advice on additional controls to reduce reoccurrence +1 Aware that other organisations have been affected Final scale point 4 so this a level 2 and would be reportable

A disgruntled technician from the IT Department who is due to be downgraded as part of a reorganisation deletes vast sections of the Active Directory structure (discovered through audit trails). The organisation’s recovery efforts where prolonged due to issues with backup and rollback issues, with IT “normality” returning 48 hours post event. The organisation does not have a full EPR and so was able to put contingency plans in place and consequently there was not intense media interest. Baseline scale factor 2 Sensitivity factor +1 Critical Business system unavailable for over 24 hours Final scale point 3 so this is a level 2 and would generate an alert

A service user complains that a member of staff has initially befriended them on social media then made a number of inappropriate approaches. The approaches are rejected which leads to a member of harassing and trolling the service user. Upon investigation it is discovered the member of staff has utilised business IT equipment and accessed social media sites in line with the organisations social media / fair usage policy. The member of staff has also disclosed details of where the service users resides and treatment plans. Baseline scale factor 1 Sensitivity factor +1 Likely to attract media interest Final scale point 2 so this is a level 2 and would generate an alert. This incident should also go through the IG SIRI classification due to the disclosure of confidential information.

An organisation’s web site is subject was subject to large flux on incoming packets from an IP addresses outside the U.K. that intended for the site to be unavailable. The trust’s new IPS system detected the attack and took appropriate action so that the site suffered no loss of access. Baseline Scale Factor 0 Sensitivity factor 0 Final scale point 0 so this is a level 0 and this should be locally determined whether this should be logged. N.B. When determining reporting consideration should be given to the intelligence value of the incident(s) in informing Cyber responses and not the affect (or lack of) a particular incident(s).

An organisation offers free WIFI for patients and visitors in its buildings. There is also a business WIFI which is used widely used with mobile devices used at the point of care to support clinical pathways. As part of a routine examination of audit logs its believed that a user of the public WIFI has managed to cross over from the public wifi to the business network. There is also some evidence that certain accounts have had unexpectedly had elevated rights applied around the


same time frame, though due to lack of system wide logging there it’s not clear what has been effected and whether the two events are connected. The organisation is unsure how to deal with the situation and switches off both public and business WIFI. Baseline Scale factor 2 Sensitivity factor +1 Critical business system unavailable for over 4 hours +1 Require advice on additional controls to put in place to reduce reoccurrence Final scale point 4 so this is a level 2 and would generate an alert

An organisation utilises a 3rd party to provide a salary sacrifice car scheme. The providers website features the available cars and the ability to calculate your expected contribution. The website is hosted on an external cloud in North America which suffers an denial of service attack making the system unavailable for over half the working day.

Baseline scale factor -1 Sensitivity factor -1 a tertiary system affected which is hosted on infrastructure outside Health and Social Care networks. Final scale point -1 so this is a level 0 and would not generate an alert N.B. If this scenario was for a key information asset the negative sensitivity factor would not be appropriate. If the systems held more personal details potentially including salary and the attack was a hacking one this should be re-evaluated as both as a Cyber and IG SIRI.


Annex F: Breach Types defined (Cyber SIRI)

Cyber Incident Type

Examples / incidents within this definition

Hacking A deliberate attempt to comprise infrastructure or Information assets usually associated with an external (internet facing) attack.

Denial of Service (DOS)

A deliberate attempt to make infrastructure or information assets unavailable to access. Commonly this would be internet attack that floods the target with requests over its capacity to process. This leads to the target system being unavailable.

Phishing emails Mass emails with malicious intent of attempting receivers to disclose generally sensitive emails. May be combined with spoof website(s).

Social Media Platforms

Any form of disclosure from the organisation staff through social media channels that discloses sensitive information (personal or corporate) or brings that organisation or the wider health and social care sector into disrepute.

Website defacement This is a deliberate attempt to alter the contents of an organisations web site(s). The motivation is normally to further a particular cause and / or to embarrass the target organisation.

Malicious internal damage

This category is cover ‘malicious insider threats’ - Deletion / modification of information assets - Compromising infrastructure deliberately The motivation for the damage could be a disgruntled employee or a third party organisation losing a support contract.

Spoof website This is a website that purports to be a legitimate site but is however spoofed. These are commonly used to gather personal information from the victims and can form part of spam mail distribution. The spoof website true address hidden in a link. The professional presentation of a spoof website can be virtually indistinguishable to the legitimate original site. Main indicators of its status is the web site address (varies from the original) and the type of personal information it asks for.

Cyber bullying This is the category covers incidents where member of staff initiates threatening or intermediating behaviour to another member of staff or outside person most commonly through mail or social media channels. It is expected that either the initiator or receiver could be linked back to the organisation (email address or tag etc).

Other This category is designed to capture more unusual or emergent type of incident. - A new type of Cyber incident that utilises a new and distinct attack vector. - An incident type that could be classified under a significant number of types with no one type being particularly prevalent.

NHS HR Dashboard - Staff in Post Staff in Post by Staff Group 16-MAY-2016 03.01.46 PM Parameters

FTE Assignment Count People HeadcountOrg P1 Staff Group246 Merged Trust 3,440.11 3,860 3,803

Add Prof Scientific and Technic 318.49 371 355Additional Clinical Services 880.65 967 964Administrative and Clerical 813.62 915 906Allied Health Professionals 112.23 143 137Estates and Ancillary 74.54 79 79Medical and Dental 151.49 185 167Nursing and Midwifery Registered 1,089.08 1,200 1,195

Date post:	30-Aug-2018
Category:	Documents
Upload:	nguyenbao
View:	214 times
Download:	0 times