Risk register

Espa├▒ol - Italiano

The purpose of the risk register is to record information about identified risk events. The amount of information that needs to be recorded will depend upon the context of the work.

In its simplest form (in a small self-contained project) the register will be a list of risk events and the results of qualitative analysis. A much more sophisticated risk register will be designed to enable aggregations across multiple projects and programmes. It will also record, or cross-reference to, more specialised documentation showing quantitative analysis of general uncertainty (e.g. Monte Carlo analysis or sensitivity analysis).

A general structure for the risk register will follow the risk management procedure. The fields used within that structure will be selected from those described below. (Note: the procedural headings would not normally appear in the risk register)



  • Identifier
  • Each risk should have a unique identifier. This is primarily used for cross-referencing in reports and supporting documentation.

  • Author
  • The person or entity that identified the risk. In many cases this will be an individual but a programme level risk may have been identified by a project team or a project risk identified by a sub-contractor.

  • Date registered
  • The date the risk was first entered into the register.

  • Category
  • If required by the risk management plan, the register should categorise the risks. There could be multiple types of category, for example, a risk could be categorised as a threat or opportunity and then further categorised as legal, schedule, financial etc.

    This information can be used if it is necessary to review risk by category, e.g. all schedule risk or all regulatory risk. It is also useful post project, programme or portfolio when compiling check lists of risks for use in future risk identification.

  • Description
  • A full description of the risk, possibly following a ‘cause; event; effect’ structure, i.e. what causes the risk, how will the event be observed and what effect would it have?

  • Cross references
  • It is dangerous to consider any document in isolation as all aspects of a project, programme and portfolio are interrelated. Cross references could mark the link between a risk and the relevant product documents or benefit profile that it affects. It could reference a specific activity in a schedule or provide a link between a programme level risk and related project level risks.



  • Probability
  • The probability of a risk occurring will be estimated according to the preferred scales set out in the risk management plan.

  • Impact
  • The impact of a risk occurring will be estimated according to the preferred scales set out in the risk management┬áplan. The areas affected by the risk event should also be noted, typically in terms of scope, schedule and cost, but also (if appropriate) the stage, tranche or business area.

  • Expected value
  • The cost impact of a risk event can be used to calculate an expected value. In the simplest approach the cost impact is multiplied by the probability (assuming probability has been estimated on a numeric scale) to give the expected value. The expected value of more complex risk events may be calculated using tools such as decision trees.

  • Expected value provides a target cost for any response activity and also provides a useful mechanism for quantifying and aggregating overall risk. This can be used as one measure for risk appetite.

  • Proximity
  • The predicted timing of the risk event, should it occur.

  • Assumptions
  • The estimation of probability, impact, expected value and proximity may be based on certain assumptions. For example, the impact of delay in an activity in the schedule may be assessed on the basis that that activity lies on the critical path. It should be noted that the impact will be different, should the schedule change and the activity no longer sits on the critical path.

  • Supporting documentation
  • Risk registers are most suited to recording individual risk events and the results of qualitative risk analysis. For complex risk situations, the fields of the risk register may be inadequate to store all the relevant information. For instance, if a particularly complex risky situation was assessed using a Delphi technique, the detail would not be stored in the risk register, but in supporting documentation.

  • In some cases quantitative analysis techniques may be appropriate. For example, a decision tree may be used to analyse alternative scenarios or Monte Carlo analysis will be used to address general estimating uncertainty of innovative work.

  • These techniques will generate working papers and reports that are important in understanding the overall risk associated with a project, programme or portfolio and should be referenced in the risk register.

  • Other risk related information that may need to be referenced could be financial (risk budgets), schedules (contingency plans) and stakeholder details.

  • Ensuring that all references to risk are located in one place ensures that any risk aggregation, particularly across programmes and portfolios, doesn’t miss anything.


Plan responses

  • Type
  • The type of risk response may be annotated here. The nature of the response will probably be evident from its description but noting the category can aid analysis of overall risk in terms, for example, of how much threat has been transferred or what proportion of opportunity has been exploited.

  • Response
  • The actions chosen in response to the risk event and their effect (e.g. a reduction in probability, impact or both).

    The cost of implementing the response should be estimated to ensure it does not exceed the expected value of the risk itself and that the total cost of risk responses fits within the risk budget.

  • Residual and secondary risk events
  • Despite best efforts to deal with a risk event, the planned response may leave some residual risk or create a new, secondary risk. In some cases this can be covered by explanatory text, in others it may be necessary to create a new risk event with cross-references to the original risk.


Implement responses

  • Owner
  • The person responsible for managing the risk.

  • Actionee
  • The person who will implement the response. This may, or may not, be the same person as the owner.

  • Status
  • A simple statement of whether the risk event is active (default situation) or closed. A risk event may be closed if its probability or impact has greatly reduced (and it has been accepted), work has progressed beyond the cause of the event or it occurred and has been dealt with.

11th April 2017Templates added

Risk register

Back to top