ict priority 1 incident handling - bcpft.nhs.uk
TRANSCRIPT
Version 1.0 October 2016
ICT Priority 1 Incident Handling
Target Audience
Target Audience
All Staff
ICT Priority 1 Incident Handling Policy
Version 1.0 October 2016
2
Ref. Contents Page
1.0 Introduction 4
2.0 Purpose 4
3.0 Objectives 4
4.0 Process (09:00 hrs -17:00 hrs) 4
4.1 Incident Handling - Within the First of 10 Minutes 4
4.2 Within the First 20 Minutes 5
4.3 Within 20minutes – 30minutes 6
4.4 Within 30minutes – 45minutes 6
4.5 Every 1 hour Until Resolved 6
4.6 Post Incident Handling 7
4.7 Priority 1 Escalation Flowchart in Hours 8
4.8 Impact and Urgency Matrix 9
4.9 Call Logging Standards 10
5.0 Procedures connected to this Policy 10
6.0 Links to Relevant Legislation 10
6.1 Links to Relevant National Standards 11
6.2 Links to other Key Policies 11
7.0 Roles and Responsibilities for this Policy 13
8.0 Training 14
9.0 Equality Impact Assessment 14
10.0 Data Protection and Freedom of Information 14
11.0 Monitoring this policy is working in practice 15
ICT Priority 1 Incident Handling Policy
Version 1.0 October 2016
3
Explanation of terms used in this policy
Priority (P1) - an unplanned critical event that satisfies any of the following criteria: Any faults that
prevent the effective use of any major ICT services and or prevents absolutely necessary business
transactions for example: Total loss of email, Internet, EHR, Oasis, Site down, etc.
ICT Priority 1 Incident Handling Policy
Version 1.0 October 2016
4
1.0 Introduction The ICT Service Desk is the first point of contact for the support of ICT services for all Black Country Partnership NHS Foundation Trust users of IT. The ICT Service Desk handles all queries from customers and third party suppliers including fault reports, assistance with services, requests for change and enhancements to I.T services.
All requests for assistance should first be logged with the ICT Service desk, which will manage the calls to resolution. Calls will be categorised as either Incidents or Service Requests. In general, resolution of incidents takes precedence over fulfilment of service requests.
2.0 Purpose The purpose of this policy is to define the actions, communications and escalation steps that are to be used to manage a Priority 1 incident for all staff within ICT Services. 3.0 Objectives
To Identify the trigger Information
To define what is a Priority 1 Incident
4.0 Process (09:00 hrs -17:00 hrs) This process must be followed when Service Desk Engineers receive a Phone call, E-mail, System Alert, Web Portal incident or have been assigned an incident which meets the criteria of a Priority 1 Incident. This includes when an incident is either initially logged as a Priority 1, or if an existing incident is escalated to a Priority 1 from a lower priority. It is to be followed in its entirety and no stages are to be bypassed or omitted. Failure to follow this policy can cause significant delays to our users and may lead to disciplinary action.
4.1 Incident Handling - Within the First of 10 Minutes 1. An Incident is logged with the Service desk either via phone/email/Self service
Portal by the affected Service Area, by Proactive Alarm or by phone/email from a third party support vendor i.e. Virgin media, BT etc.
2. The initial prioritisation and categorisation of the incident should be performed using the Impact and urgency matrix below inline the agreed minimum data set that is required when logging all incidents
Impact
Service Impacted
Department Impacted
Employee Impacted
Urgency
High P1 P2 P3
Med P2 P3 P4
Low P3 P4 P5
(**see Impact and urgency Matrix for and the agreed Minimum Data Set)
3. The Service desk Engineer who logs the Incident is to verbally confirm with 2nd
Line Service desk Engineers that the incident is a Priority 1 and agree an incident owner. This is required before effective handover
ICT Priority 1 Incident Handling Policy
Version 1.0 October 2016
5
4. The Service desk Engineer informs ICT Services via Email using the P1 Notifications Distribution List that a Priority 1 Incident has been raised and provides an initial Response and Resolution timescale
5. The Incident Owner (2nd Line Service desk Engineer) is required to perform all suitable diagnostic tests using the available tools to ascertain as much detail as possible on the critical fault. The Incident Owner records all actions and activities performed throughout lifecycle of incident, and should always be kept up to date of what is happening with the incident. The Incident Owner is the main information point for all parties involved both internally and externally. At this stage an initial SOA (Service Outage Analysis) Form is completed with all information known at this point, and added to the SOA index. The SOA is to be completed on the incident resolution and saved to the Draft SOA folder as per SOA instructions
4.2 Within the First 20 Minutes 6. The Incident Owner liaises with the relevant Technical Specialists providing the
master incident record number (Ticket Reference), summary of the issue, how many customers are affected and what the business impact is. Priority 1 investigation and diagnosis takes precedence over any work assigned to all Technical Specialists, until a Lead Technical Specialist is established. The Lead Technical Specialist takes full responsibility for site visits, remote work and ultimately the resolution of the incident
7. The Incident Owner contacts the following managers in the order listed below. (Preferably in person or by phone)
I. ICT Service Desk Coordinator II. ICT Service Delivery Manager
III. ICT Network Manager IV. ICT Technical Support Team Leader V. ICT Services Manager
The ICT Management team will decide who the escalation manager will be for this incident. The Escalation Manager has the responsibility for organisational wide communications. The Escalation Manger is also responsible for the escalation of the incident both internally and externally with all involved parties. The Escalation Manager is responsible for the co-ordination and delivery of hourly updates if required, using suitable communication channels, both in terms of organisational wide communications, customer specific communications and system owner communications
8. The Escalation Manager has full jurisdiction over all of the ICT Services resources and assets including Service Desk Engineers, ICT Support officers, Asset officers, and Senior Technical Support Engineers
9. The Incident Owner is to ensure that all of the individuals identified below have been made aware that they are being named. The Incident Owner will then email the Priority 1 notifications distribution list & System Owners informing them of:
a. Incident Number: b. Site Name: c. Description of Problem: d. Incident Owner: e. Lead Technical Specialist: f. Escalation Manager:
ICT Priority 1 Incident Handling Policy
Version 1.0 October 2016
6
4.3 Within 20minutes – 30minutes 10. The Incident Owner contacts via email/phone all users associated with the
incident, ascertaining who should be kept up to date on progress of the incident and include the associated users in to the main email list. If multiple sites are affected there should be at least one nominated user from each site. (Recommend to nominate main reception staff for updates)
11. The Incident Owner adds all additional users into the association of the incident record within the Service Desk Incident Management System (Kayako). The Incident Owner is to keep the primary association as the first person who initially reported the issue unless instructed otherwise by a member of the ICT Services Management Team
12. The Lead Technical Specialist attempts to resolve the incident remotely during this period, if a solution is not possible remotely or further investigation required then Lead Technical Specialist MUST visit the site/location in question
13. The Incident Owner contacts any external providers i.e. N3, BT, Virgin, NHS.net informing the 3rd party vendor of the incident and logs an incident with the 3rd party vendor for investigation. The incident owner should always provide the 3rd party vendor with our local incident reference number
14. The Escalation Manager, Incident Owner and Lead Technical Specialist discuss the probable underlying cause of the incident, and review any possible solutions or workarounds, Estimated a resolution time, prepare initial communications that are to be sent to the all of the affected customers informing them of the issue at hand, what is affected and where is affected
4.4 Within 30minutes – 45minutes 15. The Lead Technical Specialist investigates the root cause of the incident,
defining where this resides and whether internal or external support is required. i.e. is the issue with a faulty switch, router issue, server failure, power failure
16. The Incident Owner receives timely updates from Lead Technical Specialist as to the root cause of the incident and updates the Escalation Manager and any external party vendors that are involved. The Incident Owner is to maintain an accurate log of times of conversations and relevant information in the Master Incident Record on the Service Desk Incident Management System - Kayako (this could be the initial Incident or may be changed to a Problem record)
17. The Incident Owner and Escalation Manager discuss sending incident specific communications to all associated customers/staff detailing where the root cause is believed to be at this time, informing them that an engineer is onsite working on the issue and also that we are working alongside any relevant external parties. The communication should include the expected resolution time or the time of the next update. If an estimated resolution time cannot be provided then Communications must state this and so that customers can initiate their relevant Business Continuity Procedures if required
18. The Escalation Manager informs the Priority 1 Notifications distribution list & System Owner on the root cause analysis and progress updates
19. The Escalation Manager assesses the complexity of the Priority 1 in question and if necessary raises a Lessons Learnt Document
4.5 Every 1 hour Until Resolved 20. The Lead Technical Specialist updates the Incident Owner of the latest
information on Site/Service issue. The Incident Owner updates the Master Incident Record and informs all Service Desk Engineers to assign any additional incidents that relate to this incident into the Master Incident or Problem record
ICT Priority 1 Incident Handling Policy
Version 1.0 October 2016
7
21. The Incident Owner liaises with all involved 3rd parties on what the latest updates are. The Incident Owner Discussing ETA’s and escalates the incident both internally and externally where required. The Incident Owner should immediately inform the Escalation Manager if timescales are insufficient or the incident has stagnated
22. If there is a significant difference in information known and Incident content since the last update, the Incident Owner immediately updates the Incident and all associated items
23. The Escalation Manager emails the Priority 1 Notifications distribution list & System Owner providing the latest updates on the incident so that all public facing staff have the latest relevant up to date information. Information should be given as:
i. Internal Only (potentially sensitive information) ii. External (what users need to know)
24. The Escalation Manager updates any relevant external news items such as the
Trusts intranet with latest information and incident content updates.
4.6 Post Incident Handling The Escalation Manager is responsible for setting up a post Priority 1 Incident meeting to discuss the Lessons Learnt Document if one was raised, the meeting can be a Telephone Conference call if a face to face meeting is not required. If no problems were encountered during the Priority 1 timeline then this meeting can be only a few minutes. The people below are required to attend such meetings:
ICT Operations manager
ICT Services Manager
ICT Service Delivery Manager
ICT Technical Support Team Leader
ICT Network Manager
Escalation Manager
Lead Technical Specialist
Incident Owner
Any other IT associated staff required
ICT Priority 1 Incident Handling Policy
Version 1.0 October 2016
8
4.7 Priority 1 Escalation Flowchart in Hours
Priority 1 Escalation Flowchart In Hours
Within 10 Minutes Within 30 Minutes Within 45 Minutes
Esca
latio
n
Ma
na
ge
rIn
cid
en
t O
wn
er
Te
ch
nic
al
Sp
ecia
list
He
lpd
esk
Every 60 Minutes Thereafter
Alert Helpdesk
Engineers
Contact/Ascertain
Associated Users
and send out
P1Email to Dist
List
Contacts
Relevant
external
Providers
Incident Owner receives update from
Technical Specialist
Incident Owner liaises with all involved and
ensures Master Incident is accurate and up to
date sending comms where needed
Technical Specialist attempts
remote Diagnosis Resolution
Technical Specialist Investigates
root cause and cascades
Technical Specialist
updates incident owner of
latest Information
Escalation Manager Prepares
Initial Comms
Inform P1
Distribution list
and System
Owner
Escalation Manager
Cascades
information internally
to keep all updated
Escalation Manager
updates external news
items with latest
information
Inform Managers,
Technical
Specialists of Issue
Assess
Complexity and if
necessary raise
Lessons Learnt
ICT Priority 1 Incident Handling Policy
Version 1.0 October 2016
9
4.8 Impact and Urgency Matrix
ICT Priority 1 Incident Handling Policy
Version 1.0 October 2016
10
4.9 Call Logging Standards
5.0 Procedures connected to this Policy There are no standard operating procedures currently connected to this policy. 6.0 Links to Relevant Legislation The Data Protection Act 1998 The Act came into force in 1984 and was updated in 1998. The Act sets out rules for people who use or store data about living people and gives rights to those people whose data has been collected. The law applies to data held on computers or any sort of storage system, even paper records. The law covers personal data such as your address, telephone number, e-mail address, job history etc. The main principles of the Act are: - If you collect data about people for one reason, you must not use it for a
different reason; - You must not give people's data to other people or organisations unless they
agree;
ICT Priority 1 Incident Handling Policy
Version 1.0 October 2016
11
- People have the right to look at data that any organisations store about them; - You must not keep the data for longer than you need to and it must be kept up
to date; - You must not send the data to places outside of the European Economic Area
unless adequate levels of protection exist; - Organisations that store data about people must register with the Information
Commissioner’s Office; - If you store data about people you must make sure that it is secure and well
protected; - If an organisation has data about you that is wrong, then you have a right to ask
them to change it The Computer Misuse Act 2000 The Act is a law first introduced in 1990 to try to fight the growing threat of hackers and hacking. The law has three parts, it is a crime to: - Access a computer without permission
there must be intent to access a program or data stored on a computer, and the person must know that this access is not authorised. This is why login screens often carry a message saying that access is limited to authorised persons: this may not prevent a determined and ingenious hacker getting access to the system, but they will not be able to claim ignorance of committing an offence
- Access a computer without permission, with intent to commit a further offence there must be intent to access a program or data stored on a computer, and the person must know that this access is not authorised. This is why login screens often carry a message saying that access is limited to authorised persons: this may not prevent a determined and ingenious hacker getting access to the system, but they will not be able to claim ignorance of committing an offence
- Change, break or copy files without permission Altering data as in the case of a nurse who observed a doctor entering his password and used it to alter patients' drug dosages and treatment records Removing data for instance to cover up evidence of wrongdoing Adding to the contents of a computer for instance it has been held that sending an email under a false name results in unauthorised modifications to the content of the mail server
The intent need not be directed at any particular computer, program or data, so this provision covers damage caused by computer viruses - even though the virus author need not have known or intended that any particular system would be affected.
6.1 Links to Relevant National Standards There are no relevant national standards linked to this policy.
6.2 Links to other Key Policies
ICT Change Control Policy The purpose of this policy is to mitigate any risks associated with implementation of changes to the Trust eHealth systems. ICT E-mail and Internet Acceptable Use Policy The purpose of this policy is to clearly define the acceptable usage and standards that apply to all Trust and NHS e-mail and internet Systems by employees and all
ICT Priority 1 Incident Handling Policy
Version 1.0 October 2016
12
other sponsored/ authorised individuals. ICT Remote Access Policy The aim of this policy is to set out the security measures, practices and restrictions in place to minimise the risks for connecting to Black Country Partnership NHS Foundation Trust’s internal network from external hosts via remote access technology, and/or for utilising the Internet for business purposes via third-party Internet service providers.
ICT Portable Devices and Portable Media Security Policy The aim of this policy is to ensure the security of the Black Country Partnership NHS Foundation Trust portable data devices. ICT Telecommunications Policy The purpose of this policy is to set out the key principles regarding the use of Telecommunications equipment within the Trust. ICT Security Policy The purpose of this policy is to provide management direction, support and outline how information security is managed throughout the Trust. The approach adopted conforms to ISO standard 27000, specifically relating to Information Security Management Systems (ISMS). The policy also aims to develop a positive culture of information security throughout the Trust.
ICT Priority 1 Incident Handling Policy
Version 1.0 October 2016
13
7.0 Roles and Responsibilities for this Policy
Title Role Key Responsibilities
ICT Staff Adherence - have a responsibility to familiarise themselves with this policy and adhere to its principles
- ensure they understand their responsibilities for priority 1 incidents and be accountable for their actions - compliance with all Trust policies is a condition of employment and a breach of this policy may result in disciplinary action
- any breaches or incidents relating to this policy and area of practice are reported on DATIX, the Trust’s electronic incident
reporting system - if a member of staff has concerns about the way this policy is being implemented or about this area of practice in general,
they should raise this with their line manager. If they feel unable to raise the matter with them, he/she may write to an Executive Director. If they feel unable to raise the matter with an Executive Director, he/she may write to the Chairman or
a Non-Executive Director. If he/she is unsure about raising a concern or requires independent advice or support, they can
contact:- - their Trade Union representative
- the relevant professional body - the NHS Whistleblowing Helpline - 08000 724 725
ICT Manager
Implementation Lead
- ensure a robust framework is in place so the Trust complies with national legislation and guidance relating to ICT security
- ensure that Groups are fully informed of their role in maintaining the required standards of practice relating to Priority 1 Incidents
- lead on strategies and innovations to improve more secure and efficient methods of mobile technology - policy lead/author of this policy
Information
Governance Steering Group
Scrutiny and Performance
- oversee the governance of information management across the Trust
- receive incidents, breaches and specific issues in relation to the delivery, development and monitoring of ICT information management systems
- review all policies, guidelines and procedures relating to information and ICT security systems
Director of Strategy,
Estates and ICT
Executive Lead
- lead responsibility for the implementation of this policy - allocation of resources to support the implementation of this policy
- Chair of the Trust’s Information Governance Steering Group - any serious concerns regarding the implementation of this policy are brought to the attention of the Board of Directors
ICT Priority 1 Incident Handling Policy
Version 1.0 October 2016
14
8.0 Training
What aspect(s) of this policy will
require staff training?
Which staff groups require this
training?
Is this training covered in the Trust’s Mandatory and Risk
Management Training Needs Analysis document?
If no, how will the training be delivered?
Who will deliver the training?
How often will staff require
training
Who will ensure and monitor that staff have
this training?
n/a n/a n/a n/a n/a n/a n/a
9.0 Equality Impact Assessment Black Country Partnership NHS Foundation Trust is committed to ensuring that the way we provide services and the way we recruit and treat staff reflects individual needs, promotes equality and does not discriminate unfairly against any particular individual or group. The Equality Impact Assessment for this policy has been completed and is readily available on the Intranet. If you require this in a different format e.g. larger print, Braille, different languages or audio tape, please contact the Equality & Diversity Team on Ext. 8067 or email [email protected]
10.0 Data Protection and Freedom of Information This statement reflects legal requirements incorporated within the Data Protection Act and Freedom of Information Act that apply to staff who work within the public sector. All staff have a responsibility to ensure that they do not disclose information about the Trust’s activities in respect of service users in its care to unauthorised individuals. This responsibility applies whether you are currently employed or after your employment ends and in certain aspects of your personal life e.g. use of social networking sites etc. The Trust seeks to ensure a high level of transparency in all its business activities but reserves the right not to disclose information where relevant legislation applies.
ICT Priority 1 Incident Handling Policy
Version 1.0 October 2016
15
11.0 Monitoring this policy is working in practice
What key elements will be monitored?
(measurable policy objectives)
Where described in
policy?
How will they be monitored?
(method + sample size)
Who will undertake this
monitoring?
How Frequently?
Group/Committee that will receive and
review results
Group/Committee to ensure actions
are completed
Evidence this has
happened
All incidents relating to non-compliance and / or
breaches in security arising
from remote access
4.0 Process
DATIX, the Trust’s electronic incident
reporting system
ICT Department
Annually
Information Governance Steering
Group
Information Governance
Steering Group
Reports and Minutes of
meetings
ICT Priority 1 Incident Handling Policy
Version 1.0 October 2016
16
Policy Details
* For more information on the consultation process, implementation plan, equality impact assessment,
or archiving arrangements, please contact Corporate Governance
Review and Amendment History
Version Date Details of Change
1.0 Oct 2016 New policy for BCPFT
Title of Policy ICT Priority 1 Incident Handling Policy
Unique Identifier for this policy BCPFT-ICT-POL-07
State if policy is New or Revised New
Previous Policy Title where applicable n/a
Policy Category Clinical, HR, H&S, Infection Control etc.
ICT
Executive Director whose portfolio this policy comes under
Director of Strategy, Estates and ICT
Policy Lead/Author Job titles only
ICT Manager
Committee/Group responsible for the approval of this policy
Information Governance Steering Group
Month/year consultation process completed *
August 2015
Month/year policy approved February 2016
Month/year policy ratified and issued October 2016
Next review date October 2019
Implementation Plan completed * Yes
Equality Impact Assessment completed * Yes
Previous version(s) archived * Yes
Disclosure status ‘B’ can be disclosed to patients and the public
Key Words for this policy ICT, P1