In the PMI process, they include a document called a Risk Register. It contains a list of all the risks -- realized and unrealized -- including some fields like probability and impact.

For software projects, what kind of fields should we include in a risk register? Mine tend to have: - Risk name - Risk severity (low/moderate/high/terminal) - Risk probability (low/medium/high) - Risk state (eg. accepted, monitor, minimized) - Risk trigger (how do we know this risk occurred?)

What else can you put in there that has value, without creating a huge, bloated documented?

This question is somewhat intended as a community wiki question.

  • Hi I found that a member asked same question in this forum some months ago. Pls use search box to find this questions with comments
    – user1041
    Apr 25, 2011 at 2:59
  • How about a link to that post, please? Apr 28, 2011 at 0:18

7 Answers 7


In addition to all the numerical data (impact, severity, likelihood, etc.), I always include:

  • Minimisation measures: They describe what we do in order to decrease the likelihood of the risk. Knowing that there is a risk and not doing anything to decrease its likelihood is silly.
  • Mitigation measures: They describe what we will do if the risk eventuates. It is good to think about this beforehand, so we can act quickly and from some well thought out base whenever bad things happen.

According to my experience, thinking about and writing down these two pieces of information for each risk is extremely valuable. It helps the project manager (as well as the rest of the team) stay alert and minimise/mitigate the risks as necessary.


Nobody has mentioned it yet (or I read over it), but apart from the risk itself the most important is the risk owner. Who is doing something about it? The PM shouldn't be the only watchdog on a project :-), nor should risk management only be practised by PM's! On the contrary, too many risks assigned to the PM is a sure sign of trouble.

  • I think your absolutely correct about assigning risk to others for them to monitor and/or periodic reporting (reassessment). I've seen companies call a big meeting on day-x of a project in order to define the risks and then it was never looked back on and managed.
    – Jeach
    Oct 23, 2011 at 5:18

A risk database (or register) should contain the following information:

  • Short name: a quick reference title, hopefully unique
  • Risk statement: this statement should thoroughly yet succinctly define the risk. Often people use the if/then structure as a guide. For example: "Lot 2 production will use a new supplier for Part X that does not have an active production line. If the supplier does not pass our quality assurance audit on X-day, then there there will be a day-for-day slip of first article delivery.
  • Risk severity and probability: often these are characterized in a five-by-five, color-coded matrix, where the y-axis represents the likelihood of the risk occurring (1 = highly unlikely, 5 = almost certain) and the x-axis represents the consequence if the risk were to occur (1 = not that bad, 5 = devastating). Often, consequence is assessed against the metrics of cost, schedule and technical (i.e. performance), with the worst rating across all three categories being the one that is assigned. The colors indicate the seriousness of the risk. Your risk database should have objective criteria defined for each level of likelihood and consequence. A helpful comment points out some mathematical rigor can be put behind how the colors are assigned in this matrix. A good synopsis of the canonical paper proves many standard matrices (like the one from NASA below) are misleading.

standard risk matrix Image credit NASA

A colored 5 × 5 matrix consistent with the findings of this paper would look more like this:

better risk matrix

  • Risk disposition: accept (we've decided to do nothing, or that nothing can be done), mitigate (which indicates a plan is in place and action is being taken), transfer (the risk has been transferred to another entity, like a subcontractor), or avoid (eliminate it--in our example perhaps going back to a proven subcontractor)
  • Risk status: active or retired (nothing's ever deleted from the database, in case the historical record is needed)
  • Mitigation plan: for risks being mitigated, this is a plan of the actions that are going to be taken to mitigate the risk, who is responsible for the action, when the action is due, and what the new assessed value of the risk will be when the mitigation step is complete. Mitigation plan steps should decrease the severity and/or likelihood of the risk.
  • Risk owner: the person or organization responsible for maintaining the status of the item in the register, for coordinating the efforts of the mitigation plan (if applicable), for championing the risk (e.g. obtaining funding and attention for dealing with it), etc.

Although this list seems long, in practice most of these fields can be very concise. Even the mitigation plan is probably no more than a sentence or two for each step.

  • Before you pursue PIG (Probability Impact Graphs), you might want to check the research of Tony Cox (e.g.g Louis Anthony (Tony) Cox, Jr., What’s Wrong with Risk Matrices? Risk Analysis, Vol. 28, No. 2, 2008.) and the Society of Information Risk Analysts PIG can be a useful tool, but not one to adopt blindly.
    – MCW
    Jun 3, 2013 at 17:46
  • 1
    I wasn't willing to put down $40 on the paper, but I found a good synopsis of its key points, which makes a very good argument for the colors in the above matrix being bad. Thanks for the advice.
    – Adam Wuerl
    May 16, 2015 at 15:23

In addition to what you have I'd include:

  • What stage(s) in the project the event is likely to occur
  • Impacts on other parts of the project (or other projects)

Besides all the items you mentioned, you should state the time when the risk can start its existence and the time when the risk ceases to exist. This will make it easier to prioritize the risks.


I don't keep a 'register', I keep a risk database that I can generate a risk list from, if I want a list. The problem with a single excel spreadsheet style of risk register, which is the type you encounter frequently on the web is that it is easy to brainstorm & list a bunch of risks, but hard to effectively manage them. I think it's important to have the risk event and event action plan as well as the risk impacts and the impact action plans. These don't have to become a huge, bloated document, but they definitely won't fit into tidy spreadsheet columns either.

The book Proactive Risk Management: Controlling Uncertainty in Product Development by Smith and Merritt has some great examples of how to organize your risks.

  • Agreed that a spreadsheet is hard to manage. Hence why I focus on the top risks -- maybe five to ten of them. Besides, not every project has the budget or facility for a more complicated risk register.
    – ashes999
    Feb 8, 2011 at 14:54

There is an MS-Excel Risk Sheet available for download in this description of the risk management process. It is used by one of the largest software companies in the world :-). This sheet includes the following additional fields:

  • Approach,
  • Appearance Date,
  • End Date and
  • Final resolution.

You may want to replace Appearance Date with Appearance Version in software development projects, so that you can track risks that are still open at some moment of the project or product development cycle.

Affiliation note: I am a member of the ]project-open[ team and might be biased.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.