Risk Register: What It Is & How to Create One

Importance of Risk Registers

A comprehensive risk register allows organizations to get a panoramic view of all the possible risks that could affect their project’s success. By documenting risks up front, teams can prioritize their response strategies based on each risk’s probability of occurrence and severity of impact. This proactive risk-aware approach allows managers to more effectively allocate resources and plan for contingencies, minimizing costly delays and disruptions down the line. To understand this further, let’s have a look at the various risks that can arise in projects.

What’s Included in a Risk Register?

The document typically includes several key components to effectively manage risks throughout a project. These components may vary depending on your project’s specific needs and the preferences of the organization.

They can be divided on the basis of four phases:

Phase 1 – Risk Identification

In this phase, the main objective is to record the identifying components of the different risks you might face, by giving it an ID, a category, a name and a description. Let’s see how you can go about this.

Risk ID

A Risk ID is a unique identifier assigned to each identified risk for easy reference and tracking.

Typically, the Risk ID follows a standardized format or numbering system, allowing project stakeholders to quickly locate and identify specific risks during discussions, reporting, or risk management activities. The ID may include elements such as project phase, Risk Category, and sequential numbering to further categorize and differentiate risks, providing a structured format to organize the risk repository.

Example:

To illustrate, consider the creation of a Risk ID following this structured format:

Therefore, for a project numbered #4321, currently in the design phase, with a Risk Category of Quality (coded as QTY) and a risk number of #12, the resulting Risk ID would be:

Risk Category

Risk Category is the categorization of the type of risk based on its nature (like we previously discussed, risks can relate to schedule, cost, scope, quality, technical, stakeholder or resource).

Example:

As we saw earlier, in the context of the project numbered #4321, currently in the design phase, the Risk Category is:

By categorizing it as a ‘quality’ risk, project teams can immediately recognize that this risk can affect the quality of project deliverables, and their attention is needed on assessing and mitigating it.

This targeted approach allows the team to proactively take risk management steps such as implementing robust quality assurance processes, conducting thorough design reviews, and engaging relevant stakeholders to validate design decisions and requirements.

The table below is an example of how you can reference risk categories:

Risk Name

The Risk Name serves as a concise yet descriptive label for identifying and characterizing specific risks. It succinctly encapsulates the nature or essence of the risk, providing stakeholders with a clear understanding of the potential threat or issue it represents.

Example:

In the context of project #4321, currently in the design phase, a risk associated with the Quality category (coded as QTY) could be:

This Risk Name highlights a potential risk pertaining to inconsistencies, inaccuracies, or errors in the design specifications developed during the project’s design phase.

Risk Description

A Risk Description is a column in the register that provides a clear and concise description of the risk, including its nature, potential impact, and associated factors.

When writing the Risk Description, ensure that you begin by stating the risk event or condition that could potentially occur. This should be a concise statement that clearly identifies the risk. Then explain the potential causes or triggers that could lead to the occurrence of the risk event. This helps stakeholders understand the underlying factors contributing to the risk.

Example:

Consider the risk for which we created a Risk ID in the previous example. The Risk ID was: Design-#4321-QTY-#12, and the Risk Name was “Inconsistencies or errors in the design specifications”. So this is what its Risk Description could look like:

Phase 2 – Risk Assessment

In this phase, we are trying to identify two things – what is the likelihood of the risk occurring as well as the impact it can cause. Once these two factors are identified, the risks can then be ranked based on priority. Let’s see how this can be done.

Likelihood

The likelihood assessment in a risk register evaluates the probability or chance of a risk event occurring within a specified timeframe. This decision is based on the available information, historical data and expert judgment.

Likelihood is often assessed using probability scales, which range from qualitative descriptors (e.g., low, medium, high) to numerical probabilities (e.g., percentages or fractions or ranging from 1-5, with 5 being the highest).

The full scale of likelihood might look something like this:

Example:

Let’s describe the likelihood of the risk – Design-#4321-QTY-#12- Inconsistencies or Errors in Design Specifications as:

The Medium assessment implies that there’s a moderate probability of inconsistencies or errors occurring in design specifications during the design phase of project #4321. Alternatively, the likelihood of inconsistencies or errors in design specifications could be quantified as 3 or a 60% probability of occurrence.

Impact

The Impact assessment evaluates the potential consequences or effects that a risk event could have on project objectives and deliverables, if it were to occur. Typically, impact assessment considers four key aspects:

