Incident Reporting Procedure

Incident Reporting Procedure Version: Version 1 Ratified by: HEE Board Date ratified: 20 March 2014 Name and Title of Mike Jones, Corporate Secretary originator/author(s): Name of responsible Director: Lee Whitehead, Director of People and Communications Date issued: 04 th July 2014 Review date: 3 Years from Date of Publication Target audience: HEE Staff Document History: Approved by Exec Team 06/03/2014 Approved by HEE Board 20/03/2014 1

Document Status This is a controlled document. Whilst this document may be printed, the electronic version posted on the intranet, and copied to the internet, is the controlled copy. Any printed copies of this document are not controlled. As a controlled document, this document should not be saved onto local or network drives but should always be accessed from the intranet. 2

Contents Page Number Introduction 4 Information Security 4 Reporting security incidents 5 Sensitive security incidents 5 Accidental breaches of security 5 Security weaknesses 6 Incident resolution 6 Further information 6 Appendix 1 8 Annex A 10 Annex B 12 Annex C 16 3

Introduction 1. Incident reporting plays a major role in helping HEE maintain a safe and secure working environment. It helps protect the confidentiality, integrity and availability of our information and systems and is an essential element for effective risk management. Analysis of reported incidents will enable the organisation to highlight areas of weakness and, if necessary, take appropriate action to reduce specific threats and vulnerabilities. 2. HEE must demonstrate a commitment to, and delivery of, effective information governance. Incident management is part of this; a process of identification, reporting, investigation, resolution and learning to minimise the risk of incidents reoccurring. 3. All staff members have a responsibility to report information security incidents whether deliberate or accidental. 4. The procedure outlines the main requirements for incident reporting related to information security only and is designed to ensure core data is recorded, the event is properly reviewed, corrective action taken as required to minimise the risk of reoccurrence and to provide clarity over accountability and responsibility for actions. 5. Incidents relating to health and safety should be reported in accordance with other relevant guidelines. +Any identified fraud should be reported in accordance with the Counter Fraud policy. Information security 6. An information security incident is any actual or potential breach of security which may compromise the confidentiality, integrity or availability of information stored, processed and communicated whether in hard copy or electronic format that relates to HEE business. 7. The term security incident covers a wide range of events which can vary considerably and it is therefore not possible to detail every single event. A range of possible security breach types is included at Annex B of this policy. 4

8. This list may not describe perfectly all possible incident types. Staff must ensure they report any incident where they have a reasonable belief that there is a risk to the security of sensitive personal data or any other type of confidential information. Reporting security incidents 9. All information security incidents should be reported using the form at Appendix 1 and the following notified: line manager, Corporate Secretary and the HEE Senior Information Risk Owner (SIRO), the Director of People and Communications. The incident report should be emailed to the Corporate Management email address: HEE.corporatemanagement@nhs.net. Any incident occurring outside secure office premises should be reported immediately to the Corporate Secretary and the SIRO. 10. Information on the incident should include a description of the data lost or stolen, whether it was held in hard copy or portable media, the quantity (if known), where it was lost and the sensitivity of the data (if known). 11. The Corporate Management Office will retain a central log of all significant security breaches. These will be reported using the Information Governance Toolkit Reporting Tool. The Corporate Secretary will report incidents internally to the Audit Committee and escalated via the SIRO as necessary in accordance with national guidance for reporting on Serious Incidents Requiring Investigation. Sensitive security incidents 12. Addressing some incidents may be sensitive, especially if colleagues or managers may be incriminated. It is important that the person reporting an incident receives absolute protection and a guarantee of confidentiality even in the event of a false alarm. In these circumstances the provisions of the Whistleblowing policy will apply and the individual identifying the incident should complete the incident report on the person s behalf and forward direct to the SIRO. Accidental breaches of security 13. If an individual unintentionally causes a potential breach of security such as losing their smart card, they should inform their line 5

manager immediately. The reporting procedure detailed below will still apply. Security weaknesses 14. Staff should report any security weaknesses they observe or suspect, such as staff sharing User IDs and Passwords, including Smartcards, or system administrator privileges given to individuals who do not require them. 15. Staff should not attempt to investigate or prove a suspected security weakness themselves as this could lead to, and be interpreted as, a potential misuse of the system. Instead, any suspected weakness should be reported to their line manager who will notify the Head of IT. The Head of IT will ensure the weakness is reported to the Corporate Secretary and the HEE SIRO, and work to resolve any issue in liaison with regional IT leads, reporting back to give assurance that a resolution has been found. Incident Management, investigation and reporting 16. Incident management will be overseen by the HEE SIRO and managed by the Corporate Secretary. An audit trail will be kept of events and evidence supporting decisions taken in relation to the incident. Where appropriate, the Information Commissioner, Department of Health and other regulators will be informed, via the IG Incident Reporting Tool, of any incidents that reach IG SIRI severity level 2 (reportable). Relevant data subjects will be informed. 17. Incidents will be investigated in line with national requirements regarding forensic preservation of evidence relating to IG incidents. The HEE SIRO will agree an appropriate Investigating Officer for any incident and ensure that they are supported by any specialist resource required (IG, IT, Records Management). Investigations will include a root cause analysis and identification of lessons learned from the incident. Final reports will be reviewed by the Executive Team for sign-off. 18. Reporting of IG SIRIs will occur in line with national guidance, included in quality or end of year reports as required and published on the HEE website. Incident resolution 19. Once an incident has been dealt with and closed, the individual who 6

