Information Governance Serious Incident Requiring Investigation Policy and Procedure

Transcription

1 Information Governance Serious Incident Requiring Investigation Policy and Procedure

2 Document Control Sheet Name of document: Information Governance Serious Incident Requiring Investigation (SIRI) Policy and Procedure Version: Final v1.0 Owner: File Location / Filename: Senior Information Risk Owner (Chief Finance Officer) G:\Corporate Documents\Policies Date of this version: December 2013 Produced by: Head of Corporate Affairs Synopsis and outcomes of consultation undertaken: Synopsis and outcomes of Equality and Diversity Impact Assessment: Approved by (Committee): N/a Audit Committee Date ratified: 14 th January 2014 Copyholders: Head of Corporate Affairs Corporate Affairs Officer Next review due: December 2015 Enquiries to: Head of Corporate Affairs Revision History Revision Date Summary of Changes Author(s) Version Number Approvals This document requires the following approval of either an individual(s), group(s) or board. Name Title Date of Issue Version Number Audit Committee 14/01/2014 V1.0 Page 2 of 20

3 Contents 1. Scope Introduction Definition Information Assets Roles and Responsibilities IG Incident Reporting Tool Reporting and Publication Monitoring... 9 Appendix 1 - IG SIRI High Level Process Appendix 2 - Assessing the Severity of the Incident Appendix 3 Definition of Breach Types Appendix 4 IG SIRI Annual Report Templates Page 3 of 20

4 1. Scope 1.1. This policy applies to all staff who work for NHS North Norfolk CCG (NNCCG) and members of the Governing Body. It is reflective of the Health and Social Care Information Centre (HSCIC) guidelines for reporting, managing and investigating Information Governance Serious Incidents Requesting Investigation (IG SIRI). 2. Introduction 2.1 This policy supports the organisation s strategic business aims and objectives by: Ensuring that the CCG has implemented an effective information incident management and response capability that supports the sharing of lessons learned; Ensuring that there is a considered and agreed IG incident response and communications plan available, including the reporting of perceived or actual IG SIRIs; and Ensuring that the CCG s management, investigation and reporting of IG SIRIs conforms to national guidance and does not conflict with the organisation s policies and procedures for non-ig Serious Incidents (SIs) (e.g. clinical incidents) 3. Definition 3.1 There is no simple definition of a serious incident. What may at first appear to be of minor importance may, on further investigation, be found to be serious and vice versa. However as a guide it includes: Any incident which involves actual or potential failure to meet the requirements of the Data Protection Act 1998 (DPA) and/or the Common Law of Confidentiality. Unlawful disclosure or misuse of confidential data, recording or sharing of inaccurate data, information security breaches and inappropriate invasion of people s privacy Personal data breaches which could lead to identity fraud or have other significant impact on individuals. Any form of media including both electronic media and paper records i.e. the CCG s information assets. N.B. Loss or theft of encrypted removable media (laptops, CDs, USB memory sticks, media cards, PDAs) is not a IG SIRI unless you have reason to believe that the protection applied to the device has been breached and personal data accessed inappropriately. 3.2 It is essential that all IG SIRIs which occur in Health are reported appropriately and managed in a robust way within work areas by applying a structured approach to the identification of Information Assets and assigned Information Asset Owners (IAO). IAOs will be supported by Information Asset Administrators (IAA) who are operational staff with day to day responsibility for managing the risk to their information assets. Page 4 of 20

5 4. Information Assets 4.1 Information assets come in many shapes and forms therefore the following list can only be illustrative. It is generally sensible to group information assets in a logical manner e.g. where they are related to the same information system or business process. Typical assets include, Personal Information Content Databases and data files Back-up and archive data Audit data Papers, records (patient care notes and staff records) Paper reports Other Information Content Databases and data files Back-up and archive data Audit data Papers, records and reports System / Process Documentation System information and documentation Operations and support procedures Manuals and training materials Contracts and agreements Business continuity plans Software Applications and System Software Data encryption utilities Development and Maintenance tools Hardware Computing hardware including PCs, Laptops, PDA, iphones, ipads and removable media Miscellaneous Environmental services e.g. power and air-conditioning People skills and experience Shared services including Networks and Printers Computer rooms and equipment Records libraries 5. Roles and Responsibilities 5.1 Senior Information Risk Owner (SIRO) The SIRO is responsible to the Governing Body for ensuring an Information Risk Policy is developed, implemented, reviewed and its effect monitored. The management and reporting of information incidents is one element of the management of information risk, which should be managed in accordance with the Assurance Framework: Key Strategic Risks. The SIRO will: Take ownership of the CCG s information risks; Act as the advocate for information risk on the Governing Body; Provide written advice to the Chief Officer, as detailed in the Annual Governance Statement; and Occupy a key role in ensuring effective management and identification of information risks. Page 5 of 20

