UCL Research Data Information Security Management System Incident Management Procedure #
Document Name: RISM13-Incident_Management_Procedure
Author: Tim Machin
Classification: Public
Version: 1.1
Last Review: 15/04/2025
Last Reviewed by: Finley Bacon
Approved by: OMG
Approved date: 12/03/2025
Review Period: 3 years
1. Document Overview #
This document describes the procedure for dealing with an Incident. An Incident is any event that results in, or could potentially result in (i.e. a near miss) a compromise of the confidentiality, integrity, or availability of an in-scope Environment.
2. Process #
2.1 ISD Incident Management Process #
All incidents, including Trusted Research Environment Severe Incidents, will be addressed using the standard UCL ISD process as described here.
Incident Management Key Stages
2.2 Trusted Research Environment Severe Incident Identification #
The Trusted Research Environment Severe Incident Management process shall be triggered if any of the following conditions are met:
- A confidentiality breach is suspected
- An integrity breach is suspected
- The Environment is completely unavailable
- The Environment is performing significantly slower than normal
- The Environment is unavailable to a significant proportion of users (e.g. ~25% or more)
3. Trusted Research Environment Severe Incident Management Process #
3.1. Roles #
When a Severe Incident occurs, actions to prevent further loss or reduce damage should not be delayed waiting to contact an Environment team member. Once available, an Environment Owner, Developer or Administrator shall take control of managing the response to the incident and act as the Severe Incident Manager. When the situation is stabilised they will prioritise any further efforts and communications.
The Severe Incident Manager will decide whether the incident should be reported as a UCL Critical Incident, Information Security Incident or Personal Data Breach.
3.2. Severe Incident Communication Protocol #
When a Severe Incident occurs, the incident manager shall communicate to the following channels:
| Role | Purpose |
|---|---|
| Information Security Group | In all cases where there is a suspected breach of confidentiality, ISG should be informed. |
| Environment Users | Keep updated on progress for restoring service or in securing data |
| Information Asset Owners and Information Asset Administrators | In cases where there is a suspected breach of confidentiality or integrity the Information Asset Owner and, if applicable, Information Asset Administrator should be informed immediately. They should also be advised to report this, if applicable, to their data providers as soon as possible, adhering to any contractual requirements. |
4. Reporting and Management #
All incidents will be recorded using a log, which will track the progress of the incident from the initial report or occurrence to resolution and review. The following information will be captured in the report and made available for review by the Operational Management Group.
- Timeline of the incident
- Incident Summary
- Response, including any changes made to the environment
- Root cause analysis
4.1. UCL Reporting - Information Security Incidents #
All suspected Information Security Incidents shall be to reported to the Information Security Group.
4.2. UCL Reporting - Breach of Personal Data #
Personal Data Breaches shall be reported via the UCL Data Protection Office.
Report a Breach of Personal Data
5. ISD Service Management Processes #
Environments and supporting services run by UCL Information Services Division are subject to the following processes in addition to the processes outlined above.