• Cost: The potential monetary consequences of a risk event on project budgets, expenditures, and financial resources.
• Schedule: The estimated time implications of a risk event on project timelines, milestones, and deadlines, measured in weeks.
• Scope: The extent of changes or modifications required to project objectives, requirements, and deliverables.
• Quality: The degree of deviation from quality standards or expectations resulting from a risk event.

They are also quantified on a severity rating of:

• Low Rating Impacts are manageable within the project’s existing setup, representing a minor setback that does not compromise project objectives.
• Medium-Low Rating Impacts are slightly more than minor setbacks but are still manageable within the project’s current setup. These impacts can be addressed with moderate effort and do not pose an immediate risk to project objectives.
• Medium Rating Impacts are noticeable but manageable within the project’s constraints. They may require some adjustments or reallocation of resources but do not pose a substantial threat to project success.
• Medium-High Rating Impacts are significant and may require considerable attention and resources to be managed effectively. While they are not as severe as high rating impacts, they exceed the project’s current allowances and can potentially disrupt project progress. Immediate action is needed to address these impacts and prevent them from escalating into more serious threats to project objectives.
• High Rating Impacts are significant and exceed the project’s current allowances. These require immediate attention and remedial action. If left unattended, they will jeopardize project objectives.

Example:

For Risk ID: Design-#4321-QTY-#12, this is what the impact assessment can look like:

In this example, “High” is used to indicate the severity level of the cost and schedule impact based on its significance within the project’s budget and resources.

Risk Priority/Ranking

The Risk Priority or Ranking section assigns a relative importance or priority to each identified risk based on the above two properties of potential impact and likelihood of occurrence.

The probability and impact ratings assessed using a scale ranging from 1 to 5 are presented in a matrix format. Both ratings combined, give the Risk Priority, categorized into five bands: Low, Medium-Low, Medium, Medium-High, and High.

Example:

In the case of Risk ID: Design-#4321-QTY-#12, if we consider the cost impact as High (or 5) since the most likely cost is $500,000 and the probability as Medium (or 3), the risk priority ranking comes out as Medium-High (or 15)

Given its medium-high ranking, this particular risk should be closely monitored and managed throughout the project lifecycle.

Phase 3 – Risk Response

In this phase, we decide who will manage the identified risk, what strategy is going to be employed, what mitigation steps will be taken as well as contingency plans in case things go south. Now let’s see each of these components in detail.

Risk Owner

The Risk Owner is the individual or team responsible for managing and mitigating a specific risk identified in the risk register.

Responsibilities of the Risk Owner may include:

• Monitoring the status and progress of the assigned risk
• Coming up with and implementing mitigation strategies and action plans
• Communicating updates and changes related to the risk to stakeholders
• Coordinating with other project team members to address interrelated risks
• Escalating unresolved or high-impact risks to higher levels of management when necessary

Example:

For the Risk ID: Design-#4321-QTY-#12, the Risk Owner would be the Project Manager.

Risk Response Strategy

The Risk Response Strategy outlines the approach adopted to effectively address and manage identified risks throughout the project lifecycle. It encompasses a range of options aimed at mitigating the impact or likelihood of risks, minimizing their negative consequences, or exploiting potential opportunities. Here are the primary risk response strategies and how they can be applied:

Avoidance

Risk avoidance involves taking proactive measures to eliminate the risk or prevent it from occurring altogether. This strategy focuses on altering project plans, processes, or activities to circumvent exposure to the risk entirely. For example:

• If a project faces a high-risk activity that poses significant threats, the project team may choose to redesign the project plan to exclude or minimize the involvement of that activity.
• Avoiding potential conflicts of interest by refraining from engaging with stakeholders having conflicting interests.

Reduction (Mitigation)

Risk reduction, also known as mitigation, aims to diminish the likelihood or impact of identified risks through proactive measures. This strategy focuses on addressing the root causes of the risk or implementing controls to minimize its adverse effects. Examples include:

• Implementing quality control measures to identify and rectify errors in deliverables, reducing the likelihood of defects or rework.
• Enhancing project communication channels and stakeholder engagement to mitigate the risk of miscommunication or misunderstandings.

Transfer

Through risk transfer, the onus of managing the risk is moved to a third-party vendor, such as through insurance, outsourcing, or contractual agreements. By transferring the risk to another party, the project team can mitigate its financial or operational impact on the project. Examples include:

• Purchasing insurance policies to transfer financial risks, such as liability or property damage, to insurance providers.
• Outsourcing specific project tasks or activities to external vendors or contractors, transferring associated risks, such as resource availability or expertise requirements.

Acceptance

Risk acceptance involves acknowledging the existence of a risk and its potential consequences without taking further action to mitigate it. This strategy is chosen when the cost or effort required to address the risk outweighs its potential impact on project objectives. Examples include:

• Acknowledging external factors, such as market fluctuations or regulatory changes, as inherent risks beyond the project team’s control.
• Accepting certain technical risks, such as uncertainties in emerging technologies, as unavoidable aspects of project execution.

Example:

For the example that we’ve been discussing – “Inconsistencies or Errors in Design Specifications” – the most suitable Risk Response Strategy could be Reduction (Mitigation).

Mitigation Actions

Mitigation Actions are the specific actions or measures planned or underway to reduce the likelihood or impact of the risk.

Example:

For the risk of “Inconsistencies or Errors in Design Specifications,” Mitigation Actions may include the following:

• Conduct comprehensive requirements gathering sessions with input from all relevant stakeholders to ensure clarity and completeness of design specifications.
• Establish a robust review and validation process for design documents involving cross-functional teams, to identify and rectify inconsistencies or errors.
• Implement version control mechanisms for tracking changes to the design specifications and ensure alignment with evolving project requirements.
• Foster open communication channels among project teams to address any ambiguities or discrepancies promptly and proactively.

Contingency Plans

Contingency Plans are the backup plans or actions that can be deployed if a risk actually materializes, helping to minimize its impact on the project. These are typically developed for risks that cannot be fully mitigated or controlled through preventive measures.

Example:

Contingency plans for the risk of “Inconsistencies or Errors in Design Specifications” could include:

• Conduct additional reviews and validations of design specifications.
• Engage stakeholders to clarify requirements and address discrepancies.
• Revise design documents as necessary to rectify identified inconsistencies or errors.

Phase 4 – Monitor and Control

The final phase in the document is all about future-proofing the risk. It will give the status of the risk as well as a date when the document was last updated for the said risk. Let’s see both of them with examples.

Risk Status

The Risk Status section provides a concise summary of the current state of each identified risk. Here’s how different statuses may be described:

• Active (Not Started) indicates that the risk is actively being monitored and controlled, but the response plan has not yet been initiated. This status signifies awareness of the risk and ongoing efforts to manage it effectively.
• Active (Ongoing) signifies that the risk is actively being monitored and controlled, and the response plan is currently being implemented. This status reflects proactive measures being taken to address the risk and mitigate its impact on project objectives.
• Active (Complete) denotes that the risk is still being actively monitored and controlled, but all work on the response plan has been completed. This status indicates that the necessary actions have been taken to address the risk, and there’s ongoing monitoring to ensure its effectiveness.
• Dormant (Not Started) indicates that the risk is not currently a high priority but may become active in the future. This status acknowledges the potential for the risk to resurface and highlights the need for continued vigilance and preparedness.
• Retired (Complete) signifies that the risk is no longer a threat to project objectives. This status is assigned once the risk has been successfully mitigated, resolved, or is not relevant for the project anymore.

Example:

The status of the risk “Inconsistencies or Errors in Design Specifications” would likely fall under the category – Active (Ongoing).

Date of Last Update

This date shows when the risk register was last updated to ensure the information is current and accurate. This helps track the history and progress of each risk over time.

Example:

Date of Last Update – January 1st, 2024

The final format, including all of these columns, will look something like this:

Examples of Risk Registers

In this section, you’ll find illustrative examples of entries you can make in a Risk Register across diverse project scenarios. Each example is structured following the typical components we discussed earlier, including Risk Description, likelihood, impact, and mitigation strategies.

Risk Entry for a Construction Project

Scenario: A construction company embarks on a large-scale building project. The risks identified can include adverse weather conditions, supply chain disruptions, regulatory changes, and safety hazards. An example of a risk entry you can make in the register could be as follows:

Risk Entry for a Software Development Project

Scenario: A software development team initiates a new product launch. The risks identified can include scope creep, technical challenges, resource constraints, and cybersecurity threats. An example of a risk entry you can make in the register could be:

Risk Register vs. Risk Matrix

A Risk Matrix is another tool to manage and mitigate risks. However, it differs in various ways: