1. Home
  2. Training Library
  3. Risk management life cycle and treatment [CISMP]

Risk register

Risk register

Before you explore exactly what a risk register is, you're going to take a look at how it can help us, and also at the Turnbull Report, which helped establish the risk register best practice.

Reasons for a risk register

A risk register seeks to achieve several objectives:

  • They permit all risks identified in the risk assessment process to be documented in a formal manner, sometimes a legal requirement.
  • They allow an authorised observer (e.g. an auditor) to have visibility of the impact and likelihood of the risk and all the associated details, and to assess the suitability of the responses selected.
  • They allow ongoing monitoring of the status of the risk and can be used as management reports on the progress of risk mitigation and of any variation in the risks.

Published in 1999 and later updated in 2005, the Turnbull report established best practice for UK listed companies to deal with risk management and internal controls and their obligations with regard to both under the Combined Code on Corporate Governance. It also served as guide for companies who needed to compile a comprehensive risk register.

It sets out best practice on internal control for UK listed companies, primarily focused on financial aspects, ensuring they have good audits and checks to ensure the quality of financial reporting and catch any fraud before it becomes a problem.

Decorative image: Risk register: person using calculator while writing in notebook 

What's in a risk register?

A risk register (also known as a register log) is a tool commonly used in risk management and project management. It’s created on the early stages of a project. It’s an important document in your risk management plan and serves to identify potential risks in a project or an organisation and it helps you record and track issues and address problems as they arise.

Generally, a risk register is shared between project stakeholders. It allows all of those involved in the project to be kept aware of issues and as well as providing a means of tracking the response to those issues. It can also be used to flag new project issues and also to give suggestions on what course of action is suitable to solve them.

A risk register should contain as a minimum:

  • The details of the threat
  • Its assessed impact and likelihood
  • The overall risk evaluation calculated from these
  • The recommended treatment (accept or tolerate, avoid or terminate, reduce or modify, transfer or share) and the actual action(s) to be taken
  • The person or department responsible for carrying out this work and the date by which it is expected to be completed

Other fields may also be included, but those listed above form the basic minimum information required of a risk register. It is common practice to review and update the risk register at intervals, typically, monthly or quarterly.

Risk register examples

Here in Figure 1 are the two examples, you’ve already looked at as they might appear in a typical risk register. You’ll see that columns for 'Risk Owner have been added.

In the first example, the risk owner has stated that the cost of running annual testing is excessive.  Even though they understand that the risk remains at a rating of high, they have accepted the risk. This is a brave decision, but is valid, if they have the authority to make this decision.

This example illustrates the need to balance the cost of implementing security controls against the cost of potential losses. It requires the organisation taking a conscious decision to accept the risk, which should be documented.

In the second example, treatment cannot be made so a medium impact has been accepted for the time being. Once course has gone live, treatment can be made, and risk reduced to ‘low’ status.

Figure 1: Risk register

Decorative image:Risk register tables showing: Issue, Threat,Impact,Likelihood,Risk,Risk treatment, Treated, Risk Owner, Treated Risk. In example 1, Table shows that business continuity plans are not being tested, the risk is being accepted and after treatment remains high. In example 2, Table shows that the websites development was revealed within HTML meta tags, there is no time to treat risk before system goes live, so risk remains medium (but can be reduced to low once treated).

What's next?

Next, in the summary, you can revise the key points of this Learning Path.


In this course, you'll be examining the risk management life cycle and treatment, you'll learn about qualitative and quantitative methods as well as risk register and asset classification.

About the Author
Learning Paths

A world-leading tech and digital skills organization, we help many of the world’s leading companies to build their tech and digital capabilities via our range of world-class training courses, reskilling bootcamps, work-based learning programs, and apprenticeships. We also create bespoke solutions, blending elements to meet specific client needs.