Risk Register - Introduction

Risk Register Template

The Risk Register is the document containing the results of the qualitative risk analysis, quantitative risk analysis, and risk response planning. The risk register details all identified risks, including description, category, cause, probability of occurring, impact on objectives, proposed responses, owners, and current status. It is a spreadsheet containing all the statements of risk identified for the project.

The risk register is developed and maintained in accordance with Public Services and Procurement Canada (PSPC) risk management policies and standards.

The Risk Management Knowledge Area provides guidance on risk management processes and tools.

Risk Register Template

Risk Register

Table Summary

Section 1: This table describes detailed information about risks, project management team decisions, tracking and control, and risk closure.

Section 1: Risk Information
Risk # Date Opened Risk OPI Risk Description Risk Category Probability Impact
(#) (dd-mm-yy) (Name) H M L H M L
             
             
             
Table Summary

Section 2: This table describes detailed information about risks, project management team decisions, tracking and control, and risk closure.

Section 2: Project Management Team Decision
Risk Treatment Strategy Priority
(A)ccept, (M)itigate, (T)ransfer, (E)liminate H, M, L
   
   
Table Summary

Section 3: This table describes detailed information about risks, project management team decisions, tracking and control, and risk closure.

Section 3: Tracking and Control
Risk Management Plan Risk Status
(O)pen (C)losed
   
   
Table Summary

Section 4: This table describes detailed information about risks, project management team decisions, tracking and control, and risk closure.

Section 4: Risk Closure
Date Closed Issue # Lessons Learned
(dd-mm-yy) (#)
     
     

Definition

Table Summary

This table describes the columns heading and descriptions in the project risk log template.

Column Heading Description
Risk # The unique number of the risk being documented and managed. # is assigned by the Project Manager or delegated Risk Manager.
Date Opened Date when the risk is identified and OPI is assigned.
Risk OPI Name of the person assigned to develop, implement and manage the risk response plan.
Risk Description A brief description of the risk.
Risk Category Category or group to which the risk belongs. E.g. Business, Application, Project Management Process, etc. See Taxonomy worksheet for more examples.
Probability (H)igh = >75% chance of occurring. (M)edium = 25 to 75% chance of occurring. (L)ow = <25% chance of occurring.
Impact Impact of the risk: (H)igh, (M)edium, (L)ow.
Risk Treatment Strategy (A)ccept: take no action as risk probability and impact are low. (M)itigate: take steps to reduce the probability and/or impact of the risk. (T)ransfer: assign the risk to an external body outside of the project. (E)liminate: take steps to completely eliminate the risk.
Priority (H)igh, (M)edium, (L)ow.
Risk Management Plan Brief description of the Risk Management Plan to be implemented to manage the risk.
Risk Status Open = Risk is being managed. Closed = Risk is no longer being managed.
Date Closed Date the risk is closed.
Issue # If a risk is realized, most often, it becomes an issue. If it becomes an issue, the risk is closed and is recorded in the Issue Log. Record the associated issue # here. Risks that become issues remain in the Risk Log.
Lessons Learned Yes or No: were lessons learned from the management of the risk? Optional summary text may be added.

Taxonomy

The following includes some examples of risk categories and risks. These are intended to help during the risk identification stage.

This is not a complete or final list but is offered for suggestion only.

Table Summary

This table describes detailed risks related to product development, project management and project constraints.

A. Product Development Think about risks to the project that may arise from the nature of the product being developed.
1 Requirements Are there risks that may arise from requirements being placed on the product?
 
  • Stability
 
 
  • Completeness
 
 
  • Clarity
 
 
  • Validity
 
 
  • Feasibility
 
 
  • Precedent
 
 
  • Scale
 
2 Design Are there risks that may arise from the design chosen to meet the project's requirements?
 
  • Functionality
 
 
  • Difficulty
 
 
  • Interfaces
 
 
  • Performance
 
 
  • Testability
 
 
  • Hardware constraints
 
 
  • Non-development software
 
3 Code and Unit Test Are there risks that may arise from the method chosen to subdivide the design and construct the pieces?
 
  • Feasibility
 
 
  • Testing
 
 
  • Coding/implementation
 
4 Integration and Test Are there risks that may arise from the way the project team is choosing to bring the pieces together and prove that they work as a whole? Examples of risk areas: hardware and software support facilities; integration of parts of the product; integration with the larger system.
 
  • Environment
 
 
  • Product
 
 
  • System
 
5 Non-Functional Attributes (formerly : Functional Attributes) Are there risks that may arise from special attributes of the product?
 
  • Maintainability
 
 
  • Reliability
 
 
  • Safety
 
 
  • Security
 
 
  • Human Factors
 
6 Development Process Are there risks that may arise from the process being used to develop the product?
 
  • Formality
 
 
  • Suitability
 
 
  • Process control
 
 
  • Familiarity
 
 
  • Product control
 
7 Development System Are there risks that may arise from the hardware and software tools being used to control and facilitate the development process?
 
  • Capacity
 
 
  • Suitability
 
 
  • Usability
 
 
  • Familiarity
 
 
  • Reliability
 
 
  • System support
 
 
  • Deliverability
 
8 (Other) Are there other risks that may arise from the nature of the product, but that are not covered by the above categories?
B. Project Management Think about risks to the project that may arise from the way the product is being developed.
1 Project Management Process Are there risks that may arise from: the way the project budget or schedule is planned, monitored, or controlled; management experience; the project's organizational structure; or the way that internal and external organizational interfaces are handled?
 
  • Planning
 
 
  • Project organization
 
 
  • Mgmt. experience
 
 
  • Program interfaces
 
2 Management Methods Are there risks that may arise from the way the development or project personnel are managed? Risks may occur in areas such as status monitoring, personnel management, quality assurance, or configuration management.
 
  • Monitoring
 
 
  • Personnel Mgmt.
 
 
  • QA
 
 
  • Configuration Mgmt.
 
3 Work Environment Are there risks that may arise from the general environment in which the project is found? Risks may arise from areas such as attitude, cooperation, communication, and morale.
 
  • Attitude
 
 
  • Cooperation
 
 
  • Communication
 
 
  • Morale
 
4 (Other) Are there other risks that may arise from the way the project is being developed that are not covered by the above categories?
C. Project Constraints Think about risks to the project that may arise from sources outside the project team's control.
1 Resources Are there risks that may arise because of resources needed for the project that cannot be obtained or maintained?
 
  • Schedule
 
 
  • Staff (HR)
 
 
  • Budget
 
 
  • Facilities
 
2 Contract Are there risks that may arise from the [already legally] binding contract?
 
  • Type
 
 
  • Restrictions
 
 
  • Dependencies
 
3 Project Interfaces Are there risks that may arise from outside interfaces that the project team cannot reasonably expect to control?
 
  • Customer
 
 
  • Associate contractors
 
 
  • Sub-contractors
 
 
  • Prime contractors
 
 
  • Corporate Mgmt.
 
 
  • Vendors
 
 
  • Politics
 
4 Legal or Regulatory Are there risks associated with legal or regulatory requirements?
Privacy Are there risks associated with the privacy of employees, contractors or the Canadian public?
5 Security Are there risks associated with security, protection of assets, documents, data, etc?
6 Other Are there risks that may arise from factors outside the project team's control, but that are not covered by the categories above?