reported the incident should be notified of the resolution. This is the responsibility of the designated manager investigating the incident but may be delegated to the individuals line manager. Further information 20. Further information, including contact details, can be found on the HEE intranet. 7

Appendix 1 Incident reporting form Please PRINT all details on this form [To be completed by the person who identified the incident or the person reporting on their behalf] Completing this form does not imply an admission of liability on any person. Date of incident Time of incident (24 hr clock) Place of incident Name of person reporting incident Position Tel: Brief description of incident (brief factual account of what happened) Brief description of any immediate action taken Date form submitted Signature Name and position of any other staff involved / witnesses [max 2] Name Signature Position Name Signature Position Date form sent to BPRD 8

Incident number Date form received Incident level Report to (tick) Audit Committee Board ALB BSU Brief description of action taken Identify likely cause of incident Action to prevent repeat of incident Investigating Officer Signature Date 9

Annex A Definition of personal data 1 Personal data is any information: which relate to a living individual who can be identified (a) (b) from those data, or from those data and other information which is in the possession of, or is likely to come into the possession of, the data controller, and includes any expression of opinion about the individual and any indication of the intentions of the data controller or any other person in respect of the individual 2 This definition should be considered in light of the extent to which the data relates to the individual s privacy in their family life, business or professional capacity. 3 The DH defines sensitive personal data as information that includes the name of an individual, combined with one or more of the following: Bank / financial / credit card details National Insurance number / Tax, benefit or pension records Passport number / information on immigration status Travel details (for example at immigration control, or Oyster records) Passport number / information on immigration status / personal (non- HEE ) travel records Health records Work record Material related to social services (including child protection) or housing case work Conviction / prison / court records / evidence Other sensitive data defined by s.2 of the Data Protection Act 1998 including information relating to: (a) racial or ethnic origin (b) political opinions (c) religious beliefs or other beliefs of a similar nature (d) membership of a trade union 10

(e) (f) (g) (h) physical or mental health or condition sex life the commission or alleged commission by him of any offence any proceedings for any offence committed or alleged to have been committed by him, the disposal of such proceedings or the sentence of any court in such proceedings. 11

Annex B - Serious Incidents Requiring Investigation Breach Types Defined These 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 Lost in Transit Examples / incidents covered within this definition 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; 12

Breach Type Examples / incidents covered within this definition - 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 13

Breach Type Examples / incidents covered within this definition 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. 14

Breach Type Examples / incidents covered within this definition 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. A recent successful prosecution for a s55 offence: http://www.ico.org.uk/news/latest_news/2013/medical-receptionistprosecuted-after-unlawfully-accessing-patients-details-12032013 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 15

Annex C - Assessing the Severity of the Incident 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 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 SIRIs entered onto the IG Toolkit Incident Reporting Tool, reaching 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, reducing the burden on the organisation to do so. The IG Incident reporting tool works on the following basis when calculating the severity of an incident: There are 2 factors which influence the severity of an IG SIRI Scale & Sensitivity. Scale Factors Whilst any IG SIRI is a potentially a very serious matter, the number of individuals that might potentially 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. 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 SIRIs sensitivity factors may be: i. Low reduces the base categorisation ii. Medium has no effect on the base categorisation iii. High increases the base categorisation 16

Categorising SIRIs The IG SIRI category is determined by the context, scale and sensitivity. Every incident can be categorised as level: 1. Confirmed IG SIRI but no need to report to ICO, DH and other central bodies. 2. Confirmed IG SIRI that must be reported to ICO, DH and other central bodies. A further category of IG SIRI is also possible and should be used in incident closure where it is determined that it was a near miss or the incident is found to have been mistakenly reported: 0. Near miss/non-event Where an IG SIRI has found not to have occurred or severity is reduced due to fortunate events which were not part of pre-planned controls this should be recorded as a near miss to enable lessons learned activities to take place and appropriate recording of the event. The following process should be followed to categorise an IG SIRI Step 1: Establish the scale of the incident. If this is not known it will be necessary to estimate the maximum potential scale point. Baseline Scale 0 Information about less than 10 individuals 1 Information about 11-50 individuals 1 Information about 51-100 individuals 2 Information about 101-300 individuals 2 Information about 301 500 individuals 2 Information about 501 1,000 individuals 3 Information about 1,001 5,000 individuals 3 Information about 5,001 10,000 individuals 3 Information about 10,001 100,000 individuals 3 Information about 100,001 + individuals 17