6 5.2 Information Asset Owners Information Asset Owners (IAO) are senior staff responsible for ensuring that specific information assets are handled and managed appropriately. This means making sure that information assets are properly protected and that their value to the CCG is fully exploited. Their roles include: Understanding what information is held; Knowing what is to be added and removed; Knowing how information is moved / transferred; Knowing who has access and why; and Ensuring compliance with the relevant legal frameworks, i.e. consent and confidentiality As a result they are able to understand and address risks to the information assets they own and to provide assurance to the SIRO on the security, confidentiality, integrity and use of the assets. 5.3 Information Asset Administrators Information Asset Administrators (IAA) support IAOs by ensuring: Policies and procedures are followed; That actual or potential security incidents are recognised and reported; Consultation with their IAO on incident management occurring; and that Information Asset Registers are up to date. 6. IG Incident Reporting Tool 6.1 From June 2013 all Organisations processing health and adult social care personal data are required to use the IG Toolkit Incident Reporting Tool to report Level 2 IG SIRIs to the Department of Health (DH), Information Commissioner s Office (ICO) and other regulators. A Memorandum of Understanding is in development between the HSCIC and the ICO to share intelligence on IG SIRIs for the purpose of supporting, guiding, investigating breaches, performance monitoring and improving standards of health and adult social care services. 6.2 Local clinical and corporate incident management and reporting tools (including Strategic Executive Information System STEIS) can continue to be used for local purposes but notification of IG SIRIs for the attention of the DH and the ICO must be communicated using the IG Incident Reporting Tool with immediate effect. 6.3 The high level process for reporting an IG SIRI is categorised as follows, a flow-chart for which is described at Appendix 1: Initial Reporting Suspected Incidents Initial information is often sparse and it may be uncertain whether an IG SIRI has actually taken place. Suspected incidents and near misses can still be recorded on the IG Toolkit Incident Reporting Tool, as lessons can often be learnt from them and they can be closed or withdrawn when the full facts are known. Page 6 of 20

7 Early Notification Where a suspected IG SIRI has taken place, it is good practice to informally notify key staff (Chief Officer, SIRO, Caldicott Guardian) as an early warning to ensure that they are forewarned and in a position to respond to enquiries from third parties. Where incidents occur out of hours, current on-call arrangements will be followed to ensure that the correct contacts are notified On-call arrangements o o o A member of staff should contact the On-Call Manager using the designated telephone number as soon as they become aware of a suspected IG SIRI; The On-Call Manager should contact the IG Lead of the appropriate CCG, within 24 hours of the initial notification; The CCG IG Lead should take the appropriate steps described below to begin the reporting procedure Reporting Incidents Details of the initial findings should be entered onto the IG Incident Reporting Tool within 24 hours of notification of the incident. Staff should therefore ensure that the Head of Corporate Affairs is notified as soon as a potential IG SIRI has occurred. The severity of the incident will be determined by the scale (number of data subjects affected) and the sensitivity factors selected as detailed in Appendix 2. If the outcome of the severity is Level 2 (reportable) an notification will be generated by the system and sent to the HSCIC External IG Delivery Team, DH, ICO and escalated to regulators, as appropriate. The IG Incident Reporting Tool should be regularly updated as the investigation progresses, to enable automated s to be triggered to the HSCIC External IG Delivery Team, who will subsequently be responsible for notifying and updating relevant organisations. The reporting tool is intuitive but is reliant upon the user entering quality information. Free text field such as summary of the incident and details of the incident should be populated with data including: Date, time and location of the incident; Breach Type (Appendix 3); Details of local incident management arrangements; Confirmation that documented incident management procedures are being followed and disciplinary action will be invoked when appropriate; A factual description of what happened; Theft, accidental loss, inappropriate disclosure, procedural failure etc.; The number of patients / service users / staff (individual data subjects) involved; The number of records involved; The format of the records (paper or electronic); If electronic, whether encrypted or not; Whether the IG SIRI is in the public domain; Whether the media are aware or there is potential for media interest; Whether the IG SIRI could damage the reputation of an individual, work-team, an organisation or the Health and Adult Social Care sector; Page 7 of 20

