Incident Management

Download PDF:

Summary

This document outlines Patients Know Best’s procedures for detecting, managing, and resolving incidents to minimise risks, protect patient data, and ensure service continuity. It covers reporting and investigating non-clinical incidents, information security vulnerabilities, and data breaches while ensuring compliance with GDPR and the UK Data Protection Act 2018. The plan emphasises prompt incident detection, triage, mitigation, and resolution through defined roles and clear processes. It aims to establish root causes, implement corrective actions, and foster continuous improvement. All incidents are subject to monitoring, reporting, and periodic review to uphold legal, operational, and organisational integrity.

1. Purpose

This document outlines the procedures for detecting, managing, and resolving incidents that may affect Patients Know Best (PKB). The goal is to ensure incidents are handled promptly, reducing risks to patient data and service disruption, and to ensure continuous improvement across all operational areas.

Occasionally things will go wrong and when they do, Patients Know Best is committed to rapidly responding to them, this document covers the process for the reporting and investigation of non clinical incidents, information security weaknesses and vulnerabilities together with the process for analysis and improvement. We aim to establish the causes of incidents, make sure lessons are learnt, enable appropriate actions are taken and suitable improvements are made to minimise any further recurrence.

The implementation of the UK General Data Protection Regulation (UK GDPR) and the Data Protection Act 2018 (DPA 2018) requires organisations to report certain types of incidents to NHS Digital, the Department of Health and Social Care (DHSC) and the Information Commissioners’ Office (ICO) (the supervisory authority).

It is a legal obligation to notify the ICO of personal data breaches of the legislation within 72 hours where there is a ‘high risk to the rights and freedoms of individuals’. The legislation also makes it a legal obligation to communicate the breach to those individuals affected without undue delay when it is likely to result in a high risk to individuals rights.

If you have an incident to report please contact our Incident Response Group (IRG) contact us.

2. Scope

This procedure applies to all PKB staff, contractors, and relevant third-party service providers involved in incident detection, reporting, and management. It covers:

Information Governance (IG), Clinical, and Security risks managed by the Incident Response Group (IRG).
Operational incidents, including system outages, performance issues, and infrastructure disruptions managed by the Engineering team.

3. Definitions

Information Security Vulnerability: A vulnerability in an information system, information system security procedures, or administrative controls that could be exploited to gain unauthorised access to information or to disrupt critical processing.

Information Security Incident: A suspected, attempted, successful, or imminent threat of unauthorised access, use, disclosure, breach, modification, or destruction of information; interference with information technology operations; or significant violation of information security policy.

Information Security Event: An occurrence or change in the normal behaviour of systems, networks or services that may impact security and organisational operations (e.g., possible compromise of policies or failure of controls).

Information Governance Incident: An event involving non-compliance with legal, regulatory, or organisational policies governing data protection and confidentiality. Examples include failure to safeguard sensitive information, mishandling of personal data, or breaches of GDPR requirements.

Clinical Incident: An event that poses a risk to patient safety, clinical outcomes, or the quality of care, often related to errors in data integrity, delays in information access, or system failures that affect clinical decision-making. Examples include incorrect patient data, delayed access to critical records, or miscommunication of clinical information.

4. Roles and Responsibilities

The following roles are responsible for managing incidents at PKB:

First Responder: Acknowledges the incident, initiates triage, and informs the relevant teams.

Incident Coordinator (IC): Oversees the resolution of the incident, ensures communication, and manages escalation.

Scribe: Documents all stages of the incident, including actions taken, lessons learned, and root cause analysis.

Clinical Lead: Evaluates the clinical impact of incidents, including risks to patient safety and care quality.

Communication Lead: Coordinates all internal and external communication regarding the incident. Works with the Incident Coordinator and other stakeholders to create and execute a communications plan that communicates the incident to users, the public, and others affected.

Information Governance Lead: Ensures compliance with data protection regulations and breach notifications.

Support Lead: Monitors and communicates the impact on patients and users.

Technical Lead: Manages system and operational issues, including outages and service degradation.

5. Policy

This policy requires that all users report any perceived or actual information security vulnerability or incident as soon as possible using the contact mechanisms prescribed in this document. In addition, Patients Know Best employ automated scanning and reporting mechanisms that can be used to identify possible information security vulnerabilities and incidents.

If a vulnerability is identified, it will be resolved within the period of time outlined in this policy, based on its severity.
If an incident is identified, it will be investigated within the period of time outlined in this policy, based on its severity.

If an incident is confirmed as a breach, PKB will take all necessary steps to resolve the incident and recover information systems, data, and connectivity. Incident response procedures will be followed to contain, investigate, resolve, and communicate information to employees, customers, partners and other stakeholders and all technical steps taken during an incident will be documented.

Information and artefacts associated with incidents (including but not limited to files, logs, and screen captures) will be preserved appropriately in the event that they need to be used for further investigation to determine if any malicious activity has taken place. The collection of evidence will be managed by appropriate staff members with proper understanding and training in forensic evidence collection. All such information will be preserved and provided to law enforcement if the incident is determined to be malicious.

Incident Lifecycle

Detection and Reporting

Incidents include:

Personal Data breaches of the UK GDPR reported to the Information Commissioner
The Security of Network Information Systems incidents reported to the Department of Health, Social Care and Cyber Security
Incidents reported to NHS Digital and High Severity Service
Incidents relating to Online and Video Consultation Software reported to the NHS Digital Service Bridge

Incidents can be detected through:

IG, Clinical, and Security incidents: These are reported via internal monitoring systems, staff reports, or patient complaints.
Operational incidents: These include system monitoring tools, infrastructure alerts, and customer-reported issues.

All incidents must be reported through the #incident-response Slack channel or via the Incident Response email to PKB’s Incident Response Group. Each report should include:

Date/time of detection.
Affected system or service.
Description of the issue and its potential impact.

Where incidents occur out of hours, we have arrangements in place to ensure Directors or other nominated individuals are informed of the incident and take action to inform and involve the appropriate staff.

Triage and Severity Assessment

All incidents are assessed for the risk, severity, scale and sensitivity of the incident based on all information known at the time. The IRG will reference the NHS Digital Guide to the Notification of Data Security and Protection Incidents as part of this assessment. The most recent version of this document can be found here.

Upon reporting, the Incident Coordinator leads the triage process, assigning severity based on the following criteria:

Severity Level	Impact	Urgency	Escalation Time

Severity Level	Impact	Urgency	Escalation Time
4 - Critical	Total system outage, severe patient safety risk, or large-scale data breach.	Immediate response required.	Escalate within 4 hours.
3 - High	Significant service impact or moderate patient/data safety risk.	Urgent response required.	Escalate within 8 hours.
2 - Medium	Moderate service impact, performance issues, or minor patient/data impact.	Response within business hours.	Escalate within 24 hours.
1 - Low	Minor service impact or low-risk issues without patient or data implications.	Scheduled response within 48 hours.	Escalate within 48 hours.

Breach Assessment

Where the incident is assessed that it is (at least) likely that some harm has occurred and that the impact is (at least) minor, the incident is reportable and full details will be automatically emailed to the ICO and the NHS Digital Data Security Centre. The DHSC will also be notified where it is (at least) likely that harm has occurred and the impact is at least serious.

Severity (Impact)	Catastrophic	5	5	10	15	20 DHSC & ICO (24 hours)	25
	Serious	4	4	8	12	16	20
	Adverse	3	3	6	9	12 ICO	15
	Minor	2	2	4	6	8	10
	No Adverse Effect	1	1	2	3	4	5
			1	2	3	4	5
			Not Occurred	Not Likely	Likely	Highly Likely	Occurred

Likelihood that individuals rights have been affected (harm)

This operates on a 5 x 5 basis with anything other than “grey breaches” being reportable. Incidents where the grading results are in the red are advised to notify within 24 hours.

The Incident Coordinator ensures both the Technical Lead and IG Lead assess the relevant aspects of the incident (operational or data-related).

Containment and Mitigation

Depending on the incident type:

For IG, Clinical, and Security incidents: The IRG team takes immediate steps to secure unauthorised access, initiate data recovery, and preserve evidence.
For Operational incidents: The Technical Lead and Engineering team isolate the affected systems and restore services.

The Incident Coordinator coordinates between teams to ensure that appropriate actions are taken swiftly.

Resolution

The resolution process involves:

Mitigation: Reducing the impact of the incident by restoring affected systems and protecting the integrity of data.
Communication: Ensuring all stakeholders are updated throughout the incident via Slack, Jira, and status pages for operational incidents.

Once resolved, the incident moves to postmortem review.

Communication

The Communication Lead, working with the Incident Coordinator, ensures that:

Internal communications: Updates are provided regularly via Slack and Confluence to keep teams informed.
Customer-facing communications: Notifications for data breaches are sent to regulatory bodies and individuals when necessary. Affected customers are kept informed of progress.

The engineering team ensures that updates for operational incidents are shared on PKB’s status page.

Postmortem and Continuous Improvement

After the resolution, a postmortem review is conducted to analyse:

Root cause analysis: Identifying the underlying cause of the incident and areas for improvement.
What worked well and what could be improved.
Action items: Preventative measures to reduce the risk of recurrence.

The Scribe ensures all documentation is completed, and tracks any follow-up actions.

Closure

Once all postmortem actions are completed and verified, the incident is closed. The Incident Coordinator ensures all steps have been documented in the tracking system, and lessons learned are shared with relevant teams.

Confidentiality and Data Protection

All incidents involving personal data breaches must be reported in compliance with PKB’s Information Security and Data Protection Policy and the UK General Data Protection Regulation (UK GDPR). The IG Lead is responsible for ensuring compliance with legal and contractual obligations, including notifying regulators if necessary.

6. Monitoring and Enforcement

The processes surrounding incident response in Patients Know Best are periodically reviewed and evaluated for effectiveness. This involves appropriate training of resources expected to respond to incidents, as well as the training of all staff regarding Patients Know Best's expectation for them, relative to incident reporting responsibilities. Failure to report information security incidents shall be considered to be a security violation and will be reported to Human Resources/People for disciplinary action.

The incident response plan is reviewed annually.

Appendix A: Guide to the Notification of Data Security and Protection Incidents

Incidents are categorised under:

Confidentiality Breach - unauthorised or accidental disclosure of, or access to, personal information.
Integrity Breach - unauthorised or accidental alteration of personal information.
Availability Breach - unauthorised or accidental loss of access to, or destruction of personal information.

Confidentiality

Confidentiality
Data sent by email to incorrect recipient	Emails containing personal information sent to an incorrect recipient.
Not using BCC when sending email	Not using blind copy (bcc) in emails resulting in sharing of personal email address without consent.
Information sent by unsecure email	Personal or clinical information sent via unsecure email method, e.g. unencrypted.
Disclosure of access details	Sharing log-in details and passwords.
Unauthorised access or disclosure	Disclosure of information to a third party who is not entitled to receive it. Wilful unauthorised access to, or disclosure of personal information without consent.
Integrity
Accidental alteration of information	A record changed in error.
Malicious alteration of information	To deliberately change / alter a record.
Security failure of IT systems / equipment	A cyber incident which changes the quality of information, e.g. accuracy, reliability.
Availability
Information uploaded or recorded to incorrect record	Leading to potential harm as information is not available in the right place at the right time.
Corruption or non-recoverable information loss	Avoidable or foreseeable corruption of information or an issue which otherwise prevents access which has quantifiable consequences for the affected individuals. e.g. Corruption of a file which renders the information inaccessible. Inability to recover a file as its method or format of storage is obsolete. Loss of a password, encryption key or the poor management of access controls leading to the information becoming inaccessible.
Loss or theft of device	Loss of information contained on portable devices which may include: Laptops. Mobile Phones. USB memory sticks. Servers. Hard Drives.
Insecure disposal of electronic / IT equipment	The failure to dispose of hardware containing personal information using appropriate technical and organisational means, which may include: Failure to securely wipe information prior to destruction. Failure to securely destroy hardware to appropriate industry standards, Resale of equipment containing retrievable personal information. Third party contractor failure to meet requirements for the safe removal, destruction, sale, recycling of personal information.

Appendix B: Incident Template

Name of Incident:
Reporter:
Incident opened:
Incident closed:

Incident checklist

Identify environments affected:

Communicate incident:

Post internal update

Flag to Clinical Risk team if patients have been potentially or actually affected physically or psychologically

Flag with Comms if multiple customers or a high volume of patients are affected

Contact information

Name of organisation(s) affected:
Has the matter been reported to affected organisations and/or authorities? Add contact information
Organisation incident reference number:
PKB reference:
Supporting documents:

Priority

PKB’s incident priority is the overall impact of the incident on the business. The current scale is 4-1 (High to Lowest). Priority at PKB encapsulates both Priority and Severity in one assessment

Classification level of the information involved:

Priority:

Issue description

Write a summary of the incident in a few sentences. Include what happened, why, the severity of the incident and how long the impact lasted.

Describe the project/programme and information involved, and, if applicable, the name of the specific programme

Investigations

Who responded to the incident? When did they respond, and what did they do? Note any delays or obstacles to responding.
Describe how the service was restored and the incident was deemed over. Detail how the service was successfully restored and you knew how what steps you needed to take to recovery

Impact

Estimated impact level: (any compromise or disruption to service?)
- Describe how the incident impacted internal and external users during the incident. Include how many support tickets were raised.
- Specify the impacted organisations and whether they have since had the issue resolved.

Timeline

Detail the incident timeline. We recommend using UTC to standardise for timezones.
Include any notable lead-up events, any starts of activity, the first known impact, and escalations. Note any decisions or changed made, and when the incident ended, along with any post-impact events of note.

Mitigations

Describe the corrective action ordered to prevent this class of incident in the future. Note who is responsible and when they have to complete the work and where that work is being tracked.

Root cause analysis

Note the final root cause of the incident, the thing identified that needs to change in order to prevent this class of incident from happening again.

Postmortem

Document lessons learned from the incident. Include what went well, what could have been improved, and any gaps in processes or communication. Identify actionable steps for improvement and assign owners and deadlines to ensure follow-through. Ensure this analysis contributes to preventing similar incidents in the future.

Security incident information

Computer Network Defence Incident Type (if applicable)
Malicious code (Worm, virus, trojan, backdoor, rootkit, etc.):
Known vulnerability exploit (List the Common Vulnerabilities and Exposures (CVE) number for known vulnerability):
Disruption of service:
Access violation (Unauthorised access attempt, successful unauthorised access, password cracking, etc.):
Accident or error (Equipment failure, operator error, user error, natural or accidental causes):
If the incident resulted from user error or malfeasance, reasons (training, disregard for policy, other) and responsible parties:
Additional details:
Apparent Origin of Incident or Attack:

Appendix C: Reportable Incidents

Incidents reportable to the Information Commissioners’ Office and/or the Department of Health and Social Care will be included in our Annual Report in the below format:

Summary of Data Security and Protection Incidents reported to the ICO and/or DHSC

Month of

Incident

Nature of Incident

Numbers

Affected

Number of Patients Informed

Lessons Learned

Revision History

Version	Date	Approver

Version	Date	Approver
2.0	11/10/2024	David Grange - Head of Information Governance
1.0	27/12/2019	David Grange - Head of Information Governance