View Categories

Risk Controls

2 min read

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