8 Whether there are legal implications to consider; Initial assessment of the severity level; Immediate action taken, including whether any staff have been suspended pending a full investigation; and Whether the following individuals have been notified: o Data subjects o Caldicott Guardian o SIRO o Chief Officer o Police and / or Counter Fraud Managing the Incident 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; Investigate the incident; Adopt formal documentation including configuration management and version control; Maintain an audit trail of events and evidence supporting decisions taken during the investigation; Inform data subjects (e.g. patients, service users, staff), especially whether there is potential for identity theft which can be avoided or mitigated if the data subject is notified of the incident; Institute recovery actions if possible; Institute counter measures to prevent reccurrence; and Invoke the CCG s disciplinary procedure as appropriate and document where a decision was taken not to take action (if it would be of relevance to a third party) Investigating the Incident Appoint an investigating officer; Engage appropriate specialist help (such as Local Counter Fraud Specialist, CSU Information Governance Manager, CSU IT Manager); Coordinate investigations conducted across organisational boundaries (such as Acute Trust, Mental Health, and Social Care); Conduct a Root Cause Analysis (RCA) Document the investigation and findings, preserving any evidence such as minutes of meetings, s etc.; Identify lessons learned; and Update the IG Incident Reporting Tool as appropriate, ensuring that only information that the CCG wishes to be published by the HSCIC has been recorded Final Reporting, Lessons Learned and Closure of the Incident Page 8 of 20

9 Set target timescale for completing investigation and finalising reports; Produce a final report and obtain sign-off from Investigating Officer, Chief Officer and Caldicott Guardian, subject to the severity (i.e. Level 2 IG SIRI); Disseminate lessons learned to staff and members of the Governing Body; Ensure that all investigations have been completed, affected parties notified and any disciplinary action against staff has been settled to enable the IG SIRI to be closed; and Complete all fields within the IG Incident Reporting Tool including action taken and lessons learned to enable the incident to be closed and the HSCIC External IG Delivery Team to be notified via Reporting and Publication 7.1 The reporting of personal data incidents in the Annual Report should observe the principles listed below: The information provided on personal data related incidents must be complete, reliable and accurate; All public statements made in relation to personal data incidents, particularly in response to requests under the Freedom of Information Act (FOI) 2000, should be reviewed to ensure that they are consistent with the information to be published in the Annual Report; and All exemptions under the FOI Act should be reviewed to establish whether details of a personal data incident are unsuitable for inclusion in the Annual Report. For example where the incident is sub judice i.e. cannot be reported publicly pending the outcome of legal proceedings. 7.2 Details of all level 2 IG SIRIs should be included in the SIRO s written advice to the Chief Officer, as detailed in the Annual Governance Statement, and using the template in Appendix Reports of Level 2 IG SIRIs extracted from the IG Incident Reporting Tool should be published on the NNCCG website. 7.4 Details of all level 1 IG incidents should be aggregated and reported in the Annual Report using the template in Appendix Monitoring 8.1 The policy will be reviewed on a biennial basis and in accordance with the following as and when required: Legislative changes; Good practice guidance; Case law; Changes to CCG infrastructure Page 9 of 20

10 Appendix 1 - IG SIRI High Level Process Potential SIRI Make an initial assessment on IGT Incident Reporting Tool and provide early warnings, if appropriate Manage in accordance with local procedures Yes IG SIRI Level 0 or 1? No IG SIRI Level 2? Yes Reported to ICO and DH via IG Incident Reporting Tool Initiate Incident Response Plan Review IG SIRI level in light of findings. Update IG Incident Reporting Tool Investigation Final Report Close incident, note lessons learned and publish in accordance with local procedure and on IG Incident Reporting Tool Page 10 of 20

11 Appendix 2 - Assessing the Severity of the Incident The main factors for assessing the severity level of an incident are: The number of individual data subjects affected; The potential for significant distress or damage to the data subject; The type of personal data breach of the Data Protection Act; The potential for media interest; The potential for reputational damage; and/or The potential for litigation Where the number of individuals potentially affected is unknown, the likely worst case scenario should be used to inform the initial assessment of the SIRI level. However the level should be re-assessed as soon as more information is known. Categorising the level of an IG SIRI 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 individuals 1 Information about individuals 2 Information about individuals 2 Information about 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, ,000 individuals 3 Information about 100,001 + individuals Identify which sensitivity characteristics may apply and the baseline scale point will adjust accordingly. 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

12 Medium: 0 The following factors have no effect on baseline score 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 Identify the adjusted scale and report as appropriate. Final Score Level of IG SIRI 1 or less Level 1 IG SIRI (Not Reportable) 2 or more Level 2 IG SIRI (Reportable via the IG Incident Reporting Tool) Example Incident Classification 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 2-1 Limited demographic data 0 Limited clinical information Sensitivity factors +1 Particularly sensitive information +1 Parents likely to be distressed Final scale point 3 = Level 2 IG SIRI (Reportable) Page 12 of 20

