The risk register

The purpose of a risk register is to record details of all risks that have been identified, together with their analysis and plans for how those risks are to be treated. The risk register is an important component of the overall risk management framework. It will include ALL risks - not just operational risks, and can be focused either on the enterprise as a whole, or on specific projects where it is used to maintain the register of project risks over the lifetime of the project.

An example of a risk register, in the form of a table, is shown in Appendix C. This table could be maintained as a simple document in either a word-processing format or a spreadsheet format, but it is more likely to be stored in a database. Each risk entry in the table has a unique identifier to avoid any confusion in cross-referencing risks to other documents.

An important parameter recorded in the risk register is the 'owner' of each risk - the person who owns responsibility for actions relating to that risk. The action plans and status reports may be very detailed, and thus quite unsuitable to be included in a table of this sort. One way to handle this issue is to use the table cells as entries of URLs or hyperlinks where the full documents can be found. This makes navigation of the risk register quick and efficient.

The 'risk type' field records a type such as 'operational', 'strategic', 'reputation', 'credit', 'market', 'liquidity' etc, so as to accommodate many different types of risk in the risk register. A starter list of risk types are given in Appendix B

It is important to record when the risk item was identified and added to the register, when the entry was last updated, and for some items, when they were closed. However, closed items should be maintained for historical analysis purposes, perhaps being transferred to a separate 'closed risks' register table.

Access to the risk register must be controlled to maintain its integrity and confidentiality. Some items recorded in the register may be very sensitive and thus not for wide publication. These confidential items can be 'flagged' by adding an extra field to the table record structure. The integrity of all item entries is also important, so you need a security policy for the register that defines who should be able to update the table and who can read it.