Information Security Incidents - Procedures
1.1Document Control
Author / Geoff Sanders/Susannah Long
Application / This procedure applies to all employees, includes authorised employees of partner organisations, Non Executive Directors, contractors, agency staff, students, audit staff, volunteers, consultants and any other person duly authorised to use systems and applications as per the local instructions.
Implementation date / July 2010
Date of review / June 2012
Expiry date / July 2013
Link to CQC
Responsibility for implementation / All Staff
Links with other documents / Risk Management Strategy, Risk Management Policy, Risk Management Process
Policy Statement / It is the responsibility of staff at all levels to ensure that they are working to the most up to date and relevant policies and procedures. By so doing, the quality of services offered will be maintained and the chances of staff making erroneous decisions, which may affect patient, staff or visitor safety, will be reduced.
Information Security Incidents - Procedures
2.1 Contents Page
Introduction 3
Purpose 3
Definitions 4
Procedures - Managing Information Security Incidents 4
Classification and Reporting 5
Appendix i – Reporting SUIs 7
Appendix ii – Security Incident Report Form 8
RM1 Flow Diagram 11
2.2 Introduction
These procedures have been produced in response to further guidance received from the Department of Health in January 2010 regarding the reporting, managing and investigating of Information Governance Serious Untoward Incidents.
2.3 Purpose
The purpose of this internal procedure between Information Governance and Risk Management is to ensure that the organisation has robust procedures in place for dealing with information security incidents. The organisation is required to have documented and accessible information security event reporting and management procedures in place to demonstrate compliance with Information Governance Requirement 302 that contributes towards the Information Governance Assurance Programme.
2.4 Definitions
STEIS:
Strategic Executive Information System
SIRO:
Senior Information Risk Owner
SUI: SIRI
Serious Untoward Incident; Serious Incident Requiring Investigation
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, any incident involving the actual or potential loss of personal information that could lead to identity fraud or have other significant impact on individuals should be considered as serious.
ICO:
Information Commissioner’s Office
SHA:
Strategic Health Authority
DH:
Department of Health
2.5 Procedures
Managing Information Security Incidents
It is essential that all serious untoward incidents that occur in the organisation are reported appropriately and handled effectively. This document covers the reporting arrangements and describes the actions that need to be taken in terms of communication and follow up when a serious untoward incident occurs.
This process should ensure that appropriate senior staff are notified immediately of all incidents involving data loss or breaches of confidentiality.
Where incidents occur out of hours and require immediate follow up, staff will ensure on-call Directors or other nominated individuals are informed of the incident and take action to inform the appropriate contacts. During normal working hours the following sequence of events should take place:
1. Individual notifies Risk Management Team of incident (paper or electronic) and category of incident is checked. There will be a link on the intranet for this.
2. Incident entered onto Incident Database by Risk Management Team if received in paper format.
3. Risk Management Team send copy of incident to Information Governance Team.
4. Incident entered on Information Governance Incident Log, severity of the incident assessed and confirmed with Risk Manager – see appendix i.
a. Incidents determined below level 1 will be managed locally
b. Incidents determined as Level 1 or above will be classed as Serious Untoward Incidents (SUIs) and the Jan 2010 Department of Health Information Governance Policy must be followed.
The table at Annex A to that document has been superseded by the process at Appendix i to this document.
SIRO and Caldicott Guardian to confirm actions to be taken if it is considered appropriate to inform patients or staff of the incident. Consideration should always be given to informing patients or staff when person identifiable information about them has been lost or inappropriately placed in the public domain. Where there is any risk of identity theft it is strongly recommended that this is done.
5. Investigation carried out by Risk Management Team and Information Governance Team as appropriate.
6. Risk Management and Information Governance Team to update progress/actions to enable closure of incident.
7. Risk Management Team to update Incident Database and Information Governance Team to update Information Governance Incident Log.
8. Ensure publication of learning outcomes as appropriate.
2.6 Classification and Reporting
1. The Risk Manager will report the incident on the Strategic Executive Information System (STEIS) The Information Governance Manager will complete the Security Incident Report Form (appendix ii) and also inform the Senior Information Risk Owner (SIRO) and the Caldicott Guardian.
2. Incidents determined as Level 2 or above will be classed as Serious Untoward Incidents (SUIs) and the Jan 2010 Department of Health Information Governance Policy must be followed. The Risk Manager will report the incident on STEIS and the Information Governance Manager will complete the Security Incident Report Form (appendix ii) and also inform the SIRO and the Caldicott Guardian. In addition, the Information Governance Manager must report the incident to the Information Commissioner.
3. Information Governance Team to provide summary report to Information Risk Group and separate summary report to Audit & Assurance Committee.
4. Risk Management Team to include all Information Governance SUIs in report to Board
Reporting to SHA
5. The organisation should report the SUI - i.e. all incidents rated as 2 or more, to the SHA through the usual SUI process. The following information should be provided in each case:-
a) A short description of what happened, including the actions taken and whether the incident has been resolved
b) Details of how the information was held; paper, memory stick, disc laptop etc
c) Details of any safeguards such as encryption that would mitigate risk
d) Details of the number of individuals whose information is at risk
e) Details of the type of information; demographic, clinical, bank details etc
f) Whether a) the individuals concerned have been informed, b) a decision has been taken not to inform or c) this has not yet been decided
g) Whether a) the Information commissioner has been informed, b) a decision has been taken not to inform or c) this has not yet been decided
h) Whether the SUI is in the public domain and the extent of any media interest and/or publication.
6. Reporting to the SHA should be undertaken as soon as practically possible and no later than 24 hours of the incident during the working week.
7. If there is any doubt as to whether or not an incident meets the SUI reporting criteria, the organisation Risk Manager or the SHA should be contacted by telephone for advice. Early information, no matter how brief, is better than full information that is too late.
8. The organisation should keep the SHA informed of any significant developments in internal/external investigations, as appropriate. The SHA should continue to keep a watching brief on developments including following up further details/outcomes of the incident.
9. The organisation’s communications team should contact the SHA’s Communications team immediately if there is the possibility of adverse media coverage in order to agree a media handling strategy. Where necessary, the SHA Communications team will brief the Department of Health Media Centre.
Reporting to the Department of Health
10. The SHA will be responsible for notifying the DH of any category 2 or above incident reported by forwarding details to the appropriate dedicated mailbox established within the DH. Incidents should be notified to DH Comms only if only scored at level 1, and to both DH Comms and the Ministerial Briefing Unit if level 2 or higher. This latter, most serious category is the one that should be referenced as a nationally reported SUI. Once an incident has been reported to DH any subsequent details that emerge relating to the investigation and resolution of the incident should also be supplied.
11. The DH will review the incident and determine the need to brief Ministers and/or take other action at a national level.
Reporting to the Information Commissioner or other Bodies
12. The Information Commissioner should be informed of all category 3 – 5 incidents. The decision to inform any other bodies will also be taken, dependent upon the circumstances of the incident e.g. where this involves risk to the personal safety of patients, the National patient Safety Agency (NPSA) may also need to be informed. The SIRO must confirm the exact information to be reported to the ICO.
Appendix i
REPORTING SERIOUS UNTOWARD INCIDENTS (SUIs) RELATING TO ACTUAL OR POTENTIAL BREACHES OF CONFIDENTIALTY INVOLVING PERSON IDENTIFIABLE DATA (PID) INCLDUING DATA LOSS
Assessing Severity of an IG SIRI
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 provides the base categorisation level of an incident, which will be modified by a range of sensitivity factors. For the purpose of IG SIRIs the scale of an incident will be one of:
0. Information about less than 10 individuals
1. Information about 10-99 individuals
2. Information about 100-999 individuals
3. Information about 1000+ individuals
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
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
2. Confirmed IG SIRI that must be reported to ICO & DH
A further category of 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 Scale0 / Information about less than 10 individuals
1 / Information about 10-99 individuals
2 / Information about 100-999 individuals
3 / Information about 1000+ individuals
Step 2: Identify which sensitivity characteristics may apply and adjust the baseline scale point accordingly.
Sensitivity Factors (SF) modify baseline scaleLow: 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; staff sensitive information e.g. sexual orientation
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
Step 3: Where adjusted scale indicates that the incident is level 2, report it to the ICO and DH following the provided guidelines.
Final Score / Level of SIRI1 or less / Level 1 IG SIRI (Not Reportable)
2 or more / Level 2 IG SIRI (Reportable)
Appendix ii
Security Incident Report Form
Date and Time of Report: /Date and Time of Incident: /
Contact Details: /
Description of Incident: /
Aspects of Security Policy Violated /
Reporting Timescale and Scope /
Seriousness of Incident (Impact)
Type of Impact
Yes/No
Disclosure of Information
Denial of Access to Information
Destruction of Information
Modification of Information /
Seriousness of Incident (Severity)
Severity Level
Types of Incident
(delete as required)
2 – Major Security Incident
Media tape loss
Personal information abused/disclosed
Security vulnerability
Small-scale data disclosure
Widespread data disclosure
Small-scale data corruption
Widespread data corruption
3 – Minor Security Incident
Correspondence missing
Incremental update late
Login failure
Possible vulnerability
Session left unattended
System-generated message /
For Information Governance Manager use only /
Explanation for incident: /
Date resolved: /
How incident was resolved: /
Action taken to prevent future incidents: /
Monitoring and Follow-Up of Actions: /
Signed ……………………… Date ………………… Information Governance Manager