BHR CCGs Procedure for Managing Information Governance/Information Security Related Incidents

Transcription

1 BHR CCGs Procedure for Managing Information Governance/Information Security Related Incidents Version Description of Change(s) Reason for Author Date Change 0.1 Draft Created Initial Draft R Lavender 30/09/ Policy N/A R Lavender 03/10/2013 Implemented (following SIRO approval) 2.0 Policy Updated Review overdue C Sadler 15/10/ Policy Updated Appendix A C Sadler 23/10/2015 requires replacement with IG SIRI reporting process flow chart Policy Reference Information Version Number 2.1 Status To be approved by IGSG Author/s Implementation Date Date of Last Review Date October 2013 Date of Next Formal Review October 2017 Carl Sadler, Information Governance Consultant Rob Lavender, RA Manager Initial October 2013 November 2015 Ratified by Date of Ratification Date of Equality Impact Audit and Governance Committee TBC TBC BHR CCG IG Incident Reporting Version October 2015 Page 1

2 Assessment BHR CCG IG Incident Reporting Version October 2015 Page 2

3 Contents Section Title Page No Contents 3 1 Introduction 4 2 What is an Information Governance/Security Related Incident? 4 3 Example of incidents that should be reported 6 4 Roles and Responsibilities 6 5 Reporting and Recording Incidents (inc SIRI /Cyber SIRI) 8 6 Investigating an Incident 9 7 Reporting and Monitoring Effectiveness 10 8 Dissemination 11 9 Future Steps 11 Appendix A IG SIRI Incident Reporting Process 12 Appendix B Information Governance/Security/SIRI Incident Reporting Form 13 Appendix C IG SIRI Breach Types Defined 14 Appendix D Assessing the Severity of the Incident Guide (Cyber SIRI) 21 Appendix E Risk Grading Matrix 23 BHR CCG IG Incident Reporting Version October 2015 Page 3

4 1. Introduction Barking and Dagenham, Havering and Redbridge CCGs have a responsibility to ensure all information governance related incidents that may breach security and/or confidentiality of personally identifiable, sensitive or confidential information or data, are identified, reported and monitored. The CCG s Incident Reporting process will be used to report, monitor and investigate all incidents, breaches, or near misses identified as information governance or information security within the organisation. This document details the specific procedures and additional required for identifying, reporting and monitoring information governance/information security related incidents. 2. What is an Information Governance/Security Related Incident? An incident is described as any event which has given rise to potential or actual harm or injury, to patient dissatisfaction or to damage/ loss of property (Ref: NHS Executive). This definition includes patient/ service user injury, fire, theft, vandalism, assault and employee accident and near misses. It includes incidents resulting from negligent acts, deliberate or unforeseen. A near miss is an incident that had the potential to cause harm but was prevented. Information governance/security incidents relate to the breach, theft or loss of personally identifiable, sensitive or confidential data, this could be for patients, service users, other clients or staff or relate to confidential corporate information. This could be for both electronic and manual records/information and could relate to anything from users sharing passwords to a piece of paper identifying a patient being found in the street. An information security incident is defined as any event that has resulted or could result in: The integrity of an information system or data being put at risk The availability of an information system or information being put at risk An adverse impact e.g. o Damage to an individual s or the CCGs reputation o Threat to personal safety or privacy o Legal obligation or penalty o Financial loss o Disruption of activities Personal Identifiable Data (PID) relates to information or data about an individual who can be identified either form that data or from data and other information which is, or is likely to come into the data controller s (the CCGs) possession. This includes: BHR CCG IG Incident Reporting Version October 2015 Page 4

5 Surname Forename Initials Address Date of Birth Other dates (e.g. death, diagnosis) Postcode Occupation Sex NHS Number National Insurance Number Local Identifier (e.g. hospital, GP practice number) Telephone Number A test of reasonableness should be undertaken when considering whether access to particular items of information is likely to result in an individual's identity becoming known. Personally sensitive information includes: Racial or ethnic origin Physical or mental health condition Sexual life Commissioned or alleged commission of offences Any procedures for any offence, committed or alleged Includes sentencing decisions made by the court Political opinion or persuasion Religious belief or other beliefs of a similar nature Trade union membership or affiliation Confidentiality is defined as ensuring that information is accessible only to those authorized to have access. Some types of communication between one person and another are "privileged" and may not be discussed or divulged to third parties. BHR CCG IG Incident Reporting Version October 2015 Page 5

