To learn more about EpiX Analytics' work, please visit our modeling applications, white papers, and training schedule.
Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


  • Date the register was last modified

  • Name of risk

  • Description of what the risk is

  • Description of why it would occur

  • Description of factors that would increase or decrease its probability of occurrence or size of impact (risk drivers)

  • Semi-quantitative estimates of its probability and potential impact

  • P-I scores

  • Name of owner of the risk (that person who will assume responsibility for monitoring the risk and effecting any risk reduction strategies that have been agreed)

  • Details of risk reduction strategies that it is agreed will be taken (i.e. strategy that will reduce the impact on the project should the risk event occur and/or the probability of its occurrence)

  • Reduced impact and/or probability of the risk given the above agreed risk reduction strategies have been taken

  • Ranking of risk by scores of the reduced P-I

  • Cross-referencing the risk event to identification numbers of tasks in a project plan or areas of operation or regulation where the risk may impact

  • Description of secondary risks that may arise as a result of adopting the risk reduction strategies

  • Action window - the period during which risk reduction strategies must be put in place


A risk register should include a description of the scale used in the semi-quantitative analysis, as explained in the section on P-I scores. A risk register should also have a summary that lists the top risks (ten is a fairly usual number but will vary according to the project or overview level). The "top' risks are those that have the highest combination of probability and impact (i.e. severity), after the reducing effects of any agreed risk reduction strategies have been included. Risk registers lend themselves perfectly to being stored in a networked database. In this way, risks from each project or regulatory body's concerns, for example, can be added to a common database. Then, a project manager can access that database to look at all risks to his or her project. The finance director, lawyer, etc. can look at all the risks from any project being managed by their departments and the chief executive can look at the major risks to the organization as a whole. What is more, head office has an easy means for assessing the threat posed by a risk that may impact on several projects or areas at the same time. "Dashboard' software can bring the outputs of a risk register into appropriate focus for the decision-makers.