13 B 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-1 no clinical data at risk -1 Landfill unlikely to be accessed Sensitivity factors 0 Basic demographic data +1 Security failure (no encryption and poor disposal) Final scale point 2 = Level 2 IG SIRI (Reportable) c Loss of an individual s medical records. The records were found to be missing when the patient concerned made a subject access request (SAR). Baseline scale factor 0 0 Basic demographic data +1 Detailed clinical information Sensitivity factors +1 Patient distressed +1 Complaint to the ICO Final scale point 3 = Level 2 IG SIRI (Reportable) Page 13 of 20

14 Appendix 3 Definition of Breach Types Breach Type Corruption or inability to recover electronic data Examples / incidents covered within this definition 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. E.g. 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 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. E.g. 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 reporting requirements pertaining to Section 55 of the DPA - unlawfully obtaining access to personal data); Failure to redact personal data from documentation supplied to third parties; Inclusion of information relating to other data subjects in error; s or faxes sent to the incorrect individual or with the incorrect information attached; Failure to blind carbon copy ( bcc ) s; Mail merge / batching errors on mass mailing campaigns leading to the incorrect individuals receiving personal data; and Disclosure of data to a third party contractor / data processor who is not entitled to receive it Lost in transit The loss of data (usually in paper format, but may also include CDs, tapes, DVDs or portable media) whilst in transit from one business area to another location. E.g. Page 14 of 20

15 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. E.g. 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; and 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 the 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 paperwork lost or stolen which could be classified as personal data (i.e. is part of a relevant filing system/accessible record). E.g. Medical files; Letters; Rotas; Ward handover sheets; and Employee records The loss or theft could take place on or off a data controller s premises, so for example the theft of Page 15 of 20

16 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). Non-secure disposal hardware The failure to dispose of hardware containing personal data using appropriate technical and organisational means. E.g. Failure to meet the contracting requirements of the Seventh Data Protection Principle* 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 *Appropriate technical and organisational measures shall be taken against unauthorised or unlawful processing of personal data and against accidental loss or destruction of, or changes to, personal data. Non-secure disposal paperwork The failure to dispose of paperwork containing personal data to an appropriate technical and organisational standard. E.g. Failure to meet the contracting requirements of the Seventh Data Protection Principle* when employing a third party processor to remove / destroy / recycle paper; Failure to use confidential waste destruction facilities (including on site shredding); and Data sent to landfill / recycling intact (this would include refuse mix ups in which personal data is placed in general waste); 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. E.g. Failures to carry out appropriate redactions; Uploading the incorrect documentation; Page 16 of 20

17 The failure to remove hidden cells or pivot tables when uploading a spread-sheet; and Failure to consider / apply FOIA exemptions to personal data 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: E.g. 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 Card Verification Data (CVD) 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); and 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. 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 Page 17 of 20

18 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. E.g. 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; and Inadequate controls around physical employee access to data leading to the insecure storage of files (for example, failure to implement a secure 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; Retention of records; Overseas transfers Page 18 of 20

19 Appendix 4 IG SIRI Annual Report Templates Summary of Level 2 Information Governance Serious Incident Requiring Investigation (IG SIRI) Involving Personal Data as Reported to the Information Commissioners Office (ICO) Date of Incident [Month / Year] Nature of Incident [Table 1] Nature of Data Involved [List of data items involved i.e. name, address, date of birth, NHS number] Number of Data Subjects Potentially Affected [An estimate of the number of individuals should be provided if no precise figure is available] Notification Steps [Individuals notified by post / / telephone / in person] [Details of media statement released] [Details of law enforcement / health and social care agencies notified] [Details of lessons learned disseminated to staff] Further Action on Information Risk [Summary of any disciplinary action taken as a result of the incident / any remedial action to prevent/mitigate reoccurrence] Table 1 A Corruption or inability to recover electronic data B Disclosed in error C Lost in transit D Lost or stolen hardware E Lost or stolen paperwork F Non-secure disposal hardware G Non-secure disposal paperwork H Uploaded to website in error I Technical security failing (including hacking) J Unauthorised access / disclosure K Other (refer to Appendix 3) Page 19 of 20

20 Summary of Other Personal Data Related Incident (Level 1) Category Breach Type Total A B C D E F G H I J Corruption or inability to recover electronic data Disclosed in error Lost in transit Lost or stolen hardware Lost or stolen paperwork Non-secure disposal hardware Non-secure disposal paperwork Uploaded to website in error Technical security failing (including hacking) Unauthorised access / disclosure K Other (refer to Appendix 3) Page 20 of 20