UCL Research Data Information Security Management System Risk Assessment and Treatment Procedure #

Document Name: RISM04-Risk_Assessment_and_Treatment_Procedure

Author: Tim Machin

Classification: Public

Version: 4.1

Last Review: 15/04/2025

Last Reviewed by: Finley Bacon

Approved by: OMG

Approved date: 12/03/2025

Review Period: 3 years

Sources: SLMS-IG37

1. Document Overview #

The purpose of this risk assessment process is to identify, evaluate, and manage information security risks in conformity with ISO 27001, ensuring that risks are appropriately mitigated to safeguard the confidentiality, integrity, and availability of information. This procedure applies to all assets, systems, processes, and people within the scope of the organisation’s Information Security Management System (ISMS).

This document covers:

This document addresses the following requirements in the ISO 27001:2022 standard:

Clauses 6.1, 8.2, 8.3

2. Standards and Methods #

The risk assessment will be conducted using a systematic approach to identify and assess risks based on their potential impact and likelihood. Risks are scored using the UCL likelihood and impact ratings and tolerated in line with the UCL risk appetite.

3. Risk Assessment Methodology #

The risk assessment process will consist of the following steps, which are described in more detail in the subsequent sections.

Risk scenario identification
Risk analysis and evaluation
Risk treatment
Risk monitoring and review

4. Risk Identification #

4.1. Risk Scenarios #

This section identifies possible risk scenarios associated with the loss of confidentiality, integrity or availability of the data and Trusted Research Environments in the scope of the Research Data ISMS. The risk scenarios below were identified by the UCL Information Security Group.

1. User deliberately or accidentally leaks information

a user shows something on their screen to a colleague who is not authorised to access the data
a user continues to have access after leaving the research team because their access has not been rescinded
a user exports the wrong set of data or sends data to the wrong recipient

2. User accidentally or deliberately damages information

a user runs a query in a database which deletes records inadvertently and goes unnoticed for a period of time
a user accidentally copies data from the wrong source into a spreadsheet

3. Premises Break-in

an opportunist notices that during a fire drill, the doors are propped open at the data centre
a break-in at a research team’s office provides access to their computers

4. Acts of God, Vandals and Terrorists

problems with drainage cause flooding
flooding risk increase due to climate change

5. Theft or loss of mobile devices

a user’s mobile phone is stolen, unlocked and used to generate a login token

6. Software failure

a software upgrade creates a vulnerability that is not reported or patched in time
a misconfiguration allows unauthorised access

7. Hardware or “infrastructure” Failures

cooling system failure
server component failure

8. Power Failure

problems with the supply of power

9. Internet/Communications Failure

The Janet Network is unavailable, and internet access fails
a change to the UCL network prevents access

10. Hacking

a system administrator’s password vault is hacked

11. Denial of Service

someone orchestrates a DDoS on a technical environment

4.2. Emergent Risks #

An emergent risk is a system, process, policy or organisational risk that a member of the organization becomes aware of. A single, lower level, emergent risk may not affect the overall risk score for a scenario in section 4.1 but may require treatment to ensure there is no incremental increase in risk over time as new risks emerge. Therefore, in addition to the treatment of the high-level risk scenarios, lower-level emergent risks will be recorded, treated and monitored by responsible teams.

Each emergent risk will be recorded, assigned an owner and linked to one or more risk scenarios. To ensure emergent risks are treated as quickly as possible, they will be assessed and given a risk score by the responsible team. Emergent risks will be evaluated using the methodology below and treated by the responsible team if the risk score is greater than 9. Residual, emergent risks with a risk score below UCL’s risk appetite can be accepted by the Operational Management Group (OMG).

5. Risk Analysis and Evaluation #

In order to understand the baseline risk, the above risk scenarios and emergent risks are given an inherent risk score before any treatment is applied. Risk treatments become controls, or modify existing controls, once they have been implemented.

Controls include any modification of technology, operations or management within the organisation that reduces risk. Risk scoring uses the methodology described in the Information Risk Assessment – Likelihood and Impact Ratings document maintained by the UCL Information Security Group.

Once risks are scored, they are evaluated against UCL’s risk appetite, which serves as the risk acceptance criteria. Where a risk is considered intolerable or severe (i.e. they are above the risk appetite), additional controls will be considered as part of risk treatment.

6. Risk Treatment #

The Risk Treatment Process identifies controls that could mitigate or eliminate the identified risks, as appropriate to the organisation’s operations. The aim of the recommended controls is to reduce the level of risk to the organisation and its data to an acceptable level. The following factors should be considered in recommending controls and alternative solutions to minimise or eliminate identified risks:

Effectiveness of recommended options (e.g. system compatibility)
Legislation and regulation
Organisational policy
Operational impact
Safety and reliability

Low-cost recommendations will be approved and implemented by the affected teams and documented in the Emergent Risk record. Where additional resource is required to implement controls a cost benefit analysis (in the form of a business case) will be used to apply for funding.

The controls may include technical, operational, and management controls.

Technical controls (e.g. built-in or add-on security product that supports identification and authentication, discretionary or mandatory access control, audit, residual information protection, encryption methods)
Operational controls (e.g. personnel security, contingency, and resumption and recovery operations, system maintenance, off-site storage, user account establishment and deletion procedures, controls for segregation of user functions, such as privileged user access versus standard user access)
Management controls (e.g. rules of behavior, security planning, education and training)

The Risk Treatment Plan is the full schedule of identified risk(s)-to-selected control(s). The effectiveness of the Risk Treatment Plan should be considered and used to assess the likelihood and impact ratings of the residual risks, post-treatment.

The output of this analysis forms the Information Security Risk Statement, which is presented by the Operational Management Group (OMG) to the Information Risk Governance Committee at least once per year or following a change in the level of risk.

This Risk Assessment and Treatment procedure requires that new, intolerable risks must be taken to IRGC for consideration at the earliest opportunity. IRGC can request additional resources from Change and Digital Committee if further risk treatment options are available but not resourced, or it can choose to accept and monitor the risk.

With appropriate resources secured and agreement from IRGC, the Risk Treatment Plan is then operationalised by the affected teams.

IRGC is responsible for deciding whether to accept residual risks where the level is determined as either Severe or Intolerable. This may happen if there are intolerable risks faced by the University with a higher priority.

7. Risk Review and Monitoring #

Risks will be monitored by IRGC and will be re-assessed by OMG annually or following an incident, non-conformity or significant change.

In cases where an intolerable risk has been accepted, acceptance of the risk must be reviewed by IRGC every term. Accepted, severe risks must be reviewed annually.