---
title: Risk Controls
description: For each hazard we identify and record in a hazard log, we identify controls that aim to reduce the likelihood of it occurring. A hazard can have multiple causes and controls. Each control strength is categorised as strong, medium or…
url: "https://www.clinicalinformatics.nhs.scot/playbook/risk-controls/"
updated: "2024-05-27"
category: Approach
---

# Risk Controls

For each hazard we identify and record in a hazard log, we identify controls that aim to reduce the likelihood of it occurring. A hazard can have multiple causes and controls.

Each control strength is categorised as strong, medium or weak. These definitions are based on ISO 14970 and their risk control considerations:

**Strong Controls**

- Inherently safe design and manufacture
  - Designed out cause or parts of the process, making it inherently safer

**Medium Controls**

- Protective measures in the software used or associated processes
  - Designing in protective measures or robust workarounds within the software or parts of the process that limit how a cause can occur

**Weak Controls**

- Information for safety and training to users
  - Providing warning signs or relying on training does help to reduce some risk, however it is reliant on users and their competence

---

Each control type is categorised as existing, additional or potential:

**Existing Controls**

- Currently in place and evidence of their implementation has been provided and verified by the CSC project team
- Controls are taken into consideration for the initial risk scoring of each hazard

**Additional Controls**

- Controls for which evidence has been provided and verified after the initial risk scoring
- Additional controls are taken into consideration for the residual risk scoring of each hazard

**Potential Controls**

- Controls that have been identified but are not implemented, or evidence of their implementation has not yet been provided
- Should be managed by the programme to implement throughout the life cycle of the digital solution

**Partial Controls**

In some instances controls are marked as partial. This can be for two reasons:

- the control has been **partially implemented**
- only **partial evidence** for the control has been provided

Partial controls are not considered as part of the risk scoring until they are fully implemented or evidenced.

**Guidance for Control Evidence**

Acceptable evidence to support the existance of a control may include:

- documents (design, testing, plans, results) that describe potential or existing controls (with version numbers, dates, and authorisers documented)
- a screenshot of the platform, and associated description/document as above
- a narrative description (versioned, dated, authorised) from the product owner(s) of required standards and documentation being in place and satisfactorily in use
- a demo of the control as part of the digital solution