6 3. Examples of incidents that should be reported Some of the more common type of incident are listed below (n.b the list is not exhaustive) and should be used as guidance only. If in doubt always report the incident Information Security Incidents include Loss or theft of computer equipment (e.g. desktop PC) or mobile or removable media (e.g. laptop, ipads, CD/DVDs, USB memory stick) Loss or theft of PID or sensitive information (e.g. patient or staff records/information. Unauthorised access to electronic information systems (e.g. using someone else s password or smartcard) Breach of confidentiality/security of PID or sensitive information Finding any paper records about a patient/member of staff or business of the organisation, for example in a corridor or in the street. The insecure transfer of PID via by a member of staff (e.g. sending an unencrypted file via unsecured ) PID being sent via internal/external post to the wrong person or not sent securely (e.g. information not sent in a sealed envelope, marked private and confidential, addressed to an individual or marked addressee only ) Patient or staff records on view to the public (e.g. on a reception desk in on view in a car) Discussing patient or staff information with someone else in an open area where the conversation can be overheard A fax being sent to the wrong person/fax machine (e.g. staff not following the Safe Haven Policy) 4. Roles and Responsibilities The Governing Body and the Audit and Governance Committee The Governing Body is responsible for governing the management of risk within the CCG. It provides oversight of risk through holding management to account for quality and risk management matters. The Governing Body will also annually review and sign off the commitment to Health and Safety Statement of Intent. The Audit and Governance Committee will receive incident reports (via the IGSG), They will have delegated responsibility from the Board to oversee the managing and monitoring of incidents and to produce a Serious Incident report with details of open incidents, action plans and lessons learned. The Joint Management Team (JMT) is the executive group whose purpose is to support the Accountable Officer and individual Directors in the fulfilment of their BHR CCG IG Incident Reporting Version October 2015 Page 6

7 responsibilities and to enable the development and delivery of corporate direction for the management of the CCG. The JMT will receive reports on matters relating to the strategic, operational and corporate management of the CCG, including Serious Incidents. The Accountable Officer has responsibility for ensuring that the CCG has the necessary management systems in place to enable the effective management and implementation of all risk management and governance systems including the reporting, management and investigation of incidents. The SIRO has responsibility for ensuring that identified information threats and vulnerabilities are followed up for risk mitigation, and that perceived or actual information incidents are managed in accordance with NHS IG requirements. They must also ensure there are effective mechanisms in place for reporting and managing Serious Incidents Requiring Investigation. These mechanisms should accommodate technical, operational or procedural improvements arising from lessons learnt The Caldicott Guardian is responsible for ensuring the protection and use of patient identifiable information, which may be used during the incident reporting process. Directors and Chief Operating Officers are responsible for ensuring that the all staff are aware of appropriate incident management processes and that incidents are managed and reported in an appropriate manner. If necessary they may be required to escalate or report to the JMT. Executive and Operational IG Leads will be responsible for recording IG/IS incidents, logging any SIRIs via the Information Governance Toolkit, for coordinating any investigations and ensuring that action plans are in place and completed. They will also escalate serious incidents as appropriate and provide reports to the SIRO and the Information Governance Steering Group. The Information Governance Steering Group will review incidents as part of their standing agenda items and prepare appropriate summary reports for Audit and Governance Committee. Expert Leads will review relevant incidents and identify any areas that need to be addressed as part of the investigation. When the incident report is completed, their role is to review the report and identify whether it has addressed all the issues and is suitable for closure. An example of an expert lead would be the medicines management lead, finance or IT specialist. Line Managers will be responsible for managing and completing any actions plans and reporting back to the investigating officer. All staff are responsible for reporting incidents and supporting the investigating officer where required. BHR CCG IG Incident Reporting Version October 2015 Page 7

8 5. Reporting and Recording Information Governance/Security Related Incidents (including SIRIs and Cyber SIRIs) Staff must follow process detailed in Appendix A of this document, complete the Information Governance/Security/SIRI Form (Appendix B) and pass it to their line manager for signature and recording, forms will then be passed to the Nurse Directorate for checking to ensure that there is no clinical element to the incident. Information Governance/security related incidents will then be forwarded to IG Lead for recording and formal investigation. The Incident form must be signed off by the appropriate Line Manger and it is the responsibility of the manager to ensure a suitable investigation and corrective action is taken. The manager must also ensure that adequate feedback has been given to the person reporting the incident. Where the severity of an information incident meets the national definitions for a Serious Incident Requiring Investigation (SIRI), the CCG will ensure that it (or its commissioned service provider) will comply with the NHS requirements for the reporting and subsequent investigation of the incident. Serious incidents must be reported within 24 hours of the incident taking place. All SIRIs will be recorded via the Information Governance Incident Reporting Tool available within the Information Governance Toolkit (n.b relevant staff must have a login to the toolkit), additional information may be requested. Full guidance is available via: What is an IG SIRI? 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. As a guide the scope of an Information Governance Serious Incident Requiring Investigation (IG SIRI):- This type of incident will typically breach one of the principles of the Data Protection Act and/or the Common Law Duty of Confidentiality. This includes 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. See Annex C for further definitions and examples of IG SIRI Breach Types. Applies irrespective of the media involved and includes both electronic media and paper records relating to staff and service users. When lost data is protected e.g. by appropriate encryption, so that no individual s data can be accessed, then there is no data breach (though there may be clinical safety implications that require the incident to be reported down a different route). When the data is protected but there is a risk of individuals being identified then this remains an incident and should be reported. The sensitivity factors within the IG Incident Reporting Tool will reflect that the risk is low. BHR CCG IG Incident Reporting Version October 2015 Page 8

9 What is an IG Cyber SIRI? There are many possible definitions of what a Cyber incident is, for the purposes of reporting a Cyber incident is defined as:- 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 It is expected that the type of incidents reported would be of a serious enough nature to require investigation by the organisation. These types of incidents could include: Denial of Service attacks Phishing s Social Media Disclosures Web site defacement Malicious Internal damage Spoof website Cyber Bullying See Annex H & I For examples and definitions Please note that all incidents recorded as level 2 or above will automatically be forwarded to the Department of Health and the Information Commissioners Office. If there is a suggestion that a criminal offence has been committed, the CCG should contact the police. The organisation should give early consideration to the provision of information and support to patients, relatives and carers and staff involved in the incident, including information regarding support systems which are available to patients/relatives/visitor/contractors. NHS organisations should follow guidance provided in their local Being Open policy. All incidents should be risk assessed by the line manager using the matrix set out in Appendix C. 6. Investigating an Incident Once reported, details of any IG related incidents should be forwarded to the IG Lead and an investigation instigated if required, this will include the member of staff reporting the incident and their line manager. Other members of staff may also be involved depending on the type of incident, for example the Operational or Executive IG Lead or the SIRO. Serious Incidents must be immediately reported to the SIRO, the Executive IG Lead and the Caldicott Guardian. Depending on the nature and severity of the incident, the CCG may report the incident and/or seek guidance from the Police and/or Office of BHR CCG IG Incident Reporting Version October 2015 Page 9

10 the Information Commissioner. Provision of legal and professional guidance will be considered and obtained where appropriate. Once recorded via the Information Governance Incident Reporting Tool any serious incidents will automatically be forwarded to the Department of Health and the Information Commissioners Office. All IG related incidents will be reported to the Information Governance Steering Group (IGSG) as per the groups Terms of Reference. The IGSG may request further information and a formal report. Serious Incident Report Report formats can be found at but as a minimum SI reports should include the following: Incident date Incident description Actual effect on patient/service Involvement and support of patients and relatives Clear, fact based chronology of events leading up to the incident Care and Service Delivery problems Contributory Factors Root Causes Lessons Learned Action Plan (containing the minimum requirements listed below) Evidence of Board level sign off before submission (including name, designation and date reviewed) Anonymised for patient and staff involved in the incident These are the minimum requirements for an action plan: every recommendation must have a clearly articulated action a responsible person (job title only) must be identified for each action point there are dates for proposed completion of actions description of the form of evidence that will be available to confirm completion. A SMART approach to action planning is recommended. That is, the actions should be: Specific, Measurable, Attainable, Relevant and Time-bound. 7. Reporting and monitoring effectiveness BHR CCG IG Incident Reporting Version October 2015 Page 10

11 Monthly reports of information governance incidents and any investigations will be provided to the SIRO and the Information Governance Steering Group (IGSG), any organisational learning will be disseminated and implemented by the Joint Management Team. 8. Dissemination These guidelines will be published on the CCGs Intranet and publicised via staff bulletins, briefings and the booklet A Local Guide to Information Governance. It is the responsibility of line managers to ensure that all staff are made aware of this process. New members of staff are advised during their induction to look at the CCG Intranet to ensure that they read and have a good working knowledge of all relevant policies, strategies, procedures and guidelines. 9. Future steps If the volume of reported types of incidents has not reduced then senior management should be alerted and appropriate action taken. This could be further training courses for staff or an improvement to existing security and/or confidentiality arrangements. Some incidents may involve the invoking the CCGs disciplinary procedures. BHR CCG IG Incident Reporting Version October 2015 Page 11

12 Appendix A 15 October 2015 Page 12

13 Appendix B - Information Governance/Security/SIRI Incident Reporting Form General Details CCG: Name: Job Title: Location: Telephone: Date of Incident Time (24 hr) Local Incident ID Breach Type 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 Other please tick Summary of incident. A brief, factual,concise description of what happened Details of incident. Further details in addition to the summary above eg details on when the incident occurred, type of records lost, information (eg personal identifiable data items),security measure in place or not, how the incident occurred, why and what circumstances associated risks. 15 October 2015 Page 13

14 Organisation Name: Organisation Code: Severity Details Near Miss? If the incident 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/non event by ticking the box to the right. This will enable lessons learned activities to take place and appropriate recording of the event. Please tick Scale of incident (nb if the scale is not known then estimate the maximum potential number) Information about: Less than 10 individuals Please tick 501 1,000 individuals Please tick individuals 1,001 5,000 individuals individuals 5,001 10,000 individuals individuals 10, ,000 individuals individuals More than 100,000 individuals Sensitivity Low Sensitivity Factors No clincial data at risk Limited demographic data at risk (eg address not included, name not included) Security controls/difficulty to access partially mitigates risk Medium Sensitivity Factors Basic demographic data at risk eg equivalent to telephone directory Limited clincial information at risk eg clinic attandance, ward handover sheet Please tick High Sensitivity Factors 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 the past 12 months Failure to securely encrypt mobile technology or other obvious security failing Newsworthy aspects or media interest (including celebrity involved) A complaint has been made to the information commissioner Individuals affected are likely to suffer significant distress or embarrassment Individuals affected have been places at risk of physical harm Individuals affected may suffer significant detriment e.g. financial loss Incident has occurred or risk incurring a clinical untoward incident 15 October 2015 Page 14

15 Data Details Type of data (summary of the type of personal/sensitive/confidential information lost or put at risk e.g. NHS patient data, staff data, service user information) Format: Please tick Encrypted Please tick Electronic/digital Yes Paper No Other Not applicable Not Known Password protected only Other please describe in data section above Volume (Approx number of data subjects (i.e. individuals) have been affected e.g. number or range of records lost or at risk) Post Incident Details Media Aware Please tick Media Notes Yes No Not known Data Subject Informed? Please tick Police Informed? Please tick Yes Yes No No Planned Planned Not known Not known Not Required Not Required 15 October 2015 Page 15

16 Actions Taken (Actions taken to investigate, manage, report, resolve, discipline negligence and prevent from re-occurring. Have you taken any action to minimise/mitigate the effect on the data subjects involved? If so, please provide brief details. Are you carrying out an investigation into the incident, if so when will the investigation be completed and what format will it take?) Lessons Learned (How this incident could have been prevented, investigated, managed or resolved better. Measures which could have been put in place to avoid or prevent the incident from occurring. What action have you taken to prevent similar incidents from occurring?) Signature: Date: Line Manager Comments: Line Manager Name: Signature: Date: The Department of Health and the Information Commissioner s Office will automatically receive notifications of ALL reported Level 2 IG SIRIs All information recorded under a "Closed" IG SIRI on the IG Toolkit Incident Reporting Tool will be published quarterly by the Health and Social Care Information Centre (HSCIC). Organisations must therefore check the content recorded within the IG Incident report before closing the record to ensure that you do not include any information that you would not normally provide or publish yourself if requested under the Freedom of Information Act Other IG SIRIs marked as "Open", "Withdrawn" or "Duplicate" will not be published by the HSCIC. See the "Publication Statement" on the IG Incident Reporting Tool landing page or accessible via the IG Toolkit Knowledgebase for further detail. 15 October 2015 Page 16

17 Appendix C - IG SIRI Breach Types 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 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. 15 October 2015 Page 17

18 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; 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; 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 15 October 2015 Page 18

19 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 Technical security failing (including hacking) 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); 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. A technical security incident may also be a Cyber incident (please see Cyber guidance within this document) Corruption or inability to recover electronic Avoidable or foreseeable corruption of data or an issue which otherwise prevents access which has quantifiable consequences for 15 October 2015 Page 19