Step 2: Identify which sensitivity characteristics may apply and the baseline scale point will adjust accordingly. Sensitivity Factors (SF) modify baseline scale Low: For each of the following factors reduce the baseline score by 1-1 for each No clinical data at risk Limited demographic data at risk e.g. address not included, name not included Security controls/difficulty to access data partially mitigates risk Medium: The following factors have no effect on baseline score 0 Basic demographic data at risk e.g. equivalent to telephone directory Limited clinical information at risk e.g. clinic attendance, ward handover sheet High: For each of the following factors increase the baseline score by 1 +1 for each Detailed clinical information at risk e.g. case notes Particularly sensitive information at risk e.g. HIV, STD, Mental Health, Children One or more previous incidents of a similar type in past 12 months Failure to securely encrypt mobile technology or other obvious security failing Celebrity involved or other newsworthy aspects or media interest A complaint has been made to the Information Commissioner Individuals affected are likely to suffer significant distress or embarrassment Individuals affected have been placed at risk of physical harm Individuals affected may suffer significant detriment e.g. financial loss Incident has incurred or risked incurring a clinical untoward incident 18

Step 3: Where adjusted scale indicates that the incident is level 2, the incident will be reported to the ICO and DH automatically via the IG Incident Reporting Tool. Final Score Level of SIRI 1 or less Level 1 IG SIRI (Not Reportable) 2 or more Level 2 IG SIRI (Reportable) Example Incident Classification Examples A Health Visitor data inappropriately disclosed in response to an FOI request. Data relating to 292 children, detailing their client and referral references, their ages, an indicator of their level of need, and details of each disability or impairment that led to their being in contact with the health visiting service e.g. autism, chromosomal abnormalities etc. Baseline scale factor Sensitivity Factors 2-1 Limited demographic data 0 Limited clinical information +1 Particularly sensitive information +1 Parents likely to be distressed Final scale point 3 so this is a level 2 reportable SIRI B Imaging system supplier has been extracting PID in addition to non-identifying performance data. A range of data items including names and some clinical data and images have been transferred to the USA but are being held securely and no data has been disclosed to a third party. Baseline scale factor Sensitivity Factors 3 (estimated) -1 Limited demographic data 0 Limited clinical information -1 Data held securely +1 Sensitive images +1 Data sent to USA deemed newsworthy Final scale point 3 so this is a level 2 reportable SIRI 19

C Information about a child and the circumstances of an associated child protection plan has been faxed to the wrong address. Baseline scale factor 0 Sensitivity Factors -1 No clinical data at risk 0 Basic demographic data +1 Sensitive information +1 Information may cause distress Final scale point 1 so this is a level 1 SIRI and not reportable D Subsequent to incident c the same error is made again and the recipient this time informs the Trust she has complained to the ICO. Baseline scale factor 0 Sensitivity Factors -1 No clinical data at risk 0 Basic demographic data +1 Sensitive information +1 Information may cause distress +1 Repeat incident +1 Complaint to ICO Final scale point 3 so this is a level 2 reportable SIRI E Two diaries containing information relating to the care of 240 midwifery patients were stolen from a nurse s car. Baseline scale factor 2 Sensitivity Factors 0 Basic demographic data 0 Limited clinical information Final scale point 2 so this is a level 2 reportable SIRI F A member of staff took a ward handover sheet home by mistake and disposed of it is a public waste bin where it was found by a member of the public. 19 individual s details were included. Baseline scale factor 1 Sensitivity Factors -1 Limited demographic data 0 Limited clinical information +1 Security failure re disposal of data Final scale point 1 so this is a level 1 SIRI and not reportable 20

G A filing cabinet containing CDs with personal data relating to several thousand members of staff sent to landfill in error during an office move. Baseline scale factor 3 Sensitivity Factors -1 No clinical data at risk -1 Landfill unlikely to be accessed 0 Basic demographic data +1 Security failure (no encryption & poor disposal) Final scale point 2 so this is a level 2 reportable SIRI H Loss of an individual s medical records. The records were found to be missing when the patient concerned made a subject access request. Baseline scale factor 0 Sensitivity Factors 0 Basic demographic data +1 Detailed clinical information +1 Patient distressed +1 Complaint to ICO Final scale point 3 so this is a level 2 reportable SIRI 21