20 data 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 Other 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. 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: prosecuted-for-illegally-accessing-patients-medical-records 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; 15 October 2015 Page 20

21 Retaining of records; Overseas transfers Appendix D-Assessing the Severity of the Incident Guide (Cyber SIRI) Although the primary factors for assessing the severity level is the criticality and scale of the incident, for example the potential for impact on confidentiality, integrity or availability. If more information becomes available, post incident investigation the Cyber SIRI level should be reassessed. Please note: Conversely, when targeted systems are protected e.g. by an Intrusion Prevention System, so that no services are affected. The sensitivity factors will reflect that the risk is low. All Cyber SIRIs entered onto the IG Toolkit Incident Reporting Tool, confirmed as severity level 2, will trigger an automated notification to the DH and HSCIC. 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 a Cyber SIRI Scale & Sensitivity. Scale Factors Whilst any Cyber SIRI is a potentially a very serious matter, the scale is clearly an important factor. The scale provides the base categorisation level of an incident, which will be modified by a range of sensitivity factors 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. A further category of Cyber 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. No impact: Attack blocked 15 October 2015 Page 21

22 0. False Alarm Where a Cyber 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. 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 Cyber SIRIs sensitivity factors may be: iii. Low reduces the base categorisation iv. High increases the base categorisation Categorising SIRIs The Cyber SIRI category is determined by the context, scale and sensitivity. Every incident can be categorised as level: 1. Level 0 or 1 confirmed Cyber SIRI but no alerting to HSCIC & DH. 2. Level 2 confirmed Cyber SIRI alerting to HSCIC & DH The following process should be followed to categorise a Cyber SIRI Identify which sensitivity characteristics may apply and the baseline scale point will adjust accordingly. Cyber Sensitivity Factors (SF) modify baseline scale Low: For each of the following factor reduce the baseline score by 1-1 (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 (2) Repeat Incident (previous incident within last 3 months) (3) Critical business system unavailable for over 4 hours +1 for each (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 15 October 2015 Page 22

23 (7) Aware that other organisations have been affected (8) Multiple attacks detected and blocked over a period of 1 month 15 October 2015 Page 23

24 Appendix E Risk Grading Matrix In order to ensure that all risks in are managed appropriately all risks will be assessed using the following risk grading matrix (see figure 2). Likelihood Rating Description Rare Unlikely Possible Likely Certain Frequency Not expected to occur in years Expected to occur once a quarter Expected to occur once a month Expected to occur weekly Expected to occur daily Rating Description A B C D E F G H Objectives / Projects Harm / Injury to Patients, Staff Visitors and Others Actual / Potential complaints and claims Service disruption Staffing and Competence Financial Inspection / Audit Adverse Media Probability <10% 10% to 24% 25%-45 50% - 74% >75% 1 Insignificant Insignificant cost increase / time slippage. Barely noticeable reduction in scope or quality Incident was prevented Locally resolved OR Incident complaint occurred and there was no harm Loss / Interruption more than 1 hour Short term low staffing leading to reduction in quality (less than 1 day) Small loss < 1000 Minor recommendations Rumours Severity Minor Moderate Major Severe Less than 5% cost or time increase. Minor reduction in quality or scope 5-10% cost or time increase. Moderate reduction in scope or quality 10-25% cost or time increase. Failure to meet secondary objectives >25% cost or time increase. Failure to meet primary objective Individual(s) required first aid Staff needed <3 days off work or normal duties. Individual(s) require a moderate increase in care. Staff needed >3 days off work or normal duties Individual(s) appear to have suffered permanent harm. Staff have sustained a "Major Injury". As defined by the HSE Individual(s) died as a result of the incident Justified complaint peripheral to clinical care. Below excess claim. Justified complaint involving inappropriate care Claim above excess level. Multiple justified complaints Multiple claims or single major claims Loss of one whole working day. Loss of more than one working day Loss of more than one working week Permanent loss of premises or facility. On-going low staffing levels reducing service quality Late delivery of key objectives / service due to lack of staff. On-going unsafe staff levels Small error owing to insufficient training. Uncertain delivery of services due to lack of staff. Large error owing to insufficient training Non delivery of service. Critical error owing to insufficient training Loss of 0.1% budget. < 10,000 Loss of more than 0.25% of budget. < 100,000 Loss of more than 0.5% budget < 500,000 Loss of more than 1% budget. > 500,000 Recommendatio ns given. Noncompliance with standards. Reduced rating. Challenging recommendations. Non-compliance with standards. Enforcement action. Low rating. Critical report. Major noncompliance with core standards. Prosecution. Zero rating. Severely critical report Local Media column. Local Media frontpage story Local media - short term National media more than 3 days. MP concern October 2